White Paper: Insurance Coverage on the Blockchain

Insurance Coverage on the Blockchain:

An example framework using the cannabis industry’s seed-to-sale model

Robert B. Dundas

rbdundas@gmail.com

Original Document

Executive Summary

A blockchain capable of supporting both currency transactions and smart contracts is an ideal foundation on which to build and market insurance products and applications; i.e. smart policies. The transparency and accountability of a decentralized ledger furthers this by allowing for peer claim validation and self-policing. Automatic triggering events and metadata contribute to the overall processing of claims and coverages to create precision policies; thus reducing exposure and premium costs. The cannabis industry is poised to implement a method of tracking seed-to-sale on the blockchain, making it an ideal candidate on which to implement this new model of insurance.

Introduction

Striving to operate outside laws and regulations, cannabis businesses have relied on cash-based transactions, hand-shake contracts, operating without coverage or protection, and other illegitimate business practices. The laws that once kept cannabis in the shadows are now changing and states are adopting laws allowing for cannabis use. At this time, 29 states have adopted laws for the usage of medical cannabis and 8 states have passed recreational use laws. Cannabis business operators are now incorporating traditional business practices and tools, such as accounting, inventory management, POS systems, etc.  Because of their ‘under the radar’ business approach, traditional insurance companies are reluctant to extend their exposure to the emerging cannabis industry, forcing these new businesses to bear the risk for any and all losses. This white paper will address a framework for offering insurance products to cannabis businesses leveraging a smart contract aware (i.e. Ethereum) blockchain, thus providing the coverage needed to stay operational in the event of a loss.

 

In addition to overcoming laws and regulations, cannabis businesses are almost entirely cash based. Many businesses have already adopted the use of the blockchain for buying and selling goods as an alternative means to reduce the risk of transacting in large sums of cash. The Blockchain also provides these businesses with an investment opportunity, due to the increasing intrinsic values of the cryptocurrencies. With this increase in the use of cryptocurrencies for transactions, these companies are now leveraging the blockchain for their business operations without the need to exchange their coins for fiat currency, such as US Dollars. Although many individuals and companies might use the blockchain to buy or sell a single product or finite service, the cannabis industry is uniquely poised to support the use of the blockchain across the entire industry. Starting with a seed, the registration, tracking, sales, and consumption of the final product is possible using the blockchain to trace the product as it moves through the stream of commerce.

 

Smart contracts, whether using the Ethereum blockchain or a layer sitting atop another blockchain, are a principal driver for insuring products that exist on it. As products are identified on the chain, information regarding that product is carried with it; the date it was created or purchased, the price, physical attributes, etc., can all be recorded along with the product’s unique identifier. In the case of a seed, this information might be the originating plant’s identifier, the strain, lot, harvest date, sex, and other relevant information describing that seed. When the seed is transferred from the seed bank to a grower, the information related to the seed is available on the blockchain for anyone to view. This is not unique to the cannabis industry, however, whether the product is cannabis or not, this manner of product tracking is available across any line of products. The cannabis industry  is the only industry at this time that is looking to the blockchain to address this need across the entire industry.

 

Due to federal regulations, admitted insurers are unwilling to offer policies covering the cannabis industry. Several surplus line insurers have begun to offer packages, but have restricted these policies to licensed businesses only. For the states that have adopted cannabis use laws, the number of licensed businesses will increase, but while federal law exists, few, if any, admitted insurers will offer coverage to cannabis businesses. The commissioner of the California Department of Insurance (CDI) recently announced that the CDI has just approved its first admitted insurer, however, the program itself is offered and serviced by a surplus lines insurer.  An environment now exists where businesses are in need of insurance but few insurers are providing coverage, none of which are offering a product on the blockchain, a technology that the cannabis business is looking to adopt to support the entire industry, end-to-end, from seed-to-sale.

An Overview of Insurance on the Blockchain

