August 14th, 2024

Where Banking APIs Fall Short

Software engineers face challenges integrating with bank APIs due to reliance on outdated file-based systems. The focus should shift to enhancing existing standards like ISO20022 rather than creating new APIs.

Read original articleLink Icon
Where Banking APIs Fall Short

The article discusses the challenges software engineers face when integrating with bank APIs, highlighting that traditional banking communication relies heavily on file-based systems rather than modern REST APIs. The author, who has experience working with bank integrations, notes that most banking instructions are transmitted via SFTP and file formats like NACHA and MT103, which are outdated compared to the more user-friendly APIs seen in consumer applications like Stripe. The fragmentation of banking APIs, with each bank having its own interface, complicates integration efforts. The author argues that instead of creating new REST APIs, the focus should be on improving existing file-based standards, particularly ISO20022, which is becoming the standard for financial messaging. The article emphasizes that the future of banking integration may lie in enhancing these file-based systems rather than reinventing them with new APIs.

- Bank APIs are often difficult to integrate with due to reliance on file-based communication.

- Most banking instructions are sent via SFTP and older file formats rather than modern APIs.

- Banking APIs are fragmented, lacking a unified, developer-friendly interface.

- The future of banking integration may focus on improving existing file standards like ISO20022.

- The author has developed iso20022.js to facilitate easier interaction with this file standard.

Link Icon 5 comments
By @habitue - 5 months
Differences between files and REST apis:

- files get persisted to disk by default. Usually we don't save every rest result to disk (though obviously, you could)

- files tend not to be processed at request time, but rather the directory acts as a queue. Usually with rest, we try to process things at request time until stuff gets too slow. Files always decouple

- multiple transports are the norm: SFTP, SMTP, etc. doesn't matter since it's not going to be processed at request time, but async. Think of "dropping it into a directory" as stripping off the transport layer the same way your web framework and reverse proxy abstract away http 2/3 for you.

- formats: much more variety than json everything. Back in the day, people liked to write custom parsers for everything. Nowadays, we like to let json be the bytes to in-memory data structure, and programmers recurse over that structure rather than spending their time ensuring their parser isn't ambiguous

By @adzm - 5 months
Even HL7 which is used for healthcare communication is still very often communicated over file drops as well. Honestly it has some great advantages in terms of simplicity. Need to reprocess a file? Put it in the folder. Fail to process? Move it to a different folder for later viewing. The biggest issue is just having good SFTP server and client solutions that are scalable on multiple platforms.
By @orev - 5 months
Batch files have been used forever (since mainframes), and I get suspicious when someone implies that APIs are the “normal” way to do things. It makes me think they don’t have enough experience outside of the app development bubble.

Files definitely have limitations (they’re almost always a single table of data—it’s hard to do data structures), and that seems to be driven by the need for someone in the chain the be able to open it in Excel.

By @crowcroft - 5 months
> The future doesn’t look like an API, it looks like better and better files.

Would be curious what the author thinks of initiatives like Open Banking, which don't seem to be a big topic in the US, but are in the EU and Canada at the moment.

My expectation is that banks should be abstracting away the 'under the hood' part, and so the future would look like an API.