A payment sent to the wrong account is almost impossible to recall once it clears, and both the UK and the EU now require banks to check the payee name against the account before the payer presses send. The UK has run Confirmation of Payee (CoP) since 2020 and the Payment Systems Regulator (PSR) has widened it to most account providers. The EU Instant Payments Regulation added a mandatory Verification of Payee (VoP) service for euro credit transfers from 9 October 2025. This guide is for payment product owners, fraud teams, treasury and accounts payable leads who need to implement the checks, design the warnings and understand what a name check cannot catch. It goes deeper than our Authorised Push Payment (APP) Fraud Guide, which covers reimbursement and the wider scam picture.
Key takeaways
- Both schemes answer one question: does the name the payer typed belong to the account identifier they entered, with a match, close match, no match or not-possible result.
- EU VoP is law, not a scheme option: Article 5c of Regulation (EU) No 260/2012, inserted by Regulation (EU) 2024/886, applies to euro area providers from 9 October 2025 and to providers in non-euro member states from 9 July 2027.
- A match proves routing, not legitimacy: CoP and VoP stop misdirected payments and invoice redirection, but not scams where the victim pays a named account the criminal controls.
- The warning screen is the control: the result only works if the close match and no match messages are specific, interrupt the flow and are logged as risk signals.
- Businesses must consume the result too: accounts payable teams should run payee checks on every new or changed supplier account and treat a no match as a stop, not a warning to click through.
How UK Confirmation of Payee works
Pay.UK describes CoP as an account name-checking service for UK domestic payments. The payer's provider sends the entered name, sort code and account number to the payee's provider, which compares the name with its own account record and returns a result that also says whether the account is personal or business. Pay.UK reports more than 300 organisations live and more than 2 million checks a day.
- Architecture: API-based and peer to peer, with no central matching engine. A directory maintained by Pay.UK tells the requesting provider which organisation answers for a given sort code.
- Participation: a provider joins as a Direct Participant (built in house or through a technical service provider) or indirectly through a PSP Aggregator that is itself a Direct Participant. Pay.UK sets the joining criteria and lists the onboarded aggregators.
- Secondary Reference Data (SRD): accounts that are addressed by a roll number or other reference behind a shared sort code (building society and some e-money accounts) are eligible, so the check must carry the reference as well as the account number.
- Mandate: PSR Specific Direction 17, in force from 24 October 2022, required Group 1 providers to send and respond to checks by 31 October 2023 and Group 2 providers (own sort code, building societies, sending customer funds over Faster Payments or CHAPS) by 31 October 2024. Savings accounts are in scope; accounts outside the UK, loan repayments, a firm's own money and suspense accounts are among the exemptions.
- Direct Debits: Pay.UK also offers Payer Name Verification for Bacs Direct Debit set-up to existing CoP participants.
Result codes you will handle
The CoP standard returns a match flag plus a reason code. The codes below are the ones most implementations design screens for; confirm the full current list in the Pay.UK CoP standard your build uses.
| Result | Typical reason code | What the payer should see | Risk handling |
|---|---|---|---|
| Match | none | Confirmation that the name matches, with personal or business indicator | Normal flow; still apply scam risk scoring |
| Close match | MBAM | The actual account name returned, and a prompt to confirm it is who they mean | Moderate risk; log the returned name and the payer's choice |
| Name matches, wrong account type | BANM, PANM | Account is business (or personal), not what was selected | Low to moderate; frequent with sole traders |
| No match | ANNM | Strong warning that the money may go to someone else, with the option to stop | High risk; step up friction, consider delay or contact |
| Account does not exist | AC01 | Details are wrong; payment cannot proceed as entered | Block and ask for corrected details |
| Unable to check | OPTO, CASS or timeout | The name could not be checked, and the payer should verify by another route | Treat as unverified, not as a match |
How EU Verification of Payee works
Article 5c(1) obliges the payer's provider to offer a payee verification service immediately after the payer provides the payee details and before the payer can authorise the transfer, whatever the channel (app, online banking, branch, file). The European Payments Council (EPC) runs the Verification Of Payee Scheme Rulebook (EPC218-23, version 1.0 published 10 October 2024 and version 1.1 published 16 March 2026) that sets the inter-provider rules and messages so that a request can be answered by any participating provider in SEPA.
- Name and IBAN: the payee's provider verifies whether the name matches the IBAN. On a mismatch the payer must be told that authorising may send the funds to an account not held by the intended payee. On an almost match the payer must be shown the name associated with the IBAN.
- Legal persons: where the payer gives an unambiguous data element such as a fiscal number, European Unique Identifier (EUID) or Legal Entity Identifier (LEI), it can be used instead of the name.
- Pooled accounts: where an account holds funds for several payees, the provider confirms whether the named payee is among them.
- Paper orders: verified at receipt, unless the payer is not present.
- No hard block: Article 5c(5) says verification must not prevent the payer from authorising the transfer. The payer keeps the final decision; the provider's job is a clear, specific notification.
- Free of charge: Article 5b(2) requires the service at no charge to all payment service users.
- Bulk opt-out: Article 5c(6) lets non-consumers who submit multiple payment orders as a package opt out, and opt back in at any time.
- Liability: under Article 5c(8) a provider that complied is not liable for a transfer to an unintended payee; a provider that failed to offer the service must refund the payer without delay, and a payee provider or payment initiation provider that caused the failure must compensate the payer's provider.
UK CoP and EU VoP compared
| Aspect | UK Confirmation of Payee | EU Verification of Payee |
|---|---|---|
| Legal basis | Pay.UK service, mandated by PSR Specific Direction 17 | Article 5c of Regulation (EU) No 260/2012 (inserted by 2024/886) |
| Payments covered | UK domestic Faster Payments and CHAPS between in-scope accounts | Euro credit transfers, standard and instant |
| Identifier | Sort code, account number, SRD where used | IBAN; LEI, EUID or fiscal number for legal persons |
| Dates | Group 1 by 31 Oct 2023, Group 2 by 31 Oct 2024 | Euro area 9 Oct 2025; non-euro member states 9 Jul 2027 |
| Inter-provider rules | Pay.UK CoP standard and directory | EPC VOP Scheme Rulebook |
| Opt-out | Account holders can opt out in defined cases (result "unable to check") | Only non-consumers sending multiple orders as a package |
| Liability link | CoP outcome feeds the PSR APP reimbursement assessment | Failure to offer VoP makes the payer's provider refund |
Designing the matching and the warnings
Most of the fraud value sits in two places: how the responding provider decides between match, close match and no match, and how the sending provider presents the result.
- Normalise before comparing: case, accents, punctuation, titles (Mr, Dr), legal suffixes (Ltd, Limited, GmbH, SA), ampersands and common abbreviations. Document the rules so the result is reproducible in a dispute.
- Define close match narrowly: transposed letters, initials versus full first name, a missing middle name, trading name versus registered name. Returning the actual name on a close match leaks a little personal data, so the threshold matters for privacy as well as fraud.
- Handle joint and business accounts: match any account holder on a joint account; for business accounts match registered and trading names held on file, and use the LEI or EUID route in the EU where it is offered.
- Write warnings that name the risk: "The name you entered does not match this account. If you continue, your money may go to someone else and you may not get it back." Generic "please check details" text is clicked through.
- Make the payer act: for a no match, require an explicit choice (edit, cancel, continue anyway) and, above a value threshold, a reason or a cooling-off delay. Never pre-select "continue".
- Repeat on change: run the check again whenever a saved payee's details are edited, and at the first payment to a new payee, not only at payee creation.
- Protect the service: the check is an oracle for account names. Rate limit by customer and session, alert on bulk lookups against many accounts, and require an authenticated session before any check.
Using payee checks in accounts payable
Invoice and supplier bank detail fraud is the case CoP and VoP catch best, because the criminal usually supplies an account in a different name. See the Invoice Redirection and Supplier Bank Detail Fraud Guide.
- Supplier onboarding: run a payee check on the account in the supplier master file, record the result and the returned name, and do not activate a no match.
- Bank detail changes: any change request triggers a callback to a contact already on file (never one from the request), a new payee check and a second approver.
- Bulk payment files: EU corporates who opt out of VoP for bulk files take on the risk the regulation was designed to remove. If you opt out, run your own pre-validation of new and changed beneficiaries before the file is built.
- Close matches: trading name differences are common. Resolve them once at onboarding with evidence, and record the accepted name so repeated payments do not train staff to ignore warnings.
Compromised mailboxes are the usual source of the fake change request; see the Email Identity and BEC Guide.
What payee checks do not stop
| Scenario | Does CoP or VoP help? | Control that does |
|---|---|---|
| Mistyped account number | Yes, no match or account does not exist | Payee check alone |
| Invoice redirection to an account in another name | Yes, usually no match | Payee check plus callback on change |
| Purchase, romance or investment scam to the criminal's own named account | No, the name matches what the victim was told | Scam risk scoring, purpose questions, delays |
| Safe account scam where the victim is coached to ignore a mismatch | Weak, warning is pre-empted | Warnings that name the scam, human intervention |
| Money mule account opened in a real or synthetic identity | No, the name matches | Receiving-bank mule detection |
| Executive impersonation instructing new transfers | No, payer intends the account | Out-of-band verification and dual approval |
The Arup deepfake fraud shows the last row: a finance worker made 15 transfers to five accounts after a video call with a fake CFO. A name check would have confirmed whatever names the criminals supplied; the missing controls were independent verification and a second approver for new beneficiaries.
Where identity fits
Payee checks assume the person pressing send is the genuine customer. If an attacker has taken over the account, they will add a payee in a matching name and pass every check. Pair CoP and VoP with strong customer authentication at payee creation and payment, step-up for high-risk payees, and session risk signals. See the PSD2/PSD3 Strong Customer Authentication Guide. On the responding side, the API credentials your provider or aggregator uses to call the directory and answer checks are machine identities: hold them in a secrets manager, rotate them and monitor their use.
Detection and measurement
- Log every check: request time, channel, entered name, result, reason code, returned name for close matches, and the payer's decision. This is evidence for reimbursement and complaint handling.
- Feed results to fraud scoring: a no match followed by "continue anyway" on a first payment to a new payee is one of the strongest APP scam signals a sending bank has.
- Monitor the service itself: availability and latency of outbound checks, share of "unable to check" results by responding provider, and lookup volumes per customer to catch enumeration.
| Metric | What it shows |
|---|---|
| Coverage: share of eligible payments with a completed check | Gaps in channels (branch, file, API) and responding providers |
| Proceed rate after no match, by value band | Whether warnings work; a rising rate means warning fatigue or coaching |
| Fraud reported on payments that proceeded after no match or close match | Warning effectiveness and where to add friction |
| Share of "unable to check" results | Interoperability and opt-out exposure |
| Close match rate on responding side | Whether matching rules are too loose (data leakage) or too tight (friction) |
How to implement
- Confirm scope and dates: which accounts, channels and payment types are in scope under SD17 or Article 5c, and whether you must send, respond or both.
- Choose the access model: direct participation or an aggregator in the UK; direct EPC scheme participation or a service provider in the EU. Check the provider's availability commitments, because a failed check is your liability.
- Clean the responding data: account holder names, trading names, joint holders and identifiers such as LEI must be current, or you will return false no matches.
- Build and test matching rules: run them against a sample of real payee names offline, measure match, close match and no match rates, and tune before going live.
- Design warnings with the fraud team: test copy with users, add value thresholds for extra friction, and agree what happens on "unable to check".
- Pilot: start with one channel or a share of traffic, compare complaint and fraud rates, then extend to every channel including branch and bulk files.
- Plan fallback: if the check service is down, decide whether to queue, warn or allow with a flag. Under Article 5c a provider that does not offer the check must refund, so a silent bypass is not an option in the EU.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| EU law | Regulation (EU) No 260/2012 Articles 5b(2), 5c(1) to 5c(9) | Mandatory VoP, charges, opt-out, liability, dates |
| UK regulation | PSR Specific Direction 17 | CoP send and respond duty |
| NIST CSF 2.0 | DE.AE-02, DE.CM-09 | Analysing check results and payment events as adverse event signals |
| NIST CSF 2.0 | PR.AA-05 | Separation of duties for supplier bank detail changes |
| NIST SP 800-53 Rev 5 | SI-4, AU-6 | Monitoring the check service and reviewing payment logs |
| MITRE ATT&CK | T1657 Financial Theft, T1566 Phishing | The fraud outcome and the usual delivery route for fake payment instructions |
Common failure patterns
- Treating "unable to check" as a pass: the payer sees no warning and the payment goes, which is exactly the gap criminals seek out by choosing accounts at providers that do not respond.
- One generic warning for every result: close match, no match and not possible are presented the same way and customers learn to click through.
- Checking at payee creation only: edited payees and changed supplier details skip the check.
- Loose close-match rules: the responding provider returns full names for weak matches, turning the service into a name lookup for fraudsters.
- Corporate bulk opt-out without a substitute: the treasury team opts out for convenience and supplier fraud lands in the payment file.
- Believing a match means safe: staff and customers read a green tick as approval, while impersonation and mule scams pass every name check.
Practitioner checklist
- Map every payment channel, including branch, file and API, to the CoP or VoP check it must run.
- Confirm your obligations and deadlines under SD17 or Article 5c(9) and record them.
- Write distinct, specific warnings for close match, no match and unable to check.
- Re-run the check on every new payee, first payment and edit of saved details.
- Rate limit checks and alert on enumeration patterns.
- Log result, reason code, returned name and payer decision, and feed them to fraud scoring.
- Make a no match a hard stop in your own accounts payable process, with callback and second approval.
- Track proceed-after-no-match rate and fraud on warned payments monthly.
- Test the fallback when the check service is unavailable.
Standards and references
- EUR-Lex: Regulation (EU) 2024/886 on instant credit transfers in euro
- European Payments Council: Verification Of Payee Scheme Rulebook
- Pay.UK: Confirmation of Payee
- Payment Systems Regulator: Confirmation of Payee requirements under Specific Direction 17
- Payment Systems Regulator: APP scams
- MITRE ATT&CK: T1657 Financial Theft
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Authorised Push Payment (APP) Fraud Guide · Invoice Redirection and Supplier Bank Detail Fraud Guide · Business Email Compromise Awareness for Finance Teams Guide · Online Fraud Regulation Map. This guide summarises UK and EU payee verification requirements and is not legal advice.