Hacker News Reader

Comment by fabian2k | Hacker News Reader

> A commonly cited application of smart contracts is insurance, where supporters believe smart contracts can simplify the claims process and encourage faster payouts.

I don't see how this makes sense at all. The big problem when handling insurance claims is determining the facts and then interpreting the insurance conditions. None of these can happen on the blockchain, so this information would have to come from an oracle, and in the end you still need to do pretty much exactly the same thing. This would be really more like an unnecessarily complex way to add a mandatory arbitration clause to the insurance. That would result in the same result, another entity chosen by the insurer will judge claims and decide on them. Adding a blockchain here doesn't seem to provide any value at all.

View on HN

AXA trialed a blockchain insurance product called fizzy. The concept was that you bought the insurance, and an oracle published flight information, and if your flight was delayed, the payout was automatic.

They haven't continued with it, so it may have had problems, and I don't know if it required proof that you actually had a ticket (not doing so could create various problems), but actually I think the blockchain is a great option for this.

The reason is that many people do not trust insurance companies. There is a feeling that they will find any excuse to avoid paying out. To have a blockchain solution where payout is according to a smart contract that is transparent and public is a way to build trust with your customers.

After quickly looking this up, it looks like this automatically sent the money to a supplied credit card. There is no part here that actually needs a blockchain or smart contracts, it's just automated evaluation of the insurance claims. The "smart contract" can't force AXA to pay money to your credit card, so it's entirely superfluous here. You could implement the same thing witout a blockchain or a smart contract.

Sure - this product may not have ultimately worked, but the general concept is finding ways to make insurance payouts more transparent. That is actually a good idea given the severe deficit of trust in insurance companies that has been identified as one of the issues stopping people purchasing insurance.

The point is not that the product didn't work. The point is that the use of blockchain technology had absolutely no (positive) impact on its viability or usefulness or reliability.

Blockchains have very few very specific usecases, and nobody wants to admit that their usecase isn't one of them.

Your point seems to be about this specific product.

My point is about the idea of using a blockchain to increase transparency and verifiability of a process that makes payments.

This is one of the 'very few, very specific' use cases that blockchains are good at.

You don't seem to understand what the previous poster said: all of this can be achieved with a database that allows some open access. You don't need a consensus protocol on a distributed system.

I'm absolutely aware that there are other possible solutions, although I doubt any of them are as practical as a smart contract blockchain solution.

Given that you seem to think that it's not that hard, I wonder if we have a different understanding of the requirements here.

We're trying to make the payment process more transparent and verifiable as a way of increasing trust. You say that we can do that with a database that allows some open access. I don't really see how.

For example - who runs that database? If it's the company that offers the insurance, it's a nonstarter - it doesn't help with trust. If it's some third party, then it's precisely as useful as the trust the customer has in that third-party. Such an approach could work, but in my opinion brings with it more difficulties than a blockchain solution in most cases.

Even if we do find someone trusted to run the 'database with some open access', there's still the question of being confident that payments are made according to the data in the database, and that the data in the database is updated according to the appropriate rules.

> If it's the company that offers the insurance, it's a nonstarter - it doesn't help with trust. If it's some third party, then it's precisely as useful as the trust the customer has in that third-party.

Don't oracles have the same issue?

> Don't oracles have the same issue?

Great point. And yes, there's a trust issue around oracles. I do think that these are dramatically less problematic than some of the other options though.

An organisation that publishes flight data and charges for it, is incentivised to produce accurate, timely data about flights.

If instead we have an insurance organisation keeping a database storing information about claims, its incentives are much more muddy.

I think this is another example of how trust isn't just a full on / full off thing, but that you can make meaningful improvements in trust that can have useful economic consequences even without solving it perfectly.

> An organisation that publishes flight data and charges for it, is incentivised to produce accurate, timely data about flights.

Depends on who pays, right? If their only consumers are insurance companies, they are incentivized to keep data in a way which is favorable to insurance companies (there are lies, big lies and statistics kind of deal). I believe this is what lead to the sub prime mortgage crisis.

> there's a trust issue around oracles

I remember asking someone about this in the early days at the Bitcoin meetup in SF. This was when Ethereum was an idea, not a reality.

