The last decade of real-time payments innovation was centered around access to rails. Instant payments popped up in seemingly every corner of the world, naturally stablecoins came along as a way to instantly bridge global currencies. But shy of RTP’s 10-year anniversary in the US, real-time payments connectivity has become a commodity. Once a key problem, it has now been solved 100x over. What remains is the lack of operational capability, which I’d argue is a much more interesting problem.

What we have collectively found out is that once banks can connect to RTP or FedNow or potentially stablecoins, a more nuanced question appears:

How does this new real-time capability actually fit into the way the bank operates today?

That question is where things get really interesting. Because the answer is: it doesn’t. Not cleanly at least.

Banks have moved from having access to real-time payment rails to not having clarity on how to operationalize them.

Connectivity was necessary, but no longer sufficient

Over the last decade, the industry made meaningful progress on coverage. RTP now reaches a majority of US deposit accounts, and FedNow participation continues to grow. More FIs can receive instant payments, and the provider ecosystem has matured around both networks.

That matters because reach is foundational. Without it, there is no broad network utility.

But the open secret is that the majority of participants remain with basic receive-only functionality, and even when a bank is technically certified to send, that does not necessarily mean customers can initiate real-time payments through the products and channels they actually use. As one industry observer puts it, “Technically, some banks can send, but many have no applications that are actually sending.”

On the other hand, access is not wide across customer types. Many banks may support instant payments for certain corporate clients but not for small business. They may have API-based initiation available for select customers but not expose the capability through online banking, mobile banking, treasury portals, bill pay or support-assisted workflows.

In other words, for the majority of banks, instant payments are yet to become a scalable product inside the bank.

That gap is easy to miss from the outside. But in my opinion, it is the missing layer to unlock the value of instant payments.

The hidden complexity lives around the API

Payment hubs and modern banking platforms have done a lot to simplify the technical side of payments. They provide rail connectivity, message handling, APIs, routing, payment status, and sometimes reconciliation or error-handling capabilities.

But an API does not, by itself, redesign a bank process.

Take AML and OFAC. Many banks already have automated screening processes. But those processes were often designed around payment workflows with more time.

Or small business enablement. Adding RTP as an option in a payment dropdown may not be the hardest part. The harder question is what enabling a small business user for RTP should actually look like.

That is a product decision. It is also a risk decision, an operations decision, a support decision, and often a legal/compliance decision.

If the API is the door, the operating model determines whether anyone can walk through it safely.

One reason this is hard is that instant payments have met fragmented bank operations.

What changes with instant payments

• Core systems

  Accounts need to be validated, debits/credits posted, balances updated, and transaction IDs made available quickly and reliably.

• Product channels

  Mobile, online banking, treasury, API, bill pay, disbursements, branch, and small business platforms may each need separate enablement.

• Risk controls

  Fraud, scam prevention, mule monitoring, limits, and velocity rules need to work before money moves.

• Compliance

  AML/OFAC workflows need to fit real-time timing expectations.

• Treasury

  Liquidity, prefunding, settlement, thresholds, and escalation become more operationally important.

• Reconciliation

  Rail status, payment hub status, core posting, GL, settlement, and customer notifications need to line up.

• Support

  Agents need visibility into payment status and approved language for finality, rejects, timeouts, returns, and scams.

• Audit

  Evidence needs to be captured across systems, teams, decisions, approvals, and exceptions.

This is why instant payments can feel simple in the product demo but complex inside a bank.

For every payment, the bank needs to deal with a chain of dependencies.

Where the white space and next frontier lives

The white space is no longer in connectivity, it’s in the operating layer.

Today, there is an entire operational layer missing that should sit above and around cores, payment hubs, fraud tools, OFAC systems, treasury, reconciliation, support, and audit.

Not to move the money, but to make the instant movement of money operable.

This layer is key in helping banks understand:

• which payment capabilities are technically available,

• which products and channels can actually use them,

• which legacy workflows are impacted,

