Every few years the corporate treasury market rediscovers bank APIs and predicts the end of file-based connectivity. It has not happened, and in 2026 it is clearer than ever that it will not happen as a replacement story. What has emerged instead is a portfolio: premium bank APIs for real-time balance, status, and event-driven flows, and host-to-host SFTP, EBICS, and SWIFT FileAct for the bulk, batch, and multi-approval workloads that move most of the money.
The reason is not bank inertia. The two channel families are good at different things, and the things files are good at, throughput, staging, batch approvals, retries, and predictable cutoff behaviour, are exactly what core payment runs need. The interesting question for a treasury team is not which channel wins but how to split the estate: which flows justify API work per bank, which stay on files, and how much heterogeneity to absorb through an aggregation layer.
Getting the split wrong costs in both directions. All-file estates leave treasury blind intraday and force positioning decisions on stale data. All-API ambitions collide with the reality that bank APIs are not standardised, and the integration budget disappears into bespoke connectors before the payment flows that pay salaries ever migrate.
What each channel is actually for
- Premium bank APIs are bank-specific corporate interfaces, often fee-based, exposing balances, transactions, payment initiation, and status. Their strength is latency: balance snapshots and payment status in near real time, which batch reporting cannot give you. Their weakness is fragmentation, since each bank exposes different objects, auth models, and semantics.
- Host-to-host SFTP is the boring backbone: scheduled, private file exchange for payment files out and statements back. Separate onboarding per bank and inherently batch, but simple, secure, and proven at volume.
- EBICS is regional infrastructure with real depth in Germany, France, Austria, and Switzerland. Inside that footprint it is often the best answer; outside it, it is not an answer at all.
- SWIFT FileAct with Alliance Lite 2 is the global file transport for multi-bank groups: one connection reaching many banks, suited to high-volume ISO 20022 payment files and reporting. The trade-off is enterprise-grade cost and setup, which is why mid-market firms often stop short of it.
- Aggregators and connectivity platforms sit above all of these and normalise access. They reduce integration pain materially, but the underlying bank heterogeneity still exists beneath the normalised surface.
Most large treasuries end up running four of these five at once. That is not indecision; it is the correct shape of the solution.
Read flows first, write flows carefully
The cleanest strategic guidance in this space: APIs fit read flows first, write flows later, sometimes never.
Balance and transaction APIs are the easy win. The business value is immediate, intraday cash visibility, account aggregation across banks, and event-driven automation such as refreshing a liquidity position when a large credit lands. The integration risk is low because a failed read costs you freshness, not money. If you are building intraday cash intelligence, API balance feeds alongside camt.052 reporting are the data layer, and this is where per-bank API investment pays back fastest.
Payment initiation is the hard side. Corporate payment runs carry approval chains, value caps, entitlement models, and cutoff logic that file workflows encode naturally: a pain.001 batch gets staged, approved by the right signatories, submitted, and if something fails there is a defined recovery path for the whole batch. API initiation journeys have to reproduce all of that per bank, against interfaces that differ in field mappings, supported payment types, and error models. And a subtlety that catches teams repeatedly: a successful API response often means “accepted for processing”, not “paid”, so you still build status polling or callback handling to learn the outcome. The write side frequently stays file-based on merit, because operational certainty beats immediacy for core runs like payroll, supplier batches, and direct debits.
The standardisation problem is the whole problem
Why APIs have not converged the way SWIFT messaging did is worth understanding, because it drives the economics.
- Schemas and semantics differ per bank. Field names, auth methods, error models, and status codes vary materially. Two banks’ “payment status” endpoints can disagree about what the same state means.
- Protocol mismatch. Bank APIs are mostly JSON-native while treasury standards revolve around ISO 20022 XML, so something in your stack translates between the two worlds, and that mapping is where defects live.
- Uneven capability coverage. One bank exposes balances but not initiation; another supports initiation only for certain payment types, currencies, or countries. Your architecture has to tolerate holes.
- Onboarding overhead. Each bank means certificates, entitlements, testing, and a support relationship. For a group with 20 banking partners, this erodes much of the speed advantage APIs promise.
This fragmentation tax is the real argument for aggregation platforms: pay once for someone else to maintain the connectors. It is also why the aggregator does not dissolve the problem, since capability holes and semantic differences pass through any normalisation layer. Treat aggregators as a way to shrink the maintenance burden, priced accordingly, and keep the per-bank capability map as your own living document.
Deciding the split for your estate
A workable decision procedure per flow: how fresh does the data need to be, how many items move at once, how many approvals does it need, and what is the recovery path when it fails mid-flight. Latency-sensitive, low-volume, low-approval flows point to APIs. High-volume, multi-approval, recovery-sensitive flows point to files. Regional footprint then picks the file rail: EBICS in its strongholds, H2H SFTP for deep bilateral relationships, FileAct where multi-bank global reach justifies the cost.
The operational reality is that the portfolio itself becomes an asset to manage. Certificates expire, banks version their APIs, file schemas drift, and cutoff calendars change; connectivity needs an owner, monitoring, and runbooks like any production system. Instrument every channel for observability, missed files and stale feeds should page someone before treasury notices, and log submissions, acknowledgements, and status transitions as an audit trail, since non-repudiation is a genuine requirement when a payment run is disputed. Renegotiate the map annually: bank API capabilities are improving quickly enough that a flow correctly left on files in 2024 may deserve reassessment now, and a written channel strategy per flow is what keeps those decisions deliberate rather than archaeological.
FAQ
Does a connectivity aggregator remove the need to understand each bank's quirks?
It moves the problem, which has value, but does not delete it. Aggregators normalise transport and give you one integration surface, yet the underlying banks still differ in supported payment types, field semantics, cutoffs, and status behaviour, and those differences leak through. Buy an aggregator to avoid building bank-by-bank plumbing; still budget analyst time per bank for mapping and testing.
When is EBICS the right answer for a treasury?
When a meaningful share of your bank relationships sit in Germany, France, Austria, or Switzerland. Inside that footprint it is cheap, standardised, and well supported for payment files and statements, and it avoids per-bank host-to-host projects. Outside the footprint it simply is not available, so treat it as a strong regional component of a portfolio rather than a candidate for your global standard.
Should new payment flows default to API initiation now?
Default read flows to APIs and decide write flows case by case. A low-volume, time-sensitive flow such as a treasury transfer before a cutoff is a good API candidate. A 10,000-line supplier run is not, because batch approvals, staging, and recovery matter more than latency there. The deciding questions are volume, approval chain complexity, and what happens when something fails mid-flow.