This is part 1 of a 3-part blog series on Verification of Payee (VoP).
Verification of Payee is live. Your bank has sent the compliance notification. Your treasury team has worked through the configuration requirements, and the question of VoP readiness has been ticked off the risk register.
There is a reasonable assumption forming in a lot of corporate treasury functions right now: that VoP compliance and payment fraud protection are roughly the same thing. They are not. And the gap between them is where the most sophisticated payment fraud currently operates.
This is not a criticism of VoP, but is more about setting the right expectations. VoP solves a specific problem and it does that well. But it does not do everything that its messaging might imply.
What is Verification of Payee (VoP)?
VoP is a messaging framework between Payment Service Providers. When your bank sends a payment instruction, it queries the payee’s bank with a name and an IBAN. The payee’s bank checks whether those two pieces of information match what it holds on file, and returns one of four responses: Match, Close Match, No Match, or Verification Not Possible.
That is the entire scope of the check – that is all the check it is designed to do.
VoP does not verify that the underlying commercial transaction is legitimate. It does not screen the payee against sanctions lists or AML databases. It does not check whether the bank account was opened fraudulently. It does not validate the invoice. It does not assess whether this payment is consistent with your historical payment behaviour to this supplier.
The European Payments Council has been explicit about this: VoP is not a fraud prevention mechanism. It is a payee confirmation mechanism. The distinction matters enormously in practice. In short, VoP tells you that the name and account number match at the payee’s bank. It says nothing about whether you should be making this payment in the first place.
The three fraud scenarios VoP was never designed to stop
Business Email Compromise
According to 2025 AFP Payments Fraud and Control Survey Report, BEC remains the dominant corporate payment fraud vector globally. VoP does not address this avenue. In a typical BEC attack, a fraudster intercepts communication between a corporate and a supplier — often by compromising an email account — and substitutes fraudulent payment instructions. The key detail: sophisticated BEC attacks now include a new IBAN and a name that matches the legal entity name of the genuine supplier.
The attacker opens a bank account under the legitimate supplier’s name — or very close to it — in advance. When your VoP check runs, it is likely to return a Match. The money moves. The fact that the account belongs to a fraudster is invisible to the system.
Insider-modified vendor records
VoP validates the name and IBAN that appear in the payment instruction your system sends. It has no visibility into what happened inside your systems before that instruction was formed.
If a vendor master record has been tampered with — by an insider, or as a result of a system compromise — the fraudulent details will pass the VoP check cleanly. The bank sees a Match between what it was sent and what it holds on file. What it was sent is wrong, but VoP has no way to know that.
This is sometimes described as “garbage in, validated garbage out.” The VoP check is only as reliable as the data upstream of it.
Complicit or fraudulently-opened accounts
In increasingly sophisticated fraud schemes, attackers prepare accounts in advance. They open a bank account using either real identity documents or synthetic identity fraud, in a name that closely matches a target supplier. When they intercept a payment instruction, they substitute the IBAN of their prepared account.
The VoP check queries the bank holding that account. The bank returns a Match — because the account holder name does match the IBAN. The fraud is invisible at the point of the VoP check because the fraudulent account was designed to pass it.
What VoP protects against
VoP is highly effective at catching accidental mismatches — the vendor data errors, typographical inconsistencies, and outdated records described in the previous post in this series. For the majority of payment exceptions, which stem from formatting errors rather than fraud, VoP provides a useful catch before money moves.
It also creates a deterrent effect for opportunistic fraud — cases where a fraudster simply substitutes their own bank details without the sophistication of opening a matching-name account. For those scenarios, VoP will return a No Match and flag the problem.
The issue is that the fraud VoP deters is increasingly not the fraud treasury teams face. The overall threat landscape has evolved beyond what a name and IBAN check can detect.
VoP compliance is the floor, not the ceiling. Treasury teams who treat it as done are leaving significant fraud exposure unaddressed.
What a complete fraud prevention stack looks like
Effective corporate payment fraud prevention requires multiple controls working together. VoP is one layer. It is not a complete answer on its own.
A practical framework has three components:
Layer 1: Pre-execution account validation
Before any payment is authorized, validate that the account exists and that the payee name matches — not from static ERP records, but against live data. This validation should happen at the point of payment submission, before any instruction reaches a bank. It operates independently of the bank’s VoP implementation and provides a consistent check regardless of which bank processes the payment.
Layer 2: Vendor master governance
The integrity of payment data starts in your ERP. Who can update vendor records? What approval is required for account changes? How are changes logged? Without documented controls over vendor master data, no downstream check — including VoP — can be fully trusted.
Layer 3: Behavioural anomaly detection
Pattern-based controls add a layer that neither VoP nor data validation can provide. Flagging unusual payment amounts to established suppliers, new IBANs for vendors with long payment histories, payment requests outside normal approval workflows, or destinations inconsistent with historical transaction patterns. These signals do not prove fraud, but they create intervention points before money moves.
The important point is that these layers are not alternatives. A corporate that has clean vendor data and VoP compliance but no pre-execution validation is still exposed. A corporate with pre-execution validation but no anomaly detection is still exposed. The goal is defence in depth — not the most sophisticated individual control, but a set of controls that together close the gaps none of them can close alone.
Account validation with TIS
Of the three layers, pre-execution account validation is the one most corporates currently have the least answer for.
Vendor master governance is typically owned by AP or procurement, and some form of it exists in most organizations. Behavioural anomaly detection is increasingly embedded in ERP platforms and TMS systems as a feature. But validating that an account is live and the name matches — at the moment of payment, against real banking data, across a global supplier base — is a gap that manual processes and static data cannot reliably fill.
TIS Account Validation is the pre-execution layer that VoP doesn’t cover. It proactively confirms the account exists and the payee name matches, before any payment reaches a bank — across 46 markets. What this does it create zero workflow disruption for your team.
To know more, reach out to TIS team and set up a personalized demo.
