I covered two Blockchain flight delay insurance products in AXA Fizzy - The New Kid On The Blockchain and Atlas Etherisc – Another New Kid On The Blockchain.

In this post, I’ll address the “Why Blockchain?” question.

Here’s a quick recap of the background to this question from the first post:

=====

...the techie in me started wondering what stopped someone from developing a similar flight delay insurance product on a traditional centralized database architecture... Is there any intrinsic shortcoming with a centralized database architecture that compels one to launch this product only on the distributed database architecture facilitated by Blockchain?

=====

I’ll first examine what AXA Fizzy and Atlas Etherisc say on the subject and then share my thoughts.

Given below is an extract from the FAQ section of AXA Fizzy's website:

FAQ: Why does Fizzy use Blockchain technology?

When you purchase a policy, fizzy writes the transaction terms (price, compensation, expected time of arrival, arrival time to trigger compensation…) on a blockchain called Ethereum. The interest of the blockchain is the inability to remove previously-written transactions. What’s more, the Ethereum Blockchain is public, any crypto developer can therefore check the validity of the information we store there. fizzy doesn’t ask you to trust it, rather proves it through trustful processes. Last thing, we never share your personal information on Ethereum, your data is safe with us.

FAQ: What if I don’t agree with the delay reported by fizzy?

fizzy is based on redundant data which enables us to trust its reliability. Besides, as we are a party to your insurance transaction, we made sure that the payment of your compensation is not decided by fizzy but directly by the plane data provider. You don’t have to trust our honesty! In spite of these measures, you can contact us through the contact tab in case of any problem. You can also find here information on the EU Online Dispute Resolution: http://ec.europa.eu/odr

I didn’t find any justification on Atlas Etherisc's website for its decision to use Blockchain.

Addressing the potential buyer of its insurance product, AXA Fizzy's replies emphasize Trustlessness, which is one of the two low-hanging fruits for a Blockchain decentralized app (Robustness being the other).

As one such prospective customer, here's what I think about AXA's replies:

• I need to trust fizzy to write the transaction terms on the Ethereum Blockchain. Going by my experience with Atlas Etherisc, this is a non-trivial step
• The Ethereum Blockchain was rolled back after DAO hack. Therefore, I don't agree with fizzy’s claim that previous transactions are immutable on the Blockchain. While it could be argued that hard forks leading to rollbacks are very rare in the Blockchain world, point is, when they do happen, they're driven unilaterally by a very few people who resemble a secret cabal in which the average Joe / Joanne Customer has no say
• An average air traveler is not a cryptodeveloper, so it’s not very useful to know that "any crypto developer can therefore check the validity of the information we store there"
• I may not need to trust AXA after fizzy has written the transaction on the Blockchain but I still do need to trust its Flight Data Provider (whoever it is).

Prima facie, the claim of trustlessness lacks depth.

It becomes even shallower when I compare these two insurance dApps with a conventional insurance product running on a centralized database architecture (herewith "cApp"):

