Where Bank APIs Fall Short
Why it's been so painful to integrate with banks as a software engineer.
Banks were the first businesses to use computers, but even though I’ve spent the last few years building against bank APIs, I’ve never seen one I particularly liked. A few years ago, I worked at WhatsApp, where we integrated UPI through banks in India to bring the instant payments to a billion WhatsApp users in India. Last year I worked at Modern Treasury, where I built and maintained bank integrations against most of the major banks in the United States. Banks across the world have interfaces that are hard to build against, and I hope I can explain why this is and how we might be able to get out this mess.
Last week, I released iso20022.js, which received over a hundred thousands views, making it to the front page of HackerNews. Clearly programmatically communicating with banks is a huge unsolved problem for developers, and I hope what I’ve learned can be helpful for others that are interested in this space.
REST APIs Aren’t How Banks Communicate, Files Are
A vast majority of the instructions sent to banks do not move through the modern day REST APIs that we are used to, they move through file.
Taking a step back - let’s consider how most developers are used to interacting with services on the internet. Most people are used to HTTP APIs, and public facing URLs that return predictable JSON responses. This wasn’t the first way computers interacted with each other. An alternative to REST APIs and gRPC is a much older and simpler solution: SFTP. Most instructions in the banking world are simply done directly via file. For example, to send a SWIFT payment means creating a SWIFT payment instruction and dropping it off via SFTP to a directory you were allocated by a bank.
In 1974, the NACHA file standard was developed to move ACH across the US. Since then, MT103 was designed to move wires, checks, and everything else. The world continues to rely on files and SFTP to power the world’s most critical infrastructure.
This is why the REST APIs offered by banks are so often not good enough. Most banking customers simply aren’t integrating against them. Even if you are, you might be using a solution that gets inevitably converted to files under the hood.
Looking deeper - the Central Banks that move the underlying funds, effectively the centralized database that powers the money movement, only interact using files or file-like structures. Consider that the Federal Reserve’s FedNow and Brazil’s PIX both move through ISO20022 messaging standards that banks provide SFTP hookups for.
Bank APIs are Not Designed to Be Easy to Use
If you’ve built consumer apps, you might be familiar with Stripe’s API. Stripe was built by software developers for software developers, and there’s a clear emphasis on usability and ergonomics. One simple interface works for every credit card and merchant.
On the other hand, Banking APIs are fragmented, and there isn’t a clear incentive to be developer-friendly.
Every bank has their own interface per each type of payment rail they offer, and are always one feature behind the file-based offerings that most of their customers use. We don’t need a thousand different adapters to interact with the banking system.
Open File-Based Messaging Standards Will Prevail
Reinventing the wheel by building new REST APIs may not be what enables developers and entrepreneurs build new businesses on top of the world’s banking institutions. Instead, the files that are currently used to power the world’s economy will continue to get used more.
The banking world started with simple “flat-file” interfaces to send payment instructions. The future doesn’t look like an API, it looks like better and better files.
ISO20022 is the next open file standard that banks use to communicate, and if you pay attention, the world is already moving to this new standard. SWIFT is mandating all instructions will be ISO20022. Currently, all SEPA payments, the ACH of the EU, move via ISO20022 file, and FedNow and Pix are following.
I built iso20022.js to help developers interact with this file standard directly. My goal is not to offer a new standard to abide by, but to make the leading one even easier to integrate with. You can check it out if you wanna see how to build a SWIFT instruction in three lines of code using standards that already exist.
If this is something that resonates with you, I’d love to learn more about your business and help you figure this stuff out. Consider subscribing if you’d like to learn more or reaching out to svapnil@woodside.sh - I’d love to hear what you think.