Beyond the Network: The Real-Time Payment Realities Banks Face in 2027

Sibos 2026 was a week about the network. For me, the most important number of the week was about the bank.

Over four days in Miami, from September 28 to October 1, the headlines focused on rails getting faster. Swift’s blockchain ledger is live, and most of its 17 first-mover banks have already used it for 24/7 payments across six continents. More than 100 institutions are live or going live on Swift’s consumer payments framework, with corridors like Turkey to Spain completing in 15 seconds. Bank of America announced its first cross-border real-time payment pilot with Bradesco, initiated over Swift and credited in Hong Kong dollars through Hong Kong’s Faster Payment System.

Then there was the number tucked inside Swift’s own announcement. Three quarters of Swift transactions reach the end bank within 10 minutes, but around 80% of a typical transaction’s journey time is spent in the last mile, after the payment leaves the Swift network and before the customer is credited.

Read that from a bank’s point of view. The network is no longer the slow part. The bank is. So where exactly is the time going?

What is the send gap?

The send gap is the distance between a bank being connected to an instant payment rail and being able to send on it safely, at volume, at any hour. It exists because the decisions a send requires (fraud, liquidity, compliance, and routing) are made in separate systems that can’t agree on current state within the time the rail allows.

You can see it in the US numbers. FedNow marked its third anniversary with more than 1,800 participating banks and credit unions. In Q2 2026, it settled an average of roughly 55,000 payments a day. Over the same quarter, the RTP network processed 142 million transactions worth $576 billion.

To be fair, the two rails have different histories and customer bases, and I don’t want to over-read the comparison. However,  the pattern underneath both is well understood. Institutions connect to receive first, and many stay there. The Federal Reserve’s FedNow leadership has publicly encouraged banks to look beyond a receive-only strategy.

Receiving is the easy half. Money arrives, you credit the account, and most of the risk sits with the sender. Sending is where the bank has to decide something.

Why do so many banks stay receive-only?

Because sending on an instant rail asks a bank to make four decisions at once, irrevocably, in seconds, and most banks’ systems were never built to make them together.

Walk one payment through a typical stack. A business customer initiates a $250,000 supplier payment at 2 am on a Sunday. Before that payment is committed, the bank needs to know:

• Is this payment fraudulent, or is this customer being scammed right now?
• Can we fund it from our current position without breaching a liquidity threshold?
• Does it clear sanctions and limit checks against the counterparty as things stand at this moment?
• Which rail should carry it, given cost, speed, and what the receiving institution can accept?

For example, the answers might tell us that fraud scoring was designed around card authorization or next-day review and the liquidity position was last refreshed on a schedule (possibly hours ago). At the same time, sanctions screening sits in its own queue, and routing is a static table someone updated last quarter. In summary, each system has a slightly different idea of what “now” means, and none of them were built to agree within the few seconds the rail allows.

That was fine in a batch world, where settlement windows gave you hours to catch and reconcile a mistake, but instant rails creates a very different environment. So when a risk team is asked to enable send, the honest answer is often that the bank can’t make those four calls together, against current state, in time. The natural response is to stay receive-only, or to set send limits so low the product is barely useful.

Which is why I’d argue receive-only is a decision problem being mistaken for a connectivity problem. Connecting to a rail is a project. Sending on it safely is an architecture.

What did Sibos 2026 change?

It made the send gap harder to ignore, on two fronts.

The first is cross-border going instant end to end. Swift announced it is working with banks and domestic instant payment schemes to make sending money internationally as easy as sending a text. When a cross-border payment lands on a domestic instant rail, the decision window that correspondent hops used to absorb shrinks to the same few seconds. Every bank in that chain inherits the last-mile problem.

The second is agentic payments. In his Sibos speech, Federal Reserve Governor Christopher Waller described an agent-delegated model, where an AI agent pays on the buyer’s behalf, and pointed to B2B purchasing as a natural fit because it already runs on rules like approved suppliers and budget limits. He was just as clear about the risk. Higher B2B values amplify the exposure from agent errors, and fraud models calibrated to human behavior will need recalibrating for agent payment patterns. He also expects LLMs to augment, not replace, the faster anomaly detection modern payment speeds require.

That last point deserved more airtime than it got. Agents can reason well about which supplier, which rail, and when to convert currency. But the moment of commitment still needs a fast, deterministic check against live state. It’s the principle I keep coming back to as 90/10: roughly 90% of what makes agentic AI work in production is the data and decision infrastructure underneath it, and the model is the last 10%.

How do banks close the send gap?

By putting a decision layer in the payment path, not by replacing the core.

The instinctive response to “we can’t send safely” is a multi-year core modernization program. Some banks genuinely need one. But for the send problem specifically, the core isn’t where the decision has to happen. It has to happen between the channel and the rail, in the milliseconds before a payment is committed.

A decision layer has a narrow but demanding job. It holds the live state the decision depends on, such as balances, velocity counters, liquidity positions, counterparty limits and active alerts. It evaluates fraud, liquidity, compliance, and routing logic against that state together, in one transaction. And it commits and records the outcome before the rail ever sees the payment. The core stays the system of record. The decision layer becomes the place where the bank actually decides.

Here are four straightforward questions that can be asked about any stack:

• Do your fraud, liquidity, and routing logic see the same state at the same instant, or are they reading different systems at different times?
• Does your liquidity position update with every payment, or on a schedule?
• Would a send decision made at 2 am on a Sunday be as current and consistent as one made at 10 am on a Tuesday?
• Is every decision recorded as it’s made, with the state it was made against, so you can explain it to a regulator or a customer later?

If the answer to any of those is no, the rail isn’t your constraint. Your decision path is.

The bank is the last mile.

Sibos moves to Singapore next September. By then, the rails will be faster again, more corridors will be instant end-to-end, and more agent-initiated payments will be testing the controls banks have in place today.

The institutions that get the most out of 2027 won’t be the most connected. Almost everyone will be connected. They’ll be the ones that can decide to send, confidently, at rail speed, at any hour.

We’ll be going deeper on this on October 20 with The State of Real-Time Payments and Risk 2026, a global survey written by FinTech Futures and sponsored by Volt Active Data and Persistent Systems. It goes well beyond fraud, measuring how wide this gap is across real-time payments, what it costs, how institutions evidence compliance, how fast they can actually execute, and what changes when agents enter the payment path.