Since October 2025, a euro-area PSP executing a credit transfer must first check whether the beneficiary name the payer supplied matches the name on the account behind the IBAN. The EPC’s Verification of Payee scheme rulebook entered into force on 5 October 2025, and the legal obligation under the Instant Payments Regulation followed on 9 October 2025 for euro-area PSPs, with non-euro-area EU PSPs given until 9 July 2027. The rollout was cushioned by three adherence waves and an EPC test and self-certification platform, but the operating reality is now in place: an inter-PSP API round-trip, per payment, before authorisation.
The regulation reads like a simple consumer protection. The engineering underneath is anything but simple, and the corporates on the sending side of bulk payment files are discovering that VoP is quietly a master-data programme wearing a fraud-control badge.
The UK ran this experiment first. Confirmation of Payee arrived there in 2019 as a domestic market initiative, and the lesson it left is double-edged: name-checking genuinely reduces misdirected and scam payments, and it generates real friction wherever names are abbreviated, trading names diverge from legal names, or account records disagree with what the payer expects. The EU version inherits both halves, at thirty-six-country scale, embedded in a binding regulation rather than a market utility.
The matching engine is the product
The naive reading of VoP is string equality between the payer’s input and the account-holder record. No production system can work that way. “Muller GmbH” against “Müller Gesellschaft mit beschränkter Haftung”, “J. van der Berg” against “Johannes van der Berg”, a transliterated name against its original script: exact comparison fails all of these, and every false no-match is a legitimate payment blocked and a payer trained to distrust the warnings.
The matching layer has to normalise before it compares: capitalisation, punctuation, spacing, diacritics, legal-entity suffixes and their abbreviations, common given-name short forms, and local name-order conventions. Then it has to place the result into the scheme’s response semantics, match, close match, no match, or unavailable, with the close-match band carrying the payee name the responder holds, so the payer can see what the record actually says.
Calibration of that close-match band is where fraud outcomes and conversion outcomes trade off directly. Too strict, and legitimate payments fail or route to manual review until users habitually override. Too loose, and the lookalike-name fraud the scheme exists to catch sails through as a close match nobody reads. This threshold deserves the same treatment as any risk model: measured false-positive and false-negative rates, versioned changes, and periodic review against override and fraud outcomes, not a one-time vendor default.
Interoperability adds a second-order problem. The scheme runs on common EPC API specifications, and the EPC built its API Reference Toolbox and certification tooling precisely to reduce divergence, but responding PSPs still differ in matching quality. The same beneficiary can score a match at one bank and a close match at another. Senders should expect that inconsistency and instrument for it rather than treating every close match as equally meaningful.
Corporates: the bulk-file problem
For treasury and AP teams, the consumer flow, a warning on a screen and a decision to proceed, does not exist. Payments leave through ERP batches, host-to-host channels, EBICS, and SEPA files, thousands of items at a time. Machine-to-machine handling of VoP outcomes is the requirement, and the regulation acknowledges the mismatch: non-consumer payers may waive the service, and may opt back in.
That waiver is a policy instrument, and the sensible use of it is segmentation rather than a blanket switch-off. Verification stays mandatory where the fraud risk concentrates: first-time beneficiaries, changed bank details after supplier onboarding, high-value transfers. Routine, high-volume disbursements to long-established counterparties can run under waiver. The exact mechanics for bulk files, per-item verification, pre-submission validation, or post-hoc exception workflow, are a design decision each corporate has to make with its PSPs; the scheme documentation does not hand you one canonical pattern, so treat it as an architecture choice with fraud, conversion, and cutoff-time consequences.
The deeper corporate exposure is data quality. A supplier whose legal name is stored three different ways across the ERP vendor master, the TMS, and a subsidiary’s local system will generate mismatches on perfectly legitimate payments. VoP effectively audits your beneficiary master data on every run, in production, with payment delays as the error report. The corporates that had invested in vendor master cleansing before October 2025 felt the rollout as a non-event; the ones that had not are now doing the cleanup under operational pressure, which is the expensive way.
What it does to fraud, and what it does not
The economics of the scheme target authorised push payment fraud and invoice redirection: attacks that depend on persuading a payer to send money to an attacker-controlled account under a plausible name. Checking the name against the account before execution attacks that dependency directly, and it converts a class of fraud that was previously invisible until the recall attempt into a pre-payment warning.
Honesty about the limits matters for anyone designing the surrounding controls. VoP does not help when the criminal controls an account whose registered name matches the impersonated identity, when a legitimate supplier’s own channel is compromised and the “new” account details come with a name that verifies, or when a payer overrides the warning because the pretext was good enough. Social engineering adapts; the scripts already coach victims through dismissing mismatch warnings. The name check is one layer, and it works best feeding the layers around it: behavioural fraud scoring on the payment itself, beneficiary-account risk signals, and payee-change controls in supplier onboarding.
Running it: telemetry, overrides, and the audit trail
Treat VoP responses as an operational data stream, not a per-payment verdict to discard. Three practices separate a working deployment from a compliance checkbox.
- Log everything, verbatim. Request, response, matched name where returned, the message shown to the user or the disposition applied by the batch workflow, and any override with its author. This record is what a fraud investigation, a liability dispute, or a regulator will ask for.
- Watch the response mix. Match-rate by counterparty, close-match clusters, unavailable rates by responding PSP. Shifts in these distributions surface master-data rot, matching-engine changes on the responder side, and emerging fraud patterns earlier than loss data will.
- Close the loop into master data. Every resolved mismatch should end with a correction in the system of record, so the same supplier does not trip the same warning next cycle. The steady state to aim for is a first-attempt match rate high enough that the remaining warnings are rare, read, and taken seriously, because a warning users see ten times a day protects no one.
FAQ
Should a corporate use the waiver and switch VoP off for bulk payments?
Blanket waiver is the lazy answer and the wrong one. The waiver exists because consumer-style prompts do not fit batch flows, not because the risk disappears. The pattern we recommend is segmentation: keep verification mandatory for first-time beneficiaries, changed bank details, and high-value or high-risk payments, and waive it only for routine disbursements to long-established, previously verified counterparties, with the policy documented and reviewed.
Who is accountable when a close-match warning is overridden and the payment turns out to be fraud?
Under the regime, a payer who proceeds after a warning generally carries the consequence, which is exactly why override handling deserves design attention. Log every response, the exact message shown, who overrode it, and on what justification. In a corporate context, route close-match overrides on new or changed beneficiaries to a second approver. The audit trail is both your fraud-investigation record and your defence that the control operated.
Do the VoP response codes feed anything beyond the payment decision?
They should. A no-match on a long-standing supplier is a master-data defect worth fixing at source. A close-match cluster against one beneficiary account from multiple payers is a fraud signal worth escalating. Repeated unavailable responses from one responding PSP are an operational-dependency issue for your bank relationship discussions. Treated as telemetry rather than a gate, VoP outcomes improve data quality, fraud detection, and vendor management.