Building Payments for an Insurance Startup(moderntreasury.com) |
Building Payments for an Insurance Startup(moderntreasury.com) |
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).
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.
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
with this you mean you don't get money from them to promote them. Please correct me if I'm wrong.
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 those operations like "addition", but it's a case where being excruciatingly, provably correct seems more important than a few extra bucks on servers.
With that said, it's better not to reinvent the wheel here and follow the flow, and it's also the safer option— it's better to charge a customer $10 when you meant to charge them $1000, than it is to charge them $1000 when you meant to charge them $10.
[1] https://stripe.com/docs/api/charges/object#charge_object-amo...
In financial transactions on the other hand, we always need only 2 decimal places. So there is no benefit in using floating point.
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.
https://developers.google.com/standard-payments/reference/gl...
Really, it’s about rounding and floating point math.
{ "amount": 12345, "exponent": 4 }
{ "amount": "1.2345" }For example, gas stations using USD often use more than 2 digits of precision.
I suspect (and hope) that situation is reasonably rare, though.
Just like how the complex algorithm of determining insurance rates is likely to yield a long decimal, it has to be rounded to translate to a currency. Heck even things like sales tax being a % requires a rounding calc to be done on majority of transactions before the monetary units are tallied for the “total”
Not to mention then you need to translate that for all the currencies, {pounds: 60, <whatever a decimal of a pound is>: 00 }
At the very least I'd want the currency marked. And once you're representing currency as a structure/object rather than a bare integer, you've got a lot more opportunities to ensure safety.
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)
But you're right, we wouldn't have expected to be able to call something like stripe with that same arbitrary precision. It was all internal pricing.