No. 141: MIES – Premium and Claim Transactions

This entry is part of a series dedicated to MIES – a miniature insurance economic simulator. The source code for the project is available on GitHub.

Current Status

Up until now, I’ve been able to demonstrate basic consumer behavior and certain market phenomena seen in the insurance industry. However, there’s been a major problem with MIES in that no money has actually changed hands in any of the simulations we’ve seen so far. Consumers have simply switched carriers depending on price, which allowed me to demonstrate adverse selection, but not much else. Consumption decisions involving insurance depend on wealth, but since there was no way to calculate wealth in MIES, its ability to model these decisions was limited.

The next view chapters in Varian place a heavy emphasis on wealth and risk tolerance, so this week, I made the decision to work on incorporating transactions before diving deeper into consumer behavior.

At first glance, transactions might seem like a simple thing to implement, after all, why not just keep a running cash balance for each entity, and then add and subtract payments as needed? The problem with this method is the same problem that leads companies to use double-entry accounting. Transactions are more complicated than simply sending money from one place to another. Loans are generated and capital is invested, which creates liabilities that must be considered when trying to calculate the wealth of an entity. Even something as simple as a premium payment is effectively a loan to an insurance company that needs to have a liability recorded (the unearned premium reserve), in addition to an increase in cash to the insurer.

Therefore, I’ve had to draw on my basic knowledge of accounting, which made me uneasy since I’m not an accountant myself. However, in order to get MIES to model the phenomena I want to model, and to answer the questions I have about insurance, I need to implement double-entry accounting, and eventually, statutory accounting rules. I ran across a post on Hacker News titled, ‘It’s OK for your open source library to be a bit shitty,’ which encouraged me to keep moving forward with the project despite the amount of discomfort I have.

I have certainly found many errors in MIES from past versions and there will likely be many more, including in this post. However, there’s not a lot of open source actuarial stuff out there, or in particular, open source actuarial simulations incorporating both economics concepts and double-entry accounting. Or, if there are packages out there, they aren’t easy to find. Thus, I’ve taken the step to put something out there, awaiting any feedback for things that need to fixed, and then making improvements. If this ever proves to be something useful, younger generations will create even better tools in the future.

The Bank Class

Banks facilitate transactions between insurers, brokers, customers, and other banks. While it may eventually be possible to define more than one bank per simulation, all the examples in the near future will have a single bank at which entities can deposit money and send payments to each other.

Schema

As with all the other entities, each bank comes with its own database:

Here, a bank can accept three types of customers. The customer table represents the customer superclass and references the person, insurer, and bank subclasses. Each customer can have an optional number of accounts. Any of these customers can send transactions to any other customer, including themself. Notice that the transaction table has two relationships to the account table, since the debit and credit account fields for each transaction both point to the account table.

The SQLAlchemy mapping is defined below:

Bank Methods

Upon initialization, a bank will register itself as a customer, this allows it to have its own accounts, as well as to accept deposits from other customers. The reason why it needs to have its own accounts is because each transaction will need to have corresponding debit and credit accounts, and transactions between a bank and its customers will sometimes have one of the bank’s own accounts involved.

The method bank.get_customers() takes a list of IDs, which can be either those of people, insurers, or banks. For each of these entity IDs, the bank will create its own identifier for the customer, which can differ between that customer’s underlying ID. For example, a person with a person ID of 1, and an insurer with an insurer ID of 1, will have separate customer ids.

The method bank.assign_accounts() takes a list of customer IDs, a type of account (such as cash), and then creates that type of account for each customer.

The method bank.make_transactions() will take a list of transactions, each of which have a debit account, credit account, transaction date, and transaction volume defined, and then store them in the transactions table.

Now that we have our bank defined, I’ll walk through the insurance underwriting/claim cycle and show how the transactions that are currently available in MIES work. First, we’ll import the necessary modules, create an environment, make a population of 1000 people, and then create a bank called ‘blargo’ that has 4B in starting capital:

Starting Wealth

Before we can issue policies to customers, we need to have a starting amount of wealth for each person so that they can actually pay for their policies. Furthermore, we also need each person to have a bank account from which they can issue payments to their insurers. To take care of these two steps, we’ll first send the person IDs to the bank, which will then create corresponding customer IDs and then establish one cash account for each customer:

This action populates two tables. The person table contains a record of all 1000 people, and the customer table has 1001 records, since each person becomes a customer, but the bank itself is already its own customer:

In the next step, we’ll use a new method called grant_wealth() which the environment uses to give each person a starting amount of wealth. Since wealth is not evenly distributed in society, I’ve drawn these values from the Pareto distribution:

The method is defined as follows:

This action deposits wealth in each person’s cash account. This is marked as the debit side of the transaction, the credit side is the liability that the bank takes on by accepting the deposits, since deposits are loans to the bank:

Policy Inception

Before we issue policies, we need to create two more entities in the simulation. One, a broker called ‘rayon’ and an insurer called ‘company_1.’ Initializing a company now requires two new arguments, a bank with which it associates, and its inception date. These new arguments are used to create bank accounts for the insurer:

