Verification of Payee (VoP): Architecture for EU Instant Payments (2026)

Verification of Payee is the check that runs a fraction of a second before a euro-area credit transfer leaves the payer’s bank: it compares the name the payer typed against the name actually held on the destination IBAN, and hands back a traffic-light verdict before the payer commits. As of 9 October 2025, this check is no longer a nice-to-have fraud control bolted on by a handful of progressive banks — it is a legal obligation under the EU Instant Payments Regulation, free of charge, for every euro-area payment service provider.

Architecture at a glance

This article is a systems-architecture analysis of the VoP scheme. It is not financial, legal, or compliance advice — consult the EPC rulebook and your regulator for authoritative guidance.

What this covers: the regulatory driver and the fraud problem it targets; the end-to-end reference architecture connecting payer PSP, directory, and payee PSP; the fuzzy name-matching pipeline and the request/response protocol between institutions; a decision matrix mapping match results to payer UX; and the operational failure modes — latency, availability, false positives, and gaming — that architects have to design around.

Context and Background

Authorised push payment (APP) fraud is the dominant fraud vector in instant-payment ecosystems precisely because instant rails remove the one control that used to save victims: time. A same-day BACS or SEPA credit transfer gave banks a settlement window to flag anomalies. SEPA Instant Credit Transfer settles in under ten seconds, irrevocably, which means a fraudster who tricks a victim into authorising a transfer to the wrong IBAN has effectively been paid before anyone can react. Chargebacks do not exist for credit transfers the way they do for cards. The money is gone unless the receiving institution recovers it voluntarily, which happens in a minority of cases once funds have been layered onward.

The UK ran the first large-scale natural experiment here. Confirmation of Payee (CoP), introduced by Pay.UK from 2020, requires UK banks to check the name against the account/sort-code pair before a Faster Payment executes. Post-implementation data from Pay.UK and the Payment Systems Regulator showed a measurable reduction in “misdirected payment” fraud (the subset of APP fraud caused by wrong-account entry, whether through fraudster manipulation or simple typos) once CoP coverage reached critical mass across the major banks. That result is the direct precedent behind the EU’s decision to mandate an equivalent check pan-European rather than leave it to individual PSPs, whose voluntary adoption had been patchy for years under earlier EPC schemes.

The legal vehicle is Regulation (EU) 2024/886, the Instant Payments Regulation (IPR), which amends the SEPA Regulation. It requires PSPs offering euro-denominated credit transfers to provide Verification of Payee — and requires that the check run for all credit transfers in scope, not solely instant ones — free of charge to the payer, before the payer authorises the transfer. Euro-area PSPs had to comply from 9 October 2025; PSPs in non-euro-area EU member states have until 9 July 2027, reflecting the later instant-payment rollout deadlines those markets face. This sits alongside broader account-to-account fraud tooling covered in our real-time fraud detection architecture piece, and it depends on the same instant-rail plumbing discussed in our real-time payment infrastructure comparison of FedNow, UPI, and SEPA Instant.

The European Payments Council (EPC), the body that also stewards the SCT Inst rulebook, was handed the job of standardising the technical layer. Its VoP scheme and rulebook define the message flows, the directory model, and the participant obligations that let any of the roughly four thousand PSPs in scope reach any other without bilateral integration. That scheme, and the intra-EPC governance around it, is the subject of the rest of this piece.

The choice to route standardisation through the EPC rather than leave implementation entirely to national regulators or individual clearing houses matters architecturally. It means the message formats, the matching-outcome taxonomy (the four traffic-light results discussed below), and the participant onboarding rules are the same whether a payer’s bank is in Ireland, Germany, or Slovenia. A payer moving between euro-area countries, or a business operating payment flows across several of them, sees one consistent verification behaviour rather than a patchwork of national implementations — the same lesson the SEPA project itself learned the hard way in the 2000s, when early instant-payment pilots fragmented along national lines before SCT Inst imposed a common rulebook. VoP inherits that governance model deliberately rather than repeating the fragmentation.

