Part 2 - Using HyperLedger Fabric v1 in (Re)insurance
In our previous post, we introduced Hyperledger Fabric v1’s architecture components and some common design patterns that we could use with it. This post will discuss the prospects of using Fabric driven consortium based blockchain network for commercial and reinsurance use cases.
Blockchain in Reinsurance
Reinsurance industry by its very nature involves multiple stakeholder collaboration in several of its inter market processes such as risk placement, retrocession, premium and claims technical accounting, settlement and claims management. Blockchain provides a decentralised shared database with each transaction recorded using a multilateral consensus amongst the parties involved. Some of the obvious benefits that a blockchain platform could provide in a reinsurance network are:
- Single version of an asset such as risk, technical or financial account, claim etc embodied in the form of smart contract
- Improvements in the accounting and settlements times because the current EBOT (Electronic Back Office Transactions) or ECOT (Electronic Claim Office Transactions) processes prescribed by ACORD standards are based on two way chatty messaging. We have explored this area of progression of ACORD Standards with Smart Contracts in an earlier post.
- Reduction in the operational cost as a lot of time is currently spent by organisations on reconciliation
Therefore, reinsurance sector seems to be a right candidate for at least initially trialling the blockchain platforms and measuring the benefits. Refer to our video below which highlights the benefits.
Public Blockchain Platform Constraints
Public blockchain networks enable anyone to participate in virtually any capacity. There is no need for network members to trust or even know each other. A reinsurance network can be built using this platform and it should solve the problem of operational inefficiencies in sharing data as every party is able to see the same version of truth without the need to reconcile. However, there are certain constraints in using a pure public blockchain platform platform for the reinsurance industry. We will use *Ethereum as an example to demonstrate some of these constraints:
Data privacy: This is best illustrated with an example in the reinsurance context. There is a Cedant C1 which has entered into a risk underwriting agreement with Reinsurers R1 and R2 who have each got a line share of the risk. Cedant C1 may not want this data to be shared with Cedant C2 or Reinsurer R3 who are also members of the same network even if the data might be in an encrypted format. One of the plausible reasons is the sensitivity of the data which the cedants or reinsurers may not want to share with a competitor.
Scalability and Performance: Low throughput and high latency are often associated with public blockchain platforms. The main reason is the proof of work consensus protocol which involves each peer node running the smart contract transaction for validation and synching up the ledger copy even if the node may not have anything to do with the transaction. Performance is typically as good as the speed of the slowest node in the network.
Restrictions of the sandboxed VM: We know that digital insurance assets like risk, claim can be modelled as smart contracts. EVM handles state and logic and provides the run time environment for smart contract bytecode. EVMs are geared to handle small code size, deterministic with no access external APIs, resistance to infinite loop situations or attacks. For the purpose of EVM, a specific language called Solidity is used to write high level programming instructions. Solidity has certain constraints i.e – it does not support float data type, therefore calculations involving decimal inputs may need to be approximated.
ChainThat has addressed some of these limitations in its Insurance Blockchain Platform (IBP) by using a hybrid of on chain and off chain shared secure storage so as to not bloat the blockchain. Similarly, the platform used a combination of symmetric and asymmetric encryption techniques for only authorized parties to access the data. Holding only referencing information and its hashes made much more sense in Ethereum platform.
* Note at the time of writing this article, Ethereum Enterprise Alliance is looking into the aspects of privacy and performance but this is work in progress.
How Fabric can solve some of the problems
With the advent of private and permissioned blockchain platforms such as Hyperledger Fabric v1, the challenges related to confidentiality and scalability can now be met in the core Fabric platform itself. There is no need to build something bespoke for it.
The image above represents a typical workflow for channel creation and setting up Chaincode. The submitting client like a cedant submits a risk to the application, which in turn creates a Fabric channel to isolate digital asset or smart contract to the participating contract members only. This allows the owner of a risk to add participants to a channel. The channel creation event intimation to the selected participants is done through off chain messaging mechanism, so that the invited contract members parties can join the channel. The receiving member application accepts the channel message, then invites its peer to join the channel. Once the channel is joined, the application installs the Chaincode on the peer file system. This process then allows the peers of multiple organisation to now send transaction or query the Chaincode with its state secured in the channel.
There are more than one way to skin the cat in terms of modelling digital assets. Some of the design decisions with Fabric that we took in IBP are:
- Create a Fabric channel per risk: In case you have a contract with multiple participants like a risk with multiple line subscribers, ChainThat has leveraged the Fabric v1 platform to allow for separation of contractual data between reinsurance parties.
- Use the concept of transaction endorsements for smart contracts/chaincodes: Not all peers need to run the Smart Contract (Chaincode) transaction. Endorsers are special kind of peers that can simulate the running of the transaction. Other peers can validate the read/write set produced by the simulated transaction. For example Cedant Peer node can act as an endorser if it needs to validate the endorsement proposal against its legacy system.
- Decoupled consensus: The consensus around the ordering of transactions is done in an ordering service in Fabric, which is outside the domain peer nodes. This feature of Fabric should allow for better scalability of the network as ordering service can be scaled independently of the peers. We don’t have documented benchmark figures of Fabric’s performance under simulated load conditions yet.
- Complex Calculations: The complex arithmetic calculations can be done inside the Chaincode unlike the constraints with Solidity. This implies more business logic inside Chaincode and lesser business logic in individual applications outside it. This shields the network from any attempts to tamper with the business logic by an individual owner of an application.
Overall, private blockchain platforms can tackle the deficiencies in the public blockchain platforms and still retain the core value adds that they offer . ChainThat Insurance Blockchain Platform provides the services to the end users using blockchain platform as a decentralized ledger. One of the core principles of ChainThat framework is to make it’s services blockchain platform agnostic. This takes away the burden of unravelling the internals of the blockchain platform from the customer. In our next post, we shall discuss our design thinking around usage of R3 Corda platform in reinsurance. Stay tuned!
*Disclaimer: The view expressed in this post are author’s own opinion