We store all our financial data in Greenwich Mean Dollars.

What are you going to do about the new Moon Dollars?

Might be a minimum for a money library (not completely sure what the absolute minimum would be). It would be an application design choice to not use one and stick to general fixed point/Big Num constructs.

That is not a viable alternative.

Even though my gut reaction is to agree with you, it’s true that it is an app design decision, so in certain scenarios it might very well be a good design decision.

Shipped applications disagree with you.

It really depends on the context of the app

Sometimes you can do all calculations in a single currency and convert at reporting time. I've worked on teams where that was fine.

Sometimes... you really cannot do that.

Completely agree.

Out of curiosity, how do you deal with changing exchange rates in that case?

You never want to be lossy with user inputs. Save what they told you and then convert for internal logic.

The OP just described a language feature where you want to multiply euros with usd one place and yen and dinar in another.

You don’t need to do that which is why a decimal or 64 bit int is a fine language approach.

it depends, if it was a currency exchange, it'll be labeled in one of 3 ways, either average rate per unit, absolute, or it'll be a reference to a MSSQL table containing exceptional spot transactions. Otherwise, a complete history of exchange rates is stored in KDB, most days you can take the average, and for small amounts on weekends or days the exchange is closed you can just interpolate, there's also a half dozen XLSXs full of certain exceptional days, so you'll have to check that you're not on one of those lists. Then if you're not dealing with USD->X or CAD->USD->X things start to get hairy.