Shaping value-added services on real-time payment rails

Real-time payment rails have largely won the argument. FedNow, the RTP network, the UK’s Faster Payments system, SEPA Instant, PromptPay, PIX, and UPI have proven that moving money in seconds, around the clock, is technically and commercially viable at national scale. That victory has quietly changed the competitive question.

an article by Anders Olofsson, Advisory Council Member Fintech Tuesdays

When the rail itself is fast, reliable, and increasingly a commodity, differentiation moves up the stack, into the overlay services built on top of it: request to pay, confirmation of payee, fraud and dispute protection, rich remittance data, and embedded financing. How those overlays get shaped now determines who captures value from real-time payments, not just who processes them.

The Rail Is the Foundation, Not the Product

An overlay service is anything that adds functionality to a bare account-to-account transfer without altering the core clearing and settlement mechanism. Confirmation of Payee checks that the name on an account matches the intended recipient before money moves. Request to Pay lets a biller or merchant send a payable request rather than waiting on a push payment. Mastercard‘s A2A Protect, launched first in the UK, layers fraud prevention and a formal dispute-resolution framework onto account-to-account payments regardless of how the payment was initiated. None of these change how the payment settles; all of them change how safe, informative, or convenient it feels to send and receive one.

That distinction matters for anyone designing an overlay. The rail operator’s job is uptime, throughput, and interoperability. The overlay’s job is trust and utility. Conflating the two tends to produce services that are technically elegant but commercially inert, because banks and merchants don’t buy speed anymore; speed is assumed. They buy reduced fraud losses, better reconciliation, and a cleaner customer experience.

Data Is the Real Substrate

Most overlay services are, underneath the marketing, applications built on richer payment data. ISO 20022 messaging is what makes this possible: it carries structured remittance information, purpose codes, and extended payer and payee details that older formats simply couldn’t hold. A request-to-pay message, a dynamic invoice, or a financing offer triggered at the point of payment all depend on that structured data arriving intact and consistently formatted across participating institutions. This is why so much of the overlay roadmap in markets like the UK (CHAPS ISO 20022 migration), the US (FedNow’s native ISO 20022 messaging), and the EU runs through data standardization work that looks unglamorous but is, in practice, the actual product.

The implication for anyone shaping overlay strategy: sequence data standardization before feature design. An overlay pitched as a fraud-scoring tool or a dynamic billing engine that outruns the underlying data quality will underperform, because the intelligence layer is only as good as the fields it can reliably read.

Regulation Sets the Floor, Competition Sets the Ceiling

Overlay adoption rarely happens purely through market incentive. Confirmation of Payee became near-universal in the UK largely because authorized push payment fraud losses forced regulatory intervention, not because banks independently converged on it. The EU’s instant payments regulation similarly mandates verification-of-payee functionality alongside SEPA Instant, turning what could have been an optional value-add into table stakes across the bloc. Shaping an overlay service, then, means reading two different forces simultaneously: what regulators will eventually require anyway, and where there is genuine room to compete once the mandatory floor is met.

The mandatory layer tends to be defensive: fraud prevention, payee verification, dispute resolution. The competitive layer is where genuine product differentiation happens: embedded financing at the point of an instant payment, dynamic invoicing overlays for B2B suppliers, loyalty or rewards logic riding on top of an A2A rail, or, increasingly, payment authorization designed for AI agents transacting on a person’s behalf. Firms that treat the defensive layer as their whole strategy end up commoditized alongside the rail; the ones capturing value are building the second layer on top of a defensive foundation they didn’t have to invent themselves.

Design Principles Worth Holding Onto

A few patterns recur across the overlays that have actually scaled. They are modular and opt-in at the institution level, so a bank or fintech can adopt fraud protection without also taking on a bundled product it doesn’t want. They allocate liability explicitly and in advance, because ambiguity about who eats a fraud loss kills adoption faster than any technical limitation. They are rail-agnostic where possible, since Mastercard’s own positioning of A2A Protect as usable „regardless of the payment initiation mechanism” reflects a broader lesson: overlays that only work on one rail have a shrinking addressable market as instant payments interoperate across borders. And they are built API-first, because the actual buyers of most overlay services are other financial institutions and fintechs integrating programmatically, not end consumers clicking through a UI.

The rails are largely built. The next decade of real-time payments will be decided in the overlay layer.