No doubt about it, blockchain is a powerful, efficiency-enabling technology, but as Markus Bassler candidly explains, for re/insurers it’s also important to be aware of the issues and limitations, and to think carefully about where it could really add value.
Yes, there’s a lot of great material out there on this ‘originally-developed-for-Bitcoin’ technology, and it can be a bit confusing at times… And yes, in the name of promoting discussion, and because it very much deserves it, I’m now going to add to it!
To condense the facts:
When multiple, ‘mistrusting’ parties (i.e. there’s a counterparty risk) need to store and share data over the long term, the option is generally to have a centralized database with shared access (controlled by a trusted third-party), or for everyone to have separate databases, to involve various intermediaries for verification, lots of back and forth emails and re-keying of data. Inefficiency can be an issue, there’s potential for error, data corruption and fraud, and enhancement attempts may be hankered by IT legacy issues. On the plus side, processing speed is good, all manner of posthumous corrections can be made, privacy is maintained and access to sensitive data can easily be restricted.
Blockchain (hereafter ‘BC’) is different. BC is a ‘Distributed Ledger Technology’. As the word ‘distributed’ implies, records are stored not in one place, but are synchronized in near real time across many computers/‘nodes’, hence it is inherently robust as many nodes would need to fail for the BC to fail. A BC securely and immutably records1 transactions/digital assets, establishing a ‘single source of truth’ that creates a high level of trust between (non-trusting) parties and improves auditing capabilities (a major plus for auditors and regulators). A BC avoids the headaches of checking and reconciling everyone’s individual records and the need for (mutually agreed upon and fully accessible) trusted third-party entities or a central authority to validate records, plus all those back and forth emails and re-keying of data. Compared to traditional solutions, a BC can therefore reduce the potential for error, data corruption and fraud, and can save considerable time and money. ‘Smart contracts’ can be incorporated to add agreed rules/ set the parameters that are then automatically carried out.
There are certainly best-fit characteristics and also issues to be aware of. Given the advantages, however, it’s likely that many of these will be resolved over time.”
Several re/insurance industry consortia initiatives, e.g. B3i2 and the Institutes RiskBlock Alliance3, are well underway developing BC proofs-of-concept.
For the re/insurance sector, BC offers a plethora of potential efficiency-enhancing applications that could reduce operational costs and increase customer satisfaction – good news for an industry faced with record losses, ongoing low interest rates, low barriers to entry and the age of instant-gratification-expectation.
BC offers efficiencies. We need efficiencies. So should we now move all our processes onto a BC?
Well ‘yes’ in some cases, and ‘not necessarily’ in others. There are issues and limitations to be aware of.
So what are the issues and limitations? Where is BC being used already with encouraging results? Where is it in fact not necessarily the best solution?
Hopefully the content I’ve pulled together below gives you some food for thought. It would be great to hear your views, ideas and experiences – which is indeed the purpose of this article – so please contact me to discuss.
Permissionless (public) BC: Any individual can join or leave the party at any time, e.g. as used by cryptocurrencies including Bitcoin. Lots of BC ‘writers4’ and ‘readers’. Validation is done by computers on the public internet5.
Permissioned (private) BC: Only authorized (requires a central entity to manage/give authorization) individuals can participate in the BC. Bank Crédit Mutuel Arkéa, for example, uses private BCs to share customer data across its different group entities.
An extension of this BC type is the ‘Consortium BC’, where a select group of companies cooperate to find solutions to their shared transactional inefficiencies (e.g. using BC platforms Quorom and Corda). Different user rights and blocks are validated via predefined rules. Blocks are usually processed by a trusted, centralized entity. Consortium BCs are the main focus for business.
Compared to a public BC, permissioned BCs have:
According to Gartner7, BC is still in the phase of ‘inflated expectations’, and yes, there are certainly best-fit characteristics and also issues to be aware of. Given the advantages, however, it’s likely that many of these will be resolved over time.
Deciding whether investment in a BC will deliver more value than other tech solutions depends on weighing up the benefits against the relevancy (see, ‘General characteristics for a good BC fit’), investment and potential impact of the following:
Multiple (non-trusting, require intermediaries) parties sharing data. Efficiencies are needed. Immutability is important. The application can be standardized. The tech requirements can be very precisely defined. For consortium solutions, all parties benefit in line with their investment.
BC sets a tough precedent
Every implemented BC application potentially impacts:
The risk landscape for re/insurers. For example, if a BC improves time and cost efficiencies in supply chain management, see examples in this paper, the risks relating to that sector are altered and potentially also reduced. Risk protection should be adjusted accordingly. Also, with or without a BC, this is risk data that re/insurance should use.
The precedent of efficiency. Aside from the fact that this is already an industry goal, if the technology used to track and correct a problem is automatic and immediate, the associated financial compensation should not take months or years to complete. That doesn’t mean that the solution must be another BC, but it might be.
These two examples present the characteristics of a good BC fit.
Increasingly critical, in particular for complex products such as an aircraft, is for all players to know and have available the exact source of all raw materials and components/products along the full supply chain.
BC can be used to track the complete origin of every component. All players, every manufacturer within the production process, the aircraft owner, the supervisor and regulatory authority, have access to the exact same verified information at all times.
If problems arise, the diagnosis period is shortened and recalls, for example, can be targeted to the correct area. The result: reduced need for generic, large-scale recalls, less reputational damage.
According to the World Health Organization, one in ten people suffer from contaminated food annually. It can take weeks to determine the exact cause and source of the contamination. The result is loss of revenue, as well as potentially unnecessary destruction of food and loss of reputation. Leading global food manufacturers joined forces in 2017 to identify BC solutions.
BC can connect all players: farmers, producers, suppliers, processors, distributors, authorities and ultimately consumers. With appropriate access authorizations, it’s possible to obtain reliable and verified information on the origin and condition of food.
Targeted recall of contaminated food via a BC solution directs resources to the right place and fast. The result: less illness, less food waste, less reputational damage.
In respect of cover types, several cat bonds/swaps and other parametric covers are already being piloted and implemented. These BCs involve a standardized, trigger-based process. Note, however, that only the ‘cat bonds and swaps’ example given below involves multiple parties, the subsequent livestock and aviation examples involve a single entity (these are private BCs) and could also be achieved, perhaps at lower cost, via traditional technologies.
Shared indemnity contracts (many reinsurance contracts) fit the bill as regards multiple parties and a need for reduced errors and efficiency gains. With transparency and speed, a BC can e.g. track the evolving risks and exposures for all players, initiate premium payments, and verify (e.g. based on a trusted source to verify that an event actually happened) and settle claims. The marine insurance example below, for example, is designed to do exactly this; first results are positive, proving that while complexity may be a challenging factor for BC, it is not insurmountable, in particular if all parties stand to benefit, as they do in this case. Applications in facultative reinsurance (see below) could also be achievable, however, BC solutions may be less successful given potential differences in investment versus benefit for all involved parties.
With transparency and speed, a BC can e.g. track the evolving risks and exposures for all players, initiate premium payments, and verify and settle claims.”
For parametric covers of this type, BC-based contracts can significantly speed up and simplify the transaction process and payments between insurer and investor. Less people are needed to run the process. The cat bond/swap application may or may not be on the BC, but will exchange data with it.
Smart contracts on the BC set the parameters of the contract, including the triggers.
The trigger is via ‘oracles’, pre-defined and agreed-upon, reliable, trusted entities such as state weather services, which are external to the BC, but which exchange data with it.
In the case of a predefined event (e.g. a tropical cyclone), the predetermined amount is paid out in the BC via the smart contract. If there is no trigger as of expiry, the smart contract triggers the agreed interest payment and repayment of the investment amount.
Regarding BC use in trades, in 2018 Solidum Partners issued cat bonds cleared through a permissioned BC. It helped them syndicate capacity for catastrophe retrocession from a small number of small ILS funds. Using the BC has reduced transaction costs and cut trading time from days to seconds.9
Kenya’s ‘Kenyan Livestock Insurance Program’ (KLIP) launched a BC pilot in the fall of 2015.
An insurance product was created for local farmers based on the normalized differentiated vegetation index (NDVI). This index measures the ‘greenness’ of vegetation using satellite data and determines the dryness of the soil (e.g. green = not dry, yellow = very dry). If a certain dryness is reached, the BC automatically (and immediately) triggers a predetermined payment to farmers that are members of the insurance program. Farmers receive a fixed amount which, for example, could be used to buy extra food for livestock to secure their survival.
Flight delays are often part of travel insurance cover; e.g. for delays of ‘x’ hours, an amount ‘y’ is paid. The claiming process, however, is notoriously tedious. BC can simplify this transaction, e.g. once a delayed flight has landed, the BC, with pre-determined parameters in the smart contract, would be informed of the delay (and potential claim) via an oracle (e.g. a weather station and/or the airline’s database). The BC verifies the parameters of the delay and, if the predefined ‘delay length necessary for a claim’ is met, the BC could, for example, immediately trigger a payment to the customer’s mobile phone.
The process becomes fast and efficient, the customer is less irritated, reputational risk is reduced. AXA’s fizzy10, launched in September 2017, was the first application of this kind.
To benefit from a BC, complex processes with multiple parties first need to be standardized, all parties must benefit in line with their investment and the BC pilot must precisely define the objectives and technical requirements (the requirement specification).
Insurwave is a consortium BC for marine insurance that connects all re/insurance parties and marine third-parties to marine identities, risks and exposures. Launched in May 2018, the solution is linked to policy contracts and enables automated policy updates and pricing adjustments to reflect changes in risk, as well as claims validation and payment11. Results so far are good. All parties benefit and success seems likely.
Complex processes with multiple parties first need to be standardized, all parties must benefit in line with their investment and the BC pilot must precisely define the objectives and technical requirements.”
As table 1 shows, facultative reinsurance12 is a major contender for BC solutions, with an estimated annual savings potential of USD 100m13. The question: Will all parties benefit sufficiently? If not, BC solutions may be less likely to succeed in the short-term.
Table 1: Key challenges in facultative reinsurance and how BC could help. Source: Cognizant.14
PartnerRe was part of the B3i consortium market testing. We perform targeted research on Insurtech developments, identifying the optimal solutions for working together, for our clients and business partners.
Please contact me to share your BC experiences and views.
Markus Bassler, Specialty Property, Head of Energy Onshore & Special Risks
+41 44 385 34 48
Editor: Dr. Sara Thomas, PartnerRe
1 in ‘Blocks’ linked by a cryptographic hash
3 e.g. https://www.theinstitutes.org/about-us/media-center/articles/institutes-riskblock-alliancetm-announces-plans-launch-blockchain
4 Also known as miners
5 Dowling & Partners report (May 2018).
6 The process for adding transactions as ‘blocks’, designed to prevent fraud, involves tremendous processing power. e.g. https://markets.businessinsider.com/currencies/news/bitcoin-mining-could-use-more-energy-than-electric-cars-this-year-morgan-stanley-2018-1-1012823094
8 Note, if privacy is required, BCs can be set up to ‘hide’ data to maintain the required levels of privacy.
9 e.g. http://www.artemis.bm/blog/2017/08/04/first-blockchain-settlement-for-cat-bond-completed-by-solidum/
10 e.g. https://medium.com/@laurentbenichou/fizzy-axa-reaches-a-new-milestone-fadd41f20e11
11 e.g. https://www.insurancejournal.com/news/national/2018/05/25/490345.htm & https://worldmaritimenews.com/archives/253550/maersk-backed-blockchain-platform-for-marine-insurance-launched/
12 A fragmented, complex business involving many players, associated with high cost ratios and errors, high administrative effort, inconsistent interpretation of contracts and long processing times.
13 ‘How Blockchain can reinvigorate facultative reinsurance contract management’, Cognizant (2017) https://www.cognizant.com/whitepapers/how-blockchain-can-reinvigorate-facultative-reinsurance-contract-management-codex2592.pdf
14 Extract by PartnerRe
The issue. Individual life insurance sales typically involve a lengthy application process, including multiple face-to-face interactions and appointments for medical testing. This process is increasingly […]