• Once I buy the policy, I get a policy document. I can take a printout to prove the transaction in case the Insurer tries to change it later. Besides, in my experience of buying dozens of insurance policies in four countries over three decades, not a single insurer has ever changed the terms of the policy after issuing it (not saying they won't in future, though)
• I don’t need to be a cryptodeveloper to understand the basic terms of the policy. Even an average air traveler can understand parameters like price, compensation, expected time of arrival, arrival time to trigger compensation (of course, even a cryptodeveloper won't be able to understand the fineprint of an insurance policy).

https://twitter.com/GTM360/status/915509365758726144 (see Exhibit 1 at the end of this post)

I know Blockchain is evolving. But, at this juncture, it's hard to accept that either of the two flight delay insurance dApps I've encountered exhibits trustlessness.

And I’m not alone. As btcethereumadmin says here:

“Even an open-source project like Bitcoin that is constantly being reviewed can have trust issues, not from the code but by the developers and reviewers of the code. So trustlessness is more of a term describing an ideal state on the blockchain where code is law with the caveat that humans write code and to err is human.”

And to forgive is not divine – at least not to IT services companies who make tons of money from SIT, UAT and other testing phases of a software project!

Technology is full of X-less movements e.g. ebilling drives paperless billing; digital payments drives cashless societies; and digital channels drives branchless banking. Most of them have failed at their X-less mission. But many of them have created a less-X* outcome in the process e.g. less paper, less cash and less branch in the case of ebilling, digital payments and digital channels respectively.

I was about to conclude that Blockchain is another such movement that will begin with trustless and end with lesstrust.

That changed when I saw the following screen on the Atlas Etherisc website.

(see Exhibit 2)

Yes, you saw that right: Stamp duty for a Smart Contract!

Stamp duty comes into picture while registering an agreement with a government authority. When a Smart Contract attracts stamp duty, it belies the claim that Blockchain helps two parties conduct business without an intermediary. It appears that Blockchain insurance policies issued by Atlas Etherisc do have an intermediary, namely, the government of Malta.

Based on this experience, a smart contract not only calls for trust in technology but also requires the blessings of a government.

This suggests that Blockchain demands more trust than a centralized application.

I know this sounds like a sacrilege to Blockchain purists, so I'm bracing myself for a few brickbats from them in the comments!

----------

Let's move on to Robustness, the second raison d'être for Blockchain dApps.

Apart from having to buy servers, operating system and database software, a company needs to do the following things to ensure high availability of a centralized app:

1. Hire DBAs to provision access rights to ensure integrity of the database
2. Hire Cybersecurity specialists to protect the database and application from DOS attacks and otherwise being hacked
3. Set up ACTIVE:ACTIVE clustering to provide redundancy / fault tolerance
4. Invest in secondary disaster recovery site for business continuity.

All of this costs a lot of money in manpower, hardware, software and real estate.

I'm sure that every insurance company spends money on DBAs and cybersecurity tools to run its current cApps. However, I strongly doubt if many of them will be able to justify the high costs of #2, 3 and 4 for a flight delay insurance system. I say this on the basis of my following experience with a high value payment system owned by a major financial institution:

• The FI couldn't find a strong enough business case for investing in ACTIVE:ACTIVE infrastructure
• When floods once struck the English town in which the FI's primary datacenter was located, I quizzed the CIO about his bank's Business Continuity Plan. He quipped, "Mops and buckets"!

Contrast this with a Blockchain dApp. Transactions are cryptographically locked down, so automatically permissioned. Data is distributed across multiple nodes, so there's no single point of failure (apart from the hosting provider of the dApp website, that is). As a result, a dApp is intrinsically shielded from data breaches and inherently enjoys fault tolerance. More on this in “Blockchains vs Centralized Databases”, an excellent article from Gideon Greenspan of Multichain.

In a nutshell, you pay virtually nothing to get a highly hardened application on the Blockchain (virtually nothing by way of fixed cost, that is. dApps do attract variable cost in the form of Gas Price but that's a story for another day.)

https://twitter.com/GTM360/status/952820223895310336 (see Exhibit 3)

----------

AXA Fizzy spins its choice of Blockchain as a customer benefit by emphasizing trustlessness. (I didn't see any spiel for Blockchain on Atlas Etherisc's website.)

I don't buy it.

Based on my current knowledge and experience on the subject, Robustness is a stronger driver for choosing Blockchain. More specifically, lower cost of achieving robustness.

Although that seems like another example of Hiding Your Secret Sauce, it's not per se a bad thing.

Lower cost is a benefit for insurance providers but higher robustness is a customer benefit.

This was driven home for the nth time when I had to link my insurance policies to my Aadhaar Number (per government mandate). All the three times I visited my insurer's website to carry out the so-called "Aadhaar seeding", the website was down.

It struck me that, if only the insurance company had used the Blockchain for its insurance applications, it would have delivered 24*7*365 operations at no cost and delivered superior CX compared to a traditional centralized database architecture.

UPDATE DATED 6 AUGUST 2018:

By connecting millions – even billions – of underutilized hard disks and storage systems in a Blockchain-managed storage mesh, Blockchain-based decentralized storage companies like Storj, Sia and FileCoin promise to drastically cut down storage costs. According to NSM’s eBook entitled The CMO Primer For The Blockchain World, “Storj already has one enterprise customer in pilot phase and the estimates are that, so far, they will be able to reduce costs of storing data by 90% when compared to AWS.”

So, low storage cost is another factor that works in favor of the Blockchain architecture over a centralized architecture.

---

*: Update dated 21 Feb 2018: This was misstated as "X-less" before.