Is Insurance the Killer Use Case?

Insurance is one of society’s fundamental products.

Through a variety of payment, indemnity, and cost-sharing mechanisms, insurance protects processes, businesses, assets, and even the value of human life. The migration of these products to the blockchain feels simultaneously sporadic and inevitable, which can be tremendously frustrating for participants and investor-spectators alike. But we must, as either participants or observers in the space, be skeptical of insurance schemes that are based on information that cannot be verified (from a claims perspective), representations that are not authenticated (from an underwriting perspective), and values that are highly speculative (from a loss reserving and accounting perspective).

That’s where smart contracts come in.

Smarter, or at Least More Digital, Contracts

The ability to host, execute, and enforce smart contracts is one of the key features that distinguishes ecosystems like Ethereum from other chains like Bitcoin. These contracts are programs that reference on-chain assets and network locations and allow for the redistribution of assets among locations subject to certain rules, triggers, or contingencies. The terms of these contracts are not, however, unique historically or functionally; they imitate or effectuate mechanisms that have existed in the form of paper contracts for centuries.

When I think about contracts that are most likely to become prevalent, or even preferred, in on-chain form, I tend to think of contracts rolling out in the following order of priority:

1. bills of transit (airbills, manifests, etc.),
2. parametric insurance contracts,
3. reinsurance arrangements,
4. contracts covering actual loss (once the ground truth needed for the claim is also on-chain),
5. indemnity agreements of various flavors,
6. letters of credit, and then (many years later…)
7. the purchase and sale of publicly traded securities (and perhaps never in some jurisdictions).

Yet relative to contracts 1 through 6, the purchase and sale of publicly traded securities on-chain (7) seems to be much further-developed than on-chain insurance. However, just because on-chain insurance isn’t happening quickly does not mean it’s not happening at all or that it won’t happen. It’s important to contemplate and to understand why some business processes are migrating on-chain more quickly than others. Further, it’s relevant to consider which insurance processes won’t soon be blockchain processes (e.g., underwriting, at least until credit ratings and other inputs are trusted on-chain values) and worthwhile to think about which “middleware” firms are best positioned to create on-chain systems for insurance policy administration, claims handling, and reinsurance.

So why have insurance policies taken so long to migrate on-chain, especially given that many Fortune 500 insurers have taken a deep interest in blockchain technology?

That’s the question I hope to answer in this blog, which I write en route to Hong Kong as the 2019 Asia Blockchain Summit wraps up and as attendees (including me) arrive for RISE Hong Kong 2019, a key Asian conference for blockchain, FinTech, and trading technology. This is my third visit to RISE, and my first visit representing FRST (www.frst.com).

Traditional Insurance Policies and Challenges

Before addressing the question posed above, it may be helpful to start with my personal history with insurance, where I’ve spent a substantial portion of my career. One area of the industry in which I’ve been deeply involved is the design and deployment of traditional insurance policies, including those created for target market sizes in the millions or tens of millions of customers. Specifically, I spent about a decade working as a consultant on the construction or redesign of two product sets: innovation in insurance (broadly defined) at a Fortune 350 property and casualty insurer and, prior to that, innovation in insurance (again, broadly defined but centered upon agricultural insurance) for a global top 10 (by customer/policyholder headcount) financial services firm.

Through this lens, I’ve come to deeply appreciate that the biggest challenge for insurance is capturing what we call “ground truth.” As anyone who has thought more than superficially about blockchain certification of any fact or transaction will realize, the problem isn’t the blockchain itself, which is self-propagating and self-authenticating. The problem, instead, is the input. “Garbage in, garbage out,” as the saying goes. And that’s as true on code as it is in audit as it is in blockchain. To illustrate this, an example on a logistics blockchain may be helpful.

Suppose you encounter a fraud scenario wherein the problem is that a trucker, carrying perishable goods, tends to arrive an hour or two late at the freight depot. Under current conditions, upon arrival at the depot, the driver can toss a pack of cigarettes to the guard at the gate and say, “Hey, Bob, write down 9:00 a.m. on the sheet” when it’s really 10:45 a.m. The problem is, if that log sheet is what gets entered into the blockchain system, the blockchain has done nothing to prevent fraud and is no better than existing paper-based or database solutions. If the “truth” control systems aren’t in place, no amount of “blockchaining” is going to outperform any other kind of recordkeeping.

