svapnil

What's a usecase for this that actually makes sense? Why does Erlang need to run on IoT devices? The main usecases of Erlang I know of are suitable for beefy machines.

Source: former Erlang engineer

Would love to hear everyone's thoughts on stablecoins vs fiat money movement! I've spent a few years in payments engineering, but would also love to hear other peoples perspectives

Hey everyone, I'm Svapnil, the creator of iso20022.js.

iso20022.js allows any developer to programatically move bank transfers with a business bank account by making ISO20022, the underlying messaging standard for money movement easier to use.

It's amazing how any developer can now move payments instantly using bank rails. I'd love for you all to take a look and let me know what you think.

Hey HN! A few months ago I built an app that allows you to trade memecoins on Discord. I'm recently open-sourcing it and releasing it to the public so everyone can see how to build Solana apps!

Hey HN, Svapnil here. I'm excited to show you something I've built over the last few months.

Would love to hear your thoughts or suggestions on where we take the project from here. Thanks!

All amounts in this library are in base units (whole numbers) and no arithmetic is used!

For financial calculations I recommend using Dinero.js

It is non-trivial. Every corporate bank usually provides some type of treasury services, which is how companies programmatically move money.

As far as I know, this is an international phenomenon. Keep in mind this is corporate banking, not consumer banking.

I'd happy answer any other questions you have @ https://cal.com/woodside/iso20022js

Thanks for finding this article olalonde! You seem to have reactivated https://news.ycombinator.com/item?id=41512930 - which is growing on HN currently

Great point hansoolo,

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

Thanks for finding this, I will fix it ASAP!

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

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 #)

Hey HackerNews,

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.

Thanks for sharing habitue

It's true that REST APIs operate under the assumption of processing at request time, while not the case with files. That's what makes Bank REST APIs so tricky - processing doesn't ever actually occur at request time.

There are so many crazy formats that are supported. Simpler is better imo

Open Banking imo === the ISO20022 standard. It already is an "API," just in a format that most web developers aren't used to

I never knew about HL7, thanks for sharing.

I agree that simplicity and open standards will win. SFTP is straightforward and has worked well in the past. In banking and finance, SFTP is what powers most programmatic corporate banking. Eventually, I think we'll see SFTP and message queues (like SQS) used more often as processing speeds up. I believe message queues are what powers much of real time payment processing already (https://news.ycombinator.com/item?id=36805571)

The most straightforward way this is done is by SFTP'ing into banks. Check out step 4 here!

https://docs.iso20022js.com/quickstart#step-4-send-the-payme...

Yes, ACH/NACHA payments work through ISO20022 aswell and are next up on the roadmap. I'd love to let you know when it's shipped - please shoot me an email at svapnil@woodside.sh so we can stay in touch!

Thanks for the feedback boursbenjamin.

The test cases for this library validate against the XSD for the ISO files, which could be extended to handle more test cases.

Banks sometimes offer a test SFTP endpoint they use. Engineers have had to do this from scratch at the companies they worked at in the past. If this is something you're interested in, we should talk more @ svapnil@woodside.sh

Hey ab_testing, this is done on a per bank basis. Perhaps bank by bank has different rules, so this is something they'd be best equip to answer.

If you have more questions, I'd love to help you out - please shoot me an email @ svapnil@woodside.sh

Would love to! It's next up on the roadmap for us - would love for you to check it out

I'd love to learn more about what you mean about the different xmlns's banks use - haven't seen that one yet.

The must know a lot about ISO20022 payments! I'd love to get in touch with you, if you can please shoot me an email @ svapnil@woodside.sh :)

Thanks for sharing Matthieu - you know a lot about the banking system. I previously worked at Modern Treasury, so I'm also very familiar with bank integrations.

If you had the time, would love to talk more about this - my email is svapnil@woodside.sh and I'd love to get in contact with you

Government mandates are almost necessary to guide standard adoption. I saw this when I worked on UPI at WhatsApp

Banks add their own features to the spec - imagine they want to add a new "Bank only" attribute that makes their XML schema differentiated and better in some way.

ISO20022 / XML allows this to be possible without breaking anything. In the past payment formats used to be fixed width text files - impossible to change or improve functionality for

Thanks for your comment phillippta, I agree with you there are a few big challenges in setting up payments companies need to deal with:

1. Security Adding vendors is a very scary thing for companies, rightfully so. Open source is great for this, because an NPM package is not a vendor.

2. Signing / Sending a Transaction iso20022.js doesn't deal with message sending yet. Best case there is a straightforward SFTP setup, which I've given instructions for here: https://docs.iso20022js.com/quickstart#step-4-send-the-payme...

3. Getting certified to send payment instructions. This should be the work of the module!

That's true, ISO20022 was designed to be extensible, meaning banks add their own crazy variants to it all the time. Currently iso20022.js can create a minimum viable working ISO20022 file, and in the future I'd love to support as many specs as we reasonably can

Thanks for your comment mkuznets. I appreciate your input regarding XSD to class conversion - I agree that this is a super useful concept for sending ISO20022 files.

I think there's always some ergonomic gap between these XML Schema generated classes and SDKs that developers are comfortable using. My intention for this library is for a non-payment developer to be able to interact with the ISO20022 schemas, while being as true to the underlying models as possible.

Hey catapart, thanks for your comment.

You're right. Accepting credit card payments over the internet is usually done handled by black-box third party payment processors.

Bank payments, like ACH, SWIFT, and others are usually built in-house by companies that move money at scale, like payroll providers, insurance companies, and other old school institutions.

As companies that do heavy financial management refresh their architecture and move to modern web servers and the like, they'll likely need to rebuild it from scratch. This is what iso20022.js plays a small part in - if they're building on Node this is a convenient library for them to use.

Thanks for asking MuffinFlavored.

There isn't something we are currently offering yet, althoug I wrote about how this works in the quickstart guide: https://docs.iso20022js.com/quickstart#step-4-send-the-payme...