1. Executive Summary
The Risk Management in a Digital World Working Party undertook an industry survey in December 2017 to better understand the views and activity in relation to InsurTech, along with the practice and capability in assessing risks emerging from InsurTech. Out of a number of “hot topics” in the context of digital innovation in the insurance industry, blockchain was identified as a subject matter that respondents were least comfortable explaining to a colleague. This highlighted a lack of understanding of blockchain and the associated opportunities and risks.
The objective of this paper is to provide a practical guide to blockchain in the context of solving insurance business problems. The paper is divided into three broad sections. First, the paper covers an education piece to provide an understanding of the technology and what sets it apart from existing solutions.
This is followed by examples of real-world applications and use cases in the insurance industry to illustrate the capability of the technology. The working party has also considered the risks and challenges of adopting the relatively new technology.
Finally, the working party has used its “Guide for Risk Considerations During the Innovation Journey”Footnote 1 in order to create a checklist of issues to consider in adopting a blockchain solution for insurance business problems. The checklist represents a suite of issues to consider at each stage of the adoption journey, phrased as questions. These are mapped to components of a typical enterprise risk management (ERM) framework.
2. Introduction to Blockchain
Interest in blockchain has risen and then waned as it failed to gain mass adoption. However, the intellectual capital, and collective energy invested in the development of blockchain, means that a tipping point is inevitable. This is the so-called Amara’s lawFootnote 2 which states that “we tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run”. As has the Internet done for the exchange of information, blockchain is an infrastructure technology that will enable a peer-to-peer instantaneous exchange of value. Once mature and adopted en masse, it has the potential to be disruptive to the insurance industry’s existing business and operating models. For example, the pooling/aggregating and transferring of risk could be achieved between end users (individuals, communities, and corporations) without (re)insurance/broker companies acting as intermediaries.
2.1 What Is Blockchain?
There is no single definition of blockchain; any attempt at a definition often spirals into semantic disputes. For the purpose of this paper, the working party uses the following definition to set a baseline and common understanding.
Blockchain, a variant of Distributed Ledger Technology (DLT), is a shared database/ledger on which the state (i.e. the current snapshot of data) is confirmed and verified without the need for a trusted centralised authority.
At its most basic level, blockchain is a database which is shared by multiple participants. Data are verified by multiple entities instead of a single organisation. The data are then propagated and stored by each participant.
The focus of this paper is less on the technical definition of blockchain and more on how it could be useful in solving insurance business problems. This paper uses the terms “blockchain”, “distributed ledger technology (DLT)”, “database” and “ledger” interchangeably as umbrella terms. The working party also recognises that blockchain is a variant of DLT and that there are technical differences in various DLT platforms.
2.2 How Is Blockchain Different?
The defining features of blockchain/DLT that set it apart from existing technologies are as follows.
-
It provides a single source of truth – this enables the exchange of value digitally without the need for a central authority, who often acts as an intermediary. An intermediary typically extracts value from transactions to the detriment of the end users.
-
Smart contracts deployed on a blockchain can automate business logic – this has the potential to reduce operational frictions and costs and hence improve business process efficiencies.
2.2.1 Single source of truth
Blockchain-based solutions could serve as the single source of truth as they have the following characteristics.
-
Distributed – verified data are propagated to participants on the blockchain network so that multiple parties have the same record. This solves the problem of data existing in silos and removes the need for reconciliation between multiple parties.
-
Decentralised – in addition to data being propagated to and stored by multiple participants, the maintenance of the network, including data verification, does not depend on a centralised authority. This removes a central point of failure.
-
Tamper-resistant – verified data are cryptographically secured, making the data resistant to malicious alterations. This provides a high degree of data integrity and immutability.
-
Transparent – the blockchain is fully auditable for those with access.
Conventional, tried-and-true database solutions may have some of these characteristics; what sets blockchain apart is that it is designed from the ground-up with all of these characteristics in mind.
2.2.2 Smart contracts
Smart contract is an umbrella term for self-executing code deployed on the blockchain, analogous to software that runs on a computing platform. When pre-defined criteria are met, smart contracts execute a set of business logic as agreed by participants involved. While they may not be “contracts” in a legal sense, they could be utilised to implement the automatic execution of a legal contract or agreement.
Self-executing code is not new; smart contracts are innovative in that they act on dependable data within the blockchain (on-chain data). Where data are not available on the blockchain, off-chain data from external sources known as “oracles” (e.g. market data provider for financial contracts and weather data provider for weather-related insured events) could be used to trigger the pre-defined action(s).
Smart contracts are important as they extend the functionality of blockchain as a shared database to that of a platform for building a wide array of applications (see examples of insurance use cases in section 3).
2.3 How Does It Work? A Non-Technical Overview
Blockchain is a convergence of multiple disciplines, including programming, information security, cryptography, distributed systems, and peer-to-peer networks. To fully grasp its inner workings, one needs a fundamental understanding of these subject matters, which is beyond the scope of this paper.
Instead, the paper provides a high-level overview by focusing on:
-
the trade-offs in blockchain design choices – this section provides an overview of the design considerations when choosing the most suitable blockchain solution for a given use case;
-
the key components of blockchain/DLT technology – this section introduces the components of blockchain. A basic knowledge of these is useful in developing blockchain applications. However, like web application developments, an extensive knowledge of the underlying protocols is not required.
Readers are referred to Nakamoto (Reference Nakamoto2008), Buterin (Reference Buterin2013), Hearn & Brown (Reference Hearn and Brown2019) and Amsden et al. (Reference Amsden, Arora, Bano, Baudet, Blackshear, Bothra and Dill2019) for further reading.
2.3.1 Trade-offs in design choices
There are two broad classifications of blockchains as shown in Table 1.
Broad Classifications of Blockchains
The differences are born out of design choices and trade-offs that favour certain features over another. This, in turn, may give one platform an edge over another in specific use cases.
The key trade-off between permissionless and permissioned blockchain is that of access versus privacy. Permissionless blockchains provide frictionless access, that is, anyone can participate in the network as opposed to the need to set up governance around the rules of participation in a permissioned blockchain. More importantly, anyone can develop applications (via smart contracts) on permissionless blockchains, potentially increasing the pace of innovation. However, transactions or changes to the database are transparent to all participants; this may not be acceptable in business use cases which require confidentiality.
Other important (but non-exhaustive) design trade-offs, as shown in Figure 1, include:
-
Decentralisation versus scalability/speed – To maximise the benefits of decentralisation (i.e. where the ownership and maintenance of the network, including data verification, does not depend on a trusted centralised authority), scalability/speed of the network needs to be sacrificed in favour of a robust decentralised consensus mechanism;
-
Scalability/speed versus security – To maximise throughput (i.e. the number and speed of transactions), certain design sacrifices need to be made to the rules that determine how data are verified and added to the shared database, potentially introducing vulnerabilities;
-
Development flexibility versus security – To maximise the flexibility in developing applications, restrictions on smart contracts may need to be minimised, potentially allowing malicious actors to exploit software bugs in smart contracts.
Examples of design trade-offs.
2.3.2 Components of blockchain
Components of blockchain are not new; the main innovation is in the mixing and aggregation of existing technologies such as cryptographic hash functions, digital signature, Merkle tree (or its variants) data structure and consensus mechanism in a distributed system. These components are described further below.
2.3.2.1 Cryptographic hash function
Cryptographic hash functions are used extensively throughout a blockchain system to secure and authenticate data. A cryptographic hash function is a “mathematical algorithm that maps data of arbitrary size (often called the ‘message’) to a bit string of a fixed size (i.e. the ‘hash’ or ‘digest’) and is a one-way function, that is, a function which is practically infeasible to invert”.Footnote 3
A small change to the input, as shown in Figure 2, would change the hash/digest that the new hash appears uncorrelated with the old hash. The only way to find the input that produces a given hash is to attempt a brute-force search of possible inputs to see if they produce a match.
A cryptographic hash function (i.e. SHA-1) at work (Wikipedia, n.d.-a).
2.3.2.2 Digital signature
Digital signature, which serves as a unique fingerprint, provides the assurance that the proposal to change the state (i.e. the current snapshot of the data) of the blockchain originates from a network node that is authorised to do so. This is achieved using asymmetric cryptography, where a pair of “keys” – one public, and the other private – could be used to encrypt and decrypt data as shown in Figure 3.
Example of digital signature in the context of signing a message from Alice to Bob, and used to verify the message (Wikipedia, n.d.-b).
An overview of how this works is as follows.
-
The proposal is “signed” with the node’s private key using a digital signature algorithm. The private key is known only to the node.
-
The signed proposal can be verified to have originated from the node by using the node’s public key and digital signature algorithm.
-
A digital signature is unique to each state change request, thereby adding extra security (i.e. the same signature cannot be re-used).
2.3.2.3 Merkle tree-type data structure
Merkle trees allow for efficient verification of data integrity. A Merkle tree is a tree of hashes constructed from the bottom up as shown in Figure 4. Each leaf nodeFootnote 4 is a hash of data (e.g. transactions), and each non-leaf node is a hash of its child nodes, culminating in the top node (i.e. the root hash or the Merkle root).
Transactions hashed in a Merkle Tree (Nakamoto, Reference Nakamoto2008).
Such a data structure optimises the storage and verification of data in a blockchain. Data storage is optimised because only the hashes need to be saved and the root hash is the fingerprint of the entire data set. Data verification is optimised because only a small part of the tree needs to be traversed in order to check where changes have occurred.
The root hash/Merkle root, the fingerprint of the entire data set, forms part of the block header on the blockchain. Another component of the same block header is the hash of the previous block. This unique data structure, where blocks are chained together as shown in Figure 5, is a distinctive feature of blockchain that makes it tamper-resistant. This is because a data change would cause the block hash to change, making it incompatible with the block header in the next block. Therefore, an adversary who wishes to change the state of a particular block would need to change all subsequent blocks. In a proof-of-work (PoW) consensus mechanism (see section 2.3.2.4), this would require more than half the computing power of the whole blockchain network (known as the 51% attack).
Previous states are linked to the current state (Nakamoto, Reference Nakamoto2008).
2.3.2.4 Consensus mechanism
The consensus mechanism is a set of rules that determines how data are verified, how conflicting information is resolved, and how agreement is reached on committing changes to the blockchain without a trusted centralised authority.
By utilising cryptography and behavioural economics, the mechanism ensures that participants are strongly incentivised to maintain and secure the network. Examples of consensus mechanism are summarised in Table 2.
Examples of Consensus Mechanism
3. Insurance Use Cases
Compelling use cases in the insurance industry arise when there is a need to
-
remove intermediaries in the process of value transfer/exchange;
-
produce a shared tamper-resistant record that is trusted by multiple participants and all stakeholders;
-
reduce operational frictions and costs in the value chain.
Figure 6 summarises examples of real-worldFootnote 5 use cases. The potential application of blockchain technology is evident throughout the insurance value chain, that is, from the underwriting and pricing of products, their sales and distribution, through to the ongoing management of product, and claims processing. The examples below are not exhaustive, and in some cases, the use of blockchain technology may not be strictly required. However, blockchain could be an enabler and catalyst to accelerate digitisation, shift the mindset towards change and transformation and foster further innovation.
Examples of use cases across the insurance value chain.
The following sections discuss the use cases in more detail, covering the problem statement, a high-level description of the use case, main beneficiaries of the use case, the benefits (other than cost savings) and challenges preventing adoption. Many of these use cases are work-in-progress and are ordered roughly by time to adoption (imminent to long term).
3.1 Claim Processing
3.2 Reinsurance and Swaps
3.3 Tokenisation of Insurance Risk (i.e. Securitisation on the Blockchain)
3.4 Decentralised Digital Identity
3.5 Decentralised Data Lake
3.6 Decentralised Autonomous Insurer
4. Risks and Challenges
As is the case with adopting any new technology, there are risks and challenges that need to be considered when adopting blockchain as an enterprise solution. These issues are not only related to technology, but also business strategy and culture, processes, regulation and financial costs.
4.1 Costs of Adoption
Blockchain is potentially disruptive, but it may not make commercial sense to be a first mover in adoption for the following reasons.
-
Blockchain is a nascent technology as standards/platforms are still emerging. The hype is ahead of development; it will take time for the technology to mature, become cost-effective for mass adoption, and more importantly, to be tested under real-world adversarial conditions. Companies across the insurance industry had piloted proof-of-concepts (PoC). Most of these failed to move to the production stage. One notable exception is a catastrophe excess of loss (Cat XoL) reinsurance application launched by an industry blockchain consortium after 2 years of trial and development.
-
Blockchain solution development is an area where mathematics, cryptography, economics, data structure and computer science skills overlap. It is rare to find experienced developers who tick all boxes. It is even more challenging to find business subject matter experts in the insurance industry with these skill sets.
-
In the case of permissionless blockchains, mass collaboration and adoption (i.e. network effect) is required to reap the full benefit. Currently, only cryptocurrencies as a use case have this level of scale, whilst other use cases receive little adoption. In the case of permissioned blockchains, intellectual property (IP) might be owned by a select few (e.g. the founding member firms) which might deter new entrants from joining the network, thus hampering adoption. A real-world example is the case of a blockchain-based marine insurance solution co-developed by a container shipping company. Other major marine cargo carriers had reservations about participating in the blockchain solution over concerns that they did not own the IP.
4.2 Security
Trust placed on a centralised authority is replaced by trust that the underlying cryptography and consensus mechanism is fit for purpose. There are a number of known potential security issues with blockchain technology that need to be considered:
-
Immutability of blockchain can be a double-edged sword; hacks/fraud/mistakes on the blockchain cannot be reversed without drastic measures, that is, “hard-forking” the blockchain (creating a permanent divergence in the blockchain), rendering the new and old versions of the blockchain incompatible.
-
Vulnerability in software, for example, smart contract codes can be badly written and exploited just like any other computer programmes. The infamous hard-fork, that is, the “Decentralised Autonomous Organisation (DAO) fork” of the Ethereum blockchain in July 2016 serves as a cautionary tale. The DAO was a blockchain-based venture capital fund built on the Ethereum blockchain. Hackers were able to siphon a substantial amount of Ether (the token native to the Ethereum blockchain, worth more than USD 50 millionFootnote 6 at the time) by exploiting vulnerabilities in the DAO smart contracts.
-
Data recorded on the blockchain are not inherently trustworthy unless data are native to the blockchain (i.e. “on-chain” data created within the blockchain). In particular, smart contracts often rely on external data feed (i.e. off-chain data) from sources known as “oracles”. Oracles ore often data silos operating in a centralised fashion, creating a single point of attack. Smart contracts are not inherently “smart” enough to determine the credibility of data feeds. This introduces a new challenge widely known as the “Oracle Problem”, whereby the execution of smart contracts could be compromised by unreliable external data feeds. This is one of the major obstacles hindering the mainstream adoption of blockchain and smart contracts.
4.3 Regulation
The adoption of blockchain-based solutions and the issuance of tokenised assets (see section 3.3) represents unprecedented regulatory issues that governments, regulators, enterprises and investors need to assess.
4.3.1 Data privacy rules
Data privacy issues have become a hotly debated topic in the blockchain space. The General Data Protection Regulation, specifically, the right to be forgotten, is inherently at odds with the immutable nature of blockchain. This is an example of existing regulations having centralised data storage architecture in mind, where it is feasible to request the data processor to delete personal data when instructed to do so. There are at least two possible solutions around this piece of legislation.
-
The first and most conventional solution is to not store any personal data on the blockchain. Instead, pointers are used on the blockchain to refer to where personal data are stored off the blockchain, which can be readily deleted.
-
The second solution is to only store the hash value of the personal data on the blockchain. It is probabilistically impossible to reverse-engineer a hash value (assuming quantum computing technology is not mature yet to break hash functions) and reveal the original input (i.e. the personal data). It may be argued that the hashed data have become anonymised data and hence do not constitute personal data.
4.3.2 Accounting and capital treatment of cryptoassets
Blockchain is well known largely due to Bitcoin, a type of cryptoasset. Cryptoasset is an umbrella term for cryptocurrencies, asset-backed tokens (see section 3.3), utility tokens, etc. There is a lack of clear guidance on the accounting and solvency capital treatment of these assets. Given a particular cryptoasset, the following considerations are likely to present challenges:
-
What is the accounting definition of the asset?
-
Which area of existing accounting standards is most relevant for the treatment of the asset? If not fit for purpose, are new accounting standards required?
-
What is the fair value of the asset if it is not traded in deep and liquid markets?
-
What are the key risks associated with the asset? Are there new types of risks that are not associated with conventional assets?
-
How does the asset behave under stress? What is the “1-in-200” scenario?
4.3.3 Legal status of smart contracts and cryptoassets
Legislation and regulation have generally not caught up with developments in the blockchain space. It is unclear whether smart contracts would be recognised as a formal legal contract. Similarly, it is not immediately obvious which legislation or regulation cryptoassets fall under. Jurisdictions around the world recognise the need to address this legal uncertainty. In November 2019, the UK Jurisdiction TaskforceFootnote 7 published its legal statement on the status of smart contracts and cryptoassets under English and Welsh law. The landmark statement concludes that smart contracts are legally enforceable and that cryptoassets should be treated as property.Footnote 8
Although the legal statement is not legally binding, it is influential and is an important step in providing confidence in the use of smart contracts and in the ownership of cryptoassets.
4.4 Business Strategy and Culture
A common feature amongst successful blockchain use cases is that business partners are willing to collaborate. Companies need to be prepared to both cooperate and compete on the same network so that everyone benefits, that is, game theory is at play. Many would struggle to embrace this new thinking and the challenges may include the following.
-
The risk of sharing commercially sensitive data, leading to a loss in competitive advantage – This is one of the reasons companies are reluctant to transact with each other on a public permissionless blockchain (see section 2.3.1). One area blockchain researchers have been focusing their effort on is the so-called ZKP. ZKP is an encryption technique which allows “one party (the prover) to prove to another party (the verifier) that they know a value x, without conveying any information apart from the fact that they know the value x”.Footnote 9 A practical benefit of ZKP is that it allows data to be shared between two parties without revealing the data, potentially enabling private transactions on public permissionless blockchains.
-
The lack of support from within the organisation due to a natural reluctance to change – New technology often means changing mindsets and existing processes. Creating a culture which encourages innovation and continuous improvements is no small task. One approach to adopting new technology is to allow transformation to take place in a gradual and ring-fenced manner by establishing a new brand under the parent company.
5. Guide to Adopting Blockchain Solutions
Blockchain is a means to an end; adopting blockchain only makes sense if there is a suitable and high-impact business use case. The lack of understanding of blockchain technologies and the advantages over existing technologies give rise to a risk of fitting blockchain to a problem, leading to failed projects and wasted investment. The following guide is provided with this in mind.
In the “Improving the success of InsurTech opportunities” paper (Bruce et al., Reference Bruce, Avis, Byrne, Gosrani, Lim, Manning and Qin2019), the working party created a timeline and checklist which considers how risk management activities can help with the implementation of InsurTech solutions. In this paper, considerations specific to the risks of adopting blockchain/DLT solutions are provided.
5.1 Timeline and Checklist
The timeline represents the key lifecycle stages of a blockchain adoption journey, as set out in Figure 7.
Blockchain adoption journey.
The checklist represents a suite of issues to consider at each stage of the adoption journey, phrased as questions. These are mapped to components of a typical ERM framework as shown in Figure 8.
ERM framework applied to blockchain adoption.
5.1.1 Stage 1: opportunity
5.1.2 Stage 2: planning
5.1.3 Stage 3: pilot
5.1.4 Stage 4: implementation
5.1.5 Stage 5: Business as usual (BAU) environment
5.1.6 Stage 6: review
6. Conclusion
This paper provides a practical guide to insurance industry practitioners on understanding, assessing and adopting blockchain. It covers the distinctive attributes of blockchain, real-world use cases currently in development, risks and challenges associated with adoption, and a guide to successful adoption of blockchain based on the framework proposed in the working party’s Phase 1 output.
It is true that the excitement surrounding blockchain has not yet led to a tangible impact on the insurance industry. However, like most innovations, adoption does not happen overnight. Blockchain adoption is a team sport relying on the collaboration of multiple stakeholders. For example, governments and regulators, in consultation with the industry, need to provide regulatory clarity to spur further innovation. The insurance industry, in turn, needs to collaborate to formulate blockchain standards and to ensure interoperability between different solutions.
Where there has been adoption, the key driver is a need to replace paper-based processes, digitise end-to-end business processes and increase trust in the value chain. This only scratches the surface of what the technology is capable of.
As Tim Harford, the economist and journalist recounted, “in 1881, Edison built electricity generating stations at Pearl Street in Manhattan and Holborn in London. Within a year, he was selling electricity as a commodity. A year later, the first electric motors were driving manufacturing machinery. Yet by 1900, less than 5% of mechanical drive power in American factories was coming from electric motors. The age of steam lingered” (Harford, Reference Harford2017).
Slowly but surely, blockchain insurance applications and use cases will mature, and adoption will increase as mindset shifts, thus transforming existing insurance business and operating models.
Disclaimer
The views expressed in this publication are those of invited contributors and not necessarily those of the Institute and Faculty of Actuaries. The Institute and Faculty of Actuaries do not endorse any of the views stated, nor any claims or representations made in this publication and accept no responsibility or liability to any person for loss or damage suffered as a consequence of their placing reliance upon any view, claim or representation made in this publication. The information and expressions of opinion contained in this publication are not intended to be a comprehensive study, nor to provide actuarial advice or advice of any nature and should not be treated as a substitute for specific advice concerning individual situations. On no account may any part of this publication be reproduced without the written permission of the Institute and Faculty of Actuaries.
Glossary
Centralised authority – A central governing organisation, typically (but not limited to) corporations or governments, which exerts control on a network or system
Consensus mechanism – A set of rules used to reach agreement on what is the authoritative version of record in a distributed database
ERM – Enterprise Risk Management
Fork – Divergence in the blockchain. Most forks are short-lived due to the difficulty of reaching fast consensus in a distributed system. Hard forks (i.e. protocol changes) are permanent and have been used to add new features to a blockchain, to reverse the effects of hacking, or catastrophic bugs
Node – A participant on the blockchain network
Nonce – An arbitrary random number which “miners” in a PoW consensus mechanism needs to solve for (by using brute computational force) to be able to commit state change to the blockchain
On-chain data – Data created within the blockchain
Off-chain data – External data not created within the blockchain
PoW – Proof-of-Work consensus mechanism which requires solving cryptographic puzzle by brute computational force for a state change to be committed to the blockchain
PoS – Proof-of-Stake consensus mechanism where a pool of validators (who hold a certain amount of the digital currency/token native to the blockchain, i.e. the stake) are selected to verify a state change and commit it to the blockchain
PoA – Proof-of-Authority consensus mechanism where trusted entities vote on whether to commit the transactions to the shared database
Smart contracts – An umbrella term for self-executing code that automates business logic on the blockchain
State – The current snapshot of the data on the blockchain
Open access
