Your TMS Supports Every Bank Channel. Through Its SFTP.

·

3 min read

·

Most TMS connectivity conversations start with the questions: Does our TMS support EBICS? Does it support this bank’s API? Is host to host on the roadmap?

Almost always, the answer does not matter.

Your TMS does not need to speak the channel

Almost every TMS exposes an SFTP folder. You drop a file in, it ingests it. You request a payment file, it lands there. That is the integration surface, and it is the same whether the data arrived by EBICS, by SWIFT, by host to host or by a bank API.

Which means the TMS and the connection method are decoupled. The TMS does not have to speak EBICS. Something upstream speaks EBICS, lands a clean file in the SFTP, and the TMS never knows the difference. The bank can deliver host to host straight into that folder. An aggregator can collect by API and drop the result in the same place. Middleware can sit in between.

So “does my TMS support this bank” is rarely a TMS question. It is a question about who puts the file in the folder, and who keeps doing it when the format changes.

That reframes the whole purchase. You are not shopping for a TMS that speaks every protocol. You are deciding who maintains the feed into the one protocol every TMS already speaks.

“Aggregator” is not one thing

You should not treat aggregators as a single category. At one end, full multibank aggregators that cover many banks across many methods, host to host, EBICS, SWIFT and API, and hand you one normalized format.

At the other end, narrow ones. API only aggregators built for open banking or premium bank APIs, that do nothing for your host to host banks. Players that specialize in a single method, a single region, or a single message type.

Buy “an aggregator” without asking which kind, and you end up with one that elegantly covers the three banks that already had decent APIs, and leaves the two awkward host to host relationships, the ones you actually wanted help with, exactly where they were.

So the real question is coverage. Which of my banks, by which method, does this specific aggregator carry. Not “do they aggregate”, but “do they aggregate mine”.

What this leaves you deciding

Strip it down and two decisions remain.

Who feeds the SFTP, and maintains that feed when certificates expire and banks change formats. You, an aggregator, the bank directly, or some mix.

And whether you need full coverage or just one gap patched. A single API only aggregator is perfect if your problem is one open banking feed, and useless if your problem is fifteen banks on five methods.

The TMS will swallow whatever you land in its folder. The work, the cost, and the thing worth choosing carefully is everything that happens before the file gets there.

Bank connectivity: who maintains the path Owner = you, an aggregator, or the bank direct Bank A H2H Bank B EBICS Bank C SWIFT Bank D API Aggregator (multibank) host to host, EBICS, SWIFT, many banks API aggregator one method Normalized files SFTP the one door into the TMS TMS The TMS only ever sees the SFTP. The connection method is decoupled. Whoever fills the folder owns the maintenance.

Treasury tech insights. No fluff.

One email per week. Build logs, tools, and opinions from the trenches.

Subscribe →