Of everything in the Payment Services Regulation, Verification of Payee (VoP) is the provision least worth planning for. Not because it does not matter, but because for most PSPs the deadline has already passed.
The Instant Payments Regulation has required euro-area PSPs to offer verification of payee on every SEPA credit transfer, instant or not, since 9 October 2025. The PSR does not introduce VoP. It absorbs an obligation that is already live into a wider fraud-prevention framework, and attaches liability to getting it wrong.
This article sets out what the check has to do, what it deliberately does not do, and where the liability sits.
The problem VoP solves, and the one it does not
Strong Customer Authentication can establish that the payer is who they claim to be and that they approved the payment. It cannot establish that the payment is going to the person the payer intends to pay.
That gap is precisely where invoice fraud and payee-substitution scams live. The payer genuinely wants to pay their supplier, their landlord, their builder. They authenticate correctly. The IBAN belongs to someone else.
VoP addresses that vulnerability by testing whether the payment account identifier and the information identifying the intended payee correspond, before the payer is offered the possibility of authorising the transfer. The timing is the point. A warning after authorisation is a notification; a warning before it is a control.
The empirical case was strong enough that the Commission treated the extension of IBAN and name verification as one of the most effective fraud-prevention measures it considered, relying particularly on Dutch and UK experience. According to the Dutch provider cited in the impact assessment, introducing the IBAN and name check in 2017 was followed by an 81% reduction in invoice fraud and scams, and a 67% reduction in payments misdirected through payer error.
Three outcomes, not two
It is tempting to think of VoP as a pass-or-fail gate. In practice the interesting case is the middle one.
Figure 1. The VoP check, its three outcomes, and the three things it is not.
A match lets the payer proceed without friction. A clear mismatch produces a warning before authorisation. But a close match, where the name is similar but not identical, has to be surfaced to the payer with enough information for them to decide. Legitimate variation is everywhere: trading names, abbreviations, married names, diacritics, joint accounts.
This is where implementation quality separates from compliance. A system that treats every near-miss as a mismatch trains customers to click through warnings, which destroys the control. A system that treats every near-miss as a match defeats the purpose. The matching logic, and how the result is communicated, is where the fraud-prevention value actually lives.
What VoP is not
The PSR builds a lifecycle of controls that do different jobs, and conflating them is a common analytical error worth avoiding.
VoP does not authenticate the payer. That is SCA under Article 85. VoP does not detect fraud patterns; that is transaction monitoring under Article 83, which draws on behavioural data, device data, and fraud intelligence received from other PSPs. VoP does not stop the payment; that is intervention under Article 65 on the payer side and Article 69 on the payee side.
VoP answers one question, and answers it well: is the money going where the payer thinks it is going?
Who is covered, and from when
The dates are unusually messy because two instruments are involved.
Figure 2. Verification of Payee obligations and their application dates.
The practical consequence for euro-area PSPs is that VoP is not a project on a roadmap. It is a live obligation, and the PSR adds a liability consequence to a control that should already be running.
Where the liability sits
Article 57 is short and pointed. Where a PSP fails to comply with Article 50, and that failure results in a defectively executed payment transaction, the payer’s PSP must without delay refund the payer the amount transferred and, where applicable, restore the debited account.
Read that carefully, because the structure matters. The trigger is not that fraud occurred. The trigger is a failure to comply with the VoP obligation that results in a defective transaction. This is the pattern that runs through the whole PSR: liability attaches to the absence of a control, not only to the presence of a loss.
Article 78 then allows a PSP that has reimbursed a payer to recover from another PSP or intermediary whose failure contributed to the liability. The customer sees one refund from their own provider; the allocation between institutions happens out of sight.
What this means operationally
Three things follow that are easy to underestimate.
First, VoP is a two-sided service. The payer PSP requests, but the payee PSP has to be able to answer, reliably and fast enough not to break the payment flow. Availability and latency become compliance questions, not just engineering ones.
Second, the VoP result is useful beyond the warning. A close match or a mismatch that the payer chose to override is a meaningful risk signal, and Article 83 monitoring is expressly designed to take account of transaction and payee data. A VoP outcome that is shown to the customer and then discarded is a wasted input.
Third, evidence matters. If liability under Article 57 turns on whether the service was provided, then the ability to demonstrate afterwards what was checked, what was returned, what the customer was shown, and what they chose is part of the control rather than an afterthought.
This is part 2 of a four-part series on the PSR and payment fraud.
Next: Who pays when the customer was tricked? PSR reimbursement rules
The full analysis is in our white paper Fraud, redrawn – 23 pages on how the PSR turns fraud prevention from a control into a lifecycle, by Eglė Kontautaitė, former Head of the Money Laundering Prevention Division at the Bank of Lithuania.
The full analysis is in our white paper Fraud, redrawn – 23 pages on how the PSR turns fraud prevention from a control into a lifecycle, by Eglė Kontautaitė, former Head of the Money Laundering Prevention Division at the Bank of Lithuania.
→ Download the full white paper here
