Money is getting faster. Banks and central banks alike are testing new models for how money might move across borders in real time.

One of the most visible of these efforts is Project Agora, a central bank-led initiative exploring how digital forms of money and shared ledger infrastructure could support wholesale cross-border payments, and it offers a useful glimpse of what next-generation settlement could look like. 

But while the instruments being discussed may be new, much of the underlying infrastructure on which they will be built is not. Many banks still rely on core systems built for batch files and end-of-day reconciliation. The pressure building between always-on money and legacy architecture is starting to constrain progress.

To better understand these bottlenecks and where they sit in the system, Trade Treasury Payments (TTP) spoke with Steve Cook (SC), co-founder and strategic advisor at Form3, whose cloud-native payments infrastructure supports Tier 1 institutions, including JPMorgan Chase and Santander. From that vantage point inside banks’ processing engines, Cook argues that tokenisation alone will not fix cross-border payments. 

Modern money on legacy rails

TTP: Project Agora has been touted as a milestone for tokenisation in cross-border payments. From your perspective, what does it show about where the industry is heading, and what does it not yet solve?

SC: Project Agora shows that tokenisation is fully moving into real-world applications, including cross-border payments. The direction is clear, but the true risk lies in the underlying infrastructure. The role of central banks in tokenisation initiatives is important for driving progress whilst delivering standardisation across new forms of money. 

But this doesn’t address the legacy banking infrastructure on which these assets will rely. In fact, tokenisation only exposes its weaknesses. Issues of reconciliation, liquidity and operational friction arise when tokenised money interacts with systems built for batch processing and limited settlement hours.

It’s impossible to leverage the benefits of tokenisation for cross-border payments while relying on legacy architecture that simply can’t handle them. Layering new digital instruments onto outdated systems can create the appearance of progress, but it will only increase cost and operational strain. Without fixing the foundations, the industry risks delivering innovation that looks impressive on paper but stalls in practice.

TTP: You have argued that the real constraint on tokenised payments is not the token itself, but the underlying payments infrastructure. Where, specifically, do today’s bank architectures fall short?

SC: Digital dollars can move instantly, as shown by fintechs. But this is far from the reality for banks’ back offices, whose legacy architecture was built for limited operating hours, not always-on payments. Many banks, particularly in the US, still rely on batch-based processing as well.  

Batch processing handles multiple transactions at specific intervals, rather than when each transaction occurs. This contradicts the very premise of tokenised or stablecoin-based payment models – instant settlement. By forcing real-time money into a slow operating system, batch processing creates friction and makes it impossible for banks to meet customer demand when it comes to the instant movement of money, tokenised or not. 

This reliance on batch processing means that current back-office platforms cannot monitor and process transactions in real time. On the other hand, nonbank providers are moving much faster because they’re building on modern, cloud-native infrastructure that lets them launch new services quickly and scale without legacy constraints.

Cloud platforms support the real-time processing and high availability that tokenised assets need, however they do raise questions around resilience. If a cloud goes down, this can have a major impact on operations that banks simply can’t afford. Multi-cloud architecture provides both the resilience and the continuity needed. Without this, tokenisation may move faster, but it will still be constrained by systems that fail.  

Legacy architecture holds back tokenisation

TTP: There is a tendency in the industry to layer new digital instruments on top of existing systems. Why does this approach risk making cross-border payments more complex rather than less?

SC: Layering new digital instruments on top of existing systems may seem like the easier and cheaper way to address innovations, however, this approach increases operational strain and cost in the long run. 

Each additional layer can introduce new points of reconciliation, monitoring, and failure. Rather than simplifying cross-border payments, this adds complexity to systems already struggling to manage liquidity, risk and settlement across multiple rails. Faster money moving through slow, fragmented systems only amplifies friction, making payments harder to manage, not easier. 

Cloud-native platforms, on the other hand, are designed for real-time money environments from the start, supporting constant oversight rather than periodic checks, which is essential for scalable, real-time payments.

Moving to continuous processing fundamentally changes how payments are managed. Instead of transactions being queued, settled, and reconciled at fixed intervals, payments are processed, monitored, and reconciled as they occur. 

In practical terms, it means that liquidity positions and risk exposure are visible in real-time rather than after a batch of money has been moved. This constant oversight also strengthens fraud prevention and consumer protection, which are no longer “nice to haves”. 

TTP: If banks do not modernise their core payments architecture, what do you expect the next phase of tokenisation projects to look like in practice? (i.e., Incremental gains, stalled pilots, or something else?)

SC: Without a modernised payments infrastructure, the next phase of tokenisation projects will fail to bring cross-border payments into the digital era. Pilot projects can continue, but they will struggle to scale or deliver sustained improvements as they run into the same bottlenecks. 

There is great demand for tokenised payments in the US, especially as consumers want more cross-border and gig-economy-led payments. Particularly in North America, we are seeing financial institutions and fintechs fighting for client value in the services they can offer customers.

We already know that banks are concerned about being overtaken by more innovative and agile fintechs. Failing to modernise will only widen this gap as customers turn to alternatives to access faster, always-on, cross-border payments. 

Building for scale

TTP: Looking ahead 5 years, what changes need to happen within banks for tokenised cross-border payments to move into everyday use at scale?

SC: For tokenised cross-border payments to move into everyday use at scale, banks need to treat payments infrastructure modernisation as a strategic priority. This means moving away from batch-based systems towards cloud-native platforms capable of continuous processing, monitoring and reconciliation. Always-on payments require an architecture where real-time oversight is built in rather than added later. 

Alongside this, greater standardisation and interoperability will be critical for a global implementation of tokenised cross-border payments. Initiatives like Project Agora are important in setting common frameworks that allow different forms of tokenised money, both public and private, to interact across borders without creating fragmentation. 

Regulation will also evolve as new models are tested in the real world. As tokenised payments scale, new regulatory requirements around fraud prevention, resilience and consumer protection will inevitably emerge. Banks will need to develop infrastructure that can adapt to these changes, embedding continuous controls and real-time updates, rather than relying on static, manual processes. Tokenisation is not a shortcut for cross-border payments. 

Without modernising the foundations, faster money will continue to run into the same old constraints.