Insurance is an agreement to compensate an insured for a specified loss for payment of a premium. Commercial insurance can be roughly divided into three main categories; property, liability and loss of income. In the cannabis industry, product insurance would provide insurance coverage for  the seeds, plants, harvest and ultimately processed units; i.e. edibles, oils, flowers, and other consumable units. In addition, the goods that are used to consume the cannabis; pipes, vaporizers, cartridges, etc., and ancillary products would be covered in the event of a specified loss. Traditional property insurance can “blanket”  products into a single estimated value, and the business would purchase a policy covering the “blanketed”  limit  for a specified term, usually one year. If a covered loss occurs , these products are not evaluated at a single unit level, rather, they are evaluated according to the percent they contribute to the overall aggregated amount or to the policy limits.

 

Using a global ledger, these products are visible to everyone on the blockchain, instead of a store owner’s proprietary software. Therefore, , it is visible when the products are bought and sold, as well as when a product is marked as destroyed. The use of the blockchain in this way is an ideal foundation on which to insure goods and services as self-aware, smart contracts, or for insurance, “smart policies”. Here, the agreement is captured on the blockchain first with the identification of a product and its value, then with terms and conditions of a policy that will compensate the product’s owner during the policy term if a loss were to occur.

 

For example, a dispensary purchases 100 electronic joints (eJoints) from a supplier at $10 each. Each of these products are uniquely identified in the dispensary’s inventory management software, which creates a record representing each eJoint on the blockchain. The dispensary purchases a smart policy on the blockchain listing each of the eJoints. As each are sold, an event occurs on the blockchain describing the transfer of it from one wallet to another, along with the transaction cost and any other sales details. A coverage event has occurred and the owner no longer requires insurance coverage for that item. A second situation occurs when a covered event ends with the destruction of one of the products. When the dispensary marks the item as destroyed within the inventory management software, a second event is recorded on the blockchain. Both of these events are visible on the blockchain, and both are covered  events triggering the smart policy. In the first, the coverage requirement has changed and the policy will no longer cover that item, which may result in pro-rata reimbursement. In the second, the smart policy would be triggered, and the coverage value would be transferred to the policyholder.

 

This simple example illustrates the interaction between the blockchain and the smart policy. As products are entered and described on the chain, they are visible to not only everyone using it, but all software interacting with it as well. These triggering events allow for the programmatic execution of logic built within each smart policy. The above is a very simple example of a single product, however, this model can be scaled up to include as many products as required.

 

Product registration is not a prerequisite to provide insurance using the blockchain, it merely allows for the complete automation of steps, thus simplifying the policy to its most basic components. This simplification allows for coverage precision and the reduction of resources required to process each claim. Coverage, claims, collection of premiums, payouts, etc., all become automatically processed.

What is a Smart Policy?

A smart contract is the use of a blockchain to control the automatic transfer of property, such as cryptocurrencies, between parties based on conditions that have been programmatically built as triggering events. Expanding this definition to insurance, the smart policy is a contract for insurance that has been programmatically created to self-execute against the blockchain as a result of a covered loss event.

 

Using the above product example, the dispensary’s eJoint smart policy would initiate the moment the product information was committed to the blockchain and terminate the moment it was sold or destroyed. The smart policy itself is a computer program that has been given the parameters necessary to determine whether a loss event has occurred and whether a payout is required. When the rules governing the contract are simple, the contract itself is simple. As the contract becomes more complicated, the code underlying the smart policy becomes more complicated. The identification of a product on the blockchain and its corresponding event, whether destroyed or sold, is a very simple model to translate to the blockchain as a smart policy. However, the variability and durational length of lawsuits is not as easily translated; therefore, liability coverage is possible, but will require a more sophisticated approach in the software and the way in which claims are tracked and ultimately satisfied.

 

With traditional policies, coverage is depicted as an umbrella over which the insurer protects the policyholder from financial losses as they rain down upon the insured. In those traditional settings, these products are lumped into a sum value and losses are recorded in terms of percents against that sum. When the loss occurs, the insurer looks to the percent loss claimed compared to the overall value and determines the amount of compensation. Here, the smart policy can be as granular as the individual plant — which itself can be traced to the originating seed — or as wide as an entire crop.  

 

Due to the granularity and transparency of transactions and information on the blockchain, it is possible for policies to cover individual plants, instead of an entire farm. This precision coverage reduces the exposure of the insurer while providing the insured with exactly the coverage they require, saving costs by eliminating coverage that is not required.

 

