Treasury Technology in 2026: APIs, Real-Time Data, and the Automation of Complex Finance

Treasury management technology for complex businesses is, for the first time, genuinely interesting. For most of the past decade, the treasury management system (TMS) market was dominated by expensive, slow-to-implement systems designed for large corporate treasury departments, with nothing meaningful in between them and spreadsheets for the mid-market. That gap is closing fast — driven by API-first payment infrastructure, real-time payment systems, and a generation of fintech tools that have made sophisticated treasury capability accessible at mid-market scale.

I want to give an honest assessment of where the technology is in 2026, because there is still too much vendor-driven hype about treasury automation and too little practical guidance on what actually works, at what scale, for businesses with genuinely complex requirements.

The API Revolution: What It Actually Enables

The shift to API-native financial infrastructure is genuinely transformative for treasury operations, but it requires the banking infrastructure to actually have useful APIs — not all do. The difference between a provider with a well-documented, RESTful API that returns real-time balance and transaction data, supports payment initiation, and provides FX rate streaming, versus a provider that offers a batch-upload SFTP interface with end-of-day reporting, is the difference between treasury automation and treasury manual processing with a digital wrapper.

The real-time balance visibility that proper API access enables changes treasury management fundamentally. A CFO or treasurer at a mid-sized iGaming operator, logging into their TMS and seeing real-time balances across all their accounts — GBP, EUR, USD, MGA-denominated accounts — with intraday transaction flows and FX position calculations automatically updated, is working in a fundamentally different information environment from one who waits for end-of-day statements and manually consolidates them in a spreadsheet. Decisions about when to convert currency, when to move funds between accounts, when to draw on a facility — all of these improve when the information base improves.

ISO 20022 and Payment Data Richness

The ISO 20022 migration — the move to a richer, structured payment messaging standard across SWIFT and domestic payment rails — is one of the less-discussed but genuinely important infrastructure changes of the current period. ISO 20022 messages carry substantially more structured data than the legacy MT standards they replace: full originator and beneficiary information, purpose codes, structured remittance information, LEI data for corporate payments.

For treasury reconciliation, this matters enormously. Automated reconciliation — matching incoming payments to invoices or expected receipts, without manual intervention — requires structured, machine-readable data in the payment message. With legacy MT formats, structured data was often absent or inconsistently formatted. ISO 20022 messages provide the data richness that makes straight-through reconciliation genuinely achievable. For high-volume payment operations — iGaming player withdrawals, affiliate payments, FX settlement flows — the reconciliation efficiency gains from ISO 20022 adoption are material.

FX Automation

FX management for complex businesses is an area where technology has improved significantly but implementation quality varies widely. The capability for API-triggered FX execution — executing currency conversions programmatically, based on real-time rate data, within defined parameters — exists and is production-ready in modern payment firm infrastructure. An iGaming operator that wants to automatically convert EUR player deposits to GBP whenever the EUR/GBP balance exceeds a threshold, at a rate within a defined tolerance of the mid-market rate, can configure and execute this without manual intervention.

The gap is between the technical capability that exists and the operational implementation that most businesses have actually deployed. Treasury automation is a change management challenge as much as a technology one. Finance teams that have managed treasury manually for years need to develop confidence in automated rules, understand how to set and adjust the parameters that govern automatic execution, and build the monitoring and exception-handling processes that keep automated systems aligned with business intent.

Where the Gaps Remain

The areas where treasury technology for complex businesses still falls short are the areas that require cross-provider integration. A TMS that connects to CCYFX's API and provides real-time visibility of CCYFX-held balances is genuinely useful. A TMS that can consolidate balances across CCYFX, a second payment provider, a crypto custody provider, and a bank account — in real time, with consistent data formats — is much harder to build because it requires API connectivity to four different systems with four different data models.

The ISO 20022 migration helps at the payment message level, but the account information APIs that different providers expose are not yet standardised in the way that open banking aspires to achieve. Until that standardisation is deeper — covering EMIs as well as banks, covering crypto-adjacent infrastructure as well as traditional payments — the multi-provider treasury visibility that complex businesses need will require custom integration work that is expensive and fragile.

That fragility is the real constraint. It's addressable through continued investment in API standards and through the open finance framework that's developing in the UK. But for businesses that need comprehensive treasury automation today, the investment in integration and maintenance remains significant — and that cost should be factored into any technology decision.