It is also worth being precise about scope: the IPR’s VoP obligation attaches to credit transfers, the “push” side of account-to-account payments. Direct debits, card transactions, and other payment instruments are out of scope for this specific mandate — they carry their own, separate fraud-control mechanisms (mandate verification for direct debits, 3-D Secure and network fraud scoring for cards) that predate and operate independently of VoP. Conflating VoP with a general “payment fraud check” overstates what the regulation actually requires and can lead architects to under-invest in the controls that still have to cover those other rails.

The Reference Architecture

Verification of Payee works as a synchronous request/response check inserted into the payment initiation journey, one hop before the payer authorises the transfer: the payer’s PSP sends the destination IBAN and the name the payer entered to the payee’s PSP, receives back a traffic-light result, and displays it to the payer for a go/no-go decision.

The architecture has four layers, and understanding why each one exists is more useful than memorising the boxes.

Layer 1: the requesting PSP (payer side)

The payer’s bank, the “requesting participant” in EPC terminology, captures the IBAN and the free-text payee name the payer typed into the payment form. It packages these into a VoP request. Crucially, the requesting PSP does not perform the name comparison itself — it has no visibility into what name the payee’s bank actually holds on file, by design. It is a pure client of the scheme.

Layer 2: the directory and routing layer

Because there is no single central registry that every PSP in Europe queries directly, the scheme relies on a routing/directory function to resolve “which PSP holds this IBAN, and what is its VoP API endpoint.” In practice this is delivered by EPC-recognised VoP service providers — payment infrastructure operators and clearing-and-settlement mechanisms that already maintain IBAN-to-BIC routing tables for SCT/SCT Inst, extended to also carry each participant’s VoP reachability and endpoint metadata. A requesting PSP typically doesn’t hard-code a directory lookup per transaction; it integrates with one or more VoP routing/directory providers that abstract this away, similar to how RTP directory services work in other instant-payment schemes. This indirection is what makes VoP scale to thousands of participants without every PSP building bilateral connections to every other PSP — the same n-to-n-via-hub pattern used in card networks and, closer to home, in the open banking API ecosystem we cover in our PSD3/PSR API architecture piece.

Layer 3: the responding PSP (payee side)

The payee’s bank, the “responding participant,” receives the VoP request, looks up the account holder name(s) registered against the destination IBAN in its core banking or account-servicing system, and runs the comparison. This is the layer with the highest architectural stakes: it must be fast (the payer is waiting, mid-checkout, for a live answer), it must be authoritative (it is the only party who actually knows the true account holder name), and it must handle the messy reality of real-world names — joint accounts, trading names distinct from legal entity names, recently renamed accounts, and non-Latin scripts.

Layer 4: the matching engine and result delivery

The comparison itself — detailed in the next section — produces one of four canonical outcomes, then that outcome flows back up through the same directory/routing path to the requesting PSP, which renders it to the payer before the authorisation step.


*Figure 1: End-to-end Verification of Payee flow, from payer input through directory routing, payee-side matching, and the traffic-light decision that gates payment authorisation.*

Figure 1 traces the full round trip. Note that the check sits strictly before authorisation — SCT Inst execution (the actual funds movement) only happens after the payer has seen the VoP result and chosen to proceed. This ordering is the entire point: once the ten-second instant-settlement window opens, there is no more room for a fraud check to intervene.

Why the check is synchronous, not asynchronous

A tempting alternative design is to run the name check asynchronously and let the payment proceed while the result is still pending, flagging suspicious transfers after the fact for investigation. The IPR forecloses this for VoP specifically: the regulation requires the result to be presented to the payer before they authorise the transfer, so the payer retains the ability to cancel. That constraint pushes the entire matching pipeline — directory lookup, cross-border/cross-PSP round trip, fuzzy comparison — into the critical path of payment initiation, with a latency budget measured in low hundreds of milliseconds if the checkout UX is not to visibly stall. This is the single biggest engineering constraint discussed later in the trade-offs section.

Why a directory layer instead of point-to-point integration

An alternative that a naive design might reach for is bilateral API contracts between PSPs — bank A calls bank B’s VoP endpoint directly, using a lookup table it maintains itself. This does not scale past a handful of participants: with several thousand PSPs across the euro area, full bilateral mesh integration is combinatorially infeasible, and every new entrant or API change would require every counterparty to update in lockstep. The directory model — analogous to how BIC/IBAN routing already works for SCT and SCT Inst clearing — lets a PSP integrate once with a routing provider and reach the entire scheme. It also creates a natural place to enforce participant authentication and scheme governance centrally rather than per-bilateral-relationship.

