Verification of Payee Simulator
Play the Responding PSP in the EPC Verification Of Payee scheme: enter the payee name a payer typed, the IBAN, and what the account-holding PSP has on file, and get MTCH / CMTC / NMTC / NOAP with every normalisation and scoring step explained.
- IBAN checkValid DE IBAN
- Account lookupaccount found and in scope
- Normalise (payer)"Maria Schmidt" → "maria schmidt"
- Normalise (held)"Maria Anna Schmidt" → "maria anna schmidt"
- Compareone name is a subset of the other (missing given/middle name)
{
"request": {
"payeeName": "Maria Schmidt",
"payeeIban": "DE75512108001245126199",
"payeeType": "NATURAL_PERSON"
},
"response": {
"matchingResult": "CMTC",
"nameMatched": "Maria Anna Schmidt"
}
}Field names are illustrative. The normative request/response schema is in the EPC VOP Inter-PSP API Specifications (EPC103-24, v1.1.1 from 20 Sept 2026); the four result values are the scheme's.
What Verification of Payee checks
Verification of Payee (VOP) is the SEPA answer to misdirected and authorised-push-payment fraud: before a payer authorises a SEPA credit transfer or instant credit transfer, their PSP (the Requesting PSP) asks the payee's PSP (the Responding PSP) whether the name the payer typed matches the holder of the IBAN. The answer comes back within seconds and is shown to the payer, who then decides. The EU Instant Payments Regulation made the service mandatory for PSPs in the euro area from 9 October 2025 and for PSPs in non-euro Member States from 9 July 2027; the EPC runs the scheme that makes it interoperable.
The four results
- MTCH — Match. The names correspond after the Responding PSP's normalisation, or a legal-entity identifier (such as an LEI) matches the account's identifier.
- CMTC — Close match. Small deviations only: a typo, a missing middle name, an initial, a legal-form suffix, a trade name the PSP also holds. The Responding PSP returns the name it holds so the payer can confirm or correct.
- NMTC — No match. The names differ beyond the PSP's tolerance. The payer is warned; if they proceed anyway, liability for a misdirected payment shifts to them.
- NOAP — Not applicable. The check could not be performed: IBAN not found, payee opted out, account type out of scope, or the Responding PSP unreachable.
Why every PSP matches slightly differently
The rulebook fixes the result codes, response times and liabilities but leaves the matching algorithm to the Responding PSP, which carries the liability for a wrong MTCH. EPC guidance asks for consistent data cleansing (case, diacritics, punctuation, titles), defined "small deviation" rules that produce Close Match rather than No Match, and matching against all names the PSP legitimately holds — legal name, trade names, joint-account holders. The sliders above expose the three decisions that move results most: the similarity threshold, word-order tolerance, and legal-form handling. Tighten them and you push friction onto genuine payers; loosen them and you own the false MTCH.
Dates that matter
- 20 September 2026 — VOP rulebook v1.1, Inter-PSP API specification 1.1.1 and API Security Framework 2.1 take effect; the security framework becomes mandatory for VOP, SRTP and SPAA participants using APIs.
- November 2026 — rulebook v2.0 expected, following the change-request consultation that closed on 30 June 2026.
- 9 July 2027 — VOP obligation reaches PSPs in non-euro Member States.
Related: validate the IBAN itself with the IBAN Validator, see how the check fits the payment in the Open Banking & PSD2 guide, and follow scheme changes on the instant-payments news feed.