We’ll now use the broker rayon to place the customers with the insurer. This method also has a bank as a new argument, which will be used to facilitate the transactions:

This action creates a policy record for each insurer, which I won’t show here since I’ve already done so in a previous post. What has changed however, is that each person needs to pay the premium to the insurer up front. The broker is able to tell the bank to create a transaction for each premium payment. This time, the debit account is the insurer’s cash account, and the credit account is the person’s cash account. In the picture below, we see that there are 1000 additional transactions starting with transaction_id 1003 (1002 was used to seed insurer capital). The debit account on all these transactions is account ID 1004, which is the insurer’s cash account:

In reality, a corresponding liability should also be created in the insurer’s accounting system. This is called the unearned premium reserve which is what the insured is entitled to recieve if their policy gets canceled. This feature is not yet implemented in MIES, but it’s an important liability to consider in insurance.

Loss Occurrence

Now that we have our policies issued, we’re ready to simulate some losses:

This action produced 57 loss events, which can be found in the events table in the universe database:

Claim Reporting

These losses are not considered claims until they are reported to the insurer. Otherwise, the insurer has no knowledge that they occurred:

This method has changed from last week. The loss amounts are now reported as case reserves, which are estimates made by an insurer on how much they will need to pay for the claim. This is now distinguished from paid losses, which are the actual payments the insurer makes to the insured:

This action creates two transactions for each claim. One transaction, called ‘open claim’ signals that a claim has been created. Another transaction, called ‘set case reserve,’ sets a case reserve for each claim. Since there are 57 losses, there are 57 claims, and 114 transactions:

Notice that we have some fairly restrictive assumptions for the simulation. The case reserves are equal to the ground up losses, and all 57 losses are reported to and known by the insurer immediately. This is not the case in the real world, where an insurer does not know how much claims will cost until they are settled, and may not know about claims until many years after they have occurred. We’ll need to revisit this problem in the future, since estimating claim amounts, including those on unreported claims, is a core function of actuarial science.

Claim Settlement

Let’s close these claims by issuing payments:

Insurer.pay_claims() is a new method used to send checks to the insureds for indemnification:

There’s a lot going on here, so I’ll break it down. The payments to the insureds are handled first. We can see this by going to the transactions table in the bank database:

Notice that there are 114 additional transactions, two for each of the 57 claims. One transaction sends a payment from the insurer to the customer. You can see this since the debit account is the cash account of the customer, and the credit accont (1004) is the cash account of the insurer. The other transaction is a payment from the insured to whomever they owe money to due to the loss. The debit side of the transaction is now a reduction in the bank’s liability account, and the credit amount is a reduction in cash equal to the claim amount for the insured:

Next, three transactions are entered for each claim into the insurer’s database:

1. Reduce case reserve
2. Claim payment
3. Close claim

‘Reduce case reserve’ is a reduction in the claims reserve to zero, signifying that the insurer no longer owes money to the insured. The ‘claim payment’ is a corresponding transaction representing the actual payment, and ‘close claim’ is a transaction that indicates that the claim is now closed. The insurer now has 5 claims transactions for each claim, 57 x 5 = 285 transactions in total. These five transactions are: 1) open claim, 2) set case reserve, 3) reduce case reserve 4) claim payment, and 5) close claim.

One source of confusion I had is that this way of recording transactions does not have the double-entry accounting that you’d see in a general ledger. Indeed, this form is more common for actuarial pricing modelers who do not usually need to get into the finer details of debits and credits. However, I’m leaning towards changing the claims transaction tables to also be double-entry, since doing so also makes things easier to program and avoids questions with negative values. For example, I had to think about whether to record case reserve reductions as a positive or negative value. This confusion is not present if I record them as credit and debit amounts.

Consumer Income

Each person now gets a paycheck during each period. This can be issued by the environment class:

There’s nothing too special about this method, it just debits each person’s cash account by their income amount:

An additional 1000 transactions have been recorded, one for each customer. As with wealth, the debit side of the transaction is the person’s cash account, with a corresponding credit to the bank’s liability account:

Policy Pricing

Now that the claims have been reported and settled, the insurer can use this information to recalibrate the premium for each customer. However, unlike last week, claim amounts are not stored as a single column called ‘incurred_loss’, but now must be calculated from the transaction amounts. To handle this, I created a set of queries that can be used to return the case reserves, paid losses, and incurred amounts for each claim:

We mostly need to be concerned about the last one of these, query_pricing_model_data() which uses the first three to combine policy and claim information together, which can be priced with a GLM:

Since most people don’t have a claim, most incurred loss amounts are zero. This data set can then be used by the insurer to reprice with a GLM, and the new pricing algorithm is used by the broker to quote and place business:

Further Improvements

Now that I’ve got transactions modeled, I can calculate the wealth for each entity in the simulation. This is key piece required to make further changes to the way consumer preferences work in MIES, which will soon incorporate risk tolerance and wealth.