TMS, EBICS, API, ISO 20022: Four Layers, Not Four Alternatives

Someone in IT, or a vendor on a sales call, asks: “Are you on EBICS or API?” It sounds like a straight choice — pick a lane. It isn’t. It’s a bit like asking “do you use email or PDF?” One is how a message travels. The other is what’s inside it. You can have either with either.

This mix-up isn’t just semantic. I’ve sat in project meetings where “we’re moving from EBICS to API” was said to mean “we won’t need pain.001 files anymore” — a conclusion that doesn’t actually follow from the premise, and that ends up costing someone a rebuilt interface for no reason.

The actual stack

Four separate decisions get collapsed into one conversation. They sit at different layers, and changing one doesn’t require changing the others.

1. Application — who decides what to send, and who reads what comes back. Your TMS, your ERP, a treasury workstation, sometimes a spreadsheet with a macro. This is the system that assembles a payment instruction or parses a statement. Examples: Kyriba, SAP, Coupa, GTreasury, an in-house tool.

2. Communication channel — how two systems physically exchange data and authenticate each other. EBICS, the SWIFT network, a direct Host-to-Host/SFTP link. This layer answers “how does a file (or a call) actually get from your infrastructure to the bank’s,” including the certificates, keys, and onboarding that make that trustworthy.

3. Interface style — scheduled files, or on-demand calls. Batch file transfer (a file lands at a certain time, you pick it up) versus a real-time API (you call an endpoint and get an answer in seconds). This is really a property of layer 2 — EBICS and SFTP are batch by nature, APIs are real-time by nature — but it’s worth naming on its own because it’s usually the thing people actually care about when they say “we want to move to API.”

4. Message standard — what’s actually inside the exchange. ISO 20022 (pain.001 for payment initiation, camt.053 for statements, pacs.008 between banks, and dozens more), or the legacy SWIFT MT formats (MT101, MT940). This layer is independent of how the message travelled to get there.

Why the confusion causes real problems

“We’re moving from EBICS to API” almost always means a change to layer 2 and 3 — a different channel, a different interface style. It says nothing about layer 4. Plenty of bank APIs still exchange ISO 20022-shaped payloads, sometimes wrapped in JSON, sometimes as the same XML you were already parsing. Conversely, plenty of EBICS connections carry ISO 20022 messages too — EBICS is just the pipe; pain.001 and camt.053 travel over it constantly. Assuming a channel change forces a message-format rebuild is how projects estimate a month of work that turns out to be a week, or the reverse.

The same confusion runs the other way: choosing a TMS (layer 1) doesn’t lock you into one channel. A modern TMS can typically speak EBICS to one bank, sit behind an aggregator for another, and call a bank’s API directly for a third — the application layer doesn’t need to know or care which channel is underneath, as long as the interface between the TMS and each channel is configured correctly.

Vendors sometimes blur these layers on purpose, because “just switch to our API and you’re modern” is a simpler pitch than “we’re changing your interface style, not your message content, and here’s what actually stays the same.” It’s worth asking, every time: which of the four layers is actually changing here?

One connection, laid out layer by layer

Take a single bank relationship and separate it out:

• Application: your TMS (say, Kyriba)
• Communication channel: EBICS
• Interface style: batch — one file exchange per day
• Message standard: pain.001.001.03 outbound (payment initiation), camt.053.001.02 inbound (end-of-day statement)

Now suppose that same bank starts offering an instant-payment API for one specific use case — say, real-time balance checks before a large payment. What actually changes:

• Application: unchanged — still your TMS
• Communication channel: now an API instead of EBICS, for this one use case
• Interface style: now real-time instead of batch, for this one use case
• Message standard: could stay ISO 20022 (many bank APIs expose pacs.008-shaped or camt-shaped data inside JSON), or could be the bank’s own proprietary schema — that’s a separate question, not implied by the channel change

Your EBICS connection for daily statements and batch payments doesn’t have to go anywhere. You end up running two channels to the same bank, each suited to a different interface style, and that’s normal — not a sign that the architecture is unfinished.

What to actually ask, per layer

When a project introduces a new bank, a new channel, or “an API,” it’s worth pulling the conversation apart by layer instead of accepting whatever single label gets used:

• Application: What does our TMS/ERP actually support as an outbound and inbound channel today? Native, or does it need middleware?
• Communication channel: Is this EBICS, SFTP, SWIFT, or a bank API — and who holds and rotates the credentials or certificates?
• Interface style: Scheduled or on demand? What’s the actual latency, and what happens if the connection is down when a file or call is due?
• Message standard: Which ISO 20022 version, and which rulebook (the bank’s, or a national one like CFONB)? Or is this still a legacy MT or proprietary format?

Four different answers, from potentially four different teams — your TMS vendor, your IT security team, the bank’s connectivity desk, and the bank’s format documentation. Getting them confused with each other is exactly what produces a requirements list that looks complete but has a layer entirely missing from it — see the Connectivity Requirements Builder if you want to check yours against all four before you commit to anything.

Sources worth reading directly

Each of these layers has an actual standards body behind it, publishing more precisely than any single article (including this one) can summarize:

• EBICS.org — the EBICS Standardisation Initiative, for the communication standard itself and its current specification.
• ISO 20022 catalogue of messages — the authoritative list of every message definition and its versions. Don’t treat any single pain.001 or camt.053 example, including the ones in our own Payment Message Explorer, as valid for every bank without checking this against what your bank actually implements.
• BCBS Report on Open Banking and APIs — the Basel Committee’s 2019 report on how banking supervisors are actually thinking about the API layer, if you want the regulatory framing rather than a vendor’s.

My conclusion: treat these as four independent decisions, not one bundled choice. Changing your channel doesn’t require changing your message format. Picking a TMS doesn’t lock you into one channel. When someone frames it as a single either/or, ask which layer they actually mean.