IBAN name verification, known formally as Verification of Payee (VoP), checks whether a payee’s name matches the account holder registered on an IBAN and returns one of four results: Match, Close match, No match, or Verification not possible. When the result is anything other than Match, do not release funds until your documented exception workflow runs its course, and always log the VoP request ID and timestamp first. This guide covers the SOPs, regulatory duties, and integration details finance and compliance teams need to comply without slowing down payments.

TL;DR:

Most VoP responses require manual follow-up or secondary verification, especially for Close match or No match results, to prevent incorrect payments.

Liability falls on the PSP if they perform and clearly display the VoP result, but shifts to the payer if the check is not executed or hidden.

Implementing VoP within a structured workflow, including onboarding validation and exception handling, reduces delays and operational risks.

Logging all request IDs, responses, and approval evidence is essential for auditability and dispute resolution, with strict retention policies.

Demivolt offers integrated IBAN validation and VoP with automatic logging, helping to prevent misdirected payments and streamline compliance.

What Does an IBAN Name Verification Check Actually Return?
Who Bears the Liability When Verification of Payee Isn’t a Match?
Building a Workflow That Uses IBAN Name Verification Without Creating Bottlenecks
How Should You Integrate VoP Technically, and What Should You Log?
A Copyable SOP for Treasury and Payment Ops Teams
How Demivolt Applies These IBAN Verification Practices
Try Demivolt’s IBAN Validator Before You Need It
An Editorial Perspective on IBAN Name Verification
Sources

What Does an IBAN Name Verification Check Actually Return?

VoP does not give a simple yes or no. The European Payments Council’s VoP scheme defines four standardized outcomes, and each one triggers different behavior in the payer’s banking interface.

Match: the submitted name corresponds to the account holder on record. Most banking UIs let the payment proceed without a warning.
Close match: there’s a partial correspondence, often a typo, a trading name used instead of a legal name, or a transliteration difference (think “Jonas Petraitis” versus “J. Petraitis”). The UI typically shows the payer the registered name and asks them to confirm before continuing.
No match: the name and IBAN don’t correspond. The payer sees an explicit warning and must actively choose to proceed or cancel.
Verification not possible: the receiving bank can’t respond, often because the account is closed, the PSP isn’t yet part of the scheme, or a technical timeout occurred.

Each response carries structured data your systems should capture: the result code, the request ID, and, where the scheme permits it, the verifying bank’s BIC or account holder name. That data becomes your audit trail if a payment is later disputed.

Who Bears the Liability When Verification of Payee Isn’t a Match?

The Instant Payments Regulation (Regulation (EU) 2024/886) mandates payee name verification for SEPA credit transfers, and it requires the check to run before the payer confirms the transaction. Euro-area payment service providers have staged deadlines through 2025 and into 2026 to support both instant and standard credit transfers under this obligation.

Liability hinges on one question: did the PSP perform the check and display the result clearly?

If a PSP runs VoP and shows the result honestly, and the payer chooses to override a Close match or No match warning anyway, liability generally shifts toward the payer who accepted the risk.
If a PSP fails to run the check, or buries the result where the payer can’t reasonably see it, liability tends to stay with the PSP.

Regulatory reality check: the Bank of Lithuania has mandated real-time IBAN name verification for PSPs operating in Lithuania, with clear display of the outcome before execution. This mirrors the four-outcome standard and shows regulators treating VoP as an operational requirement, not a nice-to-have feature.

Displaying the result isn’t optional window dressing. It’s the mechanism that determines who absorbs the cost of a misdirected payment.

Building a Workflow That Uses IBAN Name Verification Without Creating Bottlenecks

VoP works best when it’s embedded into a workflow rather than bolted on as a one-off check. Structure it around three stages.

Onboarding. Before a payee ever enters your system, validate the IBAN’s structure using the MOD-97 checksum, confirm the BIC through a directory lookup, and store the validation timestamp and source in the payee record. This catches malformed IBANs before you ever spend a VoP request on them.
Pre-payment checks. Run VoP for high-value transfers, newly added payees, and any payee record that’s been edited since the last verified payment. Save the request ID and full response every time, not just when something looks wrong.
Exception handling. Match means proceed. Close match requires a secondary approval plus a documented verification step. No match means hold the payment and verify the payee through an independent channel, such as a phone call to a known contact. Verification not possible needs a defined fallback check and a retry policy rather than an automatic pass-through.

Set an internal service-level target for exception resolution within a reasonable timeframe, and escalate exceptions that remain unresolved beyond this period. Industry feedback to the EBA has flagged inconsistent matching logic across PSPs as a real operational risk, and teams that don’t define internal thresholds tend to suffer “exception fatigue,” where staff start rubber-stamping Close match warnings just to clear a queue.

