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:

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.

The shallowness of the trustlessness value proposition is reinforced 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).

“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 they’ve created an X-less outcome 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.

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.

To ensure high availability of its centralized app, a company

Needs to hire DBAs to provision access rights to ensure integrity of content of central database (this is apart from having to buy server, operating system and database software)

Set up ACTIVE:ACTIVE clustering to provide redundancy / fault tolerance

Invest in secondary disaster recovery site for business continuity.

All of this costs a lot of money in manpower, cybersecurity tools 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 and #3 for a relatively low-ticket flight delay insurance system. I say this on the basis of my following experience:

A leading financial institution couldn’t find a strong enough business case for investing in ACTIVE:ACTIVE infrastructure even for a high value payment system

When floods once struck the English town in which a bank’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 and distributed across multiple nodes. As a result, a dApp is inherently shielded from data breaches and intrinsically enjoys extreme fault tolerance. More on this in “Blockchains vs Centralized Databases”, an excellent article from Gideon Greenspan of Multichain.

In a nutshell, you get a highly robust application on the Blockchain virtually free-of-cost. (Actually virtually free only of fixed cost. Variable cost in the form of Gas Price does apply for dApps. But that’s a story for another day.)

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 limited knowledge and experience on the subject, I think the real reason to opt for a decentralized Blockchain architecture over a centralized database architecture is Robustness, or more specifically, lower cost of achieving robustness.

That’s not 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.

This entry was posted on Friday, February 2nd, 2018 at 11:30 AM and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.