Verification of Payee and Confirmation of Payee: The Match-Code Reference

Verification of Payee (VoP) in the EU and Confirmation of Payee (CoP) in the UK do the same job — check the payee name a payer types against the name registered on the destination account before a credit transfer goes out — but they are two separate schemes with two different code models. The most common integration mistake is merging them into one table. This reference keeps them apart: the EU’s four result codes on one side, the UK’s provider-documented reason codes on the other, with operator handling and liability notes for each.

What VoP and CoP actually verify

Both VoP and CoP perform a name-on-account check: they compare the payee name the payer entered against the name registered on the destination IBAN or sort-code/account-number. That is all they do. They are not a fraud score, not a sanctions or AML screen, not a balance check, and not a guarantee that the account is legitimate or that the payee is who they claim to be. A Match tells you the name fits the account — nothing more.

Both are payer-side controls, run before the credit transfer executes, and they apply to push payments (credit transfers initiated by the payer). That push-payment scope is exactly why they tie to authorised push payment fraud: the payer authorises the payment themselves, so the only point of intervention is a warning before they confirm. VoP and CoP are that warning.

Two regimes, two code models: EU VoP vs UK CoP

EU VoP and UK CoP are separate schemes with separate code models. They share the same four broad outcomes — Match, Close Match, No Match, and an unavailable/not-possible category — but below that level they diverge sharply: the EU has no standardised reason codes, while the UK has around thirteen provider-documented ones. Do not map one scheme’s codes onto the other.

EU VoP: the four result categories

The EU VoP scheme is governed by the EPC rulebook EPC218-23 (v1.0, in effect 5 October 2025), with the inter-PSP API defined in EPC103-24. The scheme returns exactly four machine-readable result categories — and only these four:

There is no fifth code, and no reason granularity behind a failure. The EPC API specification collapses every failure reason into the single NOAP value: in the event of a negative return, the reason code is “Verification Check Not Possible” in all cases. There is no scheme-level enum distinguishing “account closed” from “responding PSP unreachable” from “service temporarily unavailable” from “responder does not support VoP.” If your provider exposes that kind of detail — for example SurePay’s “VOP Plus” tier — it is provider-proprietary, varies by vendor, and is mostly not published. Do not present EU granular failure reasons as scheme codes; the scheme has none.

One variant is worth noting: when the verification is performed against an Identification code (an LEI or VAT number) plus IBAN rather than a name, the rulebook value range swaps “Close Match” for a result indicating the Identification code is not supported or not known by the Responding PSP. The Match / No Match / Not Possible categories still apply; only the close-match slot changes meaning in the ID-code flow.

UK CoP: match outcomes and reason codes

A provenance caveat first, because it governs how much weight these codes carry. The four top-level CoP outcomes — Match, Close Match, No Match, and Unavailable — are standard and stable. The granular reason codes below, however, are drawn from provider implementation documentation (SurePay, Weavr, ClearBank), which agree with each other and reflect the de-facto production set. The canonical Pay.UK CoP standard is members-gated and was not quoted directly here. Treat the codes below as widely-used implementation codes, not as a verbatim Pay.UK enum: some codes (SCNF and similar) appear in some implementations but not all.

Match and close-match codes

No-match and unavailable codes

Operator action table

The category an outcome falls into — not the specific code — drives operator handling. The schemes are advisory in every regime, so the right action is almost never a hard block.

Customer-message guidance

Outcome copy matters as much as the code. The goal is to make a real mismatch obvious without crying wolf on the many benign ones.

• Match: Minimal or no message. “The name matches this account.” Do not add friction.
• Close Match: Always surface the actual account name returned by the responder — e.g. “This account is registered to Acme Trading Ltd. Is that who you meant to pay?” Showing the real name lets the payer distinguish a harmless typo from a scam in a way a generic “close match” banner never can.
• No Match: Warn, but avoid accusatory language. “The name you entered doesn’t match this account. Double-check the details with the person or business you’re paying.” False positives are common — middle names, trading names vs registered names, abbreviations, and joint accounts all trigger No Match legitimately.
• Unavailable / NOAP: Keep it calm and non-alarming. “We couldn’t check the name on this account right now.” Do not imply the payee is fraudulent; the check simply didn’t run.

Common false-positive sources to design around: business trading names vs registered legal names, abbreviations and initialisms, joint accounts where only one holder’s name was entered, and recently-switched accounts still propagating through the directory.

Fraud, liability, and reimbursement

