A truly decentralised P2P Insurance | Hacker News Reader

A truly decentralised P2P Insurance

hack.ether.camp

69 pointslamito48 comments

How can Ethereum-based insurance products ever be competitive? For an insurance smart contract to work, all the money must be tied up in the contract (otherwise, there would be no way to guarantee that you could be paid out). But in the real world, insurers don't just leave their money sitting uselessly in a pot, they put it to work, investing it. So the smart-contract based insurance is always going to be less efficient...

Maybe the lower premiums would cancel out the amount that real world insurers can make. Though I kind of agree with you that having a bunch of money sitting there doing nothing is bad.

> ... cancel out...

This assumes that investments made with premiums are precisely equal with the margin kept by the insurer. Considering the variety of insurers, insurance products, seasonal variation, etc. this is a pretty wild assumption.

That said, insurers do make a profit on their income and make a profit on their investments. They may tell you that they have a negative combined ratio, but it's a misrepresentation, mainly for lobbying reasons. They only include base premiums in that calculation, not all the extras they sell (alloy wheel insurance, key/fob insurance, no-claims protection, etc).

Again though, it's worth pointing out that smart contracts aren't going to get regulator approval any time soon... and will probably never have access to re-insurance markets. Customers are also going to have a hard time trusting smart-contract based systems them after recent events.

The value of optimising for decentralisation over optimising for disruption* seems negligible in this case.

If you can create a crowd-sourced insurance pool there are tons of real tangible benefits, mainly coming from the fact that the customers and "insurer" are economically aligned (unlike a conventional insurer) so the incremental value (and cost) of making it decentralised doesn't seem worth it to me.

(source/disclaimer: I founded a p2p insurance startup)

Edit: added asterix and list of genuine benefits

- Since the "insurer" isn't on the hook for paying it doesn't need whitelists of "permitted" tradespeople, or price lists.

- It can share information freely about crime hotspots, health issues, etc. It can act on the customers behalf in order to keep them safe, and a happy customer.

- Customers in a pool can work together to solve problems

- A pool of safe (and lucky) drivers might see premiums drop to 25% of market rate, which mainly covers re-insurance costs

- Knowing the repurcussions of your actions will affect you and your pool group fairly directly may change some types of risky behaviour

- Lower incidence of fraud

