Payee verification stopped being a product the day it became an obligation. Since 9 October 2025, every payment service provider in a euro-area Member State has had to offer Verification of Payee on credit transfers, free of charge, under Regulation (EU) 2024/886. The check itself is not difficult: compare a name against the name held on an account and answer. What has proved difficult is everything around it — a five-second response budget, a middle answer that is neither yes nor no, corporate files that must be taken apart before they can be checked, and a liability boundary that the regulation and the scheme rulebook both decline to draw.
Executive Summary
- The obligation is broad and unpriced. Regulation (EU) 2024/886 requires PSPs to offer Verification of Payee to the payer free of charge, across credit transfers in scope, with euro-area providers live since 9 October 2025 and non-euro-area providers following on a later timetable. Recovering the cost through a fee is not available.
- Interoperability was outsourced. Rather than every PSP connecting to every other PSP, the European Payments Council scheme routes requests through Routing and/or Verification Mechanisms, subject to an EPC qualification process. That decision solved reachability and created a third-party dependency that belongs in the operational-resilience register.
- Latency is a scheme term, not an SLO you choose. The scheme sets a maximum of five seconds for the requesting PSP to obtain a response, with a materially shorter target in practice. A timeout is not a failure state the payer can be shielded from; it is an answer, and it means "could not be checked".
- The control degrades if the UX is wrong. A warning that appears too often, or reads as boilerplate, is dismissed. Close-match handling is the single highest-leverage design decision in the whole implementation.
The Regulation Turned Verification Into Plumbing #
For a decade, name-checking was a national initiative and a competitive story. The Netherlands and the United Kingdom built schemes and marketed the fraud reduction. Regulation (EU) 2024/886 ended that framing across the euro area by making the check mandatory, free, and general.
Three properties of the obligation matter more than the rest.
It is free of charge to the payer. Article 5c gives no room for a premium verification tier, which removes the commercial mechanism a bank would normally use to fund the build and to ration usage.
It is not limited to instant payments. Although the instrument arrived inside the Instant Payments Regulation, the verification duty attaches to credit transfers in scope generally, including standard SEPA credit transfers. Institutions that scoped their programme to SCT Inst alone discovered a materially larger integration surface than planned.
It is time-boxed. The European Payments Council scheme sets a ceiling of five seconds for the requesting PSP to obtain a response, with a substantially faster target in normal operation. That figure is not a service-level objective a bank negotiates internally. It is a scheme term, and everything upstream — payment initiation UX, channel timeouts, retry policy, file processing — has to fit inside it.
The consequence is structural. Verification became a shared utility with a fixed latency budget and no revenue line. It is a cost of operating a payment account.
What the Scheme Actually Requires #
The EPC scheme defines the message exchange and, critically, the vocabulary of the answer. The requesting PSP asks; the responding PSP — the one that holds the account behind the IBAN — replies with a classification rather than with the account holder's name in full.
Table 1: Response types and what each one obliges #
| Response | What it means | What the payer sees | What the PSP must be able to evidence |
|---|---|---|---|
| Match | The name supplied corresponds to the name held on the account | Proceed without friction | That the check was performed and the response recorded |
| Close match | The names correspond closely but not exactly — abbreviation, trading name, transposed elements | A warning, and in the scheme's design the name actually held, so the payer can adjudicate | The exact string shown, the timestamp, and the payer's subsequent choice |
| No match | The name does not correspond to the account | An explicit warning before authorisation | The warning content and the override, if any |
| Verification not possible | No answer inside the window, or the responding side cannot service the request | A neutral statement that the check could not be completed | Why it failed, and that the payer was told |
The fourth row is the one most programmes under-designed. A timeout is not an internal error to be swallowed. It is a scheme outcome with a required disclosure, and it will occur — during responding-PSP incidents, RVM degradation, or simple network variance near the ceiling.
Interoperability is handled by Routing and/or Verification Mechanisms. A PSP may connect to counterparties through an RVM rather than building bilateral reachability to every institution in SEPA, and RVMs must complete an EPC qualification process. This was the correct architectural call — the alternative is an unbuildable mesh — but it introduces a concentrated third party into the authorisation path of a regulated payment service. That belongs in the DORA register of information and in concentration-risk analysis, not only in a vendor file.
The Close Match Is the Whole Problem #
Match and No Match are easy. They map to "continue" and "stop". Close match maps to "you decide", and it is where the control either works or quietly dies.
Real payee names are messy in ways that have nothing to do with fraud. A company trades under a brand and banks under a registered entity. A sole trader's account is in a personal name. Names carry diacritics that the payer's keyboard does not, or legal suffixes the payer omits. Long names are truncated by upstream systems. Two legitimate parties can differ by a comma.
That produces a steady stream of close matches on entirely genuine payments. Each one asks a person to make a judgement they are not equipped to make, at the moment they are trying to finish a task. The failure mode is well understood from every other security warning ever shipped: shown often enough without consequence, it is dismissed reflexively, and when the one that mattered arrives it is dismissed too.
Two design commitments materially change the outcome.
Show the name, not just the verdict. A warning that says "the details do not exactly match" gives the payer nothing to reason with. The scheme's design contemplates returning the name held on the account for close matches precisely so the payer can recognise that "ACME Trading Ltd" and "Acme Trading Limited" are the same counterparty, and that "A. Trading Services" is not.
Make the override deliberate and recorded. The payer's decision after a warning is the most important artefact the interaction produces. It determines who bears a loss. It should be an explicit act, captured with the exact string that was displayed, not an implicit consequence of clicking the same button as always.
Then measure the thing that actually matters. Not the count of warnings raised, but the proportion overridden — and among those, how many were later disputed. A high override rate on genuine payments means the matching is too strict. A high dispute rate among overrides means the warning is not being read.
Bulk Files Broke the Model, and the Opt-Out Became the Control #
Retail single payments were never the hard case. Corporate payment files were.
A corporate customer submits a payment file — commonly a pain.001 — containing hundreds or thousands of credit transfers. Verification does not operate on files. It operates on payees. The bank must therefore de-bulk the file, raise a request per line, and collect answers, each subject to the same five-second ceiling, before the file can be released. The scheme's own clarifications on bulk provision exist because this was not obvious from the regulation text.
The regulation anticipated the pressure. Non-consumer payment service users may opt out of receiving the verification service when submitting multiple payment orders as a package, and may opt back in. That single provision now carries an outsized share of the operational load, and it deserves to be treated as a control rather than a convenience.
Two consequences follow for corporate banking teams.
The opt-out is a risk decision made once and inherited thousands of times. A treasurer who waives verification for bulk submission has removed a fraud control from every payment in every future file until the decision is revisited. It should carry the review cadence of a mandate change, with a named owner, an expiry, and a periodic re-attestation — not a checkbox set during onboarding and never seen again.
The better answer is upstream. Verification at file submission is the wrong point in the lifecycle: the beneficiary was added to the ERP or treasury system weeks earlier, and that is where a substituted account number does its damage. Running verification at beneficiary onboarding and on any subsequent bank-detail change moves the control to the moment of the change, takes the latency pressure off the payment run entirely, and produces a far smaller volume of checks against a far higher-value decision. Banks that offer beneficiary-level verification as a standing service to corporate clients are solving the actual problem; banks that only verify at submission are solving the deadline.
The Liability Boundary Nobody Drew #
The scheme defines responses. It does not define consequences. That gap is where the next several years of argument will sit.
Consider the sequence that is now routine. A bank raises a close-match warning. The payer proceeds. The money goes to a fraudster. The bank performed its obligation precisely and can evidence it. The payer says the warning was ambiguous and that they were not told what was actually wrong.
Both positions are defensible, which is the problem. The regulation obliges the service and, where a PSP fails to provide it, contemplates consequences for resulting loss. It does not settle the case where the service worked, the warning was shown, and the human made the wrong call. National implementations, ombudsman decisions and — over time — case law will settle it unevenly across the Member States.
Three things follow for institutions that would rather shape that outcome than receive it.
Evidence quality is the defence. Not "a warning was displayed" but the exact string, the response type received, the timestamp, and the payer's action, retained for the full dispute window and retrievable by a complaints handler without an engineering ticket.
Warning quality is the other defence. An institution whose close-match warnings are specific and legible is in a materially stronger position than one whose warnings are generic. The same override, in front of the same adjudicator, reads differently depending on what the payer was actually shown.
The corporate opt-out needs a paper trail. When a bulk file is submitted with verification waived and a payment in it goes wrong, the question will be whether the customer understood what they waived. A dated, attributed, re-attested record answers that question. An onboarding checkbox does not.
The Operating Playbook #
For institutions already live, the work now is consolidation rather than delivery.
- Instrument the middle. Report close-match rate, override rate, and disputed-override rate as a monthly series, segmented by channel and by customer type. These three numbers tell you whether the control is working; volume of checks does not.
- Treat the RVM as a critical third party. It sits in the authorisation path. It needs exit planning, substitutability analysis, and incident-response integration on the same footing as any other critical provider.
- Design the timeout path deliberately. Decide, and document, whether a "verification not possible" outcome blocks, warns, or proceeds, per channel and per value band. Defaulting to silence is a decision made by omission.
- Move corporate verification upstream. Offer beneficiary-onboarding and bank-detail-change verification as a standing service. It reduces payment-run latency, improves the control, and is a genuine commercial proposition in a regulation that otherwise forbids charging.
- Re-attest every bulk opt-out. Put an expiry on it. Name an owner. Make renewal a decision rather than an absence of one.
- Prepare for the non-euro tranche. Providers outside the euro area come into scope on a later timetable running into 2027. Institutions operating across both should be building one capability, not two.
The regulation removed the choice about whether to verify. What remains is entirely a question of how well — and the difference between an implementation that reduces fraud and one that merely satisfies an auditor is visible in three places: the close-match screen, the bulk opt-out register, and the evidence trail behind an override.
Frequently Asked Questions #
Does Verification of Payee apply only to instant payments?
No. Although the requirement was introduced through the Instant Payments Regulation, the verification duty attaches to credit transfers in scope generally, including standard SEPA credit transfers, not only to SCT Inst. Programmes scoped to instant payments alone underestimated the integration surface.
Can a bank charge for Verification of Payee?
Not to the payer for the service required by Article 5c — the regulation requires it free of charge. Adjacent services that go beyond the obligation, such as verifying beneficiaries at onboarding or on bank-detail change for corporate clients, sit outside that constraint and are where a commercial proposition legitimately exists.
What happens if the responding institution does not answer in time?
The scheme sets a maximum of five seconds for the requesting PSP to obtain a response. A timeout produces a "verification not possible" outcome, which is a defined result the payer must be told about, not an internal error to be suppressed. Each institution must decide, per channel, whether that outcome blocks, warns, or proceeds.
Can corporate customers switch the check off for bulk files?
Yes. The regulation permits payment service users who are not consumers to opt out of the service when submitting multiple payment orders as a package, and to opt back in. Because that waiver then applies to every payment in every subsequent file, it should be governed as a standing risk decision with an owner, an expiry and periodic re-attestation.
Does a close-match warning transfer liability to the payer?
Not automatically, and not uniformly. The regulation obliges the service; it does not resolve the case where the warning was shown and the payer proceeded anyway. Outcomes will be settled by national implementation, ombudsman practice and case law. The institutions in the strongest position are those that can produce the exact warning text shown, the response type received and the payer's recorded action.
References #
- European Parliament and Council of the European Union, 2024. Regulation (EU) 2024/886 amending Regulations (EU) No 260/2012 and (EU) 2021/1230 as regards instant credit transfers in euro. Brussels: Official Journal of the European Union. Available at: European Parliament and Council of the European Union, 2024..
- European Central Bank, 2026. Instant Payments Regulation. Frankfurt am Main: European Central Bank. Available at: European Central Bank, 2026..
- European Commission, 2025. Clarification of requirements of the Instant Payments Regulation. Brussels: Directorate-General for Financial Stability, Financial Services and Capital Markets Union. Available at: European Commission, 2025..
- European Payments Council, 2025. Verification of Payee scheme. Brussels: EPC. Available at: European Payments Council, 2025..
- European Payments Council, 2025. Verification of Payee scheme rulebook — frequently asked questions. Brussels: EPC. Available at: European Payments Council, 2025..
- European Payments Council, 2025. Clarifications about the provision of VOP services for bulk files. Brussels: EPC. Available at: European Payments Council, 2025..
- European Payments Council, 2025. Routing and/or Verification Mechanisms for the Verification of Payee scheme. Brussels: EPC. Available at: European Payments Council, 2025..
Last reviewed .