Iso20022.js: Create payments in 3 lines of code

Github link: https://github.com/svapnil/iso20022.js

Based on my experience of building several payment gateways, it is my opinion that it's pretty much always "3 lines of code" (which isn't true about this library - more like "3 steps") to post a payment, even to the nastiest acquiring or banking API.

The remaining 675,000 lines of code are to:

- Perform Risk / Fraud scoring to decide whether you want to, indeed, process this payment.

- Deal with the myriad of failure scenarios - including mapping them to your own system's error semantics - in a way that your customers can understand to reduce support calls.

- Refund, void or reverse previous payments.

- Create the necessary accounting entries in order to do settlements / settlement reports for your customers.

- Etcetera

Payments systems are perplexing to me: Nothing is a more obvious candidate for an absolute, standardised, commoditised piece of software in the same way that the global IP network routes packets - only in payments we are routing "promises" and our routes, and routing decisions, are in many ways much simpler.

Yet there are very few industries where this particular wheel gets reinvented as often as it does; each organisation convinced that it has its own unique approach to doing this absolutely standard, regulated "thing" - which, reductio ad absurdum, is just an expensive buffer in a network of pipes.

Hopefully open-source software will pave the way: TigerBeetle is an amazing start (distributed ledgers), and it's hopefully only a matter of time until the other components of a payments switch are freely available as open-source components with high-quality APIs.

The problem with this standard is all the free text and bank specific fields that banks will use instead of the standard. One bank I integrated with had the equivalent of "Our fee is 5.65" in a text field which you had to parse, instead of the field for fees. Of course, the language of that string could also change. Fun times

Hey HN,

My name is Svapnil Ankolkar and I've recently built iso20022.js, a library for creating ISO20022 payments in Typescript.

The goal of this project is to be the easiest way to create, and eventually ingest, files in the ISO20022 standard, the defacto XML standard for bank payments.

I'd love to know what you think and importantly know about any improvements you'd like us to make!

This looks pretty interesting, but my only experience with payments are black-box payment processors that expose an API, and services like Stripe that handle all of the institutional interconnection.

Could you help me understand who the target devs are for this library? I doubt it's someone like me, who would try to use it as a replacement for stripe before realizing all of the stuff I have to do outside of that and giving up on it. But maybe this is more for people who are doing heavy financial management anyway? Or am I just completely thinking about what this is wrongly?

>> I'd love to know what you think and importantly know about any improvements you'd like us to make!

I think it's scary to do any finance related stuff using NPM dependencies. How large is your dependency tree?

I have written about the payments part of the standard around a year ago. I think it's a good primer for people who want to understand some fundamentals and gotchas of the format.

https://evrim.zone/blog/knowledge/iso_20022_pain_001

For Americans who've never heard of it, FedNow is seemingly using a 'a bespoke flavor of the ISO 20022 specification' (https://news.ycombinator.com/item?id=36805571). I think that it's a pretty handy format to be familiar with, and is quite simple to work with too. If the Fed or participating banks decide to open up the system like European banks have done so, it can be handy to get familiar with it for us financial hackers out there!

Are you planning on generating all (or a subset) of 20022 messages? That’s what we did for our Go package using 20022 for RTP. We added helpers for generating IDs and the signature sign/validate.

https://github.com/moov-io/rtp20022

XML Schema Definitions for all ISO20022 messages are public: https://www.iso20022.org/iso-20022-message-definitions

There are tools that can turn the schema files into POJO/dataclasses/structs/etc in your language of choice, sometimes with proper data validation. Not sure about Typescript, but Java/Python/Golang definitely have those.

It may very well be lost knowledge in certain ecosystems, but generating a valid XML based on the given schema is generally a solved problem. Not sure if the projects adds anything beyond that.

That's the longest 3 lines of code I've ever seen.

you cant really create anything. it's a xml formatter, so maybe the title should be how to convert json to xml in 3 lines of code. for payments to go out you would need a hell of a lot more than this unfortunately

as an average joe, I'm curious about how all this works / what else you need to make it work (what's a banking partner, etc?)

Hey this seems really interesting. But I have questions about this statement “.

In order to transmit bank payments programatically, you must have direct transmission enabled with your banking partner. If you have any questions about this, don’t hesitate to reach out to us.

So do we need to get this enabled on a per bank basis or a per account basis?

So regarding ISO 20022 it is just a format for what is sent and read so each party have a common format to use (this is only partially true as institutions like making their own variant of it thats valid ISO 20022, think yaml vs json). Sending it is a completely different story, different financial institutions use different technologies for authentication and transport of these messages (SFTP, SWIFT, exotic custom stuff, etc..). My experience has not been in using ISO 20022 to send payments so maybe the payments space all use SWIFT or something.

Nice work, can I ask how you tested this with SWIFT for example? Is there a development portal you need access to?

What is an API/service we can use this encoder/serializer with? This seems like a part of the puzzle.

It’s a shame it’s probably going to take another 10 years before any of the banks actually migrate to ISO20022 (if it ever happens) SwiftMT conversion software is currently the big sell so they don’t have to rewrite / build everything they already have.

This is a nice looking website, and I can imagine this being a really useful hook into consulting work.

Some thoughts:

- replace strings with enums where possible. E.g. "USD" should be from an enum

- this sort of data-interop library could maybe be written in a configuration language that it uses to generate libraries for different languages

- a glossary would be really helpful

- a list of banks who've adopted this ISO standard might be interesting

It isnt sending a payment in 3 LoC at all. Its generating an XML doc.

It seems very clear and easy to use, well done! I am wondering if there is any test environment like with Stripe in order to validate the flow in development?

This makes sense to be used with Open Banking regimes, that is being mandated by government legislation.

in what scenario is iso20022 payments used? would this be for forexample automating payroll?

I use node every day

I think it is a not very good idea to develop finance software in node

How about receive payment notification via webhook ? Is there standard ?

Do you have any plans to support ACH/NACHA payments?

I would've thought some sort of cryptographic signature would be used here, though maybe that's something done in a wrapper around this XML documents?

Neat none-the-less! I always like this sort of actually-it's-simpler-than-you-think peek behind the curtain.

Sounds cool

Super stupid question, but this must have some kind of authentication, right? Where is that part?

The difficult thing about payments is not necessarily formatting payment instructions to ISO20022, but rather setting up the underlying infrastructure like:

- Shelving a Windows box in some authorized datacenter.

- Going through a years long process of getting certified to send payment instructions to the scheme (e.g. SWIFT network).

- Receiving a couple of USB sticks that contain certificates and signing keys.

- Connecting to the schemes VPN.

- Having all the legals in place.

- And probably many more things I was never exposed to.

Slightly stretching the concept of "three lines of code". But it looks clean and self-documenting to this non-js developer. Nice.

Three lines with payloads minified?