IBAN name match, formally called Verification of Payee (VoP), is a real-time check that compares the beneficiary name a payer enters against the bank's record for that IBAN before a transfer settles. The check returns one of four outcomes: a full match; a close or partial match with a suggested correction; no match; or a "verification not possible" flag when the receiving bank can't confirm either way. When a warning appears, the payer decides whether to cancel, fix the name, or proceed anyway.
TL;DR:
- IBAN name match checks are mandatory for SEPA payments, helping prevent invoice fraud by verifying beneficiary names before transfer authorization.
- The verification process returns one of four codes: exact match, close match with suggestion, no match, or verification not possible, influencing payer decisions.
- Banks and payment providers can only share limited matching information due to privacy, and close matches often involve suggested corrections based on bank policies.
- Cross-border matches rely on normalization, making close matches common, but inconclusive results require secondary verification for names from non-Latin scripts.
- Implementing early verification and cleaning supplier data reduces warning rates, streamlines batch payments, and minimizes manual review and incorrect transfers.
Table of Contents
- Why VoP Exists: The Regulation Behind IBAN Name Checks
- Who Actually Has to Deal With This
- Inside a Verification Request: Match Codes and API Behavior
- How Strict Is the Matching, Really?
- Cross-Border Payments and SEPA Edge Cases
- A Practical Checklist for Finance Teams
- What the Numbers Look Like in Practice
- What Actually Matters When You Roll This Out
- Verify Payees Without Slowing Down Your Payment Runs
- Where to Verify the Rules Yourself
- Sources
- FAQ
Why VoP Exists: The Regulation Behind IBAN Name Checks
The push for mandatory payee verification comes from the EU's Instant Payments Regulation, which required payment service providers to offer Verification of Payee checks alongside instant SEPA credit transfers. The scheme applies to digital transfers made between SEPA countries, covering both instant and standard credit transfers processed through participating banks.
The stated goal is straightforward: cut down on invoice fraud and misdirected payments. A huge share of business email compromise scams work by convincing an employee to change a supplier's bank details, and a name check catches that switch before the money leaves the account. The EPC's Verification Of Payee specification standardizes how banks across the scheme communicate match results, so a check run through one bank's app behaves consistently with a check run through another.
There's a privacy layer built into the design, too. When a close match happens, the responding bank isn't obligated to reveal the actual account holder's name. It can return a generic warning instead of exposing personal data tied to someone else's account, which keeps the system from becoming a tool for looking up strangers' banking details.
Who Actually Has to Deal With This
VoP touches more roles than most finance teams expect at first.
- Payers enter the beneficiary's legal name exactly as it appears on the account and respond to any warning before the payment proceeds.
- Recipients and suppliers need invoices and remittance details that match their own registered account-holder name, since a mismatch triggers a warning on the payer's side, not theirs.
- Banks and payment service providers run the actual check, format the response, and decide how much detail to surface when a close match occurs.
- ERP and payment software vendors have to rebuild batch and bulk-payment flows so a single flagged line doesn't halt an entire payment run, and address books need a field for the verified name.
Batch and single payments both fall under the same rules. BNG bank's description of the IBAN Name Check confirms the check applies to bulk files as well as one-off transfers, and it operates within GDPR limits on how matched names get stored and shared.
Inside a Verification Request: Match Codes and API Behavior
A VoP check is a request/response exchange. The payer's bank sends the beneficiary name and IBAN to the receiving bank's VoP endpoint, and that bank returns a standardized reason code almost instantly.
The EPC's VOP API specification defines four core codes:
- MTCH — the name matches the account record exactly.
- CMTC — a close match; the response may include a suggested name if the responding bank allows it.
- NMTC — no match between the submitted name and the account holder.
- NOAP — verification wasn't possible, often because the account or bank isn't part of the checking scheme yet.
On the technical side, a successful request typically returns an HTTP 200 with the reason code embedded in the payload, while malformed requests or unavailable services return standard 4xx or 5xx errors. That distinction matters for anyone building automated payment flows: a 5xx means try again later, while an NMTC inside a 200 response means stop and review.
For everyday banking customers, this plays out as a pop-up warning in an internet banking app before a transfer confirms. For accounts payable teams running a batch of 200 supplier payments, the same codes get parsed programmatically, and only the flagged lines need a human to look at them. The EPC's own guidance notes that standardized codes make it practical to auto-approve MTCH results while routing NMTC straight to manual review.
How Strict Is the Matching, Really?
Matching engines don't demand character-for-character identity. They normalize for diacritics, common abbreviations, word order, and legal suffixes like "Ltd." or "GmbH" before comparing strings. A submission of "J. Martinez Consulting" against an account registered as "Jose Martinez Consulting Ltd" will often come back as a close match rather than a flat no match, because the underlying name components still line up.
What varies is how much the bank tells you about why it flagged something. The Dutch Payments Association's IBAN Name Check description explains that a close match can surface a suggested correction, but only when the responding bank's privacy settings permit it. Some banks show you the likely correct name; others just say "this doesn't quite match" and leave you to verify through another channel.
Either way, the responsibility for the final call sits with the payer. ABN AMRO's own explanation of its IBAN Name Check is explicit that the bank can suggest a fix for a likely typo, but the customer decides whether to proceed, correct the name, or cancel the transfer entirely.
Cross-Border Payments and SEPA Edge Cases
VoP applies across SEPA countries for digital euro transfers, which means a payment from a French business to a supplier in Portugal goes through the same match logic as a domestic transfer. The gaps show up at the edges: brand-new accounts that haven't propagated into a bank's directory yet, certain business or institutional account types, and banks still ramping up their VoP infrastructure all tend to return NOAP rather than a clean match or mismatch.
Transliteration adds another wrinkle for cross-border supplier onboarding, particularly for names originating outside the Latin alphabet. When verification comes back inconclusive, confirm the account details through a second channel, like a phone call to a known supplier contact, rather than treating a NOAP result as a green light.
A Practical Checklist for Finance Teams
Reducing warning rates starts long before a payment run, not during it.
- Clean up supplier master data first. Match the legal name field in your ERP exactly to what the bank has on file, not to whatever appeared on the original invoice.
- Run verification ahead of the payment run, not during it, whether that's a single check or a bulk CSV upload covering hundreds of suppliers at once.
- Route unmatched or close-match results into a separate review queue instead of letting them stall the entire batch.
- Require written supplier confirmation for any exception before overriding a warning and sending the payment anyway.
- Store the verified name-and-IBAN pair alongside the payment record so reconciliation doesn't require re-checking the same supplier next month.
- Track your warning rate and manual intervention time month over month; a shrinking exception queue is the clearest sign your supplier data is improving.
Pro Tip: Run a one-time bulk verification against your entire existing supplier file before your first live payment run under VoP. Most of the "warnings" finance teams see in week one are years-old data errors, not new fraud attempts, and clearing them up front saves your AP team from firefighting during actual payment cycles.
Shifting effort earlier in the process, from post-payment reconciliation to pre-payment verification, is the entire point of the Dutch Payments Association's approach to name checking, and it's the same logic tax teams apply when running TIN matching before filing rather than after a rejection.
What the Numbers Look Like in Practice
Vopify has processed over 10,000 verifications across 20 Eurozone countries, with checks returning results in under two seconds. That speed matters operationally: a check that takes ten seconds might be fine for a single wire, but it breaks down fast when an AP team is clearing a batch of 500 supplier payments before a Friday cutoff.
Vopify's IBAN and bank account verification tool supports single lookups for one-off payments and CSV uploads for bulk supplier checks, with results surfaced through a dashboard rather than buried in a bank's own interface. For finance teams juggling suppliers across multiple banking relationships, that centralizes verification instead of relying on whatever check each individual bank happens to expose. The expected payoff is fewer misdirected payments and less time spent on manual reconciliation after the fact, though results vary by how clean a company's existing supplier data already is going in.
What Actually Matters When You Roll This Out
Most teams overinvest in picking the "right" verification tool and underinvest in cleaning supplier master data first, which is exactly backwards. A pilot on your highest-value supplier segment, run before a full switch, tells you more about your real exception rate than any vendor's feature list. Expect exceptions to spike briefly right after rollout. That's old bad data surfacing, not a sign the system is broken, and it settles down within a few payment cycles. Measure success by counting prevented misdirected payments and the drop in hours spent chasing investigations, not by how few warnings you see in week one.
— David
Verify Payees Without Slowing Down Your Payment Runs
Vopify checks a name against an IBAN in real time, without contracts or lengthy onboarding, so an AP team can confirm a supplier before a payment goes out rather than after it bounces back. Where a bank's own VoP check might only cover your existing account relationships, Vopify's Verification of Payee service extends coverage across SEPA and beyond, with results back in under two seconds whether you're checking one payment or an entire supplier file.
The pricing model involves purchasing verification credits or subscribing to a monthly plan, with API access planned for teams that want to build verification directly into their payment pipeline. If your AP process still relies on manually eyeballing supplier details before a payment run, start with a single verification check on your next batch and see how many exceptions surface.
Where to Verify the Rules Yourself
For implementation details, consult the EPC's Verification Of Payee API specification and bank references like the Dutch Payments Association's IBAN Name Check page. For securing verification data, the NIST Cybersecurity Framework offers relevant controls.
Sources
- IBAN-Name Check - Dutch Payments Association
- IBAN Name Check - ABN AMRO
- NIST Cybersecurity Framework
FAQ
How Do I Check if an IBAN Name Matches?
Enter the beneficiary's name and IBAN into your bank's payment form or a dedicated verification tool; the system returns a match, close match, no match, or "not verifiable" result before the payment confirms.
What Is an IBAN Name?
It's the legal name of the account holder as registered with the bank, which must correspond to the IBAN for a Verification of Payee check to return a full match.
Do US Banks Use IBAN Numbers?
No, US banks use routing and account numbers instead of IBANs; IBAN is a European and international standard used primarily for SEPA and other cross-border transfers outside the US domestic system.
Is an IBAN the Same as a SWIFT Code?
No, an IBAN identifies a specific bank account, while a SWIFT/BIC code identifies the bank or financial institution itself; international transfers often require both.