Where the API model sits relative to existing standards

The EPC did not invent a VoP-specific protocol from nothing. The request/response pattern — synchronous API call, structured JSON or XML payload carrying IBAN and name, TLS-secured transport, PSP-to-PSP mutual authentication — follows the same architectural family as the Berlin Group’s NextGenPSD2 and Request-to-Pay (SRTP) frameworks that already underpin much of Europe’s open banking and instant-payment messaging. Participant PSPs authenticate to each other and to routing intermediaries using qualified certificates under eIDAS, the same trust framework used for PSD2 API access, so a bank does not need to build a second, parallel identity and certificate infrastructure purely for VoP. Reusing this stack was a deliberate design choice to lower the integration bar for the thousands of smaller PSPs who had never built dedicated fraud-check APIs before.

Deeper Walk-through: Matching Pipeline and Protocol Sequence

The hardest problem in Verification of Payee is not moving messages between banks — it’s deciding, in well under a second, whether “J Smith” and “John Smith Ltd” refer to the same real-world entity, without either annoying legitimate payers with false alarms or missing genuine misdirection.

The name-matching pipeline

Exact string equality is useless here. Real payee names diverge from the name on record for entirely benign reasons: a payer types “Jon” for “Jonathan,” omits a middle initial, drops “Ltd” or writes “GmbH” where the core banking record stores the full registered legal form, or transliterates a name with diacritics differently than the bank’s own records do. A matching engine that requires byte-for-byte equality would generate so many false “no match” results that payers would learn to ignore the warning entirely — which defeats the fraud-prevention purpose as surely as no check at all.


*Figure 2: The name-matching pipeline — normalize, tokenize, score, and classify into one of four traffic-light outcomes.*

Figure 2 lays out the pipeline the payee PSP runs internally:

Normalization. Both the submitted name and the stored account-holder name are case-folded, diacritics are stripped or canonicalised (é → e, ü → ue or u depending on locale convention), and whitespace/punctuation is standardised. This alone resolves a large share of superficial mismatches.

Legal-form and stopword handling. For business accounts, tokens like “Ltd,” “GmbH,” “SA,” “BV,” “SRL,” and “PLC” are recognised and either stripped before comparison or weighted down, since their presence or absence carries little discriminating signal — a payer who types “Acme Ltd” and a bank record of “Acme Limited” should not be flagged as a mismatch on that basis alone. Personal-name accounts get analogous handling for honorifics (“Dr,” “Mr,” “Ms”).

Tokenization. Both names are split into tokens (given name, family name, middle name/initial, business name components) so the comparison can reason about token order, missing tokens, and partial tokens rather than treating the name as one opaque string.

Similarity scoring. The engine computes one or more similarity metrics — token-level edit distance (Levenshtein or Damerau-Levenshtein), phonetic matching for common transliteration variance, and token-set overlap (how many tokens from the submitted name appear, in some form, in the stored name and vice versa). Individual accounts, business accounts, and joint accounts (where the stored record may list two or more names, and a match against any one of them is generally accepted) each need slightly different scoring logic, because the shape of the “correct” comparison differs.

Threshold decision. The composite similarity score is compared against tuned thresholds to classify the result. This is the step with real precision/recall trade-offs baked in, discussed next.

The four traffic-light outcomes

Result	Meaning	Typical trigger
Match	High-confidence the submitted name corresponds to the account holder	Near-exact token overlap after normalization; minor formatting differences only
Close Match	Plausible same entity, but not exact — the payee PSP may return the actual held name (or a masked version of it) so the payer can self-verify	Partial token overlap, transposed name order, missing middle name, legal-form variance beyond a simple strip
No Match	Submitted name does not correspond to the held account holder name with meaningful confidence	Low token overlap, different surname entirely, mismatched entity type (personal name submitted against a business account)
Not Possible / Other	The check could not be completed	Payee PSP unreachable, IBAN not found, account type out of scope (e.g., some payment institution wallets), scheme participant not yet onboarded

