4 ms·

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

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.

deleted 2y ago
[deleted]
enahs-sf 2y ago
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?
- logicalmind 2y ago
  There are a lot of hurdles. I'm not exactly sure why an end-user would even want to use ISO20022. Some end-user system may use ISO20022 behind the scenes, but the UI's are very simplified. ISO20022 as far as I have used it (20+ years in finance) is for payment networks. And a random person can't just send messages on any payment networks that I'm aware of. These payment networks generally exist as message queues that are interconnected and they use ISO20022 as the data format. 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).
svapnil 2y ago
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-payment-initiation-message-to-the-bank 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!

deleted 2y ago

[deleted]

enahs-sf 2y ago

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?

logicalmind 2y ago
There are a lot of hurdles. I'm not exactly sure why an end-user would even want to use ISO20022. Some end-user system may use ISO20022 behind the scenes, but the UI's are very simplified. ISO20022 as far as I have used it (20+ years in finance) is for payment networks. And a random person can't just send messages on any payment networks that I'm aware of. These payment networks generally exist as message queues that are interconnected and they use ISO20022 as the data format. 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).

svapnil 2y ago

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-payment-initiation-message-to-the-bank 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!