Sending money to the wrong account because a beneficiary name and IBAN don't actually belong together is one of the oldest problems in payments, and one that instant transfers make worse rather than better. Once a SEPA payment settles, it settles. There is no float period to catch a mismatch. Verification of Payee (VOP) is the EU's answer: a name-check that runs before the transfer, not after.

It is easy to confuse VOP with the UK's Confirmation of Payee, because the two schemes solve the same problem. But they sit under different regulatory regimes, different governance bodies, and different rulebooks. For anyone building payment flows that touch both the UK and the eurozone, the differences matter operationally, not just legally.

Why VOP exists

The EU's Instant Payments Regulation requires payment service providers that offer euro credit transfers to also offer instant credit transfers, and to do so at pricing no higher than standard SEPA credit transfers. Instant payments settle in roughly ten seconds, which removes the traditional window where a bank might query an unusual payment before it clears. Verification of Payee is the regulation's built-in safeguard: PSPs must check that the name on the transfer matches the name on the account before the payment is authorised, and flag it to the payer if it does not.

The obligation applies to payment service providers operating within the eurozone, covering both the sending and receiving side of a transaction. It is a scheme-level requirement built into SEPA infrastructure, not an optional add-on that individual banks choose to offer.

What the check actually verifies

VOP compares the payee name entered by the person initiating a payment against the name registered to the IBAN they are paying. The account-holding institution runs the comparison and returns a result before the payment proceeds. This is fundamentally a data-matching exercise, not an identity check or a fraud score. It does not confirm the account is legitimate, only that the name and IBAN combination is consistent with the bank's records.

The comparison logic allows for a degree of tolerance. A payment to "J Andersson" when the account is registered to "Johan Andersson" should register as a close match rather than a failure, because minor variations, abbreviations and transliteration differences are common and shouldn't block genuine payments. Getting this tolerance right is one of the harder engineering problems behind VOP, since too strict a match rejects legitimate payments and too loose a match defeats the purpose.

What happens end to end

The mechanics follow a consistent pattern across providers, though the API implementation differs:

  • The payer enters the beneficiary's IBAN and name, typically inside their bank's app or a payment initiation flow embedded in a merchant platform.
  • The paying institution sends a verification request to the account-holding institution, using the shared messaging standard the scheme defines.
  • The account-holding institution checks the submitted name against its own records for that IBAN.
  • A result is returned: match, close match, no match, or unable to verify (the last typically because the receiving institution hasn't implemented the check, or the account type is out of scope).
  • The paying institution presents that result to the payer before the payment is confirmed. A close match or no match doesn't block the payment outright; it puts the decision back to the person sending the money, with a clear warning.

The entire exchange happens in the seconds before authorisation, which means the underlying messaging has to be fast and highly available. This is one of the reasons VOP is being rolled out alongside instant payments infrastructure rather than as a standalone product: the two need to work at the same speed.

Match outcomes and what they mean in practice

A "match" result gives the payer confidence to proceed without further checks. A "close match" usually surfaces the registered name so the payer can compare it manually against what they expected, which is useful when dealing with business accounts registered under a legal entity name rather than a trading name. A "no match" is a strong signal that something is wrong, either a mistyped IBAN, an out-of-date payee record, or a fraudulent instruction, and most payment flows will require an explicit override before letting the payment through. "Unable to verify" is a gap in coverage rather than a red flag, and platforms need to design their user messaging so customers don't mistake it for a warning.

VOP versus UK Confirmation of Payee

The two schemes share a purpose but differ in scope and governance. Confirmation of Payee sits under Pay.UK and applies to Faster Payments, CHAPS and Bacs. VOP sits under the EU's Instant Payments Regulation and the European Payments Council's scheme rules, and applies specifically to SEPA credit transfers. A platform operating GBP collection accounts identified by sort code and account number, alongside EUR IBAN issuance for eurozone customers, needs to treat these as genuinely separate compliance obligations rather than one feature ported across two markets. The match logic, the response codes, and the messaging requirements are not interchangeable.

This matters more once cross-border payments SWIFT flows enter the picture. A payment leaving the SEPA zone via SWIFT doesn't carry VOP checks with it, since the scheme is specific to SEPA rails. Platforms that route payments across multiple rails need to be explicit with users about where a name check has actually happened and where it hasn't, rather than assuming the same reassurance applies throughout a payment's journey.

What this means for platforms building on top of it

For a fintech building marketplace payouts, client money accounts, or any product that moves euros on behalf of end users, VOP is not a feature you can bolt on later. It sits at the point of payment initiation, and the user experience around match results, overrides and warnings has to be designed into the payment flow from the start.

A common integration mistake is treating every non-match result the same way. Blocking a payment outright on a "close match" frustrates genuine customers, particularly for accounts registered under abbreviated or legal-entity names. The better approach is layered messaging: match proceeds silently, close match surfaces the registered name for a quick human check, no match requires deliberate confirmation with a clear warning. Getting this balance wrong either erodes trust in the check or trains users to click through warnings without reading them, which defeats the point of the scheme entirely.

For platforms working with a BaaS provider for EUR IBAN issuance and euro payment rails, the practical question to ask is not whether VOP is supported, but how match results are surfaced through the API banking platform and how much control the platform has over the warning language shown to its own users. That detail sits underneath payment scheme membership and rarely appears in a feature list, but it shapes how the check actually behaves in production.