We are now seeing consortia forming in the insurance sector to explore opportunities for the application of blockchain, distributed ledger technology and smart contracts. This makes commercial sense, as there are a number of features of distributed ledger technology which align with general shifts in the consumer insurance sector.
Blockchain-based insurance contracts could provide many practical benefits for the customer experience. Whilst this is good for an insurer's own brand, it may potentially also have the reciprocal benefit of assisting insurers in meeting the FCA's objectives of requiring good customer outcomes and treating customers fairly.
Although there is no legal framework specially designed for blockchain, distributed ledgers or smart contracts, the FCA has recognised that these technologies have the potential to offer genuinely innovative solutions to financial services. To date, legal analysis and commentary on these issues has focused on the theoretical risks and challenges of unregulated, permissionless ledgers and smart legal contracts. However, the underlying technology can be adapted or designed so that the solution fits within the existing legal framework.
In this context, blockchain refers to a new way of connecting different parties on a network, where all members have their own copy of the entire history of all transactions and events that have been logged in a way that can be retrospectively verified, but not altered. Leveraging smart contracts and data privacy, members can create logical workflows to run distributed applications while keeping their private information securely encrypted. The potential result is a very secure system with no single point of failure that could be subject to a cyber security breach in contrast with a traditional centralised database solution.
Smart contracts
The term 'smart contract' has no settled definition, but some of the definitions used include autonomous machines; contracts between parties stored on a blockchain; or any computation that takes place on a blockchain.
While a smart contract may in one sense be viewed as a container of code and data, there is a wide range of possibilities for what that code and data might do. At one end of the spectrum, this code could be a record of contractual interactions that replace the need for a natural language contract. At the other, the code could simply execute agreed business logic based on contractual parameters that are agreed or expressed outside of the code - for example, the execution of a payment obligation.
There is also a range of intermediate possibilities, including a hybrid model, where digitised performance is encoded in computer code with wider contractual terms written in natural language.
One of the main benefits of smart contracts is that data can be encrypted and stored within this container, locked with a private key to which only the user has access. Public keys are then shared to other members on the network to interact and make transactions. As a simple comparison, a public key is similar to an email address while a private key is similar to the password to a user's email account. Smart contracts also provide a way of codifying business process logic into computational logic, so that transactions will automatically self-execute when certain conditions are met.
An insurance use case in seven steps
The below example uses the real-world example of a blockchain marketplace application that connects customers and insurers for home flood insurance, in order to better demonstrate the potential use of blockchain technology in insurance.
A customer types in the website address into her browser exactly as she would with any non-blockchain web application, and signs up to the platform by entering her email address, password and details of the property.
On sign-up, the customer is issued a public and private key, the latter of which is stored securely on her device or in her browser.
At this stage, there is very little difference between a consumer using the blockchain platform as opposed to any other aggregator/insurance quotation platform. Accordingly, the same legal considerations would apply, including data privacy, acceptable use and ensuring the blockchain platform operates in accordance with applicable consumer and e-commerce law; for example, ensuring adequate cookie consent notices where applicable.
In particular, insurance-specific regulation will apply. In the context of a blockchain platform directed at UK customers, the use of blockchain will not water down the need for insurers to comply with Financial Conduct Authority (FCA) and Prudential Regulation Authority (PRA) requirements. These rules and guidance are not currently tailored to the use of blockchain, but insurers using the platform will still need to consider applying best practice and interpreting the FCA's High Level Principles to ensure good customer outcomes.
At the point of sign-up, the customer can be required to agree to terms and conditions applicable to the platform. The terms would govern the consumer's use of the platform and, potentially, the terms and conditions of any products or services procured through the platform.
The customer receives and installs a number of tamper-proof flood detection devices in various locations in her home. These devices each have a hardware-secured private key of their own, a GPS locator, a built-in camera and the ability to detect and send water level information signed using their own private key.
This data is encrypted and stored securely within a smart contact on the blockchain as part of the customer's account, using her device's private key. Unlike a traditional web application, where private customer information is stored centrally in one server by the platform owner, the blockchain shares a perfect, but encrypted, copy of the customer data across each node of the network, resulting in no single point of weakness vulnerable to an attack.
As the customer and her devices hold their own private keys, the platform can even be set up so the platform owner cannot even access her own data, meaning far greater data privacy.
The data uploaded by the customer will, to some extent, constitute personal data. Therefore, it is essential that controls are put in place and the blockchain constructed in such a way as to protect that personal data as required by law. The challenges presented by data obligations are complex and need to be carefully considered.
The customer decides that she wants to receive an offer from an insurance company, and so requests a quote by permitting the insurers on the platform to access her flood detection devices and any personal information that may influence the quote.
Rather than providing only basic information, or too much information that is not relevant to receiving the quote, the customer can dynamically provide permissioned access to only the specific items of data that are relevant, and only for the period of time required by the insurer to return a quote. This can be as simple as a slider option to enable or disable access to certain categories of data.
Additional integrations to third-party data sources may also be in place for KYC [know your customer] or further risk profiling.
The customer either manually selects her preferred quote or, if the platform has been designed to do so, the best quote is automatically selected for the customer based on the preferences and pre-sets she has entered in her profile. The customer then confirms her acceptance of the offer.
The offer is confirmed by the customer signing the transaction with her blockchain private key. This can be done via biometric authentication, such as TouchID on the iPhone, if the private key is stored on the device; or by verification through the customer's browser.
At this point, the customer enters into a legally binding smart contract with the insurer that will self-execute and automatically release payment if verified proof is given that the house has been flooded. A direct debit of the agreed monthly amount is initiated by the smart contract.
Compared to a traditional database, this entire process can take place in seconds rather than after several minutes of entering payment information. If selection of the best quote is automated using smart contracts, then the entire process from providing permission for insurers to viewing customer data to signing the agreement with a private key and initiating the payment could take just a few seconds.
Several months later, the customer's house is flooded. She returns to the platform to see photos captured and water detection data recorded in the blockchain by the connected flood detection device.
The data and images are stored on the blockchain directly by the device, signed by the device's own hardware-secured private key. This time-stamped data, coupled with GPS location including height, provides immutable proof of the water detection event occurring at a certain time and date. The report is only accessible by the specific insurer that requires proof for the claim: no other insurer, customer or even the platform owner can access it.
The traditional non-blockchain model for claims is very slow, resource-intensive and painful for customers, normally requiring several phone calls with a customer support centre.
Automated image analysis, automated analysis of the flood level detector devices, GPS location and public flood information confirming a flood occurred in the area and the policy parameters are then processed by the smart contract and associated automated analysis components to make an automated decision for an agreed payment to the customer.
The payment may be initiated automatically, without any human interaction, where the platform integrates directly with necessary third party data sources to verify the existence and severity of the flood to be valid and checks this against details of the legally-binding smart contract.
The traditional claims model is resource-intensive and takes several weeks of back and forth for the due diligence of the claim to be finalised before a payment is made to the insured. This is not a good customer experience. In addition, the customer needs to trust that the insurer will make the payment when the event occurs.
The automatic payment initiation is an example of a self-executing smart contract. There is no legal barrier to such automatic execution provided that all contracting parties have agreed to the triggers and to be bound by them. This proviso highlights the need for clear contractual terms communicated via natural language.
In reality, it may not be in one or more of the parties to have completely automatic self-execution. The insurer, for example, may with to carry out a claims assessment before initiating payment.
If the smart contract has not been communicated in clear language, a dispute may well arise as to the nature of the contractual terms. A clear dispute resolution procedure should therefore be included in the natural language contract communicated and agreed between all relevant parties.
Tim Roughton is a financial technology expert at Pinsent Masons, the law firm behind Out-Law.com. This article is based on a joint paper by Pinsent Masons and Applied Blockchain, which was launched last month at the International Fintech Conference. Register here for a copy of the full paper.