Fintech Engineering Handbook • Hacker News Board

Re: Fintech Engineering Handbook

#101

Post by solumos » Sat, Jun 27, 2026, 3:48 PM UTC

dahart wrote: post #77

xlii wrote: post #29

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

What are you referring to with the integers/floats comment? The article says clearly that the rule of thumb is not to use floats and that they’re “almost never” a good idea, that they cause unpredictable precision loss, and recommends integer or BigDecimal types in multiple places. Are you also talking about rationals? So what is the bad advice here, exactly? For FX, it seems like you’re reinforcing what the handbook…

With integers/floats, he's saying it's not opinionated enough. Anything other than integers with minor-unit precision, unless you have a very good reason, is a bad idea. So "floating point is almost a bad idea" doesn't go far enough, and the other alternatives are presented somewhat equally.

The FX critique is saying that it's glossing over a lot of the complexity. I'd say the same is true for the treatment of DE ledgers, and it borders on bad advice (e.g. "Balance is never stored. It’s derived from the movements of money.")

Re: Fintech Engineering Handbook

#102

Post by zdragnar » Sat, Jun 27, 2026, 3:51 PM UTC

lxgr wrote: post #69

xlii wrote: post #29

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

> thank you Rust decimals represented as JSON floats What do you mean? JSON doesn’t have floats, it has numbers, and how they’re used after being parsed is not part of the spec. > If I ever see a monetary value stored in something else than integers I'm going to run away screaming That’s good, then we’ll likely not be working on the same system :) I consider running from “amounts as integer” systems these days (but u…

> JSON doesn’t have floats, it has numbers, and how they’re used after being parsed is not part of the spec.

I think that's the problem they were trying to describe. Without a formal spec, systems won't agree on how to handle floats. JS engines treat numbers as 53 bit signed floats, so passing a well defined decimal there through JSON means losing precision at the edges.

Money stored in integers gets around the issue by simple virtue of not really needing more than 53 bits to accurately represent the values anyone is going to encounter.

There are downsides like all the extra math or functions to handle doing the math everywhere money is manipulated or displayed, but this is the sort of thing where static typing is really helpful, and isn't too hard for juniors to understand that they should always use money functions to work with money data.

Re: Fintech Engineering Handbook

#103

Post by dahart » Sat, Jun 27, 2026, 4:04 PM UTC

solumos wrote: post #101

dahart wrote: post #77

Earlier quoted context omitted.

What are you referring to with the integers/floats comment? The article says clearly that the rule of thumb is not to use floats and that they’re “almost never” a good idea, that they cause unpredictable precision loss, and recommends integer or BigDecimal types in multiple places. Are you also talking about rationals? So what is the bad advice here, exactly? For FX, it seems like you’re reinforcing what the handbook…

With integers/floats, he's saying it's not opinionated enough. Anything other than integers with minor-unit precision, unless you have a very good reason, is a bad idea. So "floating point is almost a bad idea" doesn't go far enough, and the other alternatives are presented somewhat equally. The FX critique is saying that it's glossing over a lot of the complexity. I'd say the same is true for the treatment of DE led…

> Anything other that integers with minor-unit precision, unless you have a very good reason, is a bad idea.

The article clearly communicates this sentiment, no? What else needs to be said? How much further does it need to go, and why?

It might be a mistake for either us or the handbook to be absolute or dogmatic about floats. It’s not a sin to mention that they exist, and it’s a fact that some people in fintech use them for some reasons that have a defensible engineering position and well considered tradeoffs. I’ve been on the side of assuming people don’t use floats for money and then been surprised when I bumped into people here on HN who report using floats in finance routinely.

BTW, is your quote “almost a bad idea” a typo? There’s a world of difference between ‘almost a bad idea’ and ‘almost always a bad idea’. The actual words in the article, if we’re quoting the article, are: “almost never a good idea” in reference to using floating point types.

> it’s glossing over a lot of the complexity.

Of course it is, that’s a good thing. It’s not pretending to be a spec or rules, it’s an introduction and general principles. The article is already introducing new complexities that people outside of fintech might not be aware of. But do we really have to mention ALL complexity? The biggest problem with Wikipedia is that it’s overrun by nuance and complexity, so much that you often can’t read an article on a topic without already being an expert on that topic. This is why experts are often bad teachers. Being unable to gloss over some complexity is not good for learning and doesn’t make a good environment for newcomers. Let’s allow people to write for non-experts and make room for learning. We don’t have to avoid glossing over some of the complexity; it’s useful to get the general direction and gist correct while leaving out some of the detail.

