Live data from Hacker News

Fintech Engineering Handbook

w.pitula.me

151–160 of 234 posts

Re: Fintech Engineering Handbook

#151

Earlier quoted context omitted.

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.

What exactly do you think a floating point number is?

Usually that, but in binary, which causes lots of headaches for financial math.

Re: Fintech Engineering Handbook

#152
post #53

As a programmer, what I feel when I see fintech programmers each speaking from their own different experiences and perspectives is that it makes me wonder what it really means to be good at programming. What user xlii said about not storing monetary amounts as floats is a common IEEE 754 issue. And while it's true that financial tracking should be done through immutable logs or event-based records, I don't think ever…

A good programmer is just a bad programmer who’s learned not to make the same mistake twice. That’s part of expertise and why it differs too, everyone has made a different set of mistakes, domain-coded.

Re: Fintech Engineering Handbook

#153

I have just left a fintech company after 5 years and I can say after reading this, it looks legit to me (not AI slop as someone asked). These are the same sort of lessons I learned during my time in the industry. I would recommend anyone starting in fintech to take some time to understand accounting principles and the ledger in a bit more depth than just debits vs credits - this is likely what is most unfamiliar to p…

> I would recommend anyone starting in fintech to take some time to understand accounting principles and the ledger in a bit more depth than just debits vs credits

Probably good advice (for everyone in fintech, not just programmers) considering the absolute disaster that happened at Synapse. Kind of wild nobody has gone to jail for that.

Re: Fintech Engineering Handbook

#154

Earlier quoted context omitted.

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

I love how this sensible take is followed by a tornado of comments that boils down to "NEVER use floats JUST BECAUSE".

Never use floats for financial calculations. Because hard won experience.

"Floats" are simulations of Real Numbers, and Reals are uncountable. Not what you want for finance, where everything is counted.

Re: Fintech Engineering Handbook

#155
post #69

Earlier quoted context omitted.

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

> JS engines treat numbers as 53 bit signed floats

Please do not use Javascript for finance applications. Just do not do it

Save it for user interface elements and dancing whizzimagigs, where it will do less harm.

Re: Fintech Engineering Handbook

#156
post #81

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?

Aren't decimal types BCD coded?

Re: Fintech Engineering Handbook

#157
post #120

Earlier quoted context omitted.

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.

There are pretty trivial ways to use binary floating point values that don't result in 0.1 + 0.2 producing 0.30000...4 and it saddens me when this topic comes up and people go to such extreme lengths to recreate a second hand buggy reimplementation of a subset of floating point numbers to do it.

> There are pretty trivial ways to use binary floating point values that don't result in 0.1 + 0.2 producing 0.30000...4

Not across all architectures and operating systems there are not

Listen to those who have done this. Use integers for finance.

Re: Fintech Engineering Handbook

#158
post #131

Earlier quoted context omitted.

> You store the sums on either end, the currencies, the exchange rate and the final sum? There is a remarkable amount of disagreement as to whether one should do one’s back office work based on the price or based on the quantity of the counter currency. > No one has .0000145 cents in their account. Rounding occurs in the real world. Indeed. But you either need to convince all parties to agree to round the same way or…

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.

Re: Fintech Engineering Handbook

#159
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…

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

[flagged]

Re: Fintech Engineering Handbook

#160
post #155

Earlier quoted context omitted.

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

> JS engines treat numbers as 53 bit signed floats Please do not use Javascript for finance applications. Just do not do it Save it for user interface elements and dancing whizzimagigs, where it will do less harm.

Excel does the same thing, and has been used to track money for decades. Somehow, we're all still alive.
Post reply on HN