Using Corda in (Re)Insurance

Introduction

R3 runs a consortium with over 80 members on a blockchain inspired distributed ledger platform called Corda. R3’s Corda platform has been designed and built taking into account requirements such as data privacy/confidentiality and transaction scalability of financial institutions in mind. Its design can easily be extended in non-financial domains such as insurance. R3 and ChainThat have formed a partnership to develop distributed ledger technology solutions for the insurance industry.

In this post, we shall briefly look at the Corda architecture, its security, consensus and tooling.  Then, we shall describe its usage in the accounting and settlement process in reinsurance. The prototype for accounting and settlement developed on Corda was recently demonstrated in Corda’s Insurance Symposium and shall again be demonstrated in the InsTech Shown and Tell event on 26th Sep 2017.

Along the way, we shall also compare Corda with some of the public blockchain implementations like Ethereum and private blockchain implementations like Hyperledger Fabric.

Corda Architecture

Corda has adopted a Bitcoin like state transition model of Unspent Transaction Outputs (UTXO) and not an account based model used by Ethereum.  UTXO model is stateless unlike an account based model which stores the balance of each account.

  • States are “Shared Facts”. They are like immutable data classes which evolve through transactions. States typically contain state properties (values), participants and the contract reference (hash of the contract). Each state is like a digital asset and has a state type defined by the class. In insurance world, it could be Risk, Quote, Claim Movement, Technical Account, Financial Account.
  • Vaults keep track of the history of the states. Vaults have pointer to the head of the state which is the current value of the state. In case of Bitcoin, if we imagine UTXO as a ‘coin’, then wallet balance is the sum of all your UTXOs. This balance is not stored on the ledger but calculated by the wallet application. The vault does a similar job as a wallet application. It will store all the states of the digital asset as it undergoes changes in its status.
  • Contract has got contract code and a reference to legal prose to relate to the contract wording. Typically contract code has a verify function. Unlike Ethereum where each peer executes transaction or in Fabric where endorsing peer simulates the transaction execution, Corda contracts only verify the proposals. In the case of Reinsurance Account state, the Contract can validate the risk or claim reference against the risk or claim assets if they are stored in the ledger or against a legacy system. The contract also validates the Tech Account xml message as per the ACORD schema definition.
  • Transactions are atomic units of change. Proposed transactions, which change state need to obey rules. These rules are defined in Contracts. A transaction can involve multiple state types.  For each transaction, there are 0 to n input states and 0 to n output states. Transactions are created using a transaction builder and then verified. There is one Merkel tree per transaction. Contains all the input and output states related to the transaction.
  • Corda Services are common infrastructure services available in the network. Network Map Services controls the membership which involves provision for registration of new members. It is a central service but all nodes keep a local cache of all the members, so there is no runtime dependency on this except during on-boarding process. There is a doorman service to keep track of the access control/authorisation. There is also provision for writing your own oracle service in Corda which can be deployed on a trusted Corda node
  • Flows are the BPM engines in Corda and effectively the heart of the Corda Application or Cordapp. It is where the different stages of a business process come together.

For more on Corda architecture, refer to Corda documentation.

Security

  • Sybil attacks involve the attacker spoofing a number of fake nodes to control the network. Public blockchains like Ethereum and Bitcoin prevent Sybil attacks by making proof of work computationally intensive. A simple PC would not be able to fake a miner’s as the difficulty level for the puzzle is too high for it. Private and permissioned blockchains like Corda prevent Sybil attack during the on boarding process itself. The entities operating inside the network are known to each other. As a result, there is enough trust inside the Corda network to not require any proof of work like computation, which means chunking transactions into blocks is not really needed. Therefore, Corda provides a transaction level consensus rather than a block level consensus. In fact, there is no concept of blocks in Corda.
  • Double Spending Problem .Two transactions for the same thing can’t happen (double spend) in Corda because a transaction is sent to a Notary service to confirm if the input state to that transaction hasn’t been consumed. The Notary then replies yes or no. The detailed functioning of  Notary service is described in the consensus section.

Consensus in Corda

  • Corda treats validation aspect of consensus as distinct from uniqueness aspect. Validation means the participating nodes checks for input states, output states and signatures. Uniqueness check is done by Notary service to avoid double spending problem.
  • Some trusted nodes can be configured to run the Notary service which is the consensus engine.
  • The current pluggable consensus engine (Notary service) is based on RAFT protocol and there is work in progress on the BFT implementation
  • Timestamps are defined within the flow. They are basically time windows. Notary service looks at timestamps.

