Confirmation of Payee Architecture and Request-to-Pay Services
Designing Name-Check and Request-to-Pay Services Customers Actually Trust
Confirmation of payee looks like a small feature. Send an account number and a name, receive an answer, show it to the customer. Teams routinely scope it as a quarter of work and then spend a year on it.
The reason is that almost none of the difficulty is in the lookup. It is in deciding what counts as a match when a customer types a nickname, in presenting a close match without frightening someone out of a legitimate payment, in building the responder side without turning your own account base into a lookup service for fraudsters, and in doing all of it inside a payment journey that cannot pause. Request-to-pay then sits on the same party data and inherits every one of those decisions.
What are confirmation of payee and request-to-pay meant to fix?
Misdirected payments and authorised push payment fraud, where the payment itself is technically correct.
Both services exist because the money moves exactly as instructed. On an irreversible rail there is nothing to reverse, and the Payment Systems Regulator describes name checking as the service designed to help prevent both scams and misdirected payments. That framing matters for your design: this is not only an anti-fraud control, and the ordinary typo volume it catches is usually larger than the fraud volume.
What does a name check actually return?
Four outcomes, not two, and each needs its own handling.
A match confirms the name and account agree. A close match means the details are nearly right and the responder supplies the correct name so the payer can decide. A no match means they disagree. Verification not possible covers unreachable participants, unsupported account types, and timeouts. Systems built around a boolean will be rebuilt, because the interesting cases are the middle two and they carry different legal, fraud, and user-experience consequences.
How is request-to-pay different from a direct debit?
The payer keeps control of every payment instead of granting standing authority.
A request arrives with the amount, reference, and due date prefilled by the biller, and the payer approves it, declines it, pays part of it, or asks for more time. There is no mandate, no unexpected debit, and no reversal process, which is why it fits naturally on instant rails: the RTP network supports a request for payment message alongside the credit transfer itself. For the payer it removes manual data entry, which is where misdirection starts. For the biller it removes a whole class of failed collections and the follow-up work behind them, the same operational drag described in this look at solving payment delays with better workflow design.
Scoping a payee verification programme as a simple API integration?
Talk to Digiqt about a payee verification architecture review
Where are these services mandated and on what timeline?
Across the UK and the euro area already, with non-euro EU states following, and market-driven adoption elsewhere.
| Market | Requirement | Timing |
|---|---|---|
| United Kingdom | Confirmation of payee name checking, overseen by the PSR alongside APP reimbursement rules | In force, rollout extended across payment firms |
| Euro area | Verification of payee under the Instant Payments Regulation, provided free to the payer | Since 9 October 2025 |
| Non-euro EU member states | Same verification obligation | From 9 July 2027 |
| United States | Request for payment available on the RTP network, payee verification driven by market practice | Available now, no single mandate |
Two design implications follow. First, in mandated markets the check is free to the customer, so the cost sits entirely with you and per-check efficiency is a real engineering concern. Second, you are always both a requester and a responder, and most programmes underinvest in the responder side because it produces no customer-visible feature.
How should the name matching service be architected?
As a tiered matcher with explicit thresholds, versioned rules, and a recorded decision for every check.
Matching is a policy decision disguised as a string comparison. Make the tiers explicit, keep the thresholds in configuration rather than code, and store which version decided each check, because you will be asked to explain a specific outcome months later.
Which matching tiers belong in the service?
Exact match, normalised match, and scored fuzzy match, in that order.
Exact comparison resolves the large majority of checks at almost no cost. Normalisation handles case, punctuation, honorifics, ordering of given and family names, common legal suffixes, and diacritics, and it should be applied identically on both sides of the comparison. Only what survives those two tiers reaches a scored comparison with a threshold for close match and a threshold for no match. Keep a deliberate band between the two thresholds rather than one cut-off, because the space between them is exactly where human judgment adds value and where a bad automated call does the most damage.
How do you handle nicknames, trading names, and joint accounts?
With curated equivalence data and account-type awareness, not by loosening the fuzzy threshold.
Loosening the threshold to accommodate nicknames makes every other comparison worse, which is the most common mistake in these builds. Handle known given-name equivalences from a curated list, hold registered trading names alongside legal names for business accounts, and check a supplied name against every holder on a joint account rather than against a concatenated string. Sole trader and trust accounts need their own rules because the account name legitimately differs from the person paying. Each of these is a data problem with a narrow fix, and solving them individually keeps the general matcher strict.
What response time budget applies?
Sub-second end to end, with a defined timeout and a safe default when it expires.
The check sits inline while the customer waits, so treat it like any other hot-path dependency: cap the outbound call, cache nothing that could be stale in a way that misleads, and decide in advance what happens on timeout. The correct default is verification not possible plus a clear message, never a silent pass and never an indefinite spinner. The failure modes are identical to any real-time decision path, and the diagnosis in this guide to real-time fraud detection applies here too: precompute what you can, and never let an external dependency decide how long your customer waits.
How should the responder side be built?
As a hardened, rate-limited service that reveals the minimum necessary and logs every request.
You answer other institutions' questions about your own customers, which makes this an information disclosure surface before it is a payments feature. Design it that way from the start.
What must the responder return, and what must it never leak?
Only the outcome, plus the correct name on a genuine close match, and nothing else ever.
Return the outcome and, where the scheme requires it on a close match, the name held on the account. Never return account status, balance, whether an account merely exists in isolation, or any hint of why a check failed beyond the defined outcomes. Requests for accounts that do not exist and requests for accounts that do but fail matching should be indistinguishable in timing and shape, because a measurable difference between them is itself a disclosure.
How do you prevent the service being abused for enumeration?
Rate limits per requesting party and per account, pattern scoring, and alerting on unusual request shapes.
Legitimate traffic looks like a payment journey: one or two checks against an account, spread over time, from an institution that then sends a payment. Abuse looks like repeated checks against the same account with varied names, or sweeps across sequential account numbers, or a requester whose check-to-payment ratio is wildly out of line with the network. Rate limit on both dimensions, score requesters continuously on that ratio, keep a full audit trail with the requesting institution recorded on every call, and give your fraud team a mechanism to throttle a specific requester without taking the whole service down. Then monitor it as a security surface rather than a payments endpoint, because that is what it is.
Building a responder service without treating it as an information disclosure surface?
Talk to Digiqt about hardening your payee verification responder
How do you present a close match without destroying conversion?
By naming the specific difference and letting the customer decide, rather than warning them generically.
The engineering can be flawless and the feature can still fail in the interface. A close match that says only that details may not be correct pushes cautious customers to abandon a perfectly good payment and teaches everyone else to click through warnings. Show the name held on the account, state plainly what differs, and offer a clear choice to correct the details or continue. Reserve genuinely strong friction for no match, where the risk is real, and phrase verification not possible as a system limitation rather than as a hint of suspicion, since the customer did nothing wrong. Measure abandonment separately for each outcome, because a single conversion number hides whether your copy is the problem.
How does request-to-pay change the payment journey?
It replaces manual entry with an approval decision, which removes the moment where misdirection happens.
| State | Owner | What matters technically |
|---|---|---|
| Request created | Biller | Validated party data, unique reference, expiry |
| Request delivered | Payer's institution | Reliable delivery, notification, no duplicates |
| Awaiting decision | Payer | Clear presentation of amount, payee, and due date |
| Approved, declined, part paid, or extended | Payer | Every outcome modelled and reported back to the biller |
| Paid | Both | Payment linked to the original request for reconciliation |
| Expired | System | Deterministic expiry with a defined biller notification |
The states that get skipped in first implementations are part payment, extension, and expiry, and they are the ones that generate support contacts. Model all of them, link the resulting payment to the request so reconciliation is automatic rather than inferred, and remember that a request-to-pay flow is only as trustworthy as the party data behind it. For institutions paying beneficiaries across borders, the same verification logic sits alongside the currency and sanctions checks covered in cross-border claims payments.
What changes in fraud outcomes after go-live?
Misdirection falls quickly, social engineering adapts, and your reporting has to keep both visible.
Expect an immediate drop in misdirected payments, since typos and stale details are caught mechanically. Expect authorised push payment fraud to fall too, then partially recover as social engineering adapts to coach victims through the warning, which is a real and documented pattern. That is not a reason to skip the control. It is a reason to instrument it: track how often customers proceed past a close match or no match and what share of those payments are later disputed, and feed that back into thresholds, copy, and limits. In the UK, reimbursement is shared equally between sending and receiving firms, so your responder-side accuracy has direct financial consequences and cannot be treated as a courtesy service.
How should delivery be sequenced?
Requester-side check first, then the responder service, then request-to-pay on the same party data.
Start with the requester-side check because it reduces losses from the day it ships and needs no other institution to change anything. Build the responder service next, with abuse controls in place before it opens rather than after, and load-test it against enumeration patterns as well as normal volume. Invest in party data quality throughout, since matching quality is capped by the data you hold and no algorithm compensates for a name field that was never captured cleanly. Add request-to-pay last, because it depends on the same verified party data and on an instant rail that can settle the approval immediately, which brings you back to the ledger and response-path decisions behind FedNow and RTP participation.
Payee verification is one of the few payment controls that pays for itself in a form a board recognises, because misdirected payments are visible, expensive, and obviously preventable. What decides whether it works is not the matching algorithm. It is the quality of your party data, the honesty of your close-match copy, and how seriously you treat the responder side that nobody outside the fraud team ever sees.
Frequently Asked Questions
What does a confirmation of payee check actually return?
One of four outcomes: match, close match with the correct name supplied, no match, or verification not possible. Each needs a distinct user experience and a distinct audit record.
Is confirmation of payee a fraud control or a data quality control?
Both. It catches misdirected payments caused by typos and stale details as well as social engineering, and the misdirection volume is usually larger than teams expect.
How fast does the check have to be?
Fast enough to sit inline in the payment journey without a visible pause, which in practice means a sub-second round trip with a defined timeout and a safe default when it expires.
What happens if the responding institution does not reply?
You return verification not possible and let the customer proceed with a clear warning. Blocking the payment on a peer outage moves an operational problem onto the customer.
How do we stop the service being used to fish for account details?
Never return a name unprompted, rate limit per requesting party and per account, score enumeration patterns, and reveal a corrected name only on a genuine close match.
Does a name check hurt payment conversion?
Well-designed close-match handling costs very little conversion. Poorly worded warnings on legitimate name variations are what cause abandonment, so the copy matters as much as the matching.
How is request-to-pay different from a direct debit?
The payer stays in control. A request arrives with amount and reference prefilled, and the payer approves, declines, or asks for more time rather than granting standing authority.
Where should we start if we have to do both?
Build the requester-side name check first because it reduces fraud losses immediately, then the responder service, then request-to-pay on top of the same party data.