Worked examples

A payer intends to pay a supplier and types “Marco Rossi.” The account holder on file is “Rossi Marco” — token order reversed, a common artefact of how some core banking systems store personal names. After tokenization, both tokens overlap fully; the engine returns Match.

A payer types “J. Bakker Transport” for a business account registered as “Bakker Transport BV.” After legal-form stripping (“BV” removed from the stored name for comparison) and treatment of the initial “J.” as a low-weight token, the core tokens “Bakker” and “Transport” overlap fully, producing Match or a high-confidence Close Match depending on how conservatively the PSP has tuned initials handling — a legitimate area of inter-bank variance the scheme rulebook permits within bounds.

A payer types “Anna Keller” but the destination IBAN is registered to “Klaus Keller.” Surname matches, given name does not — token overlap is roughly 50%, past the “definitely no match” floor but well short of a confident match. This lands in Close Match, and good UX design shows the payer a masked version of the actual held name (for example “K*** Keller”) so they can recognise their own error, or a fraudster’s substitution, without the PSP fully disclosing a stranger’s private data to an unrelated party.

A payer types “Emma Novak” for an IBAN actually registered to “TechSupply Solutions Ltd” — a personal name against a business account entirely. Token overlap is near zero and the entity-type mismatch is itself a strong signal; the engine returns No Match.

The request/response protocol sequence


*Figure 3: Protocol sequence — payer PSP resolves routing via the directory, authenticates to the payee PSP, and receives the traffic-light result before the payer authorises the payment.*

Figure 3 shows the message sequence underneath Figure 1’s architecture. Two details matter operationally. First, the directory lookup (resolving which payee PSP owns the destination IBAN and where its VoP endpoint lives) is typically cached or pre-resolved at the routing-provider layer rather than hitting a live registry on every single transaction, because directory data changes far less frequently than transaction volume — this is what keeps the added round trip inside an acceptable latency budget. Second, PSP-to-PSP authentication uses certificate-based mutual TLS aligned with eIDAS qualified certificates, the same trust model PSD2 established for open banking API access, rather than a bespoke VoP credential — reusing infrastructure banks had already built for other regulatory APIs.

Decision matrix: result to payer UX

VoP result	Recommended payer-facing treatment	Liability posture consideration
Match	Proceed with minimal friction; brief positive confirmation	Standard authorisation flow
Close Match	Show masked held name; require explicit “proceed anyway” confirmation	Payer proceeding after a Close Match warning is a materially different fact pattern than an unwarned payer, relevant to later dispute handling
No Match	Strong warning; require a deliberate override step, not a single tap	PSP should log the override explicitly; broader APP-fraud reimbursement frameworks look at whether adequate warning was given
Not Possible	Disclose that verification could not be performed; payer proceeds at the PSP’s stated fallback policy	Distinct from a “No Match” — should never be visually conflated with a fraud warning

This mapping is deliberately non-prescriptive on exact wording because the EPC scheme and each PSP’s own risk policy govern the precise UX language and override mechanics; the architectural point is that the four outcomes require materially different friction levels, not a single generic pop-up.

Trade-offs, Gotchas, and What Goes Wrong

Latency budget versus the instant-payment SLA

SCT Inst guarantees fund availability to the payee within ten seconds of initiation. Verification of Payee has to complete — directory lookup, cross-PSP network round trip, matching computation, and result rendering — while the payer is still sitting at a checkout or banking-app screen, before that ten-second clock even starts. In practice this means PSPs and routing providers are engineering for response times in the hundreds of milliseconds, not seconds, which rules out anything resembling a manual review step and pushes matching entirely into automated, pre-tuned scoring logic. A payee PSP whose core banking lookup is slow (legacy mainframe account-holder queries are a common bottleneck) risks becoming the reason an otherwise-fast instant payment feels sluggish to the payer, which is a reputational problem the requesting PSP did not cause but the payer experiences as if it did.

Availability and the fallback question

VoP is a distributed, multi-party check: if the payee PSP or a routing intermediary is down, degraded, or simply hasn’t onboarded to the scheme, the honest answer is “Not Possible,” not a fabricated pass. The regulation does not require the payer’s transfer to be blocked outright when VoP is unavailable, but PSPs have to decide, as policy, what friction (if any) to apply to a payment proceeding without a completed check — and that decision has to be communicated clearly enough that “Not Possible” is never mistaken by the payer for “verified safe.”

