The Interoperability Barrier
Why the Current Real-Time Payments Model Breaks at Global Scale
If you are looking at payments from 30,000 feet, the real-time payments landscape can be a little deceiving. We have instant payment systems. We have modern messaging standards. We have giant institutions with serious engineering muscle. We seem to have innovation across traditional and tokenized currencies. And yet, what most people fail to understand is that for all of its innovation, real-time payments systems are not interoperable, a payment that starts on one real-time network cannot simply glide over to the other one the way an email travels across providers. The fragmentation in real-time payments runs deep and wide.
Real-time payments systems are like beautifully built high-speed train systems that use similar maps, similar station signs, and similarly shiny trains. But the tracks, ticketing rules, and settlement engines under the floor are not the same. You can absolutely imagine a bridge between them. It’s just less of a simple wooden bridge and more like the Golden Gate on steroids. That in a nutshell is the interoperability problem in real-time payments.
The ACH Interoperability Illusion
To understand why interoperability of instant payments is such a headache, we have to look at ACH, the OG of payment rails. A network actually made up of two separate networks: FedACH, operated by The Federal Reserve and EPN, operated by The Clearing House. In industry shorthand, ACH is often treated as the great interoperability success story. For decades, it has pulled off a remarkably convincing optical illusion.
How?
Everyone can fall back to the Fed: Every bank is connected to FedACH. So if one bank uses EPN and the other does not, the payment can still go through because the Fed handles it. In that situation, The Clearing House is treated as a third-party processor, basically helping pass the file along, not acting as the main network.
EPN banks settle up in batches: If both banks are on EPN, EPN can handle the payment between them. Instead of settling each payment one by one, it adds everything up and sends the Fed the final totals a few times a day.
ACH has time to catch mistakes: As you may know, ACH is not instant. A payment may be processed first, but the actual settlement happens later. That delay gives banks time to spot errors, fix issues, or deal with exceptions before the money is fully settled.
And this is the key distinction: ACH pulls off the interoperability illusion by being forgiving because it can be patient, it was built in a world of batch windows, net settlement, and correction time. A feature that real-time systems lack.
Instant Payments: The Speed Trap
When we move to real-time networks, that safety net disappears. In the world of real-time, settlement isn’t a “later” problem; it’s a “right now” requirement. And this is where we hit the wall.
When a real-time payment is initiated, the sending side, receiving side, operator, and settlement engine all have to agree in near real time that the payment is valid, funded, final, and complete. There is no roomy gap for manual fixes or end-of-day balancing. That means interoperability has to work across three layers at once: settlement, message formatting, and payment orchestration. If even one of those layers misaligns, the bridge gets wobbly.
Barrier 1: Settlement is the big, ugly one
If you only remember one thing from this post, remember this: real-time networks, whether it is FedNow, RTP, SEPA, Pix, Lightning, etc. They do not settle the same way.
Take two of the most simple examples:
In FedNow, each payment settles by debiting and crediting banks’ Federal Reserve master accounts immediately.
In RTP, settlement happens by updating positions on The Clearing House’s pre-funded ledger structure. No funds are transferred at the Fed. There is no transaction in the New York Fed RTP joint account.
That means the systems are not just different brands of the same machine. They are fundamentally different machines. This is a massive barrier.
Imagine trying to merge two amusement parks where one ride system uses tokens and the other directly debits your card every time you board. Sure, you can make the guest experience look smooth, but under the hood someone has to reconcile two different value systems in real time.
Barrier 2: The messages are cousins, not twins
At this point you might say: fine, settlement is messy. But at least the industry has migrated to a global messaging standard, ISO 20022, right?
Yes. And also, not so fast.
Back to our example above, FedNow and RTP both use ISO 20022 elements, but not in exactly the same way. So if a payment is going to jump from one network to the other, someone has to translate the message.
And translation is where small headaches become large operational migraines: fields may map imperfectly, data can be truncated, edge cases can be misread, and exceptions handling gets more complex. Think of it like trying to translate a joke from English to French; sometimes, the “punchline” (the money) just doesn’t land.
The clean solution would be for all systems to use the exact same formatting conventions. The less disruptive solution would be to agree on mapping and translation standards. Both are doable. Neither is light work.
Barrier 3: The process flow is almost the same, except for the last 5%
Interoperability problems in real time payments are often annoying precisely because the systems are so close.
In the case of FedNow and RTP, they have slightly different orchestration logic. Settlement is tied to different steps in the end-to-end message flow.
FedNow settlement is tied to leg 3. Settlement happens as soon as the receiving FI sends its accept / accept-without-posting response. Settlement is embedded earlier in the flow.
RTP settlement is tied to leg 4. There is effectively one more hop before settlement finality is completed, after the receiving side’s response has been processed through the network and the network completes settlement in that next leg.
Each network also uses different timeout logic when waiting for the receiving bank’s confirmation. In a FedNow transaction, the “timeout” clock is about 20 seconds from the moment the sender hits the button. In RTP, it’s a 15-second window from the moment the message leaves the TCH hub. If you try to bridge these two systems, those five seconds become a digital eternity.
That sounds esoteric. It is. It is also really important.
In plain English: imagine two relay teams that both run the 4x100. One team passes the baton in zone A, the other in zone B, and they start the stopwatch from different markers. To a fan in the stands, it looks basically identical. To the coaches and the judges, it is a different rule set. You could argue they’re not really running the same race.
What this means for the fintech and banking ecosystem
It is due to these complexities that in our example US banks have mostly chosen the easier path so far: join both FedNow and RTP networks and maintain liquidity positions in both, instead of making the networks behave as one. This isn’t elegant, but it works.
The problem however becomes impossible to ignore when you attempt to take real-time payments across borders, across currencies, across asset types (hello, stablecoins) and reach true scale. That’s the key word: true. As in the $5 trillion moved everyday through SWIFT. As settlements, messaging standards and process flows differ, the liquidity problem begins to rear its ugly head. You now need to maintain liquidity positions across the same number of geographies, currencies and assets that you are trying to seamlessly connect.
More networks means more liquidity needs, more idle capital and capital requirements that become tougher to forecast. All of this leads to one very expensive, very unsustainable exercise I like to call: The Liquidity Sprawl, where money basically ends up spread all over the place.
For operators, founders and investors alike, the temptation up to this point has been to view interoperability as a box to be checked eventually. But the more accurate view is that interoperability is itself a major infrastructure opportunity.
If real-time rails remain fragmented, multi-connectivity, orchestration layers, processors, fraud tooling, treasury software, and network-aware routing platforms all gain importance. The fragmentation creates pain that will eventually become deafening — and deafening pain is often where venture returns like to hide.