A policy can be sold as blanket coverage or as individual coverages. For example, These details are built into  a “property”  smart policy and recorded against the blockchain. In the event of a loss, the policyholder must record the loss on the blockchain, where, once completed, claim validation and payout are triggered.

 

How are loss events covered?

Traditional insurance companies rely  on the “law of big numbers” to collect enough premiums for a given exposure to offset the number of claims required to pay out to the policyholders and pay for company expenses and profits. The greater the number of policies sold, the more money the insurance company collects , and the less likely one common event will impact the book of business for that  exposure.

 

In the blockchain model, this is not required.

 

Instead, pools will be used to ensure that there is enough coverage for all exposure. While the traditional policy term is typically 1 year, here, the policy term can be days, weeks, or months, and would vary from product to product. Each policyholder would buy into their policy pool — a wallet that has been created specifically for their policy. At the expiration of each policy, the amount of premium collected for that terminated policy would automatically transfer to the group pool, where similar risk policies are used to combine or  share the same risk exposure. Once a threshold has been reached for the group exposure pool, excess amount pours into the super exposure pool. The super pool will include enough cryptocurrency to ensure adequate coverage for the entire risk exposure. Finally, once the threshold amount has been reached for the super exposure pool, excess amounts are transferred to the operating pool, which will be used for the operation of the company; operating costs, salaries, etc.

 

As individuals record their products against the blockchain, the micro-policy is created against each product. These micro-policies are aggregated into a single policyholder account, where products within the policy are added and removed according to their selling status or destruction on the blockchain. As described, the policies themselves may be as granular as a single product for a single named peril (i.e. theft), or as broad as all inventory for an all peril. Actuaries will be required to determine the full scope of coverage versus the premiums charged.

Claim Processing Against the Blockchain

Due to the seed-to-sale nature of the cannabis industry, there is complete product visibility from the origin of the plant to its final consumption. As the product moves through the supply chain, we are able to trace the product to the steps that preceded it and track it throughout its lifecycle. An insured must be able to interact with the chain to record the products and the loss events against the blockchain (see IBM above). When the insured submits a claim, the event is recorded against the blockchain, along with the details surrounding the event. For a micro-policy, the event would list the individual product identifier along with whether the product was completely or partially destroyed.

 

Using the eJoint example, a micro-policy would exist for a single eJoint. The cost of the product is $10, and the micro-policy premium is $1. When the dispensary recorded the inventory against the blockchain, the micro-policy is purchased and the dispensary was automatically debited for the amount. During the term period, an occurrence was recorded  and the eJoint was destroyed. The dispensary enters the information within their inventory management system and the claim is automatically submitted against the micro-policy. The smart policy then validates the status of the eJoint product identifier and the claim, where once the product is determined to be destroyed, the claim is automatically satisfied by transferring the micro-policy limit amount from the policy pool into the insured’s  account.

 

This level of visibility prevents fraudulent claims from being submitted, as once the product is marked as destroyed on the blockchain, that destruction is visible downstream on the blockchain; i.e. a user purchasing the product would see that the product was marked as destroyed. Inventory software should be programmed in such a way as to remove the ability to sell a product that has been previously marked as destroyed. This visibility and the software that records against the blockchain, is the first defense against fraudulent claims.

 

This approach is a very specific and automatic approach to processing claims against the blockchain, however, the policyholder must have a complete integration between their products, the policy and the blockchain.

 

Managing blanket coverage to a smart policy

The smart policy still exists on the blockchain, however, the loose integration with it requires more manual intervention to validate and satisfy the claim. In this case, the claim and all of the details related to it are attached to the blockchain. This claim event triggers the insurer to review the claim. Here, the smart policy would be programmed to perform certain actions depending on the complexity of the claim.

 

For example, a smart policy was issued for $1,000 worth of inventory (50 eJoints that were unable to be individually identified). A claim was issued indicating that 20% of the inventory was destroyed, eg $200. The claim occurs on the blockchain as an unsatisfied claim. The smart policy would look into the details of the claim and determine whether or not automatic processing was possible (automatic processing is programmed into the smart policy based on claim amounts and coverage limits of the policies and their respective pools). Assuming that automatic processing is unavailable, the status of the claim moves to peer-validation.