I pondered, "Will Ethereum have a way to query the Web in a transaction?". I never got a straight answer from anyone about how that would work well. Later, I discovered that Bitcoin script doesn't have loops, but is still somehow "Turing Complete" according to the inventor, who may or may not be the inventor.

My take then and my take now is that cryptocurrencies have some value for transitory things and imaginary value for more permanent things.

> This is one of the 'very few, very specific' use cases that blockchains are good at.

Blockchains are providing no value here, as the parent keeps saying.

> keeps saying

Well yes, but I'm looking for something substantive rather than just repeated disagreement [Edit: this was unfair, Fabian2k's comments are all thoughtful and substantive, even if I disagree with where the balance falls].

My claim is that smart contracts can provide value by providing a payment process that is more transparent and verifiable.

I'm still not clear whether the disagreement is based on

* believing that having a more transparent and verifiable payment process is not valuable,

* or that smart contracts don't provide more transparent and verifiable payment processes than the typical insurance industry approach,

* or that smart contracts do provide more transparent and verifiable payment processes, but that there are other technologies that would be better at doing that (in which case, what are they?)

In the specific example from AXA the payments didn't go via the blockchain, so there is absolutely no advantage to it here.

If the payment also is handled via the blockchain, there is a large number of potential concerns here. For me, I don't see how the really minor benefit here would be worth the rather big unknown risks. One important aspect here is that in fully automated systems like this, exploits are also much more efficient and can affect many more people at once.

It is also not clear to me how this would work for insurance at all. For automated and verifiable payment you need to deposit the funds into the contract somehow, and that is simply not how insurance works. If the insurance companies had do lock down funds like this, that business model simply would not exist. So in practice this would have to be some mechanism that only deposits a fraction of the funds. And then I, as a consumer that bought some insurance there would also be vulnerable if someone cleaned out that pool of money, e.g. by exploiting a flawed oracle or risk estimation process.

I don't understand enough of the details here to actually judge the risk, but to me that is a point against the entire thing.

Why did you use that example if you agree that it wasn't a good use of blockchain technology?

Pretty much every insurance I care about cannot be resolved with an API call.

And the problematic cases are the ones with enough ambiguity in facts or insurance conditions to make things messy, and those are pretty much impossible to automate.

they probably saw they don't need a slow and pricey blockchain for that.

They could just get flight data from API's which already exists. For example in the EU all flight and all flight passenger data are stored in a DB.

Just call that API check against it and pay out the cash.

No need for a smart contract

Cheaper, faster and as secure as any smart contract.

The thing that is interesting to me about this idea is that it is at the moment the only way that you can have a program make an automated payment and have that program verifiable by your customer.

Your point seems to be that having an automated payment for this case is easy. Yes, it is, but if it's running in a datacenter somewhere on hardware you control, the user cannot inspect or ask someone else to inspect the program that controls that payment. They can't see when it changes. They cannot be sure that a published claim that the payment is automatic will really be held to, or even that a trade reviewer will get the same treatment as them so it doesn't help address the deficit of trust.

A smart contract gives you another way of making a publicly verifiable claim about your payments process. It's an additional tool in building trust.

If I don't trust AXA I don't make any contract with them.

If nobody trust AXA they will go out of business.

I don't understand that logic.

Why do I need more trust?

Why should I care about the inner workings? At the end I want the money on my bank account

Everybody should have there own data center? Even my 80 year old grandma? In what strange world do you live in?

It sounds to me like your living in a trustless world were everybody has access to a datacenter and fast internet...

Your trust issues are the problem here and smart contracts are not solving them

> If I don't trust AXA I don't make any contract with them.

One of the huge challenges of the insurance industry at the moment is that while research shows that 60% of people think insurance is important, only 30% have a positive view of the industry. https://www.nsinsurance.com/analysis/the-geneva-association-...

This leads to people still buying insurance, but buying much less of it than they or the industry would like. So yes, this lack of trust is leading to bad outcomes for both the industry and the individuals, but the argument I worry you're making - that the industry exists and so therefore is fully trusted is not a valid one.

