Hacker News Reader

Comment by robk | Hacker News Reader

This seems cool but what's the intention with the USD/2 notation? Is that for fractional sub-cent precision in rounding situations?

View on HN

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].

[1] https://docs.formance.com/stack/unambiguous-monetary-notatio...

What about units that cost sub-cent? For examples, I've seen private company stocks being $0.0001

Not sure why you'd need to make a note in the internal representation, vs. leave adapters to handle conversions.

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?

If I understand their docs correctly, that’s equivalent to [USD/4 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.

Doesn't the Fed recognise mills ? They are not extinct.

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.

I'm curious – what edge cases did you find?

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!

Reply on news.ycombinator.com