Corda Tooling

  • Runtime: JVM, H2 (in memory) SQL database for vault – JDBC integration allows to hook onto any SQL database,  ActiveMQ Artemis for messaging
  • Development: Kotlin or Java for writing Cordapps, Gradle for Build and Deployment.
  • The latest release of Corda is M14 at the time of writing this article. There has been a recent announcement that R3 will be releasing Corda 1.0 by end of September 2017.

 Usage of Corda in Reinsurance A&S Process

Below is a high level process overview of Accounting and Settlement in Reinsurance

SImple_process_overview.png
  • A debt (invoice) is typically raised by a broker for amount type like a premium instalment or a claim through a technical account message. There is one technical account message for a sender (broker) and a recipient (reinsurer).
  • Technical Account is then agreed upon by the reinsurer to confirm the debt.
  • At the time of settlement, a financial account is created referring to the agreed technical account.
  • A settlement bank would typically do the actual payments in settlement currency and may also provide an add on service related to netting and settlement of payments.

Corda Node View

Corda-Prototype-Node-View.png

The above diagram is an illustrative Corda Network set up. We are running a similar network set up on Corda Test Net environment on Corda M14 release. For the EBOT accounting flows, Broker and Reinsurer Nodes are interacting with each other until the Tech Account is accepted.  These interactions involve initiating the accounting process by sending the Tech Account XML, a query loop or updating the draft tech account. Once the state changes to a Financial Account type, then a chosen Settlement Bank comes into play for the EBOT settlement related flows.

Reinsurance Account State Transition Flow

Corda-State-Transition.png

A reinsurance account state type involves storing the XML as an attachment and parsing some of the key attributes used in business validation or calculations and storing it in the distributed ledger.  The state sequences will involve the change in status and transitioning from a technical account to a financial account once the settlement is triggered.  The contract will do all the technical validation (XML schematic) and business validations on the state of the account.

Accounting and Settlement related Flow

Below are the steps involved in the Create Tech Account Flow:

EBOT-Create-Tech-Account-Flow.png
  • From an initiator perspective, the  flow steps will be:
  • Initiator (Broker or Cedant) generates an unsigned Tech Account transaction
  • Verifies that the Tech Account transaction is valid by checking against the rules specified in Tech Account Contract
  • Signs the Tech Account transaction
  • Sends the Tech Account state to counterparty (Reinsurer)
  • Receives the counterparty’s signature
  • Notarise and record the Tech Account transaction in both party’s vaults.
  • From an acceptor perspective, the flow steps will be:
  • An acceptor (Reinsurer) verifies that the Tech Account transaction is valid by checking against the rules specified in Contract
  • Signs the Tech Account transaction

Conclusion

Corda is an extremely good fit for peer to peer commercial insurance/reinsurance use cases as it has got a well defined conceptual model behind it and it addresses the privacy/confidentiality without limiting the usage of states for future purpose.

  • Aligns with ACORD message types: EBOT and ECOT message types as defined in the ACORD GRLC data standards are designed for peer to peer messaging with each message having one sender and one recipient. These message standards works quite well with Corda DLT as only the parties involved and mentioned in the ACORD xml are privy to the transaction.
  • No separate messaging infrastructure required for confidentiality: P2P Messaging is inbuilt in Corda using standard AMQP which takes away the need of any external messaging solution for confidentiality requirements.
  • No computationally intensive consensus algorithm: Consensus is on a transaction basis and the separation between validation and uniqueness concerns makes it easier to define the responsibilities of the Node and Notary service. Unlike Fabric, there is no channel like partitioning in Corda. This is a good feature as channels isolate state/chaincodes in Fabric and we cannot use contracts across different channels.
  • Extendible architecture: There is no reason why the reinsurance sector cannot adopt the learnings of the financial institution consortium on R3 Corda. From an outset, there is a lot of synergy in some of the reinsurance process like the accounting and settlement or net settlement process which maps closely to regular payment processes in financial institutions.

References

*Disclaimer: The view expressed in this post are author’s own opinion

 
Praveen Nagpal is an ACORD certified expert in Global Reinsurance & Large Commercial as well as being an expert in both design and development  of Blockchain and Smart Contract insurance solutions

Praveen Nagpal is an ACORD certified expert in Global Reinsurance & Large Commercial as well as being an expert in both design and development  of Blockchain and Smart Contract insurance solutions