SEPA Instant: verification of payee in practice

The verification-of-payee requirement under the SEPA Instant regulation is now live across all providers offering credit transfers in euro. The design intent is clear: catch mistyped account numbers and social-engineering fraud at the moment of payment initiation. The field pattern in the first ten months is that most integrations handle the happy path fine, and stumble on the ambiguous middle.

Based on field notes from client reviews April–August 2026; written August 2026.

The three states

The result of a VoP check has three states worth modelling explicitly:

• Match — the account name matches what the sender entered.
• Close match — the check returned a similar name (e.g. missing middle initial).
• No match — either the name doesn't correspond, or the check failed.

The "close match" state is where integrations vary most. Some banks show it to the customer; others silently treat it as a match. The regulation gives room for either, and both are defensible — but the resulting user experience is inconsistent across banks.

The false-negative problem

Corporate accounts, joint accounts, and accounts held under a legal name that differs from the trading name produce far more "no match" results than the design assumes. Merchants operating under trading names are the worst-affected. Some banks handle this via a dedicated business register lookup; others don't.

What to do about it

• Treat "close match" as a first-class UX state in your payment initiation flow.
• If you handle B2B payments, register the trading name variants that your customers use.
• Log the raw VoP response verbatim — the argument you'll eventually have with the bank starts there.