It's easier for the US to manage the relationship with Marutius instead of with the UK [0] while buying favor from India and France [1].
It also aligns with Mastro, Doshi, and Colby's doctrine around the US retrenching in the Indo-Pac and the UK concentrating on the European continent [2] as the US increasingly cannot guarantee boots on the ground in Europe and Asia at the same time.
With the UK in the Indo-Pac, British supply chains would be stretched with marginal benefit for the US in an Asian theatre, but the same resources spent on BIOT could be better spent on British possessions in Cyprus, bases in the Middle East, and the North Atlantic.
It's indeed relative to cents in a sense, the idea is to force you to declare the precision of the monetary amount you're expressing.
You can see various interpretation of what "USD" means in the wild, as some APIs will happily parse USD 100 as $1.00 while some others might parse USD 100 as $100.00.
So we recommend this explicit [ASSET/SCALE AMOUNT] notation, where SCALE describes the negative power of ten to multiply the AMOUNT with to obtain the decimal value in the given ASSET.
It makes subsequent interaction with external systems much easier. You can read a bit more about it here [1].
Used to work at a payments company. Yes, you need to be *very* explicit in how you model currency amounts and precision. See also earlier post about Canadian rounding rules. Some of the "logic" is regulatory/compliance driven.
ref child post about stocks trading for 0.0001. Yes, those are real trades and (probably) fully legal etc, but I'm not sure the Fed recognizes currency amounts less than 1 US cent ($0.01), so the accounting rules and tax rules might not match expectations based on generalized floating point math.
Just to add to this, having also implemented a production payment system, we did the same thing. One needs to be very explicit about the scale and how it should be rounded and dealt with, and how to operate on two different scale systems. Quite a fun challenge, though I do not miss the edge cases.
Our system was a payment system for childcare management software, interfacing with banks and the government directly.
Mostly bank specific: the parsing and rounding approach wasn’t always consistent depending on what was being run. Still crazy to me that it was all CSV (with some special extra formatting/structure) via FTP to run transactions too at the time!
Not to speak for them, but I think you’ve understood the point exactly. You need to be able to support arbitrary precision, but that support needs to be intentional to avoid errors. And you have to record that decision somewhere if adapters are to correctly handle your outputs; why not in the unit name?
