How Verification of Payee works
From the moment a payer types a name and IBAN to the answer on screen — the complete Verification of Payee flow, the EPC scheme request, and the four outcomes that come back in under a second.
A real-time question between two banks
Verification of Payee works by turning the payer's bank and the payee's bank into two ends of a single, real-time question: does this name belong to this IBAN?
The exchange happens through the EPC Verification of Payee scheme over standardised APIs, so it slots into the existing payment flow without changing how people pay. The whole round trip completes before the payer authorises the transfer.
The result is always one of four standardised outcomes, so the payer — or the system initiating a batch of payments — gets an unambiguous signal every time.
Verification of Payee, step by step
Four stages, completed in real time between the requesting and responding payment service providers.
- 1
Capture name + IBAN
The payer enters (or imports from an invoice) the payee name and IBAN, exactly as for a normal SEPA credit transfer.
- 2
Route to the payee's PSP
The requesting PSP looks up the responding PSP from the IBAN and sends a secure VoP request through the EPC scheme.
- 3
Match at the bank
The responding PSP compares the submitted name against the registered account holder and returns a standardised match result and the responding BIC.
- 4
Show the answer
Match, close match, no match or not available is surfaced to the payer in under a second — before authorisation, never after.
What the check returns
VoP responses are standardised across Europe — each maps to a clear scheme code.
Match (MTCH)
The name matches the account holder. Safe to send with confidence.
Close match (CMTC)
Almost right — the verified name is suggested so the payer can confirm or correct it.
No match (NMTC)
The name does not belong to this IBAN. A strong signal to stop and double-check.
Not available (NOAP)
The payee's bank can't verify right now. The payer decides whether to proceed.
Verification of Payee vs. a manual IBAN check
Why an in-flow, real-time check beats checking names by hand after the fact.
| Capability | Manual / no check | Verification of Payee |
|---|---|---|
| When it happens | After the payment, if at all | Before authorisation, in real time |
| Who answers | Guesswork from the payer | The payee's own bank |
| Speed | Minutes to days | Under a second |
| Result format | Unstructured | Four standardised outcomes |
| Scales to bulk payments | No | Yes — name checks via API |
One flow, many entry points
The same VoP mechanism works wherever a euro credit transfer starts.
Online & mobile banking
Surface the match result inline as the payer reviews a new beneficiary, before they confirm.
Bulk & ERP payments
Verify supplier and payroll IBANs in batch through the API before a payment run is released.
Payment initiation
PISPs and platforms call VoP at initiation so the payer sees a verified name before consenting.
How the check works, answered
The mechanics in plain terms.
It is designed for instant payments and typically returns a result in well under a second, before the payer authorises the transfer — so the payment experience stays fast.
The requesting bank sends the name and IBAN; the responding bank returns a standardised match outcome (and, on a close match, the verified name as a suggestion). Full account-holder details are not exposed.
The name is almost right — a missing middle name, a legal vs trading name, a transliteration. The service can return the verified name so the payer confirms or corrects without guessing.
No. VoP is informative: it gives a clear answer, but the decision to send, fix or stop stays with the payer. That is exactly why it is effective against social-engineering scams.
Yes. Through the API, names and IBANs can be verified in bulk — ideal for treasuries and ERPs checking supplier and payroll details before a payment run.
See Verification of Payee in your flow
Talk to us about the EPC scheme, the API, and going live before your deadline.