Rethinking Blockchains in Insurance in June 2022

Note: These are my personal views and not those of my employers, Tata Consultancy Services

In August 2015, I was the first in the world to write publicly about how Blockchains can be applied to insurance. I know that because I searched hard on google at the time and mentioned this. I have been fortunate to work on Blockchains in insurance since 2015. It has been a slow journey. While I have dabbled in other domains too, insurance has been my focus. I frequently use it to illustrate wider viewpoint. In 2017, September or so, I first predicted that permission less blockchains would have a bigger role in the future. My objective here is to review my conclusions then based on my learnings from my journey since and the credible options that have emerged while I have been on my journey.

My learnings from a journey focused on enterprise blockchain, which till date for me has meant permissioned blockchains are as follows

1. Consortiums are hard to operate
2. There is a bit too much standardization needed upfront
3. Permissioned blockchain technology needs investment to make adoption much easier (e.g., automated on-boarding and KYC as well as automated integration to enterprise systems). Permissioned blockchains providers have yet not invested to make this extremely simple.
4. With permissioned blockchains, some code and data now move to blockchain. This disturbs well set systems and processes, which is difficult to understand, explain and justify business case for
5. The need for all parties to have nodes and the lack of focus on solving challenges of having multi-tenant nodes exacerbate the entry barrier created by the economics (annual cost of nodes, network membership costs, annual cost of licenses)

Since a year, I have explored a technology called “Baseline”. In recent months, my understanding of this technology has improved significantly due to a demo by https://provide.services. Baseline uses permission less blockchains (mainly Ethereum and its Layer 2 blockchains) and enables creation of applications which will meet the rigorous privacy and security requirement of large enterprises, banks, financial institutions and insurers. The key advantages of the Baseline approach for BFSI are

1. Clusters of organizations can implement workflows among themselves without having to depend on folks outside these organizations (essentially consortium role is smaller and need not include operating network).
2. Due to (1) there is less standardization needed upfront. Different clusters could have variations
3. Baseline folks have already built the automated on-boarding and automated integration and so adoption is easier. The reason for this is that they have focused on SSI at the core.
4. The most important thing is that enterprise systems largely continue to do what they currently do and integrate with the baseline middleware which runs multi-enterprise workflows and the role of blockchain is limited to storing proof that the workflows have done what they were required to. This makes it easier to understand and justify business case.
5. Some people struggle to understand how this works. Those who understand how SSI enables private channels between two parties will easily appreciate how parties to a particular cluster could easily exchange data with each other without any other party getting any visibility.
6. Folks anchoring clusters can set up workgroup for the cluster and invite cluster members to join. Folks who accept can join with little ceremony. Cluster/workgroup anchor and set up workflows containing work steps. Each work step requires communication between one subset of cluster members. In this work-step, they exchange data with each other through the mechanism described in (5) and use the Blockchain to record the proof that the work step was indeed carried out. Workflows record proofs that the sequence of work steps was carried out.
7. The key thing that is involved in (5) and (6) is that there is some level of standardization needed for data sent from one enterprise system to be processed by the enterprise system of the receiver. The key point is that this standardization can be specific to the cluster and need not be global. In INSURANCE case, it might very well be the case that the existing e-mail/FTP data flows themselves could be quickly leveraged to accelerate adoption. If the standardization is common across all the clusters, that is an added benefit, but it is not mandatory. The workflows are to be written to the local/global standards and adaptors map the data to/from enterprise systems into each work step. The hash of the data in the local/standard format confirmed by parties to the work step can be the basis of the "proof" written to blockchain. There are some nuances about writing different levels of proofs to the blockchain. I will leave those for a later article.
8. Each member of each cluster can similarly set up a separate workgroup, workflows, work steps and invite cluster members of their choice. These cluster members can include some/all from previous cluster and new ones. The workflows can be same/similar or totally different. The members can be from the same industry or can be from a totally different industry.

I would like to specify the benefits of taking this approach

1. If a cluster has a business case for a workflow, that is adequate to get off the ground
2. Cluster anchor can provide the node for cluster participant, or the cluster participant can provide its own node
3. Reuse and revision/extensions of workflows and workgroups from one cluster for other clusters need not be too constrained. This allows for lot of diversity in clusters. There can be a hierarchy of clusters. Each next level cluster enables standardization from the diversity underlying it. THERE IS A VERY SUBTLE BUT IMPORTANT POINT HERE. If the workflows, work steps and proofs have been designed to enable trust in same data items separately within a group of clusters, then it is possible for next higher-level cluster to create cross-original cluster workflows related to such data items, since "trust in proof scales". Such higher-level cluster workflows could very well be constructed out of ERC20 tokens from the lower-level data items mentioned above and can leverage the typical benefits of ERC20 tokens.
4. There is a need for a "consortium", but the role of a consortium is more of setting standards for data exchange and ERC20 tokens and the like and local clusters can self-organize within the standards framework. Typically, in industries like insurance, clusters would organize around brokers, but there is nothing mandatory about this. Any party which can get a cluster with a business case can generate value through this kind of process and ensure the benefits of WISIWYS and always reconciled data generating high quality analytics.
5. Those who have already created Blockchains/DLT consortiums, blockchain applications et all can easily port their applications to this world.

In September 2017, I had predicted that digital identities and exposure data would be provided through public permission less blockchains in the future. While digital identities suitable for usage by insurance industries are here, legacy blockchain technologies do not provide these natively, preferring something from the past. Digital wallets of insured parties can easily be designed to store and leverage exposure data for insured parties today. But this use case does not have high priority yet. It is possible to design exposure data capture, verification, correction/cleansing, augmentation, storage around this paradigm. I will be happy to discuss with anyone interested in this. Sadly, I think I must wait few more years before these become high priority for people. Essentially what I predicted in 2017 is now possible to do in an enterprise grade manner.

I had anticipated that the era of insurance processes on permissioned blockchains will eventually give way to insurance processes on permission-less blockchains. Do I think that that day has arisen? I am not sure yet. I will not advise an industry transition unless I am sure. What do you think?

Regards

Pratap Tambe