The ‘Last Mile’ Problem: Why Real-Time Payments Aren’t Always Real-Time

Executive Summary

A new generation of “Real-Time Payment” (RTP) networks like FedNow (US), SEPA Instant (Europe), and UPI (India) has promised a revolutionary, 24/7/365, “instant” payment experience. However, for many customers, this promise feels broken. A payment may be sent “instantly” by one bank, but it can still take hours—or even until the next business day—to be credited to the recipient’s account. This gap is known as the “last mile” problem. The core issue is that while the central payment network is a high-speed highway, the “on-ramps” and “off-ramps” at many traditional banks are still legacy systems, batch processors, and manual compliance checks that bring the entire process to a grinding halt.

1. The Real-Time “Illusion”

The core concept of an RTP network is that it settles transactions in “real-time,” with immediate finality, 24/7. In theory, this means a payment sent at 3:00 AM on a Sunday should arrive in the recipient’s account within seconds.

The “last mile” problem emerges because the payment network is only one part of the journey. A payment must complete three legs:

1. The “First Mile”: The sending bank’s internal systems (core banking, fraud check) must process the payment and send it to the RTP network.
2. The “Middle Mile”: The RTP network (e.g., FedNow) instantly clears the payment and sends it to the receiving bank. This part works perfectly.
3. The “Last Mile”: The receiving bank’s internal systems must receive the payment from the network, run its own compliance checks, and post the funds to the end customer’s account.

This “last mile” is where the modern system collides with legacy infrastructure, and it’s where the delays happen.

2. The Bottlenecks: Why “Instant” Becomes “Hours”

Why can’t a receiving bank instantly post the funds it just received? The reasons are a mix of technology, risk management, and outdated business logic.

• Batch Processing Cores: This is the single biggest culprit. Many banks, especially older, larger institutions, still run on core banking systems (mainframes) designed in the 1970s. These systems were built for a 9-to-5 world and operate on “batch processing.” This means that instead of processing transactions one-by-one as they arrive, the system saves them all up and processes them in a large “batch” at set times (e.g., 10:00 PM, 1:00 AM, and 4:00 AM). A real-time payment arriving at 1:01 AM might sit in a queue for three hours until the 4:00 AM batch runs.
• Offline Compliance & AML Checks: Every bank is legally required to screen all incoming payments against sanctions lists (OFAC, EU, etc.) and for anti-money laundering (AML) red flags. While the “middle mile” network is 24/7, a bank’s compliance system may not be.
  • Many banks pipe incoming RTP payments into the same compliance engine that processes their “next-day” ACH or wire payments.
  • If a payment creates a “false positive” alert, it is moved to a manual review queue to be cleared by a human compliance officer… who may not start their shift until 9:00 AM the next business day.
• “Stand-In” Risk Processing: To offer a 24/7 service without upgrading their core, some banks use a “stand-in” model. They will accept the real-time payment notification but will not post the actual funds to the customer’s account. Instead, they will provisionally update the customer’s “memo balance” (the “available balance” you see in your app) but will not settle the funds in the core ledger until the next batch process. This creates a confusing customer experience where money seems to be there… but isn’t technically “final.”

3. Solving the Problem: A Full Core Upgrade

The “last mile” problem is not a flaw in the real-time networks themselves; it is a symptom of technical debt within the banks.

The only true solution is for banks to upgrade their internal infrastructure to be as modern as the networks they are connecting to. This means:

• Moving to a 24/7/365 Core: Adopting modern, event-driven, cloud-native core banking systems that can process and post transactions individually, in real-time, as they arrive.
• Real-Time Compliance: Integrating AI-powered RegTech solutions (as discussed in Report 11) that can perform sanction and fraud screening in milliseconds, not hours, allowing the vast majority of “clean” payments to be posted without manual intervention.
• API-First Architecture: Re-architecting systems so the core banking ledger, the compliance engine, and the RTP connection are all communicating instantly via APIs, rather than handing off batch files to each other.

Conclusion

Real-time payments are the future, but the industry is in a painful transition. The new, high-speed networks are exposing the “last mile” bottlenecks that banks were previously able to hide within “next-day” payment cycles. Neobanks and modern fintechs, which were built on real-time infrastructure from day one, do not have this problem, giving them a significant competitive advantage. For traditional banks, solving the “last mile” problem is now a race against time, requiring deep, expensive, and non-negotiable modernization of their core technology.