> it borders on bad advice

Be specific. What’s wrong? Note that contributions are invited.

Re: Fintech Engineering Handbook

#104

Post by lxgr » Sat, Jun 27, 2026, 4:05 PM UTC

microgpt wrote: post #95

lxgr wrote: post #67

Earlier quoted context omitted.

Unary is exactly as expressive as decimal or binary for integers, but somewhat less efficient, so why would you?

idk, why would you store integers as ASCII strings? It's somewhat less efficient.

Because it's much more explicit. Computers are fast, engineering is expensive. You usually never want to optimize prematurely when dealing with monetary amounts.

Re: Fintech Engineering Handbook

#105

Post by mnahkies » Sat, Jun 27, 2026, 4:08 PM UTC

lxgr wrote: post #88

gmm1990 wrote: post #86

Earlier quoted context omitted.

That’s quite a bit slower to process. At least if you’re converting to integers to do the calculations and the calculations would be quite a bit slower if you kept the big decimal type

True, but this is usually your least concern when you're dealing with monetary amounts/math.

They specifically mentioned HFT so I suspect they care a lot about processing speed

Re: Fintech Engineering Handbook

#106

Post by jjmarr » Sat, Jun 27, 2026, 4:18 PM UTC

microgpt wrote: post #51

noitpmeder wrote: post #40

Earlier quoted context omitted.

The only real correct solution here is to send mantissa and exponent as two separate integers. It's trivial to convert between exponents for whatever math you want, it can be as correct as you want, and is unambiguous. In the HFT space you save some wire space if you can commit to a consistent exponent for some {slice} up front (think instrument/tick-size/asset-class/exchange/feed/server/whatever/...) such that you o…

If you do that though aren't you just reinventing floating-point?

No, because you're doing decimal floating point, which eliminates the rounding errors of binary floating point.

Re: Fintech Engineering Handbook

#107

Post by skipants » Sat, Jun 27, 2026, 4:36 PM UTC

xlii wrote: post #29

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

That was the first thing that popped out and made me distrust the whole wiki; there's only One Right Way to store money (as integers[1], as you said) and it should have been explicit about that.

You can also use fixed-point if whatever you're using supports it but it's still technically integers.

Re: Fintech Engineering Handbook

#108

Post by gib444 » Sat, Jun 27, 2026, 4:37 PM UTC

krever wrote: post #24

dc_giant wrote: post #3

Sorry have to ask these days. Is this carefully written down information from years of experience in the field or AI slop?

Hey, author here :) Its at least 80% organic artisanal writing and maybe 20% AI when I needed help with grammar, completeness, broader perspective and everything around.

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 as an integer in its smallest unit: €12.34 becomes 1234."

or

"In practice, this means storing the amount as an integer in its smallest unit (e.g., €12.34 becomes 1234)"

Re: Fintech Engineering Handbook

#109

Post by snsnsjjsjsiisa » Sat, Jun 27, 2026, 4:38 PM UTC

microgpt wrote: post #52

denismenace wrote: post #10

Earlier quoted context omitted.

> but it'll bite you incredibly hard if you ever stumble upon an edge case such as working with a partner that has a different implied number of digits for a given currency Why would that be a problem? You just transform the values when interacting with their API.

Customer was charged $0.995 after fees, how to represent in your data model with integer cents?

You use 1/1000th or 1/10000th or whatever you need. You do not need “cents”.

Re: Fintech Engineering Handbook

#110

Post by amluto » Sat, Jun 27, 2026, 4:49 PM UTC

antonymoose wrote: post #33

lxgr wrote: post #8

Word of advice to anyone considering the "minor-units precision" strategy for representing monetary amounts: Don't (or at least, don't use it as an interchange/API data format). It seems like a clever idea (fast integer math, no rounding problems for addition and subtraction), but it'll bite you incredibly hard if you ever stumble upon an edge case such as working with a partner that has a different implied number of…

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 to track your account balance is a rational number with an absolutely immense denominator forever?