• which APIs and data objects are available,

• which gaps are technical versus operational,

• which processes need redesign,

• which controls must be in place before scaling,

• which teams own each exception,

• and what evidence is needed to prove the process worked.

Translating payment capability into operating readiness.

The role of human and artificial intelligence

The most interesting version of this layer combines human operating knowledge with artificial intelligence.

Human intelligence matters because payments are full of context: regulatory expectations, bank policy, legacy workflows, risk appetite, customer segments, channel behavior, vendor constraints, and institutional history.

Artificial intelligence can help because the operating surface area is too wide for every team to manually connect the dots every time. AI becomes useful when it is grounded in the bank’s actual operating context.

An operating layer could understand:

• the bank’s existing ACH, wire, bill pay, treasury, and support workflows,

• the APIs available from the core and payment hub,

• the instant-payment status and reason codes,

• the bank’s fraud and compliance requirements,

• the reconciliation data needed,

• the customer language that is approved,

• and the evidence audit will expect.

Then it could help answer practical questions:

“If we enable RTP send for small business users, what has to change?”

The answer may include:

• define a new eligibility model,

• set default limits by segment,

• confirm account validation data from the core,

• map payment hub IDs to core transaction IDs,

• expose status to support,

• update fraud rules,

• approve customer-facing finality language,

• define exception ownership,

• and create an evidence packet for audit.

That is the kind of operating intelligence that helps payment capabilities become real products.

Why this matters beyond instant payments

Instant payments are the sharp edge of the problem because real-time exposes the limitations of legacy workflows quickly.

But the broader pattern applies beyond RTP and FedNow as banks are forced to modernize money movement.

Each new capability creates the same question:

How does this fit into the bank’s existing product, risk, compliance, operations, reconciliation, support, and audit environment?

Before instant payments can reach their full potential, banks need a clearer way to understand how real-time capabilities fit into the messy, practical reality of how banking works. The opportunity now shifts toward operating readiness.

The next big build in payments is not another money movement product. It is the intelligence layer that brings it all together.

For those of us who have studied, built around, and obsessed over RTP and FedNow from the beginning, the article hit a nerve. And I couldn’t help but wonder: are the people now laser-focused on stablecoins as the future of payments seeing the resemblance?

RTP and FedNow are faster, richer, always-on payment rails. And yet, volumes are still tiny compared with ACH, the less glamorous but extremely entrenched payments rail.

That should sound familiar. Strip out the noise and the stablecoins curve flattens considerably.1

Stablecoins may be faster, programmable, global, and always on. But as FedNow and RTP have taught us, technical superiority doesn’t guarantee adoption. The best rail doesn’t win because it is elegant, it wins when and if it disappears into the products, workflows, and back-office systems people already use.

And payments have a lot of all of the above.

To disappear, payment infrastructures need to be able to seamlessly speak to all the systems that do all the boring but essential things like: message validation, payment status, fraud controls, reconciliation, liquidity management, exception handling, customer support, disclosures, governance, and rules for what happens when things go sideways.

Moving money is half the job, the other half is moving information. So I wanted to breakdown some of the key learnings that stablecoins could borrow from the RTP/FedNow experiments.

Ubiquity Beats Elegance

As Steve and Lee point in their article, RTP and FedNow had a distribution problem. ACH, cards, Zelle, wallets, push-to-card services, and bank products already had reach when they came around. And they were embedded in the places consumers and businesses already lived.

Stablecoins have the same problem, with extra plumbing.

I often hear that stablecoins already have global reach because public blockchains are open. Technically, yes. Practically, not quite.

For stablecoins to have meaningful reach, the industry needs things like custody, compliance, fraud controls, accounting tools, tax reporting, merchant settlement, bank connectivity, and liquidity management. Some which exist, but nowhere near the level that traditional payments offer.

A business doesn’t just need to “receive a payment.” It needs to know who paid, why they paid, whether the payment is compliant, how to reconcile it, if needed how to convert it, how to refund it, how to report it, and how to explain it to finance, legal, and auditors.

