The Difficulty of Peer to Peer Insurance – Finding Something to Insure

Vitalik’s whitepaper mentions the possibility of Ethereum being used for insurance contracts and he specifically mentions crop insurance as a possibility and is able to explain it as being a financial derivative based on the weather:

One can easily make a financial derivatives contract but using a data feed of the weather instead of any price index. If a farmer in Iowa purchases a derivative that pays out inversely based on the precipitation in Iowa, then if there is a drought, the farmer will automatically receive money and if there is enough rain the farmer will be happy because their crops would do well.

To create a smart contract for crop insurance when no farmers are actually using Ethereum to protect their crops is akin to creating a gambling platform where people bet on the weather. To make the claim you have created a peer to peer smart contract for insurance you would need to demonstrate that policy holders are choosing to pay premiums with the intention of mitigating a possible future loss that is directly tied to an asset they possess. Claims need to be directly tied to the loss of this asset. The most obvious question we should ask then is, "what is an asset that members of the Ethereum community would actually be willing to pay to insure?"

Think for a second and consider what assets do you already insure? I have auto insurance, health insurance, dental insurance, previously I had renters insurance and at one time my employer purchased life insurance on my behalf. The government also uses taxes as a means of providing insurance benefits to its citizens so indirectly I am paying for disability insurance, and unemployment insurance.

The ideal candidate for peer to peer insurance on Ethereum is something unique. Something that people do not currently insure, could be insured for only a few dollars a month, non-payouts due to buggy code resulting in minimal non-detrimental losses. Costs of participation should not exceed the novelty benefit of exploring the technology. Over time as people’s perceptions change the reliability of being able to collect on a claim should be preeminent but it is doubtful initial participants will be asking themselves "how much can I rely on this policy." People reading this blog post years from now will need to remind themselves that Ethereum once had a phase called 'frontier' where people warned each other that Ethereum was considered a safe decentralized software platform. The perceptions and expectation of early participants in the peer to peer insurance space is different from people who buy insurance from a traditional provider. This is why choosing to insure an asset for which people have never purchased coverage previously is a good strategy for insurance technology that is still in the proof of concept phase. Best not to compete against any existing concepts regarding how coverage should work.

If you want to gain participants you need to leverage the strengths of a DAO (Distributed Autonomous Organization) over traditional insurance providers. Your proof of concept needs to appeal initially not to the general public but to technical members of the Ethereum community. Offering a service most people already receive from a traditional provider is asking people to pay for the same thing twice because who is going to use unproven technology to replace their existing provider?

Auto, health, life, property, and disability insurance all require premiums greatly exceeding the novelty benefit of experimenting with this new technology unless you are providing a piecemeal policy associated with traditional insurance such as for auto glass. I specifically mentioned auto glass as an example in my whitepaper because such a policy would greatly reduce the complexity of creating a peer to peer insurance contract.

Various benefits associated with creating an insurance policy for auto glass include:

• Claims insure property with rough price equivalence regardless of the year, make, and model of the vehicle.
• Lack of complex variables simplifies the underwriting of polices and evaluation of claims
• Low premium costs
• Policy unlikely to be affected by adverse selection
• Payouts not significant enough to incentivize fraud.
• Relatively easy to validate claims.
• Correct pricing of monthly premiums can reference existing auto insurance premiums which already model drivers risk to provide competitive pricing.
• The value of such a policy relative the cost of premiums can be easily understood by participants

Unfortunately the problem with most piecemeal policies is that they don't offer any substantial benefits:

• Coverage already issued to participants by their existing insurance provider.
• Lack of novelty associated with the asset / service equates to lack of interest in participants.

So what type of insurance could possibly meet our criteria?

• Not competing with standard polices most people already purchase
• High degree of novelty
• Low barrier to entry
• Low monthly payment
• Lower perceived losses associated to the risk of a claim not paying out.
• Lower expectation concerning the need for reliable coverage

Supplemental unemployment insurance is successful at meeting all above criteria. It seems like a very unlikely candidate but the idea is flexible enough to create premiums as low as one dollar a month. Additionally because claims are paid out incrementally and not in one lump sum there is some benefits with regard to mitigating hard and soft fraud.

The Secret to Peer to Peer Insurance – Simplifying the Problem

Insurance is a tough nut to crack and you want to start off with something easy. Easy defined as being:

1. Narrow scope, low condition complexity, and low factor complexity
   
   1. Narrow scope of policy requiring the evaluation of few initial conditions
   2. Low condition complexity requiring the assessment of limited factors to determine if condition evaluates as true or false
   3. Low factor complexity resulting from factors that easily resolve to a yes or no or a number between 0-9.
2. Minimal human judgement required to underwrite policies and evaluate claims such that untrained policy holders can function in this capacity.
3. Underwriter logic can be automated allowing the DAO to award new policies in coordination with policy holders.
4. Claims verification logic can be automated allowing the DAO to award new claims in coordination with policy holders.
5. Oracles are available which are needed to accurately report on the state of real world conditions that lie within the policy’s scope. Reliable APIs exist which interface with these oracles. Ideally the same fact can be confirmed by different oracles which are cross checked against each other via a robust API.

The reason why you cannot transform most types of insurance institutions into DAOs today is because the insight which would allow you to simplify and automate the underwriting and claims investigation process is lacking. If you knew how to fulfill all the above requirements for a policy within the limit of what real smart contract code operating on Ethereum in coordination with a backend server and a frontend client is capable of doing then you could possibly create an insurance DAO. There may be other unforeseen barriers but the above list is a good place to start. Imagine having to fulfill the requirements of that list above for auto insurance. Can you list out the scope evaluation for a general purpose auto policy? Can you list out all the conditions which must be evaluated? Can you create logic which maps all the factors into numerical values? You can do this for unemployment insurance.

UI basically evaluates to a 0 or a 1 once you get various questions related to self-employment resolved. There are various other factors which are weighted to decide if someone is eligible for a policy but if you can prove that you are a real person via LinkedIn who has a salaried job then chances are you can get a policy. The process of opening a claim and proving that your employment status has changed and you are now eligible for claim payments is not too terribly complicated for the DAO to run once you have figured out the solution. Intuitively I believe almost all future types of insurance running on Ethereum will be like this. Complex to solve initially but not too terribly complicated to code and execute. Many DAOs will have to solve the same or similar challenges. The first person who realizes that they need to give the DAO a way to pay for backend servers independent of relying upon its creators will solve that problem and most everyone will borrow and improve upon their solution. As more DAOs exist writing DAO architecture will become progressively easier to the point where most technical people will be expected to read basic smart contract code in the same way most technical people are expected to read HTML today.

The process of using Ethereum to do novel things that have never been done before is currently a relatively slow one. As a developer how do you conceptualize the workings of this technology to do something useful? How do you transform the value provided by the Ethereum network from something theoretical to concrete products and services? Once these service offerings become accessible with someone using an Ethereum client how can they serve to benefit members of the general public? All these questions are currently in the process of resolving themselves and in five years I can imagine that in the same way a teenager can create an app for the android or iphone app store they will also be able to grab snippets of existing codebase and whip up smart contracts with about the same level of difficulty. Everyone is slowly being required to learn how to program in order to fully participate in the information age in the same way simply being able to use the internet now is a prerequisite for almost anything.

In our next blog post we will get a better understanding of Dynamis’s unique solution which creates a DAO smart contract for supplemental unemployment insurance.