There has been much talk about how smart contracts on the blockchain will revolutionise insurance and reinsurance policies and contract wordings; about how they will be quicker, cheaper, digital, authenticated by nature, pay claims automatically and overall reduce the risk to all parties. The question therefore is, “can a smart contract on a blockchain replace an (re)insurance contract?”.
Back to First Principals
What is a blockchain?
A blockchain is essentially a distributed ledger system. It is distributed in that it exists on many nodes which are replicated and each participant has the ability to change their own account on the ledger. Provided that each participant runs their own node, it removes the need for a trust entity to keep the ledger and make the ledger entries. This is a strength when participants desire or require the removal of the trust entity. However where participants are happy to trust the trust entity, then one of the potential benefits falls away, and the significant downsides of using a blockchain make it much less attractive than using a centralised database system.
What is a smart contract?
A smart contract is a piece of code which is embedded and confirmed into the blockchain where it is immutable. Such smart contracts can make binary decisions on binary inputs, following the logic of the code, which may then for example lead to the automatic execution of transfer of value from one account to another.
Can a smart contract replace a (re)insurance contract?
(Re)insurance contracts are not binary in nature as a smart contract is. A (re)insurance contract confers liabilities and duties on both sides of the contract, all of which must be fulfilled before there can be any payment of any claim. Unlike the financial markets which works on the underlying premise of ‘caveat emptor’ (buyer beware), (re)insurance contract law turns this on its head with the underlying premise of ‘utmost good faith’. When purchasing a (re)insurance contract the cedent/insured must give all the information which is material to the risk being assumed by the (re)insurer, whether it is directly asked for or not. In the event of a claim the (re)insurer can go back and review the information submitted and if there were omissions or if the information was materially incorrect they have the legal right to decline the claim. This type of ‘post-event or post-loss due diligence’ is impossible to program into code, binary or otherwise.
Further (re)insurance contracts are contracts of indemnity – this means that they indemnify the loss suffered, making a financial settlement such as to place the (re)insured back to the same position they were in prior to the occurrence of the loss event. Under an indemnity contract the (re)insured cannot ‘profit’ from the occurrence of the loss (apart from certain clauses which provide ‘new for old’ when replacing items lost). Any insurance loss therefore has to be ‘adjusted’ by an insurer. This means that prior to payment of any claim the insurer will send a loss adjuster to review the loss in order to assess the claim amount to be paid. The claim payment amount is therefore always decided by the insurer. This work is critical to the insurer and any reinsurers protecting the insurer by way of reinsurance, and indeed the ability of an insurer to quicky and accurately adjust claims has a direct impact on the price of their reinsurance.
Given that the claim amount is decided by the reinsurer based on much qualitative work and not merely quantitative work, any smart contract cannot replicate this automatically, or allow a claimant to trigger a smart contract to pay them a claim directly without agreement or direct involvement of the insurer or reinsurer.
Finally all is not necessarily over once a claim has been paid. The (re)insurer who has paid the claim now owns all the rights of the claimant with regards the event that has been indemnified. This includes salvage (the potential future recovery of the property) and subrogation (the legal rights of the (re)insured to claim a recovery from a third party). Again none of this is contained within a smart contract.
Reinsurance Case Study – Avalon Re
A good example which shows why a (re)insured cannot claim directly via a smart contract would be the Avalon Re cat bond. The story of the claim and the workout is more fully described in the blog post Avalon Re Workout. In short OCIL, the sponsor of the Avalon Re cat bond, suffered a claim arising from a steam pipe explosion in Lexington Avenue, New York City which released asbestos into the surrounding area. Con Edison, OCIL’s insured, had a valid claim on the OCIL insurance policy despite the fact that that policy had an exclusion clause for losses involving asbestos. The exclusion did not apply in cases where asbestos contamination arose from an explosion (a so-called ‘write-back’). The reinsurance contract of OCIL which was securitised into the Avalon Re bond however contained a broader and stricter asbestos exclusion clause without this write-back, meaning that the loss, despite the fact that it was caused by an explosion, was not covered by the Avalon Re bond. This did not stop OCIL trying to claim the loss from Avalon Re, and it was only by working through legal channels that Solidum, together a small core of investors, was able to have the claim declined. In this instance a smart contract would merely have paid the loss erroneously and the legal costs of recovery would have been excessive. Given in this one instance the loss amount was USD 135,000,000 the financial quantums involved mean that paying claims cannot be left to a simple computer programme fixed on a blockchain.
Is there a requirement to remove the ‘trust entity’ in a (re)insurance contract
As mentioned above, one of the reasons of using a blockchain is to remove the ‘trust entity’ from transactions/relationships. Any (re)insurance contract is in fact merely a ‘promise to pay’ upon the occurrence of an event. Given the purchaser is buying a ‘promise’ they do de facto trust the insurance or reinsurance company they are purchasing from. If they do not trust the (re)insurer they are purchasing from, they should then not purchase the cover from that entity at all.
Unlike the rest of the financial markets, the (re)insurance market does not fund each $ of risk that they assume, it would never be possible – not enough money exists in the world to do so! (Re)Insurers work on probabilities, the law of large numbers and diversification to calculate and charge a premium that reflects the risk each contract brings to the portfolio such that they can fund all of the losses that are likely to occur during the given risk period. They mutualise all the premiums that they receive and from this pay all the valid and covered losses that occur. This mutualisation of the premium received by a (re)insurer requires that the (re)insurer must control the process and therefore must be trusted to do so.
Using blockchain as an interface between purchasers and sellers in (re)insurance policies makes little sense given that the (re)insurance entity is by necessity a ‘trust entity’. Further to this, purchasers of insurance or reinsurance policies do not want to run their own nodes (or multiple nodes if they buy cover from more than one (re)insurer which is the norm). This would be expensive, highly inefficient and, given most purchasers would actually need a third party to manage their node adds an additional cost layer as well as introducing a new trust entity! Note: whereas the Bitcoin blockchain has never been hacked, the entities hosting nodes have been and that is where people have lost money through theft. This is therefore an increased risk and not a reduced risk.
Centralised databases managed by the (re)insurers are a much superior solution both in terms of efficiency (cost and maintenance) and trust. Insurance companies are large enough to ensure it works and in the unlikely event that there is a problem they are also large enough to assume any financial loss that occurs as a result of the failure, rather than leaving it with their clients.
(Re)Insurance contracts are long complex legal documents with clauses that have been tried and tested through the court system. They are contracts that require legal interpretation, sometimes by the courts where there is a dispute, to be correctly understood and to function correctly. (Re)Insurance is about taking financial risks arising from often unknown risks or unexpected losses arising out of known risks. Smart contracts do not interpret, they merely use binary logic, and they cannot be programmed at all when the details of the potential risks or the exact details surrounding a loss are totally unknown.