Are Smart Contracts Able To Replace (Re)Insurance Contracts In The Future?

Nowadays, there has been much talk about how smart contracts on the blockchain will revolutionize 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 a (re)insurance contract?”.

Back to First Principles

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 trusted entity to keep the ledger and make the ledger entries. This is a strength when participants desire or require the removal of the trusted entity.

However where participants are happy to trust the trusted 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 centralized 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 the 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 work 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 a 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 quickly 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 recovery from a third party). Again none of this is contained within a smart contract.

Conclusion

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.

Centralized 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.