Under the EU Instant Payments Regulation, the VoP result is advisory: a payer can proceed after a No Match and then bears the fraud-loss risk themselves. But that allocation flips if the payer’s PSP fails its part — if the PSP does not deliver the discrepancy warning and executes the transfer anyway, the PSP is liable to refund the payer. So EU liability hinges on whether the PSP warned, not merely on the payer’s choice. Note that PSD3 and the PSR (the proposed Payment Services Regulation) are expected to reshape gross-negligence and liability rules further, but as of mid-2026 they are not yet final law — treat them as forthcoming, not current.

In the UK, mandatory APP scam reimbursement has been live since 7 October 2024: the sending PSP reimburses in-scope victims (generally within five business days), with liability split 50/50 between sending and receiving PSP, an £85,000 per-claim cap, and an optional £100 excess that is waived for vulnerable consumers. CoP is the fraud-prevention front-end to this regime. A customer who ignores a clear CoP No Match can have that factored into the consumer-standard-of-caution assessment — but reimbursement remains the default, not the exception. The governing detail sits in PSR PS25/5 (May 2025) and the PS24/7 cap. For the full mechanics of how these warnings sit inside real-time push-payment fraud, see Authorised Push Payment fraud on real-time rails.

PSP and API implementation notes

The scheme defines the result categories; providers and aggregators add the operational layer on top. SurePay is the dominant infrastructure provider for both EU VoP and UK CoP: it offers a “VOP Standard” tier (EPC-minimum — only the four codes) and a “VOP Plus” tier (enriched outcomes that are not fully public). Other providers in the space include Banfico (which runs an EPC-VOP portal), Bottomline, iPiD, Token.io, Mastercard (Open Banking / Account Name Check, via its Vocalink heritage — Vocalink is a Mastercard company and operates UK central payments infrastructure), and Visa (a minor player here).

The practical takeaway: any reason granularity beyond the four EU codes is provider-specific and varies by vendor. An operator integrating VoP or CoP should map to their provider’s documented enum, not assume a universal set exists across PSPs. For the EU mandate that makes VoP compulsory in the first place — the deadlines, pricing parity, and SCT Inst rollout — see EU Instant Payments Regulation: the compliance timeline.

Common pitfalls

• Treating Close Match as Match. A Close Match is not a pass — always surface the returned account name so the payer can judge the difference themselves.
• Hard-blocking on No Match or NOAP. Both schemes are advisory. Blocking creates support load and inflicts false-positive harm on legitimate payments (joint accounts, trading names, switched accounts).
• Assuming EU VoP exposes granular failure reasons. It does not. Every failure returns NOAP; there is no scheme-level “why.”
• Ignoring account-type mismatch codes. BANM/PANM catch business-vs-personal entry errors that a plain name match would miss — they are signal, not noise.
• Treating provider-specific codes as portable. A code returned by one provider may not exist, or may mean something different, at another. Codes are not portable across PSPs.
• Conflating VoP and CoP enums in one integration. They are separate schemes. Keep the EU four-code model and the UK reason-code model in separate mappings.

---

Scope note

• Primary sources (confirmed): the four EU VoP result categories and the NOAP catch-all are from the EPC rulebook EPC218-23 and API spec EPC103-24, read directly; the matching logic is from EPC288-23. The IPR mandate dates come from Regulation (EU) 2024/886. The UK reimbursement regime is from PSR PS25/5 and PS24/7.
• Provider-documented (de-facto, not canonical scheme text): the ~13 UK CoP reason codes are compiled from SurePay, Weavr, and ClearBank implementation docs, which agree with each other; the authoritative Pay.UK CoP standard is members-gated and was not quoted directly. Codes such as SCNF (and similar provider variants) appear in some implementations but not all.
• In flux: PSD3 and the PSR will reshape EU liability and gross-negligence rules, but are not yet final law as of mid-2026. The EU VoP API spec is v1.0 — future versions could add reason codes; this page reflects the v1.0 / October-2025-mandate state.
• Verify with your PSP: exact enums, edge-case behaviour, and provider tiers (Standard vs enriched) vary by aggregator and bank.

Related references

• EU Instant Payments Regulation: The Compliance Timeline — the VoP mandate, SCT Inst rollout, pricing parity, and deadlines.
• SEPA Return and Reject Codes: The R-Transaction Reference — the post-execution failure codes that sit downstream of a VoP check.
• Authorised Push Payment Fraud on Real-Time Rails — why name-checks exist and how APP fraud and reimbursement interact.
• SEPA Credit Transfer, Instant, and Direct Debit: Operator Guide — scheme mechanics for the transfers VoP guards.

For term definitions — SEPA and IBAN — see the Payments Glossary.