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.
Building Payments for an Insurance Startup
11–20 of 38 posts
Re: Building Payments for an Insurance Startup
#12Why do you use integers to represent monetary values? It seems like $600 is represented as 60000. Or is that a typo?
Work in fintech, I second everyone else saying integers is the way to go.
Re: Building Payments for an Insurance Startup
#13Why do you use integers to represent monetary values? It seems like $600 is represented as 60000. Or is that a typo?
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.
Re: Building Payments for an Insurance Startup
#14Why do you use integers to represent monetary values? It seems like $600 is represented as 60000. Or is that a typo?
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 those operations like "addition", but it's a case where being excruciatingly, provably correct seems more important than a few extra bucks on servers.
Re: Building Payments for an Insurance Startup
#15> 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).
Re: Building Payments for an Insurance Startup
#16Why do you use integers to represent monetary values? It seems like $600 is represented as 60000. Or is that a typo?
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…
Uh, yeah, good luck with that. Based on my own experience, money values that require actual precision are one of the most difficult problems in back end software development.
I have used BigDecimal and Java Money API in the Java world. Joda Money, too.
Re: Building Payments for an Insurance Startup
#17Earlier 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…
Not every currency has a decimal amount. For example, there are no decimals in the Japanese yen.
Not to mention then you need to translate that for all the currencies, {pounds: 60, : 00 }
Re: Building Payments for an Insurance Startup
#18Why do you use integers to represent monetary values? It seems like $600 is represented as 60000. Or is that a typo?
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.
Re: Building Payments for an Insurance Startup
#19Earlier 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…
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.
Re: Building Payments for an Insurance Startup
#20Earlier 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…
Not every currency has a decimal amount. For example, there are no decimals in the Japanese yen. Not to mention then you need to translate that for all the currencies, {pounds: 60, : 00 }
Yes, exactly. That's the advantage. You need to display pounds different from yen and dollars and bitcoins. It's good to have the code say, "Whoops, I was only expecting dollars and cents, and I'm not prepared for this thing you handed me" rather than accidentally displaying the wrong thing.
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.