The Next Real-Time Payments Frontier

How adoption now depends on operational capability, not connectivity

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.