False positives and warning fatigue

Any fuzzy-matching system trades precision against recall. Tune thresholds tightly (require near-exact matches for “Match”) and genuine payments — to a supplier whose legal name differs slightly from what the payer knows them by, to a relative whose bank record still shows a maiden name — get flagged as Close Match or No Match far more often than the underlying risk warrants. Payers who see warnings on transactions they know are legitimate learn, fast, to click through every warning without reading it — the same habituation problem that plagues browser certificate warnings and cookie banners. That habituation is arguably worse for fraud prevention than no check at all, because it creates false confidence that “the bank would have stopped me” while actually training users to dismiss the one signal that would have stopped a real fraud. This tension — the precision/recall trade-off under user-attention constraints — is structurally the same problem covered in more general terms in our real-time fraud detection architecture piece, applied here to a single, narrow signal (name match) rather than a full risk-scoring stack.

Gaming and adversarial adaptation

VoP does not verify identity or intent — it verifies that a name string corresponds to an account-holder name string. A sufficiently prepared fraudster can open or acquire a mule account under a name deliberately close to a target’s expected payee (for instance, registering a business under a name one character off from a legitimate supplier the victim already deals with), which would sail through as a Match or Close Match despite the underlying fraud being entirely intact. VoP is a control against misdirection and casual impersonation, not a substitute for broader authorised-push-payment risk scoring, transaction monitoring, or behavioural analysis — it closes one specific gap without closing the category.

Privacy and data minimisation

Returning the actual held account-holder name to an unrelated payer on every Close Match or No Match result is itself a data-protection question — the payee did not consent to have their legal name disclosed to whoever happens to type their IBAN into a payment form. The scheme’s answer is masking (partial disclosure, e.g., showing only a portion of the name) rather than full disclosure, and this is one of the genuine engineering tensions in the design: enough information for a payer to self-correct a mistake, not so much that VoP becomes a name-lookup oracle that can be abused to harvest account-holder identities by iterating over IBANs.


*Figure 4: The five operational failure modes architects have to design around — latency, availability, false positives, adversarial gaming, and privacy/data-minimisation limits.*

Capacity and cost economics

Because the IPR requires VoP to be offered free of charge to the payer, the responding-side cost of running the matching engine and account-holder lookup does not translate into a direct per-check fee the payee PSP can pass on to whoever is querying it. That shifts VoP from a revenue-adjacent service into pure infrastructure cost, sized to peak transaction volume rather than to a metered API business model. For a payee PSP with millions of incoming-transfer-eligible accounts, the query pattern is effectively “every credit transfer initiated anywhere in the euro area that names one of our IBANs as destination,” which for a large retail bank can mean sustained throughput far higher than its own outbound payment volume alone would suggest — a bank with modest transaction volume can still be a heavily-queried VoP responder if its customers are common payment destinations (utilities, large employers, popular marketplaces). Capacity planning for the responding side has to be sized against total inbound query load across the whole scheme, not against the bank’s own customers’ payment habits.

Practical Recommendations

Treat Verification of Payee as a latency-critical, high-availability microservice sitting directly in the payment authorisation path — not a batch or best-effort add-on. Payee-side implementations should optimise the account-holder-name lookup specifically for this call pattern (read-heavy, low-latency, high query volume relative to normal account-servicing traffic), which for many banks means fronting a legacy core with a purpose-built, cached lookup layer rather than hitting the core system directly on every request.

Invest matching-engine effort proportionally to where errors actually cost the most: false “No Match” on legitimate payments erodes trust and generates support load; false “Match” on genuinely different entities defeats the entire control. Both failure directions need monitoring with real production feedback loops — track override rates by result type, and treat an unusually high Close-Match override rate for a given payee-name pattern as a signal worth investigating, not just accepting.

Keep the payer-facing UX for each of the four outcomes visually and behaviourally distinct — a “Not Possible” should never look like a pass, and a “No Match” override should require a deliberate action, not a single dismissible toast. Log every override with enough context (result type, masked name shown, timestamp) to support later dispute investigation, since liability discussions after an APP fraud incident increasingly turn on whether an adequate warning was shown and how the payer responded to it.

