Do smart contracts become 3rd party custodians when they hold premiums?

It depends. TL;DR if premiums are pooled or moved from one month to the next then smart contracts can facilitate other members of the group to become 3rd party custodians. Given the right architecture the answer is no, let’s see why this is.

The individual lock box analogy

Forget how insurance works normally, you send a payment to a provider and you have no idea what they do with it. The figure above is trying to create a clear set of rules for a step by step process that will determine ownership of a premium.

P2P insurance architecture has two options:

Each premium goes into its own individual virtual lock box at the start of every month (for a more concrete explanation see: Individual safe analogy).

- Authority to move the funds is with the individual policyholders.

- Authority to move the funds is with the individual policyholders. Premiums go into a shared pool of funds at the start of every month.

- Authority to move the funds is determined by some form of governance.

In either case the funds are locked for one month and cannot move. After the month is over and the claimants have been whitelisted, then funds can move. Whoever has the authority to move funds is the defacto custodian of those funds. The smart contract in itself cannot move funds unless it receives instructions as to where those funds should go.

If the funds go into a pool and ownership of the funds is determined by:

A vote, then the group is the custodian of those funds.

An administrator, then the administrator is the custodian of those funds.

If the funds never go into a pool or are combined with other policyholders funds, there is no ambiguity. They belong to the policyholder until they are released by them for payment to a known claimant. Individual lock box architecture allows for custody to remain in the possession of the policyholder.

As a consequence, a policyholder must finalize their premium at the end of every month. They may also choose to defect with their monthly premium if they feel that a claim is fraudulent. The ramifications of permitting defections are discussed in great length in this post. An explanation of how permitting defections provides greater protection against fraud and abuse is described in this post.

The logical lock box architecture test

The test if a software architecture is functioning as a logical lock box is as follows. Policyholders have the assurance that the premiums they place in the holding account can be moved only by the following three events:

Their own private key signing a transaction to move their premium amount to a whitelisted claimant address.

Their own private key signing a transaction to move their premium amount to themselves (aka defection).

A timelock expiring which moves their premium amount to a whitelisted claimant.

Aside from defections which can only return funds to the sending policyholder, premiums can never be moved to an address that has not been previously whitelisted by the secretary. No entity other than the policyholder can ever sign a transaction that would move the policyholders premiums from the holding account to anywhere else.

Why must all balances be reconciled to zero each month?

I wrote about this extensively in another post where I describe zero-reserve architecture. Insurance, by its very nature, is inherently a method of transferring risk from one party to another party. A premium is the price policyholders pay to obtain indemnity from certain types of risks. Actuarial models concern themselves with how to price risk by predicting the future. The goal of these models is to charge premiums so that there is an excess which is saved for future claims. This excess is called a reserve. These architectures require that premiums be pooled so that a policy can hold sufficient reserves to pay for future claims. More specifically, these models should provide sufficient reserves when the cumulative value of claims in a given future month is very high. Actuarial pricing requires reserves, reserves require funds to be pooled, pooling funds takes them out of the custody of an individual policyholder. Thus actuarial pricing models transform our smart contracts into custodians because they require funds to be pooled in order to effectively price risk.

Can we price risk some other way that doesn’t require funds to be pooled? Yes, actuarial pricing is not the only way to price risk, it just is the most efficient way to provide up-front pricing. Monthly premiums using rebate pricing can be 2x to 8x more expensive depending on how good the coverage is. This doesn’t mean that the policy is 2x to 8x more costly just that the upfront expense of the policy is 2x to 8x greater. Later once it is determined how many claims occurred in the past, rebate pricing performs an accounting and returns the remainder back to policyholders. This remainder is called a rebate and it allows the policy to price risk retroactively. This type of risk pricing enables us to reconcile all accounts to a zero balance at the end of each month. The result is our architecture is never required to hold any funds in reserves or carry premium funds forward from one month to the next.

To sum up, the difference between these two models is as follows:

Actuarial models attempt to predict the value of claims in the future to price premiums. They require policies to hold reserves.

attempt to predict the value of claims in the future to price premiums. They require policies to hold reserves. Rebate models can perfectly calculate the value of claims in the past to price premiums. Because the premiums can be 2x to 8x larger, these types of policies are not required to hold reserves.

Both models can potentially fail to hold enough funds to pay out all valid claims. Since full rebate models (holding zero reserves) hold far less funds, people assume this means that this type of model is less reliable. The reality is far more complex and nuanced.

Can full rebate models reliably pay out claims in full?

We don’t have any data, is the best answer I can give you. For sure you can’t use full rebate models for every kind of insurance coverage, only a very narrow subset insurance policies, which I describe in this post.

So full rebate models are required to go to zero each period?

That’s why they’re called full rebate models, they pay rebates! What goes in must come out.