Ubiquity isn’t just the ability to send a token to any wallet address. Ubiquity is the ability to pay the right person, in the right format, with the right information, under the right rules, in a way both sides can actually use.

Real-Time Payments Create Real-Time Operations

Instant payments are not like regular payments but faster. They fundamentally change the operating model of financial institutions.

If payments move 24/7/365, the support model, fraud model, liquidity model, reconciliation model, and escalation model also need to work 24/7/365.

A stablecoin transfer may settle in seconds on-chain, but someone still has to answer the boring-but-essential questions:

Who reconciles it? Who monitors fraud? Who handles a failed payment? Who helps the customer on Sunday night? Who explains why the blockchain worked but the compliance process did not?

Without this operational muscle, we end up with a weird paradox: the payment settles instantly, but the business cannot make sense of it until later. Most people would be amazed by the amount of manual steps that occur inside banks even to this day.

Liquidity Is the Hidden Product

Payments look simple from the outside: tap, send, receive, done.

Behind the scenes, liquidity is doing all the work.

Instant payment systems require funding, forecasting, intraday liquidity management, weekend planning, reconciliation, and contingency arrangements. Stablecoins have all of that, plus issuer and reserve risk.

Stablecoins face liquidity questions at every layer:

Does the user have the right asset on the right chain? Can the platform support conversion and refunds? Can the market exchange the stablecoin at par? Can the issuer meet redemptions under stress? Can the reserves be turned into cash quickly without losses?

That last part matters.

Stablecoins are not just payment instruments. They are privately issued monetary claims. Their value depends on reserves, redemption processes, liquidity, issuer risk management, and market confidence. If users suddenly want out, even high-quality reserves may need to be sold quickly. That starts to look less like the future of money and more like bank run.

Stablecoins promise instant digital money. But the stress test still lives in the old world: cash, treasuries, banking relationships, redemption windows, market depth, and confidence.

The rail may be on-chain. The panic is still very TradFi.

Finality Is Great Until It Is Not

There’s this saying around the industry: “Faster payments, faster fraud”. Instant payments and stablecoins share a unique feature: once money moves, it may be very hard to get back.

That is wonderful for settlement certainty. It is less wonderful when someone sends funds to the wrong wallet, falls for a scam, pays a sanctioned party, or realizes five seconds too late that “0x7f…” was not, in fact, their vendor.

Traditional payments have reversals, disputes, chargebacks, returns, investigations, behavioral monitoring, customer protection frameworks and escalation paths. They are imperfect, but they exist for a reason.

Finality doesn’t only exacerbate mistakes, fraud, or compliance issues, it also makes them more urgent.

Governance Turns Rails Into Infrastructure

Payment systems run on something not very elegant but very durable: rules, agreements, disclosures, warranties, indemnities, liability allocation, regulatory obligations, and error-resolution procedures.

A business deciding whether to use stablecoins does not only ask, “Can this settle faster?”

It asks:

Who is responsible if something goes wrong? What protections apply? What happens if a payment is misdirected? What if a wallet provider, issuer, custodian, exchange, or bridge fails? What law governs the transaction? What records must be retained? What happens across borders?

Until those answers are clear, stablecoins will remain a powerful but uneven infrastructure.

Payments at scale require technology. They also require rules all stakeholders can trust.

The Takeaway

If this sounds like a laundry list of things that the industry needs to build, that’s because it is.

In some cases, incumbents are best positioned to build, in others, startups may be the ones that make a meaningful dent. The real question is which players can thrive where, and the answer depends on the complexity of the integrations. Some of these opportunities sit far too deep in the infrastructure for new entrants to realistically tackle.

But if RTP and FedNow have taught us anything, it’s that the market doesn’t need “instant settlement” packaged as a consumer-facing product. It needs instant-payment rails that quietly make other products better, and for the underlying systems to be more rail agnostic. Without this, adoption is slow, painfully slow.

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.