How to Build an Insurance Company

Note: Modern Treasury empowers teams to make payment operations simple, scalable, and secure. The “Guides” series walks through representative businesses or payment processes and explains step by step how best to go about building them from scratch. ‍

Introduction

Building a new insurance company is in vogue. The brimming new “insurtech” sector attracted over $3 billion in venture funding in 2018, with new insurance offerings covering home and renter insurance (Lemonade, Hippo), car insurance (MetroMile, ClearCover), health insurance (Sana, Oscar), and many others.

Let’s first define what an insurance company does. An insurer’s value proposition is to insulate its customers from future risks in exchange for a payment. Those future risks can vary from regional risks like hurricanes and wildfires to individual risks such as health issues or car crashes. Insurance firms sometimes cover extremely “long-tail” risks, such as alien abduction insurance.

Ultimately, though, the mechanics are similar irrespective of what is being insured: an insurer first calculates the potential damage and the odds that damage might occur. Then, it charges a payment on a regular basis that, in aggregate across all those insured, is designed to make a profit for the insurance company itself. And finally, when and if the risky event comes to pass, the insurance company approves a payment to the customer that incurred the damage. That payout is called an insurance claim.

Insurance markets vary and, as is the case in lending, the real secret sauce is acquiring and underwriting the right customers. This post is a guide to the operational, money movement elements of building an insurance company. Specifically, we will build a system for a regular monthly charge and a claim payout.

The user experience

Perhaps the best known insurance company in the world is Geico, with its familiar green gecko mascot. Originally known as GEICO, or the Government Employees’ Insurance Company, the company has been a prized jewel of Warren Buffett’s Berkshire Hathaway since 1996. The company provides auto coverage for more than 28 million vehicles in the US.

We will use a new competitor, Getco, as a sample insurance app and design payment ops for an auto insurance company. The user experience Getco might want to offer is:

1. Application: Devyn Driver, a user, signs up and applies for auto insurance on Getco’s web page. Based on the vehicle, the profile of the driver, and other data, Getco then prices a policy.
2. Regular payments: If Devyn Driver buys the policy, Getco can then collect their bank account details and start charging. Some car insurance companies charge for the whole policy upfront, some charge monthly, and some charge twice per year. Let's assume Getco charges semiannually.
3. Claim payouts: When something happens, Devyn Driver comes back to the site and files a claim. Getco’s team reviews and decides whether the claim is valid or not, and if it is approved, the payment ops team will initiate payout. Depending on the incident, the payout could be directly to the insured customer, or it could be to an auto body shop that is performing repairs. (There are other circumstances in which claims payouts could go to another insurance company, hospitals, lawyers, etc.)

Payment ops architecture

Before writing any API calls, you need to make sure you have a relationship with a bank that will help you run the business. Getco can open a single or multiple bank accounts. Because the claim payouts generally happen sometime after the first payment is collected, it is likely worthwhile to have a ‘reserve’ account holding funds for anticipated payouts, and a separate ‘receiving’ bank account for incoming payments. Once the payment ops team confirms everything received is correct, the funds can be transferred to the more permanent reserve fund.

So, let’s assume you build for the following setup:

With the bank accounts set up and with access granted by the bank for ACH, wire, and check payments, you can begin designing your application.

API calls and timings

Everything starts with the insurance application. If an insurance policy is not approved, then no money moves. But if the insurance policy is approved, the process starts by setting up a regular payment.

Step 1: Collect bank account details

First, you must collect your user’s bank account details. With Modern Treasury, we call that “onboarding a counterparty” since any payer or payee you interact with is represented as a counterparty. There are several ways to collect bank account details (more about that here), but once you collect the routing and account number you need to create a counterparty:

Step 2: Get the first payment

Now that you have the bank account details set up with a counterparty, you can initiate an ACH debit for the sum calculated by the insurance model. Let’s say you want to charge the user $600 every 6 months, on March 1 and on September 1.

You can set up a payment using a simple API call for an ACH debit, and schedule it be charged on March 1, 2020. Note that the amount is in cents, so $600 is sent as 60000:

Step 3: Transfer the funds to a Reserve account

Once the funds clear, you can do a book transfer to move those funds from the Receiving account to the Reserve account. You can do this again using an API call for an ACH credit:

Since this transfer is likely going to be for an aggregate amount across all of that month’s customer payments, you will want to use line items for this API call. Note that since line items can each have their own metadata, you can capture the specific customer ID’s, incoming payments, and other information within the total that is transferred for that month. This can prove helpful in future reconciliation and finance team investigations.

Step 4: Fund a claim payout

If a damage event occurs, users can come to the Getco website at any time and file for a claim. Claims can be small, such as $600 to fix a dent in a car, or large, such as a $25,000 payout for a totaled car. Whatever a claim is, once your team has approved a claim, you can make that payment using an ACH credit:

As mentioned before, the payout can go to the customer or to another party, such as an auto body shop. If it’s the customer, then you can use the bank account details you used to charge them for the payout. But if it’s a new counterparty, such as an auto body repair shop, you will need to collect their information and onboard a new counterparty.

Sometimes it’s easier to pay a one-time counterparty by check, and Modern Treasury provides an API for that as well. You will have to make sure check printing is set up with your bank first, but once set up you can use the following API call to print and send the check to the new counterparty:

What can go wrong?

What was described above is the happy path. Things can, and often do, go wrong. In the ACH system there are a number of ACH return codes that you might see when payments cannot be completed for one reason or another. A common example might be Insufficient Funds, where your customer did not have sufficient funds to honor the $600 you charged their account for. In such a case, you would have to ask them to reauthorize you to charge them again, and repeat the same API call for ACH debit you used above.
‍
This, of course, is a highly mechanical view of what an insurer is. The specifics of each company’s credit model — and each risk the company chooses to insure — are the secret sauce that power the insurer’s business model. But every insurer needs a payment operations team and each insurer must do a version of the activities described above to manage its business. We invite you to partner with Modern Treasury as you contemplate building a new insurance product and bringing it to market.