Flight Delay Insurance – Why Blockchain?

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 of the above two posts:

…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 answers 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 / Jane Customer has no say
  • An average air traveler is not a cryptodeveloper, so doesn’t gain anything from its assurance that “any crypto developer can check the validity of the information we store there (on the Blockchain)”
  • After fizzy has written the transaction on the Blockchain, I may not need to trust AXA to pay out but I still do need to trust its Flight Data Provider (FlightStats.com or 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 original 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
  • 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 (it’s another matter that even a cryptodeveloper won’t be able to understand the fineprint in an insurance policy).

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. I’ve read at least two serious rebuttals to Blockchain’s claim to being inherently trustworthy:

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! To quote Stephan Karpischek, Co-founder of Etherisc and disrupt consulting, from Flight Delay Dapp — lessons learned,

Of course we want decentralized governance! Yes, please! In the end this is one of the main reasons why we are so excited about blockchain. However, we all know that bugs are inevitable, and bugs in smart contracts tend to have drastic consequences. So some form of emergency control and upgrade paths are necessary, and this is much easier to realize with central control.

And as Kai Stinchcombe explains in Blockchain is not only crappy technology but a bad vision for the future:

When the novelist proposes the smart contract, you take an hour or two to make sure that the contract will withdraw only an amount of money equal to the agreed-upon price, and that the book — rather than some other file, or nothing at all — will actually arrive. Auditing software is hard! The most-heavily scrutinized smart contract in history had a small bug that nobody noticed — that is, until someone did notice it, and used it to steal fifty million dollars. If cryptocurrency enthusiasts putting together a $150m investment fund can’t properly audit the software, how confident are you in your e-book audit? Perhaps you would rather write your own counteroffer software contract, in case this e-book author has hidden a recursion bug in their version to drain your ethereum wallet of all your life savings? It’s a complicated way to buy a book! It’s not trustless, you’re trusting in the software (and your ability to defend yourself in a software-driven world), instead of trusting other people.

Technology is full of X-less claims e.g.

  1. ebilling will drive paperless billing
  2. digital payments will lead to cashless societies, and
  3. digital channels will result in branchless banking.

Most of them have failed at their mission to eliminate X. But many of them have indeed created a less-X outcome in the process e.g.

  1. ebilling has driven less paper billing
  2. digital payments has led to less cash societies, and
  3. digital channels have resulted in less branch banking.

I was about to conclude that, in the same vein, Blockchain will aspire to trustless but will at least achieve lesstrust.

I changed my mind 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 agency. When a Smart Contract attracts stamp duty, it introduces government as a Middleman and thereby belies the claim that Blockchain helps two parties conduct business without an intermediary. By needing stamp duty, 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 means that Blockchain demands even more trust than a centralized application.

I know this sounds like a sacrilege to Blockchain purists, so I’m bracing myself for brickbats from them!


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

To ensure high availability of a cApp on a centralized database, its developer not only needs to buy servers, operating system and database software but also needs to do the following things:

  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 running cApps spends money on #1.  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’m led to this conclusion after my exposure to 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 I quizzed its CIO about the FI’s Business Continuity Plan after floods once struck the English town in which the FI’s primary datacenter was located, 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 Fees 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 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 per se 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.

PS: Since I published the above post, I’ve come across many updates around Blockchain and dApps that have either reinforced my skepticism about decentralization or raised new doubts about resilience or both. I’ve consolidated them into a follow on post entitled Blockchain – Calling BS On Decentralization & Resilience.