( * By disruption I mean the proper sense of the word. It's an entirely different business model rather than just being an innovation. )

(source: I founded a p2p insurance startup)

Interesting! What is its name / website?

Guevara (heyguevara.com). UK motor insurance. We started after Friendsurance in Germany but before Lemonade in the US.

I am a big fan of heyguevara, and happily disagree with you on regulatory approval and access to re-insurance markets: these need to be addressed, and we are happy to have discussions with insurance brokers and regulatory bodies to do that. as soon as those risks are reduced and some examples established, smart contracts will make it very easy for any group of people to start their own p2p insurance with their own parameters and rulesets instead of relying on less flexible central platforms.

Appreciate it, thanks. Don't misunderstand I totally respect anyone willing to get stuck into this stuff... I just think you're making a rod for your own back by adding this "distributed" requirement.

I don't see customers caring about distribution, whereas it would make several areas more difficult to manage... fraud for one. It's cool and all, but it's a walled-enough-garden even without that constraint... a constraint that regulators, reinsurers, etc will find alien and confusing.

That isn't necessarily true. You could buy "shares" in a contract. The contract then uses share capital to underwrite many insurance claims, and you're paid a monthly interest for owning the share capital.

I.e. the money then wouldn't be sitting idly, it could be used again and again to underwrite more contracts, up to the risk limit.

It's still less efficient than 'real world' insurance, which also pays out, but does not need the money to be locked away.

I don't see why Ethereum-based insurance contracts necessarily lock money.

For example, the contract could give another address the authority to take risks with some percentage of the deposits, or pretty much any other arbitrarily complicated setup.

If the money isn't available (i.e. locked up in some way by the contact), then the contract cannot guarantee to pay out, making its promises worthless.

If you have to rely on a human being to decide to pay out, then the smart contract part of the deal is pointless.

>...pointless

Pointless and unacceptable to financial regulators, meaning nobody will be able to use it for anything worthwhile.

The address given authority to invest the insurance float doesn't have to be controlled by a human—it can represent some other arrangement, for example a stake-voting investment scheme.

It doesn't matter how many hops there are between the insurance contract and the money, if the cash isn't sitting idle on the blockchain, the insurance contract cannot guarantee to pay it out.

Just like how if an insurance company has invested part of its float in bonds, it cannot guarantee to pay for all losses simultaneously... right?

I'm trying to understand what you think is the essential difference between an Ethereum-based insurance scheme and a traditional insurance scheme in this respect.

I'd guess it's a combination of (i) there's a not unreasonable belief that a human (or a trading algorithm that evolves over time according to human input) can do a better job of managing an investment portfolio than an immutable "contract" algorithm (ii) insurance companies tend to be much larger and better diversified than an individual insurance contract on the blockchain (iii) insurance companies are often considered to be "too big to fail" by governments even when they do screw up...

For Ethereum-based smart contracts you can probably throw in (iv) Ethereum-based asset classes are riskier than many liquid investments available in dollars, and even if you can write your smart contract to seamlessly exchange the cryptocurrency float for nice, safe Federal Reserve bonds and convert back if and when more of that float is needed to pay claims, you've got more counterparty risk and exchange rate risk than carrying out the same trades purely in dollars.

I have a feeling that people tend to underestimate the role of "semi-trusted" actors in the future of cryptoeconomics.

In other words, I think that indeed most interesting applications won't be pure on-chain algorithms. The computational power is extremely limited. On-chain bookkeeping is extremely useful as a base layer, but the real intelligence will always have to come from elsewhere.

(For these reasons, many of my blockchain friends consider "smart contract" a pretty stupid catchphrase, preferring instead to talk about e.g. "dumb durable software objects".)

So, for example, consider an insurance contract structured as a "DAO", where some combination of stake and reputation translates to influence in investment decisions. Obviously there could be enormous problems with that, but it's also an interesting possibility, and I predict that such experiments will keep happening and we will learn more about collective decision-making etc.

What happens if there's a catastrophic event that results in everyone claiming at once?

Here in the UK there are quantitative requirements that state insurance companies have to have enough capital meet all their obligations over the next 12 months with a probability of 99.5%. How would you even come close to that if you're sharing capital between contracts?

You can add a feature that offers investments in DAO's

thanks, very good point. this is great feedback and a really valuable discussion for us. we need to have more experiments with decentralized applications and insurance markets to explore that. we are looking forward to address these questions with insurance and financial service providers.

Just to be clear, most insurance companies have very strict risk management policies and almost exclusively invest capital in government bonds. As you are probably aware, these bonds have had very low rates of return in recent years - getting close to 0℅ yield (or even negative yield in some regions)

So I don't think the difference in efficiency will always be a significant factor.

In addition it is possible to create bond tokens on Ethereum, which might provide opportunities to invest the capital from premiums - provided that the bonds have sufficiently low risk.

With public "willing" (ignorant enough) to subsidise that "investements" (google: AIG bailout), every time they inevitably fail, nothing really can compete in short term. Rich get richer with guaranteed profits.

Despite what neo-cons/keynsians acolytes proclaiming, saving money is an investment (low yield, but quite safe), and it should be yielding profit (in form of deflation).

As money tied in such a p2p contract will be deflationary, it will be competitive (as long as the Ethereum/currency it uses does OK).

How is e.g. the flight delay insurance decentralized? According to [1] it uses a traditional API to fetch the delay data, which very much sounds like a trusted 3rd party.

[1]: http://medium.com/@skarpischek/youll-love-to-be-late-for-dev...

It's worse than that ...

You have to use a third party which fetches the data for you ... So at least 1 third party but likely 2 third parties.

The way it basically works is that someone has a proxy contract to which they can post information to send to other contracts. Your contract trusts this contract to receive information, and therefore implicitly trusts the source to accurately query the information from elsewhere and send it to you.

However, this can be commoditised (e.g oraclize.it), and you could use a quorum of many different proxy contracts.

The trouble is that ethereum operations and transactions (especially involving storage) are expensive, and that there are much cheaper ways of achieving distribution and/or trust for many use cases.

I looked into this before. I just don't get it. There is definitely a trusted 3rd party in play which to me breaks the consensus model of having something decentralised. Maybe you can have many trusted 3rd parties and they all agree I don't know. But then insurance is a lot trickier than just paying out automatically when your flight is delayed. How do you even know the person took the flight. Maybe that doesn't matter. But lots of other questions probably do e.g. If we have a major event which delays worldwide flights would that bankrupt the insurance scheme. What capital must the decentralised insurance hold to be liquid. Who can recapitalise it if there's a black swan event. I am not against these decentralised models I just know there are a multitude of very difficult questions which insurance companies have already answered. P2P, decentralised and smart contracts can't be the answer alone?

I'm sceptical of Ethereum, but seems a bit too much to expect a proof of concept to include every nuance of current insurance theory. The question seems to be: is it impossible to model those problems using smart contracts? If not, it'll be done eventually.

it isn't yet. the current implementation relies on the flightstats API and oraclize.it to call the API from the contract. I think we are still far from truly decentralized applications, and it needs experiments like this to slowly get there. as a next step redundant data sources and oracles might help.

I find a lot of the lingo that Ethereum uses to be crazy confusing. However the concept is appealing to distribute risk. It will only work though if there is an easily verifiable source of truth for what you are trying to distribute the risk for. For example if it was car insurance and you were trying to distribute accident risk there has to be a uniform and guaranteed way to say "this accident happened and it cost $5000". This is where the insurance company adjusters come in. You'd need infrastructure that isn't easily hacked that can guarantee a repair took place.

However for life insurance this might be possible. I think you can verify death 100% (or maybe not since there is probably fraud there as well).

Stuff like options on stocks and price can definitely be verified fairly easily.

Any example that this would be useful and most of all actually applicable to real-world? The example of air flight delay is already done (see: https://www.airhelp.com ) with much better payout.

The problem I see on such "presentations" is that they focus on abstract ideas instead of taking a pragmatic approach of how to actually make it usable on a real use-case outside of the experimental playground. Sorry for the rant but it's really disappointing to keep seeing ideas that immediately fall apart when they close to be actually implemented/used.

airhelp is one of many services which deal with compensation claims which are mandated e.g. by EU regulation and take a good cut of the payout for trying to make a really cumbersome process less bad. the customer experience of claiming compensation is in my opinion much worse than a fully automated payout and the whole process a real pain for both customers and airlines.

But how is airhelp.com a P2P system? I had a look at their website and they look like all other flight-delay systems, just fees seem to be slightly lower (still 25%). I couldn't find anything regarding P2P on their website.

Freebird (www.getfreebird.com) is actually taking the pragmatic approach but does not seem to have the p2p component. Could be an easy add to them...

Interesting concept but I struggle with the practical aspects. The reasons for central underwriting authority are clear...

1. Economies of scale needed to deal with regulatory, dept. of insurance, etc.

2. Economies of scale needed to administer policies

3. Economies of scale needed to administer claims

4. Expertise needed in pricing and actuarial

In an ethereum based true P2P system the individual is more or less self insuring and re-insuring their risk via an ethereum contract.

I think there's something worth paying for to be able to say a financial institution is covering you. I have a hard time believing the financial saving for an individual is worth the trouble. I also have a hard time believing the regulatory and administration needs are met without some staff supporting the contract.

note that we just released a first demonstrator for devcon2 https://fdd.etherisc.com

some more information on https://medium.com/the-future-requires-more/youll-love-to-be...

and some discussion on reddit https://www.reddit.com/r/ethereum/comments/529o5p/flightdela...

Thanks for sharing, see you in Shangai!

If you guys hope to have an limit order-book for this you may find yourself running into serious limitations with ethereum. Storage related operations are expensive. A frequently transacted market would make the costs prohibitive.

How does a system like this detect and cope with insurance fraud?

... by limiting it to events that can be reliably determined. E.g. was the plane late or not?

Create a lending system without requiring collateral from the borrower using this for risk mitigation on the lending side and you will conquer the world.

can you elaborate? wouldn't "this" be collateral since funds are tied up in a smart contract?

What's stopping someone putting a lot of money on an insurance policy then calling in a fake bomb threat on the plane? Pretty low risk way to make money from anywhere in the world.

the total amount of payouts per flight is limited as well as premiums and individual payouts. there is a non-negligible legal risk of such action and the payout limits in the end will converge to the price of the risk someone is going to take.

The legal risk is zero for someone who is out of the jurisdiction of the US completely (eg in some developing country).

Ironically, your system is meant to help compensate people when delays to flights occur yet to me it looks like you've built something that strongly incentivises people to cause more disruption to flights.

Finding the right balance of incentives needs some trial and error. The discussions are not new and well known e.g. with generic prediction markets like Augur or Gnosis.

I think we will find a way to deal with those issues. Experiments like these will help us (and society in general) to come to the right conclusions. Of course we should be careful not to cause too much harm on the way.

Also see https://www.reddit.com/r/ethereum/comments/529o5p/flightdela... and the discussion there.

also note that there is an easy workaround to limit this which essentially is the difference between a bet and an insurance: check if the user has a valid ticket for the flight.

I'm not well versed in Ethereum, but this sounds like creep towards the solutions we already have today.

I think the design space is much larger than what we have today, and blockchain applications surely have interesting features it might be worth exploring in that space.

Interesting discussion! 1. Indeed, we already have many incentives to stop planes by fake threats, and it does not happen. 2. The problem of moral hazard is present in all insurance economies. Of course, this has to be solved. 3. Part of the solution will be a P2P approach, limiting the payout to people who themselves have "skin in the game". We will elaborate on these topics in the next time (disclaimer: I'm one of the founders of the FlightDelay DApp)

Reply on news.ycombinator.com