Banks move money by sharing files, and that's OK
Engineers' efforts to build banking APIs have failed because they're approaching bank transfers the wrong way
Pay by bank is a white lie.
This payment method category, which includes Stripe’s Link, Paypal’s Fastlane, or Shopify’s Shop Pay, is fundamentally different from a bank transfer as a payment method. It’s a wallet in disguise, one where your bank account and other sensitive information is stored for recurrent use. Just like ApplePay stores your credit card credentials, "pay by bank" stores your bank account's.
There is no bank in "pay by bank".
“Pay by bank” exists as a reaction against the creepiness of scraping the banks' websites with your login credentials exposed. Which is what Plaid does.
And Plaid exists because banks do not have a clean API to programmatically access your bank account. It gets around this limitation by scraping: you give Plaid your username and password, and its system uses it to basically log into their portal on your behalf.
Doesn't it sound shady? That's because it is.
Now, most engineers don't understand that, even though banks aren't particularly happy about this, they aren't trying very hard at preventing this from happening. Yes, banks move slowly, especially when it comes to technology. But the real reason why banks haven’t build robust APIs is that neither they nor their customers need them.
What they do instead is sharing files.
Picture this. ACH was put online in the 1970s, and its primary goal was to mitigate the burden that processing checks had become. If you've ever wondered why banks are usually closed in the afternoon, it’s because they needed the rest of the day to keep up with the explosion of check usage.
When ACH came about, the simplest and most effective way to transfer data over the network was FTP.
Save some modernization efforts, such as switching to SFTP, that's basically where bank transfers remain, technologically, to this day:
Bank executives don’t see themselves as the leaders of tech companies.
Bank transfers have been traditionally very lax in terms of settlement speed: instant money movement was the realm of cash, checks and credit cards, whereas transfers fulfilled obligations known days in advance, such as utilities and salaries payments.
File transferring is difficult and expensive to phase out (high stakes and entrenched dependencies). The obvious path has been to half-ass an API that transforms requests into files and vice versa.
As a result, all bank transfers in the US and the EU run through files. And I know is shocking, but this is a good thing.
I’m Alvaro Duran, and this is The Payments Engineer Playbook. Each week, we investigate the technology to transfer money, so that you become a smarter, more skillful, and more successful payments engineer. And we do that by cutting off one sliver of the technology of payments, and extracting tactics from it.
One reader said that The Playbook consists of “deep dives on the stack behind the magic”.
Today, we’re looking at bank transfers, and specifically why the path forward isn’t to move everything to HTTP, but to have a better file transfer protocol.
What's the valuable thing about network protocols? It's not the speed of data transfer; that's for the most part determined by the hardware.
No, what's valuable about network protocols is the delicate balance between security and accessibility.
SFTP is secure enough, and banks can provide a server to external parties once they've gone through a verification process.
What makes this whole arrangement feel “old” is the lack of a consistent developer experience.
Doesn't this story reminds you of the Stripe's API redesign? After years of being incapable of keeping up with the Cambrian explosion of payment methods, Stripe's engineers finally realized that they shouldn't strive for the simplest API possible.
They should’ve aimed at making the building of applications consistent.
Banks are slowly reaching the same conclusion. It's not that file sharing is antiquated; it's that developers who want to build integrations with multiple banks are having a terrible time.
The transfer of data isn’t the bottleneck. It's the format of the data being transferred.
That's why I'm following with excitement the development of a library called iso20022.js.
ISO20022 is the global standard for bank transfers. Both the Federal Reserve and SEPA are mandating banks in the US and the EU to support that standard. For every bank that's adopted it, uploading a file that follows ISO 20022 into their SFTP server will work like a charm.
And on the other end, a consistent format will make processing transfer requests much easier to automate. It is embarrassing that many banks, in 2025, are still processing money movements with human beings, rather than machines. They're the bottleneck to the adoption of real time bank transfers.
The problem, though, is that ISO20022 is an extremely precise and complex standard.
Which is why having a library is so useful! It makes the learning curve so much smoother. It makes common use cases more idiomatic, and provides guidelines and help on how to go deeper into less common scenarios.
It's 2025. FedNow is finally a thing. And since the 9th of January, SEPA has effectively made instant bank transfers in the Eurozone free .
This is the ultimate push that a consistent standard for bank transfer communication needs. Developers can now build systems that talk money with multiple banks easier. Banks are being pushed into automating their back office, and fast.
If you're curious about the ISO20022 standard, the creator of iso20022.js has put together a tutorial on how to make SEPA transfers from scratch. It's mindbogglingly simple.
This has been The Payments Engineer Playbook. I'll see you next week.