Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building Payments for an Insurance Startup

moderntreasury.com

Post reply on HN
Print view View original

21–30 of 38 posts

Re: Building Payments for an Insurance Startup

#21

Post by toast0 »

czbond wrote: post #5
stevekrouse wrote: post #2

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

It's a pain in the butt, but I've realized integers are a good practice. Especially due with oddities of conversions and "maths" like Javascript perform.

Integer cents is certainly less of a pain in the butt than floating point dollars; I worked on an advertising project where I couldn't convince people to use integer cents, and the result was predictable madness where floating point values didn't line up.

Re: Building Payments for an Insurance Startup

#22

Post by saarons »

irond13 wrote: post #18
namirez wrote: post #13

Earlier quoted context omitted.

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. S…

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.

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" }

Re: Building Payments for an Insurance Startup

#23

Post by unilynx »

jfengel wrote: post #14
saarons wrote: post #7

Earlier quoted context omitted.

CTO of Modern Treasury here, like the other replies said it's much safer to use integers so we can bypass all the complexity (and gotchas) of floating point.

Seems to me it would be even safer to represent it as an object: amount: { dollars: 60, cents: 00 } or some such. In addition to being ready for foreign currencies, you can build in type safety to ensure that nobody does something meaningless like "60 dollars times 90 dollars", and prevents you from accidentally asking for $6,000 when you meant $60. It's less efficient, to be sure, and you have to implement all of th…

Or just use strings. That's what we do for basic webshop math - any naive attempt at doing eg a multiplication will break, requiring you to use the supplied math library (just like with objects...)

But: with strings you still have pass-by-value. So you can pass the values anywhere without worrying that whoever received the values will be modifying your object. And we still have the infinite range that integers can't give, which is especially useful when doing the multiplications for VAT and coupon codes etc..

The only remaining danger is that '+' works on strings, but we should notice those fast enough - it hasn't been a real issue yet.

(And if we need to start optimizing things at some point, I'd expect to have a better starting point when the data is already in a string than if we have to copy around objects all the time)

Re: Building Payments for an Insurance Startup

#24

Post by dvlsg »

ThrustVectoring wrote: post #19
jfengel wrote: post #14

Earlier quoted context omitted.

Seems to me it would be even safer to represent it as an object: amount: { dollars: 60, cents: 00 } or some such. In addition to being ready for foreign currencies, you can build in type safety to ensure that nobody does something meaningless like "60 dollars times 90 dollars", and prevents you from accidentally asking for $6,000 when you meant $60. It's less efficient, to be sure, and you have to implement all of th…

If you store integer amounts of the smallest currency subdivision, you're already ready for foreign currencies. You just need to specify how each currency converts from a representation like `$60` to an integer count like `6000`. This even accounts for non-decimal currencies (which basically aren't in modern use) - just set a conversion factor of 500 or 60 or whatever instead of 100.

Probably worth noting that in some cases the currency alone isn't enough information.

For example, gas stations using USD often use more than 2 digits of precision.

I suspect (and hope) that situation is reasonably rare, though.

Re: Building Payments for an Insurance Startup

#25

Post by 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.

Re: Building Payments for an Insurance Startup

#26

Post by HillRat »

lumengxi wrote: post #11

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 comp…

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.

Re: Building Payments for an Insurance Startup

#27

Post by 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

Re: Building Payments for an Insurance Startup

#28

Post by raphaeljlps »

BillinghamJ wrote: post #27

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 t…

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.

Re: Building Payments for an Insurance Startup

#29

Post by juskrey »

stevekrouse wrote: post #2

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

Dunno why you guys are so married with integers.. With even slightest increase of financial process complexity, only BigDecimal or such works. With explicit exceptions when math is done without predefined rounding rules and no catastrophes when some money orders start to come in 1/100 of previously relevant units

Re: Building Payments for an Insurance Startup

#30

Post by kyrra »

stevekrouse wrote: post #2

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

At Google Payments we tend to operate in micros. It makes it so we never have to worry about floats.

https://developers.google.com/standard-payments/reference/gl...

Post reply on HN