Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Iso20022.js – Create payments in 3 lines of code

iso20022js.com

Post reply on HN
Print view View original

101–110 of 139 posts

Re: Show HN: Iso20022.js – Create payments in 3 lines of code

#101

Post by Kiro »

franciscop wrote: post #6
svapnil wrote: post #2

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!

Since you do say it in HN tagline, what are the "3 lines of code"? I can only see 43 LoC in the landing page. A tool to help massively with payments is always welcome of course, but if this is really 43 lines instead of 3 it'd feel like shady marketing (no judgement until there's a reply/clarification).

Nothing shady with that at all and extremely obvious what 3 LoC refers to.

Re: Show HN: Iso20022.js – Create payments in 3 lines of code

#106

Post by aerzen »

kevsim wrote: post #105
worik wrote: post #104

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

What makes node inherently unsuitable for finance software?

The culture of the ecosystem, ease of dependency chain attacks, lack of static type system + rigorous number handling which can lead to subtle bugs.

Re: Show HN: Iso20022.js – Create payments in 3 lines of code

#107

Post by leokennis »

mrloba wrote: post #36

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

I work in banking in the EU, we process SEPA messages only (not SWIFT) and the standards for interbank communication are very strict and top-down. I.e. (fictional), if you want to charge a fee when you return money after you received an investigation, it MUST be put in "field xyz" and if you do so, "field abc" MUST contain the code "ABC1" or "DEF2" etc.

The times when the standards are expanded or updated are fun (https://www.europeanpaymentscouncil.eu/what-we-do/epc-paymen...), translating hundreds of pages of PDF into working code and then have hundreds of banks implement those changes in the same nightly hour during a weekend...but once it is working, there is no ambiguity or (horror) manual intervention in payment messages. Either you as a bank send valid messages and they are processed, or you don't and they get rejected.

Re: Show HN: Iso20022.js – Create payments in 3 lines of code

#109

Post by evrimoztamur »

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!

Re: Show HN: Iso20022.js – Create payments in 3 lines of code

#110

Post by evrimoztamur »

leokennis wrote: post #107
mrloba wrote: post #36

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

I work in banking in the EU, we process SEPA messages only (not SWIFT) and the standards for interbank communication are very strict and top-down. I.e. (fictional), if you want to charge a fee when you return money after you received an investigation, it MUST be put in "field xyz" and if you do so, "field abc" MUST contain the code "ABC1" or "DEF2" etc. The times when the standards are expanded or updated are fun ( h…

In my experience at the frontlines (banks allowing users to submit SEPA XMLs), the situation is a lot messier. I ended up building an exporter from Xero (globally renowned cloud accounting software) to SEPA for both payments and direct debits, and we have several bespoke export templates for a handful of banks that want it this-not-that way.

I wrote a bit about the tool and my experience with SEPA standards at https://evrim.zone/blog/projects/batch2sepa, check it out!

Post reply on HN