That seems super dumb indeed. I really wish JSON had an actual decimal type, we already have valid "e" notation (like 10e2), why not have a "d" notation, like 5d3 (meaning 5.3) or 5.3d.
It would be if it did any arithmetic. But maybe it works without any computation. Then the fp arithmetic is not a problem. Or could you provide an example?
Neither 0.1 nor 0.01 are representable exactly in binary (much like 1/3 is not representable exactly in decimal). Thus means that your cents, if any, are never precise. Not a big deal for Swift transfers where you can safely round to cents. But various commissions, taxes, and fees are often very small fractions, and rounding errors become noticeable with large quantities of small amounts added / subtracted. They may be too small to matter financially, but they are bothersome because your sums do not match exactly where they should, and this affects trust to the system.
IDK about banks; in one billing system where I was involved we used decimals (and clear rules of assignment of the rounding errors), in another, all amounts were in picodollars.
Yeah, they are not, but still, afaik when I have 0.1 or 0.01 in some variable and pass it around the system it doesn't suddenly change to 0.10000000000012 (or whatever), but the problem arises in case you want to make arithmetic with it, like 0.1 + 0.2 !== 0.3, which you do not do in this library, you just pass "calculated" value how much to send where and you are done.
Partially Im just playing the devils advocate here, I know that you have to use Decimals for working with prices etc., (maybe they did not use it because it will be pretty fat dependency), but still imho it's not needed.
Should be fine up to about 9 quadrillion[1]. Though with arithmetic it can get messy. The example doesn't show, but I hope dollar amounts are in cents and don't use decimals.
Maybe when sending money to Zimbabwe it could be an issue.
Thanks for bringing this up chuzz - we're actually only using base amounts for the money representation for amounts here. (no $2.3232321), only (amount: 232)
See the https://dinerojs.com/ package to see how money is handled (tldr it's a combination of currency and amount which helps us get to the root #)
I published iso20022js.com a few weeks ago, and I was incredibly surprised by the overwhelming traction it received. I wanted to share more about some payments fundamentals that engineers might need in order to run this package - specifically, how sending these types of bank payments actually works.
It's the largest one with traction so far! It currently has over 300 stars on Github, meaning it's the largest package that I believe people care about right now
This is frankly the actually difficult part of the process. ISO20022 is just a way to send messages, your actual commercial and settlement arrangements still need to be done. Banks are not required to provide such a service, you will specifically need an arrangement with a bank that offers that. Or more likely with an intermediary like Wise which will abstract the distractions like ISO20022 away from you.
In the EU the PSD2 directive explains which market parties can apply for access to these systems. Which usually means you need to have a company that has interest in this kind of access and provide service to third parties. Unfortunately i think PSD2 only sets technical rules for authentication. Not for the actual API. So the bank might not give you direct access to SWIFT but to an API that abstracts it instead.
AFAIK, Wise has currently stopped allowing payments through its API[1] for private persons due to regulation, and there don't seem to be any other worldwide providers to do so.
[1] You can send prepared payment orders to Wise, but still need to log in and manually approve them.
> Are all banks required to provide such a service? How about countries outside the USA
I'd be more worried about banks in the USA than outside. You won't get "No, we only take endorsed and double-signed paper checks!" from a European bank...
ISO20022 has a huge namespace and can do all kinds of things. My current focus on making transaction banking namespaces more accessible (think pain.001 002 and 008) aswell as CAMT files
Great effort, thanks! I just recently had to implement camt054 for our client and others will follow, because it's becoming the new standard soon. There's definitely a whole lot more in that namespace, yes.
I accidently also stumbled across the different einvoicing types that exist. What a space to explore :)
This is cool; I'd love to hear more about how the actual transfer of money works e.g clearing, r-transactions and so on if you're looking for a follow up blog ;)
Since you mention r-transactions (which is specific to SEPA): the SEPA rulebooks are surprisingly easy to read (e.g. for SCT[1]). For the US, NACHA maybe publishes similar specs? Neither are Swift though, for that perhaps https://www.swift.com/standards is what you're looking for.
How the actual settlement happens (e.g. RTGS/Target 2) is a bit more involved, and you won't find that in these rulebooks.
Nice article! It's always interesting to look behind the scenes of payment infrastructure.
BTW, when I tried the interactive demo [1] I noticed that it appended "undefined" to the end of the generated XML. Happens both in Firefox and Chrome, so it doesn't seem to be a browser quirk.