What is peer claim validation?

Once the smart policy determines that peer claim is necessary, peer users and software can view and validate the claim. For example, a claim for a total loss against a particular plant would be visible to a subsequent buyer for that plant.  This peer-visibility would act as a first defense and primary deterrent against fraudulent claims. If further investigation was required, peer claim adjustment would be a second layer of claim validation, where the entity immediately prior or following the entity making the claim (i.e. suppliers and customers) could endorse or reject the claim. Analogous to a co-signer on a loan, the endorsing entity would be subject to the same flagging process if the claim were found to be fraudulent, thus acting as a second level deterrent.

 

Finally, third-party investigation may be required in the event of larger claims, where if the claim was found to be fraudulent, the cost of the investigation would be charged to the one submitting the claim , and another revenue opportunity for the blockchain; eg an open contract for a claim adjuster who provided sufficient evidence to refute or accept the claim.

Funding and Crowdfunding the Pools

When a smart policy terminates, the premium is automatically transferred from the corresponding pool into the next level pool above it. For example, when an individual product is sold, the micro-policy is terminated automatically and the premium is transferred from the micro-policy pool into the policyholder’s policy pool. This pool will increase as micro-policies are added and expire, but will decrease according to the claims issued against the pool. Once the policy pool is funded to an amount that covers the overall risk, excess amounts are poured into the group pool, as described above. Once the policy pool is funded, as the policyholder continues to contribute to the policy, the  excess amount may be split between the policyholder and the group pool. This will allow the policyholder to retain more income to invest in additional products or services, thus creating the need for additional coverage, while further driving the market.

 

Ideally, the balance between the risk exposure and the premiums collected will offset one another. However, this is not likely the case.

 

In addition to the individual policy funding, policies, groups and exposure pools can be funded using established crowdfunding models. For example, a dispensary may have purchased a smart policy with the cryptocurrency equivalent limit of $100,000. Patrons of the dispensary may crowdfund the policy by contributing any amount to the policy pool’s fund. As the policy terms within the smart policy are satisfied, the excess amount is available to payout as dividend payments in a percent relative to their individual contribution amount. These amounts can be adjusted to ensure that each of the pools are funded adequately for their respective exposure groups. In this way, businesses and their patrons are working together to ensure that products and services come to market, as well as providing a means in which these groups may retain coverage while providing a mechanism to provide  a return to these investors.

 

Similarly, group policies will and may be additionally funded by the policyholders within their group. As a pseudo Risk Purchasing Group (RPG), similar situated policyholders that all share a common risk, may contribute more to the overall group pool. In this way, the group shares in the risk, which decreases the claims made against the group and acts as a deterrent against fraudulent claims, and also shares in the profit once the group pool is completely funded.

 

Finally, the total exposure pool acts in the same manner as the lesser pools, but is more widely available for crowdfunding. As this insurance business is launched, an ICO (Initial Coin Offering) can be used to baseline the total exposure pool, and trickle down to fund the lesser pools. This will seed the pools with enough capital to cover the overall risks advertised. The first policies will be capped according to that fund amount, so as not to have an increase in exposure that the pool cannot satisfy.

 

Whether ICO or privately funded, the concept is the same and availability of the funding does not expire. As the business continues, shares will continue to be available for purchase according to the overall increase of the exposure pool; i.e. the more policies that are written, the greater the exposure, which leads to the release of additional “risk” shares for purchase. As premiums are collected, the exposure wallet will increase and the excess amounts will be paid out in the form of dividends per share.

The Technology

There are many models that can be applied to the above, the most straightforward of which is the use of Ethereum. Ethereum uses contract language that is already built into the blockchain, where the smart policies are written directly against the chain. Additional code and contract conditions are used to transfer funds between policy, group and exposure pools, as well as dividend payouts. As the technology emerges and evolves, the use of the blockchain will further root itself in the industry, but the use of Ethereum is not a necessary precursor to this concept.

 

