Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

So true. And next to the 675,000 lines of business logic that you describe, you'll need an additional 133,700 lines of boilerplate code that:

- ensures all operations are atomic. You can't just post to an API and then insert something in your database: that's a guarantee to have payments in one place and not the other.

- has some way to retry on failure: your average job-queue with exponential backoff is quite certainly still too naive.

- has full, secured and guaranteed audit logs. That have all the data needed for an audit, but also not too much. You chose to not go for the Event Sourced Architecture because of Reasons? Good luck bolting it in now.

The hard part isn't generating some pain.001.001.03 (yes, that really is the name for the SWIFT Payments Initiation in iso-20022) format. The hard part is everything else.



Add some lines for managing the bank's security requirements: signature, encryption and authentication.

If you work with multiple banks, like many corporates or fintechs, multiply many of these lines by the number of banks you work with.

Even before starting to code anything, a big part of the job is obtaining the documentation from each bank and specifying the integration for each bank.

For instance, for the same payment scheme, different banks require different maximum payments per file or payload, or maximum payment file or payload size.

More things to consider in this high-level article https://www.numeral.io/blog/bank-payment-integrations-challe...


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 [email protected] and I'd love to get in contact with you




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: