All this debate about floats or ints or decimals, obscures the fact “reconciliation” is an essential part of dealing with money - essentially some separate implementation of the money movement that detects when your rounding strategy or floats end up creating or destroying money, but all the accounts balance at then of the day.
Fintech Engineering Handbook
171–180 of 234 posts
Re: Fintech Engineering Handbook
#172I glanced, and I found this handbook shallow and - in some areas - even bad advice. E.g. If I ever see a monetary value stored in something else than integers I'm going to run away screaming (thank you Rust decimals represented as JSON floats). It's always integers unless you have a VERY good reason to do otherwise (though exported view can be in anything, even in weird bitcoded formats). FX exchange. Resolution of F…
> E.g. If I ever see a monetary value stored in something else than integers I'm going to run away screaming (thank you Rust decimals represented as JSON floats). It's always integers unless you have a VERY good reason to do otherwise (though exported view can be in anything, even in weird bitcoded formats). That really overstates the issue. Whole domains of finance run just fine on doubles. If you're doing Monte Car…
Basically whenever you are acting as a custodian e.g., a bank. Then you have to be super careful.
No one cares if you’re mortgage calculator is off by a penny
Re: Fintech Engineering Handbook
#173Earlier quoted context omitted.
All of the data we control (in the database, in our apis, etc) is integer cents. When we have to interface with a system that represents money using JSON numbers as dollars.cents, we parse or serialize it into an arbitrary precision decimal type. Hasn't been much of a problem.
This started out fine for us except that int32s were a bad idea and upgrading was painful
That's definitely valid, for b2c applications though a lot of the time you will never deal with numbers of that magnitude.
Re: Fintech Engineering Handbook
#174Nice. The book contains a bunch of good information that could already be found elsewhere but collecting it is quite practical. I highly suggest to read Kleppmann's Designing Data-Intensive Applications. The first edition was very good, a second one came out recently. I was CTO of a FinTech where I built the whole software stack from scratch: the lessons in the book are mostly correct. I say mostly, because as always…
Why content-addressed storage? I'm assuming this is mostly for auditability after the fact? Wouldn't it make sense to use some business identifier to be able to refer it back easily?
Re: Fintech Engineering Handbook
#175Re: Fintech Engineering Handbook
#176Earlier quoted context omitted.
Having done HFT / low-latency in C++ with a browser based (read: JavaScript) management front-end: Go ahead and use integer cents everyone. It’s practically an industry standard and it works just fine. Anything else is a worse compromise.
If someone sells you 12345.55 EUR vs USD at a rate of 1.12345, how many EUR do you think you end up with? Do you think all market participants even agree? What if the rate is 1.123456? For added fun, you can introduce division. Some systems will allow you to sell 12345.55 USD to buy EUR at a rate of 1.12345. The article’s “no lost data” tenet is not really viable when this sort of division is involved. Are you going…
The only one who has to “agree” is the exchange. And it should be covered by the TOS
Re: Fintech Engineering Handbook
#177Earlier quoted context omitted.
My experience in consumer banking says that every instrument specifies the precision of the calculation, how and when rounding happens, and slew of little details. So, yes, everyone has to understand how all their partners are doing rounding and summing.
In certain areas of the institutional finance world, everyone seems to accept that everyone's math is allowed to differ by a few cents, and they tally up the errors and move on with their lives. I would, however, by quite surprised if my personal bank account did this.
When the bank owes you money, they round down.
When you owe the bank money, they round up.
Re: Fintech Engineering Handbook
#178Earlier quoted context omitted.
Native English speaker. I scanned it and IMO there's a slight overuse/misuse of hyphens. Maybe the AI tool could be asked to identify and correct? (The hyphens might be triggering people to think it's AI, too). They mostly need replacing with a full stop or a colon. E.g. "In practice this means storing the amount as an integer in its smallest unit - €12.34 becomes 1234" -> "In practice, this means storing the amount…
Hyphens here are meant to be formatting. You would be correct if this was a literary piece, but handbooks and sheets don't need to use these rules.
Spelling, grammar and punctuation matter everywhere, in my opinion.
I wouldn't have read your comment if it were all lowercase and used zero punctuation, for example.
Re: Fintech Engineering Handbook
#179Earlier quoted context omitted.
In certain areas of the institutional finance world, everyone seems to accept that everyone's math is allowed to differ by a few cents, and they tally up the errors and move on with their lives. I would, however, by quite surprised if my personal bank account did this.
When the bank owes you money, they round down. When you owe the bank money, they round up.
Unless you work for the bank, in which case your annual salary is divided by 12 and rounded up for a monthly figure.
Re: Fintech Engineering Handbook
#180I glanced, and I found this handbook shallow and - in some areas - even bad advice. E.g. If I ever see a monetary value stored in something else than integers I'm going to run away screaming (thank you Rust decimals represented as JSON floats). It's always integers unless you have a VERY good reason to do otherwise (though exported view can be in anything, even in weird bitcoded formats). FX exchange. Resolution of F…
> It's always integers unless you have a VERY good reason to do otherwise
I don't really agree. This seems like one of those outdated "greybeard rules" which people love to cargo cult, but to me it just comes with its own set of trade-offs, like now you have to think about exponents everywhere and getting them wrong comes with orders-of-magnitude consequences.
If you have a modern DB and your languages handle its decimals well then I'd use them. You can translate as needed for imports and exports, but the core of your system is always sound. Switch to the more basic formats if and only if there was some perf problem with decimals, which for most fintechs will be a VERY long time with modern DBs.
What really pushes me towards decimals is the consequence of getting something wrong. Relying on comparing raw ints, with variable exponents baked in, can lead to catastrophic errors with multi-order-of-magnitude gaps if that implicit exponent isn't carried along correctly. It's a massive footgun always waiting to happen. Decimals avoid that whole class of problem. So the goal is to maximise the "safe" decimals as source of truth everywhere you can, and have very well-tested "in and out" paths for any producers or consumers with different representation preferences. To me, that's good system design. And when, not if, you're manually inspecting DB records to track down a bug, having everything normalized in a glanceable, obvious format like decimals will let you recognise errors faster and more intuitively.
This goes extra for crypto, especially stablecoins, where one USD stablecoin might be exp-6 and another might be exp-9. And you're representing them in the same DB! Off by a factor of a thousand if you miss that exponent! Decimalize that immediately says I.