91–100 of 139 posts
>> 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?
Why NPM in particular? Is there any package manager where you don't have to audit your dependencies?
>> 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?
That’s what fintech is, one large dependency tree
Super stupid question, but this must have some kind of authentication, right? Where is that part?
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
Earlier quoted context omitted.
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
> impossible to change or improve functionality for You have to think inside the box! What if, say, instead of lastname "SMITH" we used "SMITH,FEE: 5.65"
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 XM…
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 bein…
Generating classes from the XSD's is fairly trivial in most languages. The hard part is being able to read the XSD's and then being able to create the ISO20022 message with all of the required elements (given all the possible combinations of valid elements).
I guess creating a code-time library where it was not possible to create an ISO20022 message that invalid would be interesting. But being able to create invalid ISO20022 is fairly easy to do for free.
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.
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.
As of early next year, the Fed (US) will not accept anything other than ISO20022 messages on their networks. So any banks that are using Fed networks are required to use ISO20022.
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. - Con…
Can you go into a bit more detail here. Seems like there are a lot of hurdles in place to preventing any random from just moving money around?
Not to mention that the flows of ISO20022 messages are full duplex. If you send a message you need to be ready to handle a response (acceptance or rejection of a credit/debit for example).
Earlier quoted context omitted.
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
> impossible to change or improve functionality for You have to think inside the box! What if, say, instead of lastname "SMITH" we used "SMITH,FEE: 5.65"