I think you've misunderstood my data center point. The point is that if our hypothetical insurance company has a brilliant automated payment system, but it's running in a place that it cannot be verified, then there's little benefit to trust. A smart contract solution on the other hand can be public and verified (without your grandma running a datacenter). None of this requires fast internet or even datacenters.

Trust issues absolutely are the problem here, and a deficit in trust is leading to bad outcomes. Smart contracts are a tool that can be used to help, because they act as a public, transparent, verifiable statement of what the payments process actually is.

I'm sure stories of people having their insurance locked up in a buggy contract that won't pay out won't help increase trust in the industry.

> at the moment the only way that you can have a program make an automated payment and have that program verifiable by your customer.

Far from the only way, unless you restrict the "only" to the ability to verify the software before it runs.

if you allow the more general case, and the one I think most customers would care about, the concern is a verifiable guarantee that if their flight is cancelled, the insurance will pay out within X hours of the official cancellation of the flight.

However, this is already verifiable by the dumb contract. Noting that this "dumb" contract can be enforced by law.

The law (and the regulations on the insurance industry) are a publicly verifiable claim about the payments process. Yes, the public verification stops at the interface layer (and hides the application layer), but we usually accept this as a good principle of software design, don't we?

> To have a blockchain solution where payout is according to a smart contract that is transparent and public is a way to build trust with your customers.

How many of the said customers are even remotely capable of grokking the pile of Solidity which actually make the smart contract?

Software engineer don't even review code for their npm packages these days, and you expect random people to audit their insurance smart contract?!

Additionally, we all know how be company marketing work: after a bit of time their will be hundreds of different contracts, with completely different guaranties and undecipherable naming schemes which would make it really hard even for the most motivated solidity programmer to actually know what he's bought.

> Adding a blockchain here doesn't seem to provide any value at all.

This is generally true, AFAICT, in pretty much all situations.

you got it XD

Blockchain/Smart Contracts are a solution were we first have to find a problem they are really solving or solving better.

That's one of millions of applications.

But yes, a human or a group of humans still need to be in the loop somewhere along the automation line, but depending on the insurance type, this sort of activity can be partially automated by automatic data feeds from oracles, such as what Etherisc does with crop insurance and flight insurance: https://etherisc.com/#products

Etherisc's crop insurance product, in particular, is aimed at developing nations that do not have robust legal systems or mature, reliable, trustworthy insurance companies. They can, however, get some level of protection by blending weather disaster reports from oracles (drought, hurricane, flood, etc) along with geolocation data with automatic payouts.

So in that scenario it's actually a big improvement over the existing system, which is no crop insurance at all. And a smart contract that is provably solvent is far better than a fleeting promise from a local company that may steal your money with no legal recourse due to the jurisdiction.

> a big improvement over the existing system, which is no crop insurance at all

Wat. It’s been provided by the federal government since 1938 [1]. It’s basically free for catastrophic. (It’s true that it’s not available for all crops in all counties. But that’s usually for a good reason. And private insurance fills the gaps.)

[1] https://legacy.rma.usda.gov/aboutrma/what/history.html

[2] https://en.m.wikipedia.org/wiki/Agricultural_Adjustment_Act_...

In third world countries with no robust legal systems, such as Kenya, where they deployed. Read what I'm saying. All of what I'm saying.

> countries with no robust legal systems, such as Kenya

Genuine question: since land ownership rests on said legal system, what prevents me from taking out insurance on the whole of Kenya?

Is this a tacit admission that the USA is a "developing nation"? (Which is what GP is referring to).

Because I'd buy that theory.

(Less so a blockchain solution to anything)

chrisco255 does have a good point. Many areas the world do not have good crop insurance. The 'parametric' insurance policies (which is what I think etherisc offers) are indeed the future of the industry.

However, parametric insurance policies in no way need a blockchain to provide the service. Western Union does a great job of getting money to unbanked regions.

Which makes me wonder one more thing about blockchain based solutions. What currency is the payout made in?

How is blockchain an advantage if the payout is to be in USD? or local currency? If it is instead in crypto, how do you manage the FX risk? Or the legal risk? or the simple "I don't have an easy way to convert crypto to local" risk?

Reply on news.ycombinator.com