Smart Contract-based Insurance Policies in Praxis

We recently explained the benefits of implementing insurance policies in smart contracts. We have also discussed privacy issues and how Black Insurance deals with privacy protection by interfacing a private consortium blockchain with the public Ethereum chain.

In this article, we will look at how insurance policies can be implemented in smart contracts using a real-world example.

An Example Insurance Policy Contract

Imagine you are organizing events that rely on good weather. In case of bad weather, the event is canceled, and you lose money. A clever insurance provider might see this as an opportunity for an innovative insurance product and provide an insurance policy that compensates you in case of bad weather at the event’s location on the event’s date.

According to the Black Insurance model introduced in a previous article, this type of policy is underwritten by a group of investors organized as an insurance syndicate. Therefore, the insurance contract will need some code for investors to pay into syndicates and to allow insurance syndicates to underwrite the insurance.

In Hyperledger Fabric, the following function signatures provide entry points to these functionalities:

function onInvestInSyndicate(syndicateInvestment);
function onUnderwritePolicies(policyUnderwriting);

We also need a transaction for issuing new insurance policies:

function onIssueNewPolicy(newIssuedPolicy);

Issuing a policy is limited to accounts held by insurance brokers.

We will not look at the details of these functions in this article. The above code merely serves to illustrate the smart contract’s interface.

Let’s instead look at how claims are made, as this can teach us an interesting concept of smart contract-based insurances; namely, the ability to automate insurance procedures by interfacing with external systems.

Whitelist to the Black ICO now, to secure a bonus!

Interfacing with the Real World through Oracles

There are two functions that allow insurance claims to be made in our example:

function onSubmitClaim(claimSubmission);
function onSettleClaim(claimToSettle);

Claim processing is split into two transactions due to a Hyperledger Fabric-specific optimization.

An interesting feature of making a claim through a smart contract is that claim validation can be automated in some cases. A bad weather insurance can connect to a weather data monitoring system to automate decision making. The decision on a claims acceptance can be based on real data, such as rainfall measures at a specific location.

Interfacing a smart contract with external systems brings some complications, due to the nature of the blockchain. As we have seen before, smart contracts transition from one state to another through transactions. These transactions are validated using the underlying blockchain’s consensus mechanism. In the case of Ethereum, consensus is provided through proof of work. In Black Insurance’s Hyperledger Fabric consortium chain with authenticated participants, a more efficient voting-based consensus mechanism can be used. However, the principle is the same: all state changes are the consequence of consensus-validated transactions.

Therefore, blockchains cannot interact directly with external data to trigger state changes in smart contracts. To achieve this, trusted data feeds are required. Such a feed is called an oracle and can be defined as follows:

A blockchain oracle is an agent that obtains and verifies external data and puts it at the disposal of smart contracts.

Oracles may come in the form of web APIs, sensors or any other machine to machine interface.

There are security complications, in that we have to be able to trust the external data source. To mitigate this risk, off-chain trusted computing techniques may be used, such as TLSNotary proofs, which we won’t go into detail here.

In our example, an oracle provides the weather data of a certain location to verify a claim. In fact, we can go one step further and structure the policy in a way that allows the claim to be submitted directly by the oracle. To this end, only the oracle can invoke the submit and settle claim transactions. Using this pattern, we treat the oracle as a trusted user that holds the only valid private key to execute these functions.

Verifying that the origin of the submit and settle transactions is indeed the oracle is easily achieved in Hyperledger Fabric. We just have to include the following check in both functions:

if (transactionRequestingUser.getFullyQualifiedIdentifier() !==   ‘insure.black.poc.PlatformUser#RAIN_ORACLE’) {
throw new Error(‘Transaction can only be submitted by RAIN_ORACLE’);
}

Now, on submitting the claim we have to check the validity of the claim by comparing the weather data attached with the thresholds specified in the policy.

If the claim is valid, the smart contract calculates and approves the payment.

In the separate settlement transaction, the payment is processed, increasing the policyholder’s balance by the approved value and subtracting the same value from the balance of the insurance underwriter.

Final Thoughts

The above example shows a real-world use of smart contract-based insurance policies. The example also highlights one the advantages of using smart contracts, namely process automation. In this case, we have shown how to automate claim processing by using a trusted data feed as an oracle.

The example also illustrates the type of innovative insurance products made possible by the Black Insurance concept.

Be sure to check out our website as well as connect to our social media on Telegram, Facebook, Reddit, Twitter, LinkedIn and Bitcointalk.