Checklist for a euro-area PSP building or reviewing a VoP implementation:

• Confirm end-to-end latency (directory lookup + payee-side round trip + rendering) stays within a budget that does not visibly stall checkout, under realistic peak load, not just quiet-hour testing.
• Verify all four traffic-light outcomes are visually and behaviourally distinct in the payer UI, with “Not Possible” never conflated with a pass.
• Confirm the matching engine handles joint accounts, business legal-form variance, and at least the transliteration cases relevant to your customer base.
• Confirm masked-name disclosure on Close Match/No Match meets data-minimisation expectations rather than returning the full stored name.
• Confirm override actions are logged with sufficient context for later dispute review.
• Confirm a documented fallback policy exists for “Not Possible” and is communicated to payers, not silently defaulted to “allow.”
• Re-test thresholds periodically against real override-rate data rather than leaving initial tuning untouched indefinitely.

Frequently Asked Questions

Is Verification of Payee mandatory for all EU banks?

It is mandatory for payment service providers offering euro-denominated credit transfers under the EU Instant Payments Regulation. Euro-area PSPs had to comply from 9 October 2025. PSPs based in non-euro-area EU member states have an extended deadline of 9 July 2027, reflecting their later instant-payment adoption timeline. It applies to standard and instant credit transfers alike, not exclusively to instant payments, and must be offered to the payer free of charge.

Does a No Match result block the payment?

Not automatically. The payer retains the decision to proceed or cancel after seeing the result — VoP is a warning mechanism inserted before authorisation, not an automatic block. However, PSPs are expected to require a deliberate, explicit confirmation step for a payer who chooses to proceed despite a No Match, and that override may be relevant if a fraud dispute follows.

How is Verification of Payee different from IBAN validation?

IBAN validation is a checksum/format check confirming the IBAN itself is structurally well-formed and (often) that it corresponds to an existing account. It says nothing about whose name is on that account. VoP adds the name-matching layer on top: given a structurally valid, existing IBAN, does the account holder’s actual registered name correspond to the name the payer believes they’re paying.

Can Verification of Payee stop all APP fraud?

No. It specifically targets misdirected-payment fraud — cases where the destination IBAN doesn’t correspond to who the payer believes they’re paying, whether through error or deliberate manipulation. It does not address APP fraud where the payer is knowingly, if deceptively, sending money to the correct account the fraudster controls under their own name, such as many investment or romance-scam patterns. VoP is one layer in a broader fraud-prevention stack, not a complete solution.

What happens if the payee’s bank doesn’t support VoP yet?

The scheme returns a “Not Possible” (or equivalent “Other”) result rather than a false pass. Since VoP is now a regulatory obligation for in-scope PSPs, near-universal reachability is the expected end state, but during rollout windows and for out-of-scope account types, requesting PSPs need a defined, disclosed fallback policy for this case rather than treating it as an edge case to handle ad hoc.

Does VoP replace Confirmation of Payee in the UK?

No — they are separate, parallel schemes operating under different legal regimes. Confirmation of Payee is the UK’s domestic scheme, run under Pay.UK rules and enforced through UK regulation, predating and informing the EU’s approach. VoP is the EU-wide scheme under Regulation (EU) 2024/886. A cross-border payment between the UK and the euro area does not automatically get covered by either scheme purely by virtue of the other applying on one side.

Further Reading

• Open Banking PSD3/PSR API Architecture (2026) — the broader regulatory API stack VoP’s authentication model reuses.
• Real-Time Fraud Detection Architecture (2026) — how a single-signal check like VoP fits into a full risk-scoring pipeline.
• Real-Time Payment Infrastructure: FedNow, UPI, and SEPA Instant — the settlement rails VoP sits in front of.
• European Payments Council, SEPA Verification of Payee Scheme Rulebook — europeanpaymentscouncil.eu
• Regulation (EU) 2024/886 on instant credit transfers in euro — EUR-Lex
• Berlin Group, NextGenPSD2 and Access to Account Framework — berlin-group.org

By Riju — about