How to Build National Real-Time Payments and Not Screw It Up

The Short Version

1. A mandate can create reach. It cannot create usage.
2. Stakeholders will not align just because the project is nationally important.
3. The vision must choose one primary problem, even when politics demands several.
4. Strategy starts with customer groups and value propositions, not features.
5. Metrics must prove behavior change, not just launch progress.
6. Demand comes from packaged use cases, not from settlement rails.
7. Integration quality is adoption strategy.
8. Architecture must protect the system's core job and resist decorative complexity.

Define the Payment Domains First

Terminology in this space is messy. The same family of systems is called real-time payments, instant payments, faster payments, immediate payments, fast payments, or account-to-account payments depending on the market and institution.

In this playbook, RTP means electronic account-to-account payments that complete in seconds, operate 24/7/365, and provide immediate confirmation to payer and payee. It uses the same C2C/C2B/B2C/B2B notation as the public SBP dashboard. Most modern systems use ISO 20022 messaging, but ISO 20022 is not the product. The product is the set of payment experiences the rail enables.

This taxonomy matters because every domain has a different buyer, adoption path, commercial model, risk profile, and integration surface. A system that wins in C2C does not automatically win in C2B. A system that has instant settlement does not automatically have merchant acceptance. A QR standard does not automatically solve reconciliation.

Do Not Rely on Mandates Alone

Central banks sit naturally at the center of national RTP systems. They can settle between banks in central-bank money. They can create rules. They can require participation. They can convene stakeholders who would otherwise avoid the same room.

That power is necessary in many markets. It is not sufficient.

FedNow is a useful caution. The Federal Reserve launched FedNow in July 2023. By July 2025 it had more than 1,400 participants, and official Federal Reserve statistics show 8.4 million settled customer credit transfers in 2025 and 2.7 million in 2026Q1. That is real progress, but modest in the context of the US banking system. The Federal Reserve itself frames adoption as gradual across more than 9,000 financial institutions.

The lesson is not "FedNow failed." It did not. The lesson is that a rail can be live, growing, and still need market-facing use cases before it becomes a daily habit.

Canada shows the other side of the same issue. Its Real-Time Rail is still planned for Q4 2026. The project has support, public policy logic, and a clear infrastructure goal, but the live payment experience cannot emerge until the program survives build, testing, legal, operational, and ecosystem readiness work.

Even pure regulation has limits. Strong Customer Authentication in Europe and the UK was backed by law and fraud-reduction logic, yet regulators had to allow migration periods and deadline extensions because the ecosystem was not ready. Mandates set direction. Execution still happens in thousands of product, risk, technical, and operational details.

Map Stakeholders Before You Design the System

National RTP is not a normal software project. It is critical financial infrastructure with a product surface. Your product environment includes central-bank departments, ministries, banks, payment processors, card acquirers, bank software vendors, merchants, retailers, telecom operators, fintechs, security agencies, consumer advocates, and sometimes political actors who never touch the product directly.

The first job is not to pitch. It is to understand incentives.

• What frustrates you about the current payment landscape?
• Which outcomes would make this system worth the effort?
• Which outcomes would make it dangerous for you?
• What would you lose if this works?
• What capabilities do you control that the system depends on?
• Who else needs to be involved before decisions become real?

Listen for the gap between public slogans and actual incentives. "We support innovation" can mean "we want access to bank customers." "We support sovereignty" can mean "we want to weaken foreign card schemes." "We support cheaper payments" can mean "we want lower merchant discount rates but no disruption to our current reconciliation process."

Build a simple stakeholder table. Keep it practical: who holds power, who has fear, who has data, who owns the last mile, and who can derail the project after everyone has already said "yes."

Build the Vision Around One Primary Problem

The most dangerous RTP vision is a list of good things.

"We will reduce cash, increase competition, strengthen sovereignty, lower merchant fees, improve inclusion, accelerate government payments, support fintech innovation, modernize settlement, and prepare the country for digital money."

Every item on that list may be true. Together, they are not a vision. They are a political compromise disguised as strategy.

Start with the core question: why are we building this national RTP system at all?

• If the goal is a cashless society, start where cash hurts most.
• If the goal is merchant economics, start with C2B.
• If the goal is financial sovereignty, define the threat precisely.
• If the goal is inclusion, do not design only for banked urban smartphone users.
• If the goal is competition, access rules and pricing may matter as much as the payment message.

In the SBP work, the final stakeholder-aligned vision had three parts: increase cashless payments in retail, stimulate competition through open and equal access, and support financial sovereignty through a domestic payment method aligned with international best practices. That was not textbook-perfect focus. But it was a hard-won narrowing of a much larger idea set.

If you cannot say what the system is not trying to solve first, you do not yet have a vision.

Turn Vision Into a Strategy Blueprint

Vision defines why the system exists. Strategy defines what you will build first to make that vision real. Roman Pichler's note on separating product vision from product strategy is useful here: the vision should keep the team anchored while the strategy changes as evidence improves.