Using a proprietary blockchain may allow for better contractual programming and more control over the commits against the underlying financial blockchain; ie Bitcoin, Litecoin, Ethereum, etc., but may require more code customizations and API (Application Programming Interface) development to integrate with the inventory and accounting software used by the individual businesses.

 

In either case, the foundation will exist on a blockchain and programs must be written to allow customers to build and customize their individual policies. A rules engine must be built to allow users (humans that define policies) to write rules that would translate into smart policy conditions and ultimately into coverages, premiums and limits for each policy. As end-users (customers) interact with the rules engine using a website or mobile application, they enter information that is relevant to their budget and needs. Rules will be selected from the rules engine where each rule corresponds to code that will be added to the smart policy and executed when specific triggering events occur.

 

For example, in the simple case of the eJoint, the customer might enter the eJoint product number, cost, and information into the policy. The rules engine would select a rule corresponding to an electronic cannabis product allowing for automatic claim processing as a micro-policy. The rules engine would interact with the customer to indicate coverage limits for the item, such as 100%, 90%, 80%, etc., replacement cost, where the lower the percent replacement, the lower the premium cost for that micro-policy. Once the rule is selected and the rule conditions are satisfied, the corresponding code is added to the policy. Because this provision of the smart policy is completely contained within the rule, where the execution of the rule is Boolean (true or False), it is a self-executing micro-policy. As more complicated rules are added to the rules engine, more interaction is required from the policyholder. These rules may require additional human interaction at the time the policy is created or when a claim is submitted against it. For example, it may be sufficient to have a rule that creates a coverage limit of $100,000 for the peril of theft , but satisfying the claim against it would require more.

 

Rules created that can be satisfied automatically can be issued at a reduced cost, because they require less resources to process the claim. Rules that require more interaction, require additional resources; therefore, they cost more to the customer.

 

The rules are written and stored within the company’s database. Each rule will correspond to a set of code that will be added to a customer’s policy. This code will eventually be the code that is executed during one of the triggering events, such as a claim event, payout or policy termination. APIs will be written to interact with the rules engine so that other software — proprietary software or inventory and accounting software created by another technology provider — may make an API call while using the software to retrieve the rule and add it to the policy. As the policy is built, the code is added to the policy until the customer is satisfied that the policy is complete and comprehensive, where the customer then commits the policy to the blockchain. Once committed, coverage is automatic and the premium amount is transferred from the customer’s wallet into the corresponding policy pool(s). At the moment of the commit to the blockchain, the policy becomes global and cannot be undone.  

 

Application Programming Interfaces (APIs) will be written to interact with the rules engine to select the rule and the corresponding code that will ultimately build the smart policy. The APIs will be written in various languages; JavaScript, Python and C++, that may be used by developers of other software to integrate with their own software and interact with the blockchain. These APIs will be the foundation on which this company’s own software is used to interact with the blockchain. In this way, all use is through the same set of APIs, reducing integration errors and interoperability between the insurance company and the various integrated software.

 

APIs should be encapsulated to work against only the designated corresponding wallets. Withdrawing from one pool to another may be automatic at the lowest level, but less so as the pools increase. One advantage of using a proprietary blockchain is to isolate the blockchain from potential hacking and other malicious behaviour.  

Further Consideration

The intent of this white paper is not to layout the foundation of a new insurance company. Instead, it is to present a possible model for how insurance might leverage the blockchain to build policies, collect premiums, submit, validate and satisfy claims, and terminate policies, both automatically and manually.

 

Regardless of the direction of the cannabis industry, the foundation and functionality remains the same. Smart policies can be written using a rules engine that corresponds to policy conditions and code that will ultimately execute against any blockchain. This policy approach may be used for any product or service and against any blockchain.

 

Biography and Contact Information

By Robert B. Dundas

rbdundas@gmail.com

 

Robert B. Dundas is a California-based attorney and licensed insurance broker specializing in the Cannabis industry (cannabisinsurancesales.com | The Dundas Agency, Inc.) and author. He has 18 years of experience as a software developer and Senior IT Program Manager for Seagate Technology, LLC., where he built and supported the company’s eCommerce and internet based B2B sales platform, and an IT officer for Sarbanes-Oxley compliance.