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 FX isn't a point-in-time thing, things like buyer rate-in-time, seller rate-in-time, agreement, agreement tolerance, agreed upon resolution timestamp come in the effect.

Immutability - that's why you want to have event sourcing everywhere that touches money:

    # Resolved stream
    A -> B -> E

    # Actual stream
    A0 -> Edit(A0, A) -> B -> C -> D -> Rollback(B) -> E

Though in the end Fintech != Fintech. I worked at Fintech where money was treated like a baggage, and in other where money was a central point of everything.

▲ dahart 4 hours ago | parent | next [-]

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 says, that there’s no canonical rate. Aside from that, it’s talking about post-resolution records and you’re talking about how to resolve, no? That’s valid nuance of a separate goal, and it’s a fine goal of yours, but doesn’t seem like a demonstration of something missing or wrong.

The article appears to make the very same point about immutability? What are you saying that’s different?

▲

solumos 3 hours ago | parent [-]

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.")

▲

dahart 3 hours ago | parent [-]

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

	▲	3uler 2 hours ago \| parent [-]
		For me quickly scanning over the article, the fact that floating points were even presented as a possibility was an immediate red flag. And I pretty much stopped taking the rest of it seriously.

▲ skipants 3 hours ago | parent | prev | next [-]

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.

▲ lxgr 5 hours ago | parent | prev [-]

> 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 usually unfortunately can’t). In an idealized codebase that only seasoned financial programmers are allowed to touch, it can go well, but such a system is usually either overly exclusive or risks becoming brittle.

▲

zdragnar 3 hours ago | parent | next [-]

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

▲

morpheuskafka 4 hours ago | parent | prev | next [-]

I'm sure there is something I don't know here, but how is working with integers "brittle"? The only issue I see is rounding down by default, not sure if that is even an issue or not. At any rate, it seems a lot less brittle than floats or bigdecimal style number classes.

▲

lxgr 4 hours ago | parent [-]

The brittleness comes from the fact that the number of implied decimal digits per currency isn't always well-defined across all stakeholders and systems.

If you're only working in a single currency, there's usually no issue.

▲

foresterre 4 hours ago | parent [-]

As a general rule, you always include the currency code (EUR, SEK, USD etc.) and if possible also the amount of decimals, when using minor units.

Currency codes can be found in ISO 4217.

	▲	0xffff2 an hour ago \| parent \| next [-]
		ISO 4217 also defines the number of significant digits after the decimal separator if Wikipedia is to be believed.
	▲	lxgr 4 hours ago \| parent \| prev [-]
		Yes, definitely always include the number of digits, but at your system boundary you still have to pray that whoever you're working with isn't silently dropping that number and re-deriving it from their own, almost-4217-compliant currency database. Redundancy can be great, but it's not a panacea, since it's not guaranteed to be used in an optimal way.

▲

lawlorino 5 hours ago | parent | prev [-]

> I consider running from “amounts as integer” systems these days (but usually unfortunately can’t).

In the context of Fintech, how do you otherwise resolve floating point rounding issues if not representing amounts with integers?

▲

lxgr 4 hours ago | parent | next [-]

Native decimal types, if your system has them. Many languages and databases used in financial contexts do.

▲

Maxatar 2 hours ago | parent [-]

But native decimal libraries are almost always floating point.

Do people not know what a floating point number is?

	▲	lxgr 31 minutes ago \| parent [-]
		That’s alright, the important part here is that they’re decimal, not binary. You don’t want 0.1 + 0.2 to equal 0.300…004.

▲

simpsond 4 hours ago | parent | prev [-]

An integer for the value (scaled by number of decimals) and an integer value for the number of decimals. Different systems may use different values, even for the same currency or asset.

	▲	Maxatar 2 hours ago \| parent [-]
		What exactly do you think a floating point number is?