As Payment Rails multiply, Architecture starts to Converge

Payment innovation is proliferating at the edge.

Customers can now pay with cards, wallets, QR codes and account transfers. Businesses can receive money through cards, instant payments, ACH and other domestic systems, while cross-border payments can move through correspondent and specialist networks. New forms of digital money, such as stablecoins and tokenized deposits, and new ways of initiating payments, including AI agents, are adding further possibilities.

These payment methods exist for different purposes. Instant payments emphasize speed, ACH remains important for high-volume transactions, RTGS handles high-value transfers, and cards continue to offer broad acceptance and established customer protections. None is necessarily replacing the others.

A customer may use a card for a high-value purchase to earn reward points, receive a salary through an NEFT account-based transfer and send an instant payment later in the day to share a restaurant bill with a friend. To the customer, these are simply payments. Inside the bank, however, they can follow very different processing journeys—with different messages, rules, systems and operational processes.

And while payment choices are multiplying at the edge, the architecture underneath is moving in the opposite direction. Banks and PSPs are increasingly looking for common infrastructure that can connect different payment environments, understand their messages, apply the right rules, route transactions and provide a consistent view of payment activity.

This is more than the emergence of multi-rail payments. The challenge is how to manage all these different payment methods through a common infrastructure.

Every new rail adds another layer of complexity

Each payment environment comes with its own message formats, rules, operating processes, settlement arrangements and exception-handling requirements. Adding another rail can therefore mean more than adding another connection. It can create another set of integrations, another message format, another testing and certification process, another place to apply fraud and compliance rules and another operational workflow.

ISO 20022 has made payment information richer and more structured, but it has not made messaging identical across all payment systems. Different schemes can use different versions, message profiles and business rules, while older formats such as Swift MT continue to coexist with ISO 20022. Banks therefore still have to handle differences between payment networks even when they use the same underlying ISO 20022 standard.

As the number of payment environments grows, banks need a way to manage these different messages without creating a separate process for each rail. This is where a common financial-messaging layer becomes useful—one that can translate, validate and enrich messages before routing them to the appropriate payment system. The problem is not a lack of standards. It is having to operate many variations of them at the same time.

What this looks like inside a bank

Imagine a bank with separate systems for card payments, instant payments and traditional transfers.

A customer makes a card purchase. A few hours later, the same customer sends an instant payment to a new beneficiary. The two transactions may look unrelated to systems that process them separately. Yet together they may tell the bank something important about the customer's behaviour.

The same problem occurs in operations. An exception on one rail may be investigated in one system and an exception on another rail somewhere else. Reconciliation may require data to be assembled from several sources. A change to a payment scheme can trigger a separate technology project.

The more payment methods a bank adds, the more difficult it becomes to maintain a consistent view of the customer, the transaction and the associated risk.

This is why the architectural question is changing from “How do we connect to another rail?” to “How do we add another rail without creating another silo?”

The convergence underneath

The answer increasingly lies in moving common functions above individual payment rails. Instead of every rail handling its own messaging, routing, validation and operational logic, those capabilities can increasingly be shared.

A common layer can:

• Understand different payment formats
• Validate messages and required information
• Translate between formats where necessary
• Enrich payment data
• Decide which route or rail should be used
• Track the payment through its lifecycle
• Handle exceptions and retries
• Feed consistent information to risk, reconciliation and analytics

The underlying rail does not disappear, and convergence does not mean making all payment rails work in exactly the same way. It means moving the common functions above them while retaining the rules and capabilities that are specific to each rail.

The result is a common operating layer without forcing every payment rail into the same mould. The bank simply stops allowing every rail to dictate the architecture surrounding it. This is the more interesting meaning of payment orchestration. It is not just about connecting many rails. It is about creating one operating layer above them.

PAYMENT INNOVATION AT THE EDGE

Different routes to the same architecture

This is already visible in the products being developed by major payment-technology providers. The products are not identical, and their boundaries overlap. But that is precisely what makes the market interesting - different providers are arriving at a similar architectural idea from different starting points. Here is what each provider emphasizes.

The distinctions are subtle because these products solve overlapping problems. They overlap because the underlying industry need is the same: banks cannot keep building separate infrastructure every time another payment rail appears. What differs is where each provider places the emphasis—connectivity, A2A processing, payment consolidation, lifecycle management or orchestration. Together, they illustrate the broader shift toward common infrastructure underneath an increasingly diverse payment landscape.

Digital money is entering the same architecture

Stablecoins and tokenized deposits bring new forms of digital money into the payments landscape. The question is whether banks will need completely new systems to support them—or whether they can fit into the infrastructure they already use.

Recent work by IBM and Swift points to the latter approach. IBM Digital Asset Haven (a platform that helps banks and governments manage digital assets such as tokenized deposits and stablecoins) can connect to Swift's blockchain-based shared ledger. Banks can use familiar ISO 20022 messages to instruct these transactions while continuing to use their existing systems for settlement. This can allow the funds to move 24/7, including outside normal banking hours, without replacing existing payment systems.

In other words, the form of money is changing, but the infrastructure around it does not have to change completely. That is another example of innovation appearing at the edge while common capabilities remain at the core. 

The next question: who initiates the payment?

The next pressure on the architecture may come from who—or what—initiates the payment.

Today, a person or business usually starts a payment and the bank processes it. With agentic commerce, software may increasingly initiate transactions on someone's behalf. That introduces questions that do not disappear simply because the underlying payment uses an existing rail: Who authorized the agent? What can it spend? Which account can it access? What happens when it chooses the wrong payment method?

This makes a common infrastructure layer even more useful. The institution needs to apply identity, permissions, fraud controls and transaction rules consistently regardless of whether the eventual payment travels over a card network, an instant-payment rail or another form of digital settlement.

In other words, the more intelligence moves to the edge, the more intelligence the infrastructure underneath needs to coordinate.

Messaging becomes the common language

This brings us back to financial messaging. The significance of messaging is easy to underestimate because it is mostly invisible to the customer. But as payment environments multiply, messaging becomes the common language through which those environments communicate.

A modern messaging layer does not merely convert one format into another. It can make payment information understandable and usable across systems. That has consequences beyond successful transmission. Consistent, structured payment data can support reconciliation, fraud analysis, compliance, operational monitoring and eventually AI-based decision-making.

The value therefore moves from “Did the message get through?” to “Can that payment data support better routing, risk management, reconciliation and automation?” That is a fundamental change in the role of financial messaging. 

The architecture is becoming the strategic layer

The payments landscape will continue to diversify, with new rails, forms of digital money and ways of initiating payments. The challenge for banks and PSPs is to absorb this growth without creating new silos. The emerging answer is common infrastructure underneath the different payment environments—shared messaging and data, common controls, intelligent routing and a consistent operational view.

This also changes the role of that infrastructure. Messaging becomes a common language, orchestration becomes the coordination layer, and payment data becomes an input for risk, reconciliation, automation and AI. The goal is not to reduce the number of rails, but to make their growing complexity manageable through a more unified architecture.