Smart insurance contracts
14 February 2019
Smart contracts – electronic contracts performed automatically by computer networks – are one of the most promising areas of insuretech. While the technology is still maturing, businesses across sectors are investing in developing commercially viable smart contract implementations – and insurance is no exception.
Making smart contracts work for insurance
Despite their promise, there is a basic challenge in making smart contracts work for insurance: insurance contracts have to deal with the real world. Smart contract technology emerged from the blockchain revolution and the automated, distributed ledger systems it enabled (such as the Bitcoin blockchain it all started with). In the fully digitised environment of a crypto-currency, the concept of a self-executing computer-enabled contract was not such a great conceptual leap.
But the contractual relationship at the heart of insurance, between insurer and insured, is different: it is premised on the existence of triggers for payment focused on losses. Whether an insurance contract covers house fires, crop failure or medical treatments, none of these exist in the closed system of an online electronic ledger; they exist in the real world, not as yet reduced to ones and zeroes. Building any functional smart contract systems involves a number of technical and legal issues, but the insurance sector presents its own particular hurdle.
Before considering some solutions to this problem, it is worth asking what turns on the answer: why should insurers (and others) be interested in smart contracts? A first answer is that smart contracts are more than just standardised contracts that are entered into online. What distinguishes smart contract technologies from their predecessors is that the performance of the whole contract should be genuinely autonomous. I can, using current technology, validly enter into an insurance contract on an online platform by clicking "I Agree," but in the event of a claim, the processing, assessment and pay-out on that claim will require the intervention of a human agent. The idea of smart contracts is that, once the platform is set up, the human agent is no longer required: everything, from identifying whether an insurable event has arisen, to paying out should flow directly from the smart contract code automatically performing its function.
Code vs contract
Smart contracts purport to create not only automated execution systems, but also to ensure that this automated execution is accompanied by a legal contract that a court would be willing to enforce. Despite the benefits of automation, few insurers would embrace a smart contract model that jettisoned the security of the traditional legal contract. There is a deep question at issue, as to whether a smart contract, which exists as code to be executed by machines, is capable of being at the same time a legal contract, which courts will recognise only to the extent it is expressible in human language.
As with many difficult technical and legal questions, the best way forward is to focus on the simplest cases: a contract that involves only a small number of well-defined, bright-line rules ("Alice will pay Bob $1,000 if there is a Category 8+ typhoon in Hong Kong on X date") will be relatively straightforward to implement both as machine-executable code and as a human language contract. On the other hand, contracts that involve ambiguous, context-specific human language legal concepts such as "reasonableness" or "emotional distress" or, conversely, code that involves complex machine-level interactions with little reference to human-level legal concepts, are in all likelihood impossible to implement as dual code-contract agreements.
Parametric insurance and oracles
One area that lends itself well to smart contracts is parametric insurance – insurance that allows for a specified pay-out if a defined event occurs, such as the occurrence of a natural disaster. The advantage here is that the occurrence of the event is easier to ascertain as a binary, yes-or-no matter than the quantification of a loss. Yet there are challenges which should not be underestimated in turning such real-world events into information inputs that trigger an outcome in a smart contract system. In the jargon of blockchain, these third-party sources of information are referred to as "oracles" and they present a basic problem: if a distributed ledger system is meant to remove the need for trust by decentralising the source of truth, oracles re-introduce the need to trust a designated participant. Of course, there are real-world sources of information that would generally be recognised as trustworthy, such as public sources of weather data for natural catastrophes.
But in the online world, the existence of this kind of input channel also means the introduction of a point of failure: what happens if a malicious actor finds a way of injecting incorrect information into the system, triggering a payment where the relevant event has not occurred in the real world? This is certainly a concern, but not necessarily an insuperable one – careful selection of data sources and implementation of the interface can greatly limit the risk.
A pioneering product and example of this parametric insurance approach is AXA's Fizzy, a blockchain-based product that monitors air traffic databases and automatically processes payments to policyholders if their flight is delayed by two hours or more.
Decentralisation vs jurisdiction
One important issue for decentralised smart contracts systems is that of jurisdiction. If the platform that supports smart contracts is administered by computers in multiple countries, which laws apply to the contracts? Even if the smart contracts expressly select a governing law, will that selection always be valid, given the real location(s) of performance? In a regulated sector such as insurance, where participants will need to know which regulators they are accountable to, this is a critical question. This points towards platforms being deployed in a geographically controlled way: commercial implementations of insurance smart contracts may tend to focus less on geographically open platforms in favour of more modular platforms (such as R3's Corda), which give participants greater control over the parameters of participation and so enable more effective governing law selection.
When the code doesn't work: dealing with disputes
What happens when a smart contract fails? In particular, what happens when the code executes correctly (from a software point of view) but produces an outcome that is different from what the parties intended (a contract is, after all, defined by what the parties intended)? On a truly decentralised platform, it is impossible for a court to step in and compel an outcome other than the one the platform has produced: it is notoriously impossible to retransfer stolen bitcoins unless the thief can be caught and forced to do so.
But smart contracts platforms need not be built like Bitcoin: if it is possible for a smart contract to take an external input (such as in the case of parametric insurance), then it is also possible for a smart contract to take an instruction from a participant such as a notification of a dispute, which could, for instance, cause the performance of the contract to be suspended while the matter is referred to dispute resolution. A judge or – more likely – a specialised smart contracts arbitrator, can then resolve the issue on the basis of the human language contract and reset the smart contract to reflect the outcome of the dispute. Alternatively, where the performance of the contract is something like a simple pay-out, the outcome can be corrected by a real-world refund. There will be trade-offs: a contract which can be "paused" for dispute resolution is not fully autonomous in its performance, but building in dispute resolution functionality which is appropriate for the particular implementation will be key to commercial viability.
Smartening up insurance
Smart contracts technology is still maturing and, despite impressive efforts in the insurance space, smart contracts have not yet replaced traditional contracts to any great extent. This maturation phase is also the sweet spot of opportunity: once a technology reaches a certain point, its deployment can be swift. It was not so long ago that judges and legislators were poring over the question of whether contracts concluded online were indeed contracts – yet today contracts are more often than not entered into at the click of a mouse or the tap of a screen. The challenges of building viable, scalable smart insurance contract platforms are not slight – but neither are the potential rewards. On the longer term, will the process of digitisation and automation that is transforming how we transact in every other sector bypass the ways we enter into insurance contracts? We don't believe so.
This article first appeared in the February 2019 issue of Asia Insurance Review.