In complex billing systems (that are also often responsible for computing non-trivial taxes), using fixed point math with configurable rounding rules -- is a must.

There are requirement time discussions/rules that indicate if a computation has a rounding rule or not (and it is normally driven by whether a calculation involves division, or if a computation must match an amount in a different currency).

Dividing amounts, as example, always comes about when there are mid-cycle cancelation/onboardings to a service.

Currency translations cause that as well.

Despite what everyone says, I've spoken to several different people at several different highly-regarded banks who say that they do, in fact, use floating point for money amounts in some of their systems.

What experience do people who work in banks have?

I work in Finance, I don't use float, and I suggest you never do either.

As a concrete example, someone was running a massive online FFI for predicting the value of derivatives, and they were doing it in the real domain and using doubles on GPUs for monetary values. Where they doing it 'wrong' then? I don't know much about finance myself.

I think the problem here is that "financial computing" is too broad a term to apply a rule like that blindly. If you're making products like point-of-sale systems, ecommerce applications or account management, then it's basically malpractice to use floating point. The performance edge you get from them is so slight in the overall performance of the system and the damage bugs cause can be catastrophic. And it's very easy to get them wrong. It's pretty trivial in most languages to swap in decimal and/or rational types, so NOT doing so is just irresponsible.

However, if you're doing things like high-frequency trading systems or machine learning stuff with massive amounts of data, then performance really does matter, and using floating point is entirely reasonable. If you're making systems like that, you're hopefully aware of the limitations of floating point and know how to use them safely.

If you are predicting, chances are you don't care about all the decimals being correct and you'd rather get the result quickly.

Predicting is inherently approximate; accounting needs to be exact. They may use similar units, but they are different kinds of problems.

Predicting a value is not the same as accounting.

I work in finance, and i use floats (well, doubles) all the time!

I never use floats for any quantities which i need to exactly add up to a known total, of course.

I worked in the credit union software space for a while, and using floating points for this does lead to trouble. There were several bugs in my time that were caused by using floats and were fixed by using integer math.

We do use FP numbers for performance reasons occasionally, but we are well aware of their limitations, and when to normalize.

Running option trading models with BigDecimal is unproductive. However, when the calculations are done, we store the results back as decimal representation.

I used COBOL in a well known global American bank.

It appears to be using this: https://engineering.shopspring.com/decimal-an-arbitrary-prec...

No, original go-trader used it, since quuckfixgo uses it, and during profiling it showed as a significant cost, so I wrote Fixed.Fixed