It's customary in any discussion of Blockchain to assert that there will definitely be a change to the insurance industry. We then go on to state a number of use cases unrelated or tangential to insurance (Land Title Registry, Fine Arts Ownership and Imogen Heap are the usual suspects). But the B3i initiative and other similar ventures are, at last, giving the insurance industry real examples to consider.
The evolution of terminology around blockchain provides a clue to the likely progression of its use in insurance. Initially it was "the blockchain" as there was effectively only one, powering the Bitcoin cryptocurrency. It then lost its definite article, becoming "blockchain" or "blockchain technology" as other cryptocurrencies and separate networks leveraged the same principles. Currently it is repurposing the existing term "distributed ledger technology" as its use expands beyond digital currencies and into other worlds.
The insurance applications will almost certainly be "distributed ledgers", as opposed to true blockchains. Leaving aside the question of whether a public blockchain would be compliant with Anti Money Laundering and other regulations, it's difficult to envisage a global industry entrusting the ability to process its transactions to the continuing appetite of people to use expensive computers to mine digital currency rather than shoot zombies.
As with the Reinsurance "consortium blockchain" example of B3i, there are clear indications of the benefits of the technology to the (re)insurance industry. The reinsurance chain gives a prime example of multiple parties wanting to share the same data. To whom the accuracy of the data and the timeliness of actions are all important and where the technology adds genuine benefits – removing rekeying, adding clarity, and speeding up premium and claims settlement (this will be another nail in the coffin of the monthly close). In the broader insurance industry, MGAs and Motor Claims certainly stand out as spheres where very similar considerations apply. Equally, the London Market, which can sometimes feel like the Rube Goldberg Machine of Financial Services, ticks a lot of boxes for assessing viability of a blockchain use case. With TOM leading the way on making London a simpler place to do business, one can envisage a "TOM 2.0" built around a consortium blockchain.
Though the very concept of private and consortium blockchain is anathema to many purists, I think that it is likely. Industry or category-specific distributed ledgers serving as asset registers for specific things – energy platforms / power plants, aircraft fleet etc. and all loosely connected by an overarching protocol: a HTTP for blockchain. I believe it will end up as a protocol rather than a platform like Ethereum, where issues of scale and the need to compete to get transactions verified will cap its corporate applications.
While blockchain certainly presents an opportunity for insurers in terms of efficiency (remove rekeying of data, making shared data available more quickly, removing reconciliation errors, increased automation through smart contracts) it is also clear that these gains would have to be quite significant to be worthwhile as they will be costly to realise. The computational processes required under the current state of blockchain technology is expensive up-front and very energy intensive. The human expertise required to build and implement these networks and overcome the issues of scale also does not come cheap.
If insurers can look at blockchain as a (possible, costly) opportunity, other parts of the industry can look at it more as a threat. Brokers in particular, will feel the squeeze as they may struggle to demonstrate viability in a blockchain model: in a model built around disintermediation, what does an intermediary actually do?
But there are questions for software providers too. How much of the existing back-end database can survive if key data is on a blockchain? Duplicating data and storing it in central servers undoes the central benefit of the blockchain (a single source of data for all participants) and increases the cost. The next generation of insurance software will have a very light and flexible back-end, probably restricted to internal client coding or specific information not on their blockchain(s). The future of insurance systems will be APIs to take information from one blockchain (e.g. risk information from an asset register) and create records on another, (e.g. showing that risk is insured, when, by whom for what value etc.) triggering actions via smart contracts (collecting or making payments, issuing e-documentation etc.), which is where the "HTTP-type" protocol will be necessary. Competition will be on the breadth of APIs, and elegance of UX and dashboards to present the data.
All of this will take time, and there won't be an overnight switch to a blockchain world. The difficulty of understanding the basic concept of blockchain (cryptographic hashing, anyone?) and issues of scale (the original Bitcoin blockchain processes just 7 transactions a second) will act as a brake, but perhaps help ensure that the applications that do see the light of day are built on solid use cases.
If you compared blockchain to the internet, we are probably at the stage where a BBC-news correspondent invites us to watch him look at a painting in a virtual museum on "the information super highway" and shake our heads in wonder: it's still niche but on the edge of the mainstream. From there to ubiquity might be several years, but they are years that see progress all along the way.
