We all worked before with many types of banking connections, all file-based: web banking, host to host, SWIFT, EBICS. All of it shares one trait. You send a file, you wait, a file comes back on a schedule someone agreed to years ago. APIs break that pattern, and that is the whole point.

What an API actually is

An API (application programming interface) is a structured way for two systems to talk directly, on demand.

File based connectivity is the postal service. You write a payment file, drop it in the channel, and a statement file arrives later. An API is a phone call. You ask one precise question, you get one precise answer, immediately.

The other half of the idea is that you never touch the bank’s core system. You ask the API “what is the balance on this account right now,” and it hands back that number and nothing else. You are the diner. The API is the waiter. The kitchen stays closed to you, which is exactly what the bank’s security team wants.

The split: Open Banking versus premium APIs

For simplicity, we hear APIs are “Open Banking”. That is the mistake. There are two very different kinds of bank API, and confusing them will cost you time.

Open Banking APIs are the regulated ones. In Europe they exist because the law forced banks to build them. They let licensed third parties read your account data or trigger a payment, with your consent. They are free, standardized in theory, and built for a specific audience: fintech apps serving retail customers and small businesses.

For corporate treasury, Open Banking has a catch. It was designed for the person checking a current account in an app, not for a multinational moving forty million across six banks. Coverage is limited to payment accounts available online. The data is thinner than what you already get in a CAMT.053 statement. And the strong customer authentication rules force a fresh consent roughly every ninety days, which is fine when a human owns one account and miserable when a treasury system owns two hundred.

Premium APIs, sometimes called corporate or commercial bank APIs, are the ones built for you. The bank offers them as a product, not a legal obligation. You sign a contract, you pay, and in return you get the functionality that actually matters in treasury. Real time balances, payment initiation at scale, payment status down to the single transaction, virtual account data, FX rates, and webhooks that push you an alert the moment money lands.

Same underlying technology. Completely different deal. Open Banking is the minimum the bank was forced to give away. Premium is what they will sell you when you need it to run a real treasury.

The European directive part

Open Banking in Europe did not appear by accident. It exists because of PSD2, the Second Payment Services Directive, in force since 2018. PSD2 made banks open their payment account APIs to licensed providers and gave us two categories: AISP, which reads data, and PISP, which initiates payments.

The next chapter is already written. In 2026 the EU agreed the final texts for PSD3 and a new directly applicable Payment Services Regulation, the PSR, which together replace PSD2 (summary here). The headlines for treasury: tighter rules on API performance and uptime, mandatory name and IBAN matching on credit transfers, and regulators told to act fast against banks whose interfaces underperform. The rules are expected to apply around 2028 after publication, so this is a watch the runway item, not a fire drill.

Do not over read it. PSD3 still aims squarely at retail and consumer protection. It will make the regulated rails a little better, but it does not turn Open Banking into a corporate treasury channel. For that, you are still looking at premium APIs. The genuinely corporate open finance rules sit in a separate file that the EU is still negotiating.

What APIs give treasury that files do not

• Real time. Balances and payment status when you ask, not at 7 AM tomorrow.
• Event driven. A webhook tells you the instant a payment settles, so your system reacts instead of polling.
• Granular. You query one payment, one account, one status, instead of parsing a whole batch to find one line.
• A natural fit for instant payments, where a statement file the next morning is already too late.

If your pain is “I do not know my cash position until someone refreshes a file,” APIs are the direct answer to that specific problem.

The part the vendors skip

APIs are not a free upgrade, and anyone selling them as one is selling.

• No universal standard. EBICS and SWIFT give you one channel and standardized file formats across every bank. Each bank’s API is its own dialect, so you integrate, and maintain, each one separately.
• Maintenance never ends. APIs get versioned, deprecated, and changed. A file format from 2009 still works. An API endpoint from last year might not.
• Coverage gaps. Plenty of banks, especially outside the big markets, still have no usable corporate API. Your TMS connector list will be uneven.
• Volume. APIs shine at real time single calls. For a fifty thousand line payroll batch, a file is still often the cleaner tool.
• Reconciliation and audit. A file is an artifact you can store and reopen. API traffic is ephemeral, so you need disciplined logging to keep your auditors calm.

None of this kills the case for APIs. It means they join the toolkit instead of replacing it.

So what should a treasurer actually do

Stop treating APIs as a replacement for EBICS, SWIFT, or host to host. Treat them as the layer you add on top for the jobs files do badly. Real time visibility. Instant payment confirmation. On demand status checks. Triggering one urgent payment without logging into a portal.

Keep your bulk payments and your end of day statements on the standardized file rails that already work. Add premium APIs where real time genuinely changes a decision. Use Open Banking for specific consent based cases, not as your treasury backbone.

The bank already has the phone line open. The only question is whether your treasury is still writing letters.