After writing over 20 blog posts about TandaPay I am very excited to finally have some infographics which hopefully can make the concept easy for anyone to understand. These concepts focus on the two main aspects of the architecture:
- Exchange functionality: Conversion in and out of a cryptocurrency that holds a stable value of $1. Conversions allow for the payment of premiums to a smart contract in DAI. The smart contract then awards claims in DAI which are later converted back to USD.
- Escrow functionality: Using smart contracts to hold premiums in escrow until claims can be awarded by the group at the end of every month.
There is also a governance layer which allows groups to come to consensus on how to administrate a group policy. This layer will be covered separately because this part of the architecture does not directly handle premiums. To know if TandaPay has the property of built-in legal compliance, we only need to consider these two layers for now.
Before we can consider how TandaPay’s architecture works, we first must consider how tandas work more generally.
How Tandas Work
You may have never heard of tandas before, but they are incredibly important in the developing world. Hundreds of billions of dollars pass through tandas, chit-funds, and huis each year. Beyond their financial significance, culturally they provide a reason for communities to come together to socialize. Their presence in communities reinforces the bonds between the individual and society. Participating allows members to feel trusted by others within the community. Conversely, failure to contribute one’s fair share can harm one’s reputation and have serious social consequences.
The above image is mostly self explanatory. The key feature of tandas is that there is no third party custodian of funds. This requires that all the members assemble in the same location once per month. Given this requirement, all payments within a tanda are direct, peer-to-peer payments. Once all the members of the group are paid back the tanda disbands.
How TandaPay Works
TandaPay takes the concept of the tanda and moves it from the realm of savings and borrowing and into the realm of insurance. It does this by means of two important architectures as illustrated in the graphic above:
- Exchange points to convert:
USD to DAI to allow for the payment of premiums.
DAI to USD to allow for the conversion of claims.
- Smart contract escrows which can hold DAI for periods of 36 days.
Wait, why do we need to use blockchain all of a sudden?
Participants must first convert dollars into DAI because dollars cannot be held in a smart contract. Smart contracts are important because they enable developers to build software which is both legally compliant by design and decentralized. You could build a legally compliant centralized system, but the costs of creating something similar using traditional financial networks (banks) would be financial ruin.
As an additional cost, every jurisdiction has their own unique legal hurdles required to use traditional banking networks. This means that you can never take the investment of time to build a legally compliant system in one jurisdiction and apply it to having TandaPay work in any other jurisdiction. The result is that if you don’t use blockchain you will never have one, global, open source protocol for peer-to-peer insurance.
So you’re saying it won’t work without blockchain?
You cannot use the traditional banking system because it doesn’t offer a way for developers to build software which is legally compliant by design. You need to escrow the funds for one month for the purpose of treating all claims that occur within a given period of time equally. If you didn’t want to escrow funds up front you could just:
- Use IOUs at the start of the month to establish participation.
- Use something similar to the traditional tanda structure that we saw previously at the end of the month to pay claims.
In this IOU system claims occur first and then afterward premiums are paid. This isn’t wrong but it is thinking outside of the box of what insurance is. You could then use the traditional banking system to make direct payments between participants but this has the following problems:
- This system is not censorship resistant, you are still relying on a third party to complete transactions.
- This system does not create an official, tamper-proof, permanent record of payments and claims.
- The parties are still relying on the app developers to perform a record keeping function.
If you don’t see why the above three points are a problem you should read this article first. As I have said on many occasions, money is speech. A premium which is paid up front is a better form of money than an IOU which is paid later and thus it is a better form of speech. If we want to enable people to speak strongly and clearly we need TandaPay not tandas.
For TandaPay to work we need the following:
- To exchange from USD into DAI to allow policyholders to pay premiums to a smart contract
- To use smart contracts to escrow funds in a legally compliant manner.
- For our smart contracts to pay out claims fairly according to set rules.
- To convert out of DAI to pay claims in USD
If we can prove that even our smart contracts are not third party custodians of funds then we should have a solid argument for legal compliance.
TandaPay Exchange Layer — 1
We need to establish a cyclic pattern of exchange (conversion) from USD to DAI and DAI to USD in the system. Once we understand this cycle then we can see if it has any shortcomings. The above graphic illustrates that a period has three parts:
- Pay premiums period
- Active period where claims can be approved (one month)
- Pay claims period
Additionally the first period and the last period will overlap with the active period. If that’s all you got from the above two images then that is all you need to know.
TandaPay Exchange Layer — 2
UPDATE (Dec. 2019): The problem discussed in this section is now obsolete thanks to new advances in technology. Users do not need to rely on the secretary to obtain small amounts of DAI nor do they need to register with a cryptocurrency exchange. A fiat on-ramp is now natively integrated into the Fortmatic wallet used by TandaPay. To find out more about this please see:
So now this section brings in a few more concepts. The above image introduces the secretary as a type of human ATM, providing an exchange point for DAI and USD as needed. Just as USD moved counterclockwise in the previous image, it always moves left in the image above. Conversely, DAI always moves right.
The key points to take away from this image are:
- The secretary never holds any members’ funds, instead a secretary can only exchange an equal amount of USD for DAI or DAI for USD.
- Smart contracts do hold funds which might mean that they are functioning as third party custodian of funds, more on that later.
- If the secretary doesn’t lock their own DAI which they receive after exchanging USD for a claimant’s DAI then the group’s liquidity in DAI might dry up.
- If the secretary doesn’t hold enough DAI then everyone will be unable to convert from USD to DAI to pay their premiums at the start of the month. This means that they cannot reliably function as a point of exchange in the architecture.
- If a secretary fails as an exchange point this doesn’t cause the architecture to fail. This works similarly to ATMs in an airport terminal running out of cash. It doesn’t mean the money in your bank is gone, it does mean that you can’t draw cash until you leave the airport.
- If a secretary does fail to hold sufficient DAI then this might halt the ability for people to pay premiums for one month until a new exchange point is found.
- Since verifying that a secretary placed DAI into a lock contract is easy to do, this should make the state of the secretary’s finances for this section transparent. This means that there is no vulnerability for this part of the architecture. 👌 👍
TandaPay Exchange Layer — 3
The image above is identical to the previous image except for the fact that previously we looked at the groups liquidity in DAI. Now we want to look at the group’s liquidity in USD. If the group loses its USD liquidity then this means that the secretary is an unreliable exchange point for converting a claim award in DAI to USD. This however will not impact claimants for longer than one month.
The key points to take away from this image are:
- The secretary only holds their own funds.
- We can clearly see that the group’s liquidity in USD is potentially vulnerable for 6 days as it sits in a secretary’s bank account.
- Simple blockchain accounting can however inform us of the following:
If a claim award in DAI was exchanged for USD
How much funds in DAI are placed into a lock contract
- Given the above it is possible to know if all of the groups liquidity was placed into the lock contract or not.
- The secretary receives USD when they exchanged USD for DAI to enable people to pay their premiums. If they don’t responsibly hold this USD then they will be unable to convert claim awards from DAI into USD later.
- If a secretary does fail to hold sufficient USD then this might halt the ability for people to convert claim awards for one month until a new exchange point is found.
Every exchange, as illustrated in the graphic above, is conversions in and out of DAI where an equal value of DAI is exchanged for an equal value of USD. Exchange therefore does not create any legal liability for the parties so long as money transmission laws are not violated. Money transmission laws change on a state by state basis. If the parties know one another, and if the values being exchanged are relatively small then in most states this does not create legal liability.
TandaPay Escrow Layer
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.
- 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.
- 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.
Is TandaPay legally compliant architecture?
As with all things in the world of law there is no rubber stamp. Efforts have been made to design the architecture of TandaPay such that the contractual features of consideration are removed. In this sense TandaPay is not a valid contract because it places the parties under no contractual obligation to perform. This is why some believe that TandaPay is legally compliant and that its use creates no legal liability for participants. I did the best I could to create architecture that minimizes legal liability. That’s why people think the architecture sucks, because it’s so limited in terms of the value of claims that can be paid. This limitation, on the value of a claim, exists because TandaPay does not use actuarial pricing to manage risk and pay claims. Because TandaPay does not use actuarial pricing, it does not hold reserves. Because it does not hold reserves, it is cannot be regulated the same way a typical “insurance” product would be regulated.
I was willing to make whatever trade-offs I could to gain the most legal compliance even if it vastly reduced the usefulness of the protocol.
I wanted to find an architecture that had the greatest potential to be out-of-the-box legally compliant. With a high probability I believe that TandaPay has a strong case that it is such a protocol. Additionally, money transmission laws may impact a groups ability to function without a license in some states.