Do not jump from vision to a feature backlog. Move through customer groups, needs, value propositions, and adoption logic. Frameworks such as the Value Proposition Canvas and Jobs-to-be-Done can help, but do not let the framework become the work.

Merchant workshops often start with lower fees. That is real. But when finance, accounting, POS, and ERP teams enter the room, a different problem appears: reconciliation. A merchant may like a 0.5% payment cost, but if the method breaks accounting, tax references, refund flows, settlement reporting, or store operations, adoption stalls.

That is why last-mile owners matter. For C2B, the important actors are not only banks and central banks. They include POS vendors, fiscal-register providers, ERP/CRM vendors, payment gateways, PSPs, ecommerce platforms, and large merchant IT teams.

Define Success Metrics Before Launch

RTP programs love launch metrics: participant banks, certified vendors, APIs delivered, regulatory documents issued, uptime, and post-launch transaction volume. Those metrics are useful. They tell you whether the machine exists. They do not tell you whether the machine is solving the problem.

Use an OKR-style structure tied to the vision:

Build a successful national RTP system that solves [primary national payment problem] for [priority customer groups].

For each metric, define the denominator. "C2B share" is useless unless the reader knows whether it means share of all retail payments, share of card plus RTP value, share of cashless payments, or share of transactions in a specific merchant group. The public SBP dashboard is strict on this point: SBP C2B / (SBP C2B + card goods/services) is useful, but it is not total market share.

Generate Demand: Offer a Product, Not Just Rails

Banks and merchants do not buy "instant settlement." They buy a way to solve a problem.

Bring data to the sale: addressable transaction volume, current cost of cash and cards, expected operational savings, fraud and dispute implications, customer-experience improvement, integration effort, and roadmap support.

For banks, the first buying reason may be cheaper money acquisition, customer retention, or avoidance of being left behind by competitors. For merchants, it may be lower fees, faster settlement, refunds, loyalty control, or reduced cash-on-delivery. For government, it may be transparent collections and cheaper payouts. For consumers, it is almost always simplicity and trust.

Demand also depends on speed. In contested markets, the first credible use case shapes the narrative. If the central scheme moves slowly, an incumbent bank or private wallet can define the user experience, capture merchant relationships, and force the national system into a follower position.

Simplify Integration Ruthlessly

Integration is not a technical appendix. It is adoption strategy.

Every bank and vendor asks the same practical questions: how do we connect, how do we test, what does certification require, what happens when messages fail, how do we reconcile, how do refunds work, and who answers questions when documentation and implementation differ?

The best schemes reduce the distance between specification and reality: public API documentation, versioned interfaces, stable test environments, realistic sandbox data, certification scripts, clear release notes, vendor enablement sessions, and participant implementation guides by use case.

Write operational bulletins and technical specifications with the teams building the system. Documentation that exactly matches implementation is a competitive advantage. Documentation that describes what someone intended six months ago becomes an adoption tax.

Set Architecture Principles and Interfaces

Architecture deserves its own article, but several principles belong in the product playbook.

1. Separate payment initiation, processing, clearing, settlement, reporting, and overlays.
2. Protect the core job of the RTP system.
3. Use public, stable, versioned APIs.
4. Make transaction types clear.
5. Treat alias services, QR, refunds, disputes, and fraud as first-order product surfaces.

A beautiful rail with unclear transaction types, weak versioning, and poor reconciliation will look worse in production than a simpler rail with disciplined interfaces.

Common Pitfalls

The central bank mandated it, so adoption will follow.

Mandates get participants to the starting line. They do not create reasons to run.

QR is the product.

QR is an initiation form factor. The product includes merchant onboarding, POS/ERP integration, payment confirmation, reconciliation, refunds, dispute logic, fraud controls, and consumer trust. For the underlying taxonomy, see the World Bank note on QR codes in payments.

Apple Pay is all consumers need.

Wallets solve convenience for card-based payments in specific ecosystems. They do not solve merchant economics, national sovereignty, bank funding costs, inclusion, or open access by themselves.

Lower fees are enough for merchants.

Lower fees open the door. Operations decide whether merchants walk through it. Reconciliation, settlement timing, refunds, tax references, and support can outweigh nominal price.

Metrics start after launch.

If success is undefined before launch, every launch can be declared successful. Define adoption, economics, quality, and integration metrics early enough to shape the roadmap.

Sources

Inline links carry the evidence trail. This list keeps the public references easy to scan.

• Pay.UK Faster Payment System
• Banco Central do Brasil, Pix Management Report
• Bank of Russia SBP analytics and the Payment Bros SBP dashboard
• ACI Worldwide / GlobalData, Prime Time for Real-Time
• Juniper Research instant payments forecast
• Federal Reserve FedNow volume and value statistics
• Payments Canada Real-Time Rail
• EBA SCA readiness report and FCA SCA deadline extension