Treasury Integration Patterns: Files, APIs and Middleware

Treasury systems integrate three broad ways — batch files, APIs, and a middleware layer that sits between them — and the real skill is choosing deliberately per flow rather than accreting interfaces by accident. File-based batch is the traditional backbone; APIs add immediacy where it pays; middleware decouples the whole landscape so it scales. Most treasury estates I've worked in are a hybrid of all three, and whether that hybrid is clean or a swamp comes down to whether someone decided the shape on purpose.

This is the broader-patterns companion to designing ERP-to-TMS integration: that piece is about the flows between two specific systems; this one is about the mechanisms you connect any two systems with, and how they compound across a whole landscape.

The three patterns

File-based / batch. The oldest and still the workhorse. Systems exchange structured files on a schedule — bank statements in as MT940 or camt.053, payments out as pain.001 / ISO 20022, accounting extracts, AP/AR feeds — moved over SFTP or a host-to-host channel. Nothing happens the instant an event occurs; it happens when the job runs. In eighteen years of SAP FI and TRM work, the overnight statement file is still the thing the morning cash position is built on at most companies, and there's a good reason it endures.

API-based / real-time. REST calls and webhooks that fetch or push data on demand: a same-day balance, an intraday statement, a payment status that updates as it clears, an instant payment. Instead of waiting for the next batch window, you ask when you need to know, or you get called back when something changes. This is the mechanism behind straight-through processing and much of what banks now offer alongside their file channels — see bank connectivity options for how these sit next to SWIFT, host-to-host and EBICS.

Middleware / integration layer. An iPaaS, ESB or integration hub that sits between the systems rather than wiring them directly together. It maps one system's format to another's, orchestrates and schedules the flows, retries failures, and gives you a single place to watch every interface. It doesn't do treasury work itself — it makes the connections between the systems that do.

The trade-offs

Each pattern buys you something and charges you something:

• Batch is simple, robust and reconciliable — but not real-time. A file is easy to reason about, easy to rerun, and easy to check with control totals (record counts and amount sums sent vs received). The price is latency: you know what the file knew when it was cut, not what's true now.
• APIs give immediacy — and add three new problems. You gain currency and on-demand access. You inherit availability (the endpoint has to be up when you call), error handling and retries (a timeout mid-payment is a different problem from a file that didn't arrive), and versioning (endpoints change, and a silent change to a field can break you weeks later). None of these are dealbreakers; they're just work that a nightly file doesn't ask of you.
• Middleware costs more up front — and scales far better than a mesh. Standing up an integration layer is real money and real effort before it carries a single flow. What you're buying is the thing that stops the landscape collapsing as it grows.

"

The cadence of an interface is a design decision, not a default. Batch, API or brokered through middleware — choose it per flow, for a reason, and write the reason down.

The choice that actually shapes the landscape: point-to-point vs hub-and-spoke

The pattern that decides whether a treasury estate stays maintainable isn't files vs APIs — it's point-to-point vs hub-and-spoke.

Point-to-point looks harmless at first. Two systems, one connection. Add a bank, add a direct link. Add a payment factory, a market-data feed, a second ERP after an acquisition — each one a fresh direct wire to everything it touches. The connection count doesn't grow linearly; it grows toward n squared. I've walked into landscapes with dozens of these — most undocumented, several with no clear owner, a couple that no one dared touch because nobody could say what would break. That's the mesh, and it's how integration quietly becomes the thing everyone's afraid of.

Hub-and-spoke inverts it. Every system connects once, to the middleware. Adding a system is one new spoke, not a new wire to every existing node. The format mapping lives in one place; the monitoring lives in one place; the ownership is clear because the hub is the owner of the connections. That's the whole case for middleware, and it's why the up-front cost is usually worth it past a handful of systems.

The concerns that cut across all three

Whatever mechanism you choose, the same handful of things separate a stable interface from a fragile one — and they matter for a file, an API and a brokered flow alike:

• Idempotency and duplicate handling. A rerun after a failure, or a webhook delivered twice, must not double-post or double-pay. Design every flow so reprocessing is safe.
• Error handling and retries. Decide what happens when a flow fails — not if. Retries with sensible limits for transient failures; a clear stop-and-alert for the rest.
• Reconciliation. Every interface should carry a way to prove all the data arrived intact. Control totals turn a silent partial failure into a caught exception.
• Monitoring. Watch whether each interface ran and completed, and alert an owner when it didn't. An unmonitored interface is a wrong number waiting to happen. This earns its own discipline.
• Clear ownership. Every interface has exactly one team that owns it. The orphaned interface — the one nobody remembers building — is where the worst incidents come from.

Docs vs reality

The architecture diagrams show clean patterns: this flow is batch, that one is an API, everything brokered through the hub. Reality is a hybrid, and that's fine — batch files for bank statements because they're robust and reconciliable, APIs where intraday currency genuinely pays, middleware in the middle so it all holds together. The problem is never the hybrid. The problem is the accidental hybrid — the one where each interface was added the fastest way that worked that day, and five years later no two look alike and no one owns half of them.

The skill isn't picking one pattern and forcing everything through it. It's choosing deliberately, flow by flow, and keeping the count of interfaces something a human can still hold in their head. Decide the shape on purpose, or the landscape decides it for you — badly.

Part of the Treasury Systems Architecture guide. See also designing ERP-to-TMS integration and interface monitoring and reconciliation. The newsletter sends one finance-systems pattern every two weeks.