Pro Tip: Set your Close match approval threshold by transaction value, not just by match confidence. A €50 Close match and a €50,000 Close match warrant very different levels of scrutiny.

How Should You Integrate VoP Technically, and What Should You Log?

A VoP integration typically sends a request containing the payee IBAN, name, and a unique request ID, then receives back a result code, an optional verified name, and the responding bank’s identifier where the scheme allows it. Requests route through directory services, sometimes called the routing/verification mechanism, that identify which PSP holds the target account and forwards the check accordingly.

Handle “verification not possible” and offline responses with a retry policy rather than treating them as silent failures; if a second attempt also comes back inconclusive, fall back to your manual verification process. Data minimization matters here: display the verified name only inside your secure banking interface, never in email or SMS notifications, since that data is sensitive enough to become a phishing vector if leaked.

Response Field	Purpose
Request ID	Unique identifier for tracing and disputes
Result code	Match / Close match / No match / Not applicable
Verified name	Returned only where the scheme permits disclosure
Verifying bank BIC	Identifies the responding institution
Timestamp	Establishes when the check was performed

Monitor latency closely. VoP checks that add more than a second or two of perceptible delay to a payment flow will push users toward skipping optional verification, which defeats the purpose entirely.

A Copyable SOP for Treasury and Payment Ops Teams

Different payment types warrant different rigor. A copyable structure looks like this:

One-off supplier payment: run structural IBAN validation, then VoP. Match proceeds automatically. Anything else pauses for manual review before release.
Bulk payroll run: validate all IBANs at upload, flag any Close match or No match results for individual review, and never let a single exception hold the entire batch.
Vendor record upgrade (say, moving from a one-time payee to a recurring supplier): re-run VoP even if the original onboarding check passed, since account details change more often than most finance teams expect.

For Close match results, require documented evidence, such as a screenshot of the verified name plus a note on the discrepancy, before approval on payments above your internal threshold. For No match, verification must happen through an independent channel: a phone call to a number pulled from a corporate registry, not one supplied by the payee themselves.

Field to Retain	Retention Guidance
VoP request ID	Keep for the life of the business relationship
Timestamp	Retain alongside the transaction record
Result code	Store with the payee profile, not just the transaction
Verifying bank BIC/name	Retain where scheme rules permit disclosure
Approver identity	Required for any override of a non-Match result

Remember that VoP reduces but doesn’t eliminate misdirected-payment fraud. Pair it with invoice verification and purchase-order matching rather than treating a Match result as proof the underlying invoice is legitimate.

How Demivolt Applies These IBAN Verification Practices

Demivolt builds structural IBAN validation and VoP checks directly into its account and payment infrastructure, so every outbound transfer carries a logged result before funds move. Payee records store the validation timestamp, result code, and approver identity automatically, which shortens onboarding and gives your team ready evidence if a payment is ever disputed. Fewer misdirected payments, faster vendor setup, and a clean audit trail come standard rather than bolted on.

Try Demivolt’s IBAN Validator Before You Need It

Structural errors, a transposed digit, a missing check character, cause a meaningful share of the payment failures that VoP later has to catch. Demivolt’s IBAN Validator runs the ISO 13616 structural check first, so obvious formatting mistakes get caught before you ever spend a VoP request on a beneficiary check.

That structural layer complements the operational workflow described above rather than replacing it. Demivolt’s platform pairs the validator with role-based approvals and integrated logging, so every Close match or No match decision carries an approver identity and timestamp automatically, ready for a dispute or a regulatory audit. If your team is still tracking exceptions in a spreadsheet, that gap is where most misdirected payments slip through.

Run a beneficiary IBAN through the free IBAN Validator today, or contact Demivolt if your business needs enterprise-grade VoP integration with audit logging built in from day one.

An Editorial Perspective on IBAN Name Verification

Most teams treat VoP as a compliance checkbox instead of a fraud control with teeth. That’s backwards. The regulation exists because misdirected payments were already costing businesses real money, and a Match result feels reassuring right up until someone treats it as proof the invoice behind it is legitimate. It isn’t. The operational discipline of logging every request ID and enforcing your own Close match thresholds matters more than the regulatory deadline itself.

— dd

Sources

Regulatory text on Regulation (EU) 2024/886, the EPC’s VoP scheme documentation, and the Bank of Lithuania’s implementation guidance cover the legal and technical basis for this playbook.

Avoid Misdirected Payments: 3 Stage IBAN Name Verification for EU Teams

Table of Contents