At the end of the week, you’re still left wondering why you own a 40-foot container of spoiled produce and the only thing that’s improved is Bob’s chance of death from lung cancer.

The same problem is common in insurance. If the inputs are bad, the claims fraud prevalence and the net loss ratio will be the same, blockchain or not. If inputs and recordkeeping are more reliable, then some portion of fraud may be detected, if not prevented. And this is why IoT containers that detect water intrusion and perishables units detecting refrigeration malfunctions matter — because those are actual, accurate on-the-ground observations of what’s going on. The more rigorous, more empirical the approach, the more likely blockchain ledger records will be helpful.

So the real question then becomes “what is the input”?

And that’s why parametric insurance, combined with IoT, is such a good fit for blockchain applications. It doesn’t actually matter what the insured party reports, or what losses are claimed, or what contest is presented (a “contest” is a refutation of the claims payment’s sufficiency). Instead, the ship either sank or it didn’t; the shipping container either went overboard or it didn’t; the rainfall either reached the mark or it didn’t. And, as a result, the insurance amount is either payable or not. The system is clean, efficient, nearly costless, and binary. Blockchain is ideal for this scenario because the contracts are designed for clear, directly observable inputs resistant to or immune to fraud.

Slow Move to the Blockchain

Although blockchain is ideal for insurance, as someone who has designed insurance products purchased and used by millions of people, I’m skeptical that all insurance will suddenly move to the blockchain and think it’ll be a long time before all the data going into blockchain systems will be reliable. Personal lines property and casualty insurance, like homeowners and personal auto (personal lines P&C in industry lingo), is likely years, if not decades, from wholesale blockchain integration as the industry standard. But known-counterparty settlement payments between reinsurers could happen today on-chain.

However, parametric transit-and-logistics insurance won’t be far behind, as logistics are already being logged on-chain in preparation for insurable transfers. In the meantime, parametric insurance models are likely to dominate on-chain, which is why I think this contract form should follow bills of lading in the list of contract prevalence and priority (nearly all bills of lading show, whether they are digital or physical, a signature of both the consigner and courier of goods, affirming the manifest and time of delivery; absent collusion between consigner and courier, whose interests are generally adverse, bill fraud is extraordinarily rare).

On the one hand, an industry where the product is a legal contract (and insurance policies are simply contracts) seems inherently well suited to a blockchain smart contract environment. On the other hand, it’s easy and tempting to underestimate the translation difficulty of these business processes and interactions from a legacy of ink signatures and filing cabinets to a digital, nearly frictionless, self-authenticating environment. I truly believe on-chain insurance contracts are the future and have believed this since 2014 or 2015, but, like reliable nuclear fusion and portable quantum computers, insurance on the blockchain seems always “just a few innovations away.”

At FRST, we’ve been honing our capabilities to not only disassemble (decompile) smart contracts but to also deeply understand their meanings, locate their parties, and identify any payments made subject to their terms. This research is in its earliest stages and is informed through access to contract template design information from some of the world’s leading insurers and reinsurers. These research projects, and the underlying mechanisms, will change and evolve over time. It’s vitally important to understand that “blockchain” isn’t by itself a silver bullet — it’s also a process requiring nuanced integration and diligent maintenance; there’s no “set it and forget it” business process, and that includes blockchain.

FRST is a blockchain analytics software company and does not endorse or offer any insurance products of any kind. This blog is not an advertisement, proposal, or solicitation for any kind of insurance business or insurance product and the design of risk and indemnity products should only be undertaken by experts with the benefit of advice from knowledgeable subject matter experts and underwriters. Karl T. Muth, Ph.D. has consulted for a variety of banks and insurance companies in the US and internationally, but this blog does not represent the plans, strategies, or views of any particular company and does not speak as to those firms’ product plans or on those firms’ behalves.