111–120 of 234 posts
The idempotency keys section alone is worth the read most devs learn that lesson the hard way.
Also audit trails. Good audit trail can save company (and you) in emergency as well. Useful for debugging and last resort of compliance data source.
That way I can debug and have a last resort of compliance, but also save time by not building the first resort of compliance.
Earlier quoted context omitted.
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…
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…
This sounds like an unreasonable position to take. “Any” is an unachievable standard that could require an unlimited engineering budget with no demonstrable value in practice.
It is good to identify the lack of a standard, and to talk about what parsers do in practice, and good to discuss the gaps and unmet use-cases. It would be a good idea to suggest that there should be a more reasonable standard, perhaps. It’s just not a good idea to demand that everyone support “any” possibility when no one really needs that, no one knows what it means, and it’s not actually possible to achieve.
Earlier quoted context omitted.
> 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?
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.
Earlier quoted context omitted.
> 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?
Native decimal types, if your system has them. Many languages and databases used in financial contexts do.
Do people not know what a floating point number is?
If you're dealing with a party who tracks currency in cents, then tracking currency with more precision than that is going to lead to rounding disagreements. Vice versa if you deal in cents but they deal in tenths of cents. And so on for all the other advice in this document.
Earlier quoted context omitted.
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.
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.
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?
It's refreshing to see someone using the correct phrasing.
The often-seen, stupid way is 'who is this book for'.
Earlier quoted context omitted.
Native decimal types, if your system has them. Many languages and databases used in financial contexts do.
But native decimal libraries are almost always floating point. Do people not know what a floating point number is?