Verification of Payee is one of the most praised anti-fraud tools in EU payments law. Under Regulation (EU) 2024/886 (IPR – Instant Payment Regulation), payment service providers must offer payers a service that checks whether the payee’s name corresponds to the payment account identifier before a euro credit transfer is authorised. Although introduced through the instant payments reform, the obligation is not limited to instant payments; it applies to both standard and instant credit transfers. DG FISMA’s (Commission Directorate-General for Financial Stability, Financial Services and Capital Markets Union) implementation clarifications expressly state that the service must be provided for every credit transfer, including instant and non-instant credit transfers, before the payer is offered the possibility of authorising the transfer. The clarifications also state that PSPs are not allowed to use the VoP service as a reason to reject a credit transfer on suspicion of fraud.
The current PSR/PSD3 compromise goes further by embedding this mechanism into a broader EU payments framework. It aligns the verification service for credit transfers that are not already covered by Regulation (EU) 2024/886 and connects it to broader fraud-prevention, transaction-monitoring, and liability obligations. The result is a more coherent framework, but not a complete anti-fraud architecture.
Verification of Payee is often presented as a major step forward for fraud prevention. In reality, however, it is only one tool in a much larger risk landscape. It can help prevent some authorised push payment fraud cases, but it is certainly not a general solution for investment scams, mule networks, vIBAN structures or money-laundering-as-a-service models.
Current legal framework
The purpose of Verification of Payee is straightforward: if a payer enters a name that does not correspond to the account holder associated with the IBAN or another payment account identifier, the payer receives a warning before authorising the transfer. In practical terms, the control is designed to detect a mismatch between the payee information entered by the payer and the account data held by the payee’s PSP.
That matters, but it also defines the limit of the tool. Verification of Payee is a name-and-identifier matching mechanism. It is not a full fraud assessment. It does not determine whether the payment purpose is legitimate, whether the receiving account is a mule account, whether the beneficiary has been properly onboarded, whether the transaction fits the customer profile, or whether the payment chain is part of a wider laundering structure.
For legal persons, the matching service may also rely on another data element, such as a fiscal number, a European unique identifier or a legal entity identifier, provided that the payer can submit that data element and it is available in the payee PSP’s internal systems. This does not change the basic nature of the tool. It verifies correspondence between account data and payee information; it does not assess the legitimacy of the transaction.
A further distinction is important. The legal framework separates three different functions. First, the payer’s PSP should verify the coherence of the unique identifier and refuse the payment order where the identifier is incoherent and execution is therefore not possible. Second, Verification of Payee checks whether payee information corresponds to the account identifier and informs the payer. Third, fraud monitoring assesses whether the transaction is suspicious on the basis of transaction monitoring or other relevant information. These functions must not be collapsed into one another. A coherent IBAN or vIBAN is not proof of a legitimate payment chain, and a VoP warning is not proof that PSPs fulfilled their anti-fraud duties.
Where it helps
Payee Verification is said to be most effective where criminals rely on name manipulation. That includes invoice fraud, business email compromise, impersonation scams, and certain forms of authorised push payment fraud. In those cases, a mismatch warning can interrupt the payment flow long enough for the victim to realise that something is wrong.
For consumers, this can be valuable. For businesses, it can stop fraudulent supplier changes or altered payment instructions. In this sense, the control has real preventive value and should be seen as a helpful friction point rather than a cosmetic feature.
The scope of the framework also matters. The PSR compromise text excludes payment transactions with electronic money tokens from the Verification of Payee and related liability provisions at this stage, while providing for a later review of whether those requirements should be extended to such transactions. This does not change the analysis for euro credit transfers, but it highlights a broader regulatory risk: as controls on traditional payment rails become stronger, fraud and laundering networks may seek alternative channels not subject to the same payee-verification architecture.
Why the “fraud tool” label is misleading
Verification of Payee is often described as an anti-fraud tool, but that label requires careful qualification. In a broad political sense, the label is understandable: a warning that prevents a payer from sending money to the wrong account can prevent fraud losses. But in a stricter legal and operational sense, VoP is not a fraud-blocking tool. It is a payer-facing accuracy warning.
DG FISMA’s implementation clarification on the IPR is clear on this point. The IPR does not contain specific rules allowing the rejection of an instant credit transfer merely because of fraud suspicion. The payee verification service gives the payer information about whether the payee name and IBAN match; the payer then decides whether to proceed.
The current PSR compromise text moves beyond this position, but it still confirms the same conceptual separation. The outcome of the payee-verification service may be a relevant element in fraud monitoring, but it should not in itself be the sole ground for refusing to execute a payment transaction. Where there are objectively justified reasons to suspect fraud, the relevant basis is not VoP alone, but transaction monitoring or other relevant information.
This creates a serious policy tension. Verification of Payee cannot be legally too weak to stop a suspicious payment, but legally strong enough to absolve PSPs after the scam has succeeded. A VoP result is one data point. It is not a fraud investigation, not proof of a clean payment chain, and not a weiver of institutional duties.
The structural limits
The main weakness is simple: many fraud and money laundering models do not depend on a false payee name at all. In EFRI’s experience, investment scam networks and their monetisation chains use correctly named accounts that are controlled by mules, shell entities, or professional laundering operators. In those cases, Payee Verification sees no mismatch, even though the transfer is still part of a criminal scheme.
That is why the mechanism is much better at catching misdirection than it is at disrupting organised fraud infrastructure. If the account holder’s name matches the IBAN, the system may look clean while the underlying beneficiary is still fully compromised. This is also why Payee Verification should not be presented as a fraud-fighting breakthrough; it is primarily a screening tool, not a substitute for KYC, transaction monitoring, or suspicious activity controls.
This limitation is particularly relevant for virtual IBANs, pooled accounts, master-account structures and payment-institution models. The EBA has warned that virtual IBANs may have the same format and functionality as standard IBANs, making them indistinguishable to third parties, while being linked to a separate master account. It has also identified money-laundering and terrorist-financing risks in which end users of vIBANs may be unknown to PSPs, including counterparty PSPs, thereby weakening transaction monitoring and supervisory visibility.
The PSR compromise text would expressly recognise virtual IBANs as valid payment account identifiers where the use of an IBAN is required, while also acknowledging the risks and challenges posed by vIBANs, including from an anti-money-laundering perspective. Formal recognition of vIBANs increases legal certainty, but it does not remove the need for transparency around the underlying master account, the end user, the economic beneficiary and the payment flow.
This is why Verification of Payee should not be presented as a fraud-fighting breakthrough. It is primarily a screening tool, not a substitute for KYC, transaction monitoring, suspicious activity controls, beneficiary-side intervention or transparency around vIBAN and master-account structures.
EFRI's practical experience
EFRI’s case work strongly suggests that the dominant problem in investment scams is not a wrong payee name, but a payment chain that is structurally built to pass through regulated institutions without being stopped. EFRI case files document failures in onboarding, merchant screening, transaction monitoring, MCC governance, vIBAN intransparency and beneficiary-side intervention across multiple institutions.
That experience supports a narrower and more realistic reading of Payee Verification. It may help prevent some losses at the edge, but it does not address the core mechanics of pig-butchering scams, mule-account networks, or payment-company enablement. In those scenarios, the real preventive levers are upstream controls, faster freezes, better data sharing, and stronger accountability for institutions that process suspicious flows.
In practical terms, EFRI’s experience also suggests that money-laundering-as-a-service will adapt very quickly to this type of control. Once payee verification becomes a standard feature of the payment flow, professional laundering networks will adjust their onboarding, account structures, identity overlays, and cash-out paths accordingly. The control may therefore force criminals to refine the network architecture they use, but it will not eliminate the underlying
monetisation model; instead, it is likely to become another cost factor that MLaaS providers build into their business logic and sell as part of a more resilient fraud infrastructure.
The real regulatory battleground is not the existence of Payee Verification, but what happens after and around it: whether the receiving PSP monitors inbound flows, whether suspicious funds are made available, whether mule accounts are frozen quickly, whether vIBAN and master-account structures are transparent, and whether PSPs face liability when they process objectively suspicious fraud flows.
A mismatch alone is not a fraud finding and should not in itself be the sole ground for refusing a payment. However, it is a relevant risk signal. Where a mismatch is combined with transaction-monitoring alerts or other relevant information, such as unusual customer behaviour, a new high-risk beneficiary, repeated payments by unrelated consumers, mule-account indicators, vIBAN opacity, prior fraud reports or rapid onward transfers, the issue is no longer VoP alone. The PSP must then assess whether there are objectively justified reasons to suspect fraud and act under its separate fraud-monitoring, AML, suspension, freeze or return obligations.
The over-warning problem
A second concern is over-warning. If banks warn too often, users quickly become numb to the alerts, especially in ordinary private transfers where legitimate name variants, middle names, hyphenations, or spelling differences are common. Once users start seeing warnings as routine noise, the protective effect weakens, and payment service providers will be quick to shift the blame to the consumer.
The PSR compromise text itself recognises the practical problem. It refers to diacritics, transliteration, differences between habitually used names and formal identification names, and differences between commercial and legal names. For close matches, PSPs should indicate the payee name associated with the IBAN or other unique identifier in a manner compliant with data-protection law.
This is not only a technical or user-experience issue. It is also a liability issue. A generic Verification of Payee warning must not become a liability shield for PSPs. The technical challenge is therefore not simply to detect mismatches, but to reduce false positives through better alias handling, smarter fuzzy matching and risk-based thresholds, so that the warning signal remains credible and does not become background noise.
Technically, over-warning can be reduced through better data and smarter matching. Banks should use verified alias lists, commercial-name handling and structured name enrichment so that common legitimate variations do not automatically trigger warnings. DG FISMA has itself recognised that collecting commercial names of payees can be key to minimising false “no match” notifications.
However, false-positive reduction must not be achieved through silent circumvention of the legal requirement. The IPR requires VoP for every credit transfer, including instant and non-instant credit transfers. For ordinary single payment orders, the answer to over-warning cannot be a general whitelist that bypasses VoP. The answer must be better matching, verified commercial-name data, calibrated notification design and contextual risk scoring.
Flexible matching must also be implemented carefully. Alias handling should be based on verified, documented and auditable data. Otherwise, shell entities, mule companies or payment facilitators may try to exploit loose matching logic by using trading names, informal aliases or misleading platform names that appear close enough to pass verification.
The goal should be to keep the warning meaningful. If every routine transfer produces the same alert, users stop paying attention and the control becomes ceremonial rather than preventive.
The liability-shield risk
The most important legal risk is that Verification of Payee may be used by payment service providers as a new liability shield. This risk is not theoretical. The current framework already contains a specific liability consequence: where a PSP has fulfilled its obligations under Article 5c, it is not liable for the execution of a credit transfer to an unintended payee due to an incorrect unique identifier. DG FISMA confirms this position.
That rule may be understandable in a narrow misdirection scenario. If a payer enters the wrong IBAN, receives a clear mismatch warning, and nevertheless authorises the payment, the payer’s PSP may have a strong defence against liability for that specific error.
The PSR compromise text also confirms the reverse situation: where the matching verification service is not provided, is provided incorrectly or malfunctions, and this results in a defectively executed payment transaction, the payer’s PSP must refund the payer. If the failure is attributable to the payee’s PSP or a payment initiation service provider, that institution must compensate the payer’s PSP.
This confirms the limited legal function of VoP. It is intended to reduce ill-informed payment authorisations by giving the payer accurate matching information. It is not a full fraud assessment and it is not a substitute for institutional anti-fraud duties.
A Verification of Payee warning does not prove that the consumer understood the fraud. It does not prove that the payment chain was clean. It does not prove that the receiving institution had properly onboarded the account holder. It does not prove that transaction monitoring worked. It does not prove that the account was not a mule account, a shell-company account or a vIBAN structure used for criminal monetisation.
In investment scam cases, the legally relevant question should not end with whether a warning appeared on the payer’s screen. The real questions are broader: Who opened the receiving account? Was the account holder properly identified and risk-assessed? Were incoming flows consistent with the customer profile? Were multiple victims sending funds to the same account? Were funds rapidly forwarded, exchanged, split or cashed out? Did the receiving PSP, EMI, PI, acquirer or merchant service provider ignore obvious red flags?
The PSR compromise text moves in that direction. It introduces payer-side suspension duties and payee-side intervention duties where objectively justified fraud indicators arise from transaction monitoring or other relevant information. For the payer’s PSP, the text provides for suspension where fraud suspicion is objectively justified and not based solely on the VoP outcome. For the payee’s PSP, it provides that where there are objectively justified reasons to suspect that a payment credited or to be credited to the payee’s account is fraudulent, the PSP may decide not to make the funds available and return them; where the reasons are clear and incontrovertible, it shall not make the funds available and shall return them.
That policy direction is incompatible with a broad “the customer clicked through the warning” defence. A VoP notification should be evidence of one control step. It should not extinguish claims based on defective onboarding, deficient merchant screening, poor AML controls, ignored mule-account indicators, vIBAN opacity, delayed freezes or failure to act on suspicious inbound and outbound flows.
Verification of Payee must therefore not become the new legal escape route for institutions that process scam money. A bank or payment institution should not be able to rely on a consumer-facing warning while ignoring its own institutional role in enabling, receiving, processing or forwarding suspicious funds.
EFRI's view
Payee Verification is useful, but it should be described honestly. It can reduce misdirected transfers and catch some types of authorised fraud, yet it does not solve the deeper problem of organised payment fraud or laundering. Its success depends on careful calibration, because too many false positives will generate warning fatigue and reduce the credibility of the system.
A consumer-facing warning cannot cleanse a suspicious payment chain. It cannot cure defective onboarding. It cannot legitimise mule accounts. It cannot excuse poor transaction monitoring. It cannot replace freeze and recall mechanisms. And it cannot absolve receiving institutions that make criminal proceeds available despite objectively suspicious patterns.
If the EU wants real consumer protection, it must combine payee checking with stronger liability allocation, better onboarding, real-time transaction monitoring, effective freeze and recall powers, transparency around vIBAN and master-account structures, meaningful cross-sector data sharing and enforcement against institutions that repeatedly process suspicious flows.
Verification of Payee should help protect consumers. It must not become another procedural tool for blaming them after the fraud has succeeded.
