Overlay Services on Instant Rails: Explained

Ask most people what makes a modern payment app great and they will describe things the underlying rail does not actually do: paying someone by phone number, sending a request that shows up as a tappable notification, or seeing the recipient's name confirmed before you hit send. These experiences are not part of the core clearing-and-settlement rail. They live in a layer above it called overlay services. Understanding this separation is one of the most useful mental models in payments.

What an overlay service is

An overlay service is a value-added capability built on top of a base instant-payment rail, using the rail to move money but adding its own messaging, directories, or business rules. The base rail's job is narrow and reliable: clear and settle a credit transfer in seconds, around the clock. Overlays reuse that engine and wrap it in features that make payments richer, safer, or easier to initiate.

The classic example is India's UPI, which sits on top of the IMPS instant rail and adds addressing, request flows, and a QR ecosystem. Similarly, the UK's Faster Payments provides the rail, while Paym (aliases) and Confirmation of Payee (name checking) are overlays. In the Eurozone, SEPA Instant Credit Transfer (SCT Inst) is the rail, and Request to Pay (SRTP) is an overlay scheme layered on top.

Common overlay services

Aliases and proxy addressing

People do not want to type account numbers. Alias overlays let a memorable identifier — a phone number, email, or handle — map to underlying account details. A central directory or addressing service resolves the alias to a real account at payment time. Brazil's Pix keys are the standout example: a Pix key can be a phone number, email, tax ID, or a random string, and the DICT directory resolves it. See our post on addressing a payment for more.

Request to Pay

Request to Pay flips the direction of initiation. Instead of the payer pushing money, the payee sends a structured request that the payer can accept, decline, or defer. The money still moves over the instant rail as a normal credit push once accepted, but the request messaging, status tracking, and links to invoices are the overlay's contribution. This is powerful for billing, because it keeps the payer in control of a push payment while giving billers the convenience of a pull.

Confirmation of Payee

Name-checking overlays let a sending bank verify that the account name matches what the payer expects before the payment goes out. This is a front-line defence against misdirected payments and authorised push payment fraud. It does not move money; it is a directory query that returns a match, close match, or no match result to inform the payer.

QR and merchant-presented codes

QR overlays standardise how merchant payment details are encoded so any compliant app can scan and pay. Standards such as EMVCo's QR specification define the data format, while the overlay scheme defines how the resulting payment is routed over the instant rail.

Why the layering matters

Separating the rail from overlays has real architectural benefits:

• The rail stays simple and robust. Keeping clearing and settlement minimal makes it easier to guarantee sub-ten-second, always-on performance.
• Innovation happens at the edge. New overlays can launch without changing the settlement core, so features evolve faster than the rail.
• Interoperability is preserved. Because every overlay ultimately settles over the same shared rail, a payment initiated through any overlay reaches any participant.
• Governance can differ. An overlay can have its own scheme rules, participants, and pricing while relying on the neutral base rail underneath.

Design implications for builders

If you are integrating instant payments, map which capabilities are rail-native and which are overlays, because they often have separate onboarding, certification, and directories. A phone-number payment might require you to join both the base rail and an alias directory service. Confirmation of Payee may be mandated by a regulator as a separate participation requirement. Treating overlays as first-class components — rather than assuming the rail does everything — prevents nasty surprises late in an integration.

Key takeaways

• Overlay services are value-added features built on top of a base instant-payment rail, not part of its clearing-and-settlement core.
• Common overlays include aliases, Request to Pay, Confirmation of Payee, and standardised QR codes.
• Examples include UPI over IMPS, Pix keys over Pix, and SEPA Request to Pay over SCT Inst.
• Layering keeps the rail robust while letting features innovate at the edge, all settling over shared infrastructure.
• Builders should treat overlays as separate components with their own onboarding, directories, and rules.