
Building Payments for an Insurance Startup - saarons
https://www.moderntreasury.com/journal/how-to-build-an-insurance-company
======
phonon
> Insurance firms sometimes cover extremely “long-tail” risks, such as alien
> abduction insurance.

That's not what "long tail" means in insurance. It does not mean unlikely, it
means the claim might need to be paid out years after the period coverage was
paid for. (Think current lawsuits about asbestos exposure from the 1970s).

[https://www.investopedia.com/terms/l/longtail-
liability.asp](https://www.investopedia.com/terms/l/longtail-liability.asp)

~~~
nradov
The alien abduction insurance was clearly described as a gag gift.

~~~
phonon
That's a secondary issue (the writer (CEO?) tried to give an example of a
insurance policy that covers a very remote event). So fine, doubly
nonsensical.

I would have also done a separate article separating paying premiums to the
carrier from the carrier paying out claims. Those are basically two totally
different parts of the insurance company, with different systems (usually) and
definitely from different bank accounts.

------
lumengxi
This is a great read from Modern Treasury. One thing highlighted in this
article that the industries not always talk about, is the concept of "Payment
Ops". This is critical in FinServ organizations from my own experience. Any
good and reliable payments infra is a function of technology, people, and
process, and you need good tooling to streamline the whole workflow that
involves engineering, finance, credit and compliance teams. Integrating with a
payments API is only half of the definition of done.

~~~
HillRat
One thing they don’t get into, but which becomes a significant pain, is what
happens if history is wrong — for example, a policy is mis-entered and you
need to adjust past financials. I architected precisely one insurance finance
system, and trying to recall the data model and logic for overlapping
timelines (what was, what should have been, what we thought it was...) still
breaks my brain.

------
BillinghamJ
Stripe Connect makes all of this stuff veeeeery easy. No need to test up
trust/FBO bank accounts/etc. for client money - just allocate money to
accounts held in the name of the correct parties.

Source: built a fairly large insurance company with zero client money accounts
by using Stripe Connect

Disclosure - we are locked into processing card payments with Stripe only, but
have no incentive to say nice things about them

~~~
raphaeljlps
just to clarify the last part: but have no incentive to say nice things about
them.

with this you mean you don't get money from them to promote them. Please
correct me if I'm wrong.

~~~
BillinghamJ
It means no incentive of any kind - monetary or otherwise

------
rubyfan
I'm honestly surprised that Know Your Customer (KYC) and OFAC regulation
aren't mentioned with respect to Claims. Besides solving for PCI complexity on
the front end of payments, Stripe has a solution for both of these things
issues on outward payments. Stripe is used by both Hippo, Lemonade and a few
other more established insurance companies.

------
stevekrouse
Why do you use integers to represent monetary values? It seems like $600 is
represented as 60000. Or is that a typo?

~~~
namirez
Fixed-point vs floating-point arithmetic! In scientific applications, you want
to preserve precision regardless of the system of units (i.e. scale). For
example, 1.23 meters is 1.23e2 cm or 1.23e-3 km. The side effect of this is
the roundoff error of arithmetic operations. Floating point operations are not
commutative or associative.

In financial transactions on the other hand, we always need only 2 decimal
places. So there is no benefit in using floating point.

~~~
irond13
Also in Fintech. In some cases it is actually necessary to have more than 2
decimal places.

For example, interest accrued daily, but only ‘compounded’ monthly. In those
cases, it is necessary to maintain far more than the 2 decimal places for the
daily accruals.

The best type to use here would be BigDecimal or equivalent. These ultimately
serialise to infinite length strings.

~~~
saarons
Totally agree on the interest use case, that's exactly where precision beyond
2 decimal places is needed. For payments specifically it makes sense to keep
it at 2 because all the payment systems in the US have that precision. When we
do build support for ledgers we've considered a few approaches for how that
might be serialized. For example we sometimes deal with MasterCard data that
tags every amount with an exponent field so something like 1.2345 might be
serialized as

    
    
      { "amount": 12345, "exponent": 4 }
    

We could do that or something like:

    
    
      { "amount": "1.2345" }

------
avip
For the record, lemonade and hippo both use stripe.

