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.
Follows EPC Verification Of Payee scheme rulebookv1.1 (in force since 20 Sep 2026) · API spec 1.1.1·verified Oct 2026· double-checked Oct 2026— matching rules are the simulator’s policy — the rulebook leaves matching to the Responding PSP; SEPA scope includes AL, ME, MK, MD and RS; LEI check digits validated
- IBAN checkValid DE IBAN
- Account lookupaccount found and in scope
- Normalise (payer)"Maria Schmidt" → "maria schmidt"
- Normalise (held)"Maria Anna Schmidt" → "maria anna schmidt"
- Comparegiven/middle name "anna" not given by the payer
{
"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
The rulebook defines the four results and that a Close Match returns the payee's name to the payer; which deviations count as a match or a close match is left to the Responding PSP. What follows is this simulator's policy, adjustable with the controls above.
- MTCH — Match. The names are identical after normalisation (case, diacritics — ü as ue or u — and letters such as Ø, Ł, Đ, ß folded to ASCII, punctuation, leading titles); with the toggles on, also the same words in another order or a legal-entity name without its legal form (GmbH, Ltd, S.A. — not words such as "Holdings" or "Group"). A trade name the PSP holds counts as a name of the payee. For a legal entity, an identifier such as a valid LEI matching the one on file is a match.
- CMTC — Close match. Small deviations only. A natural person needs the surname (exactly or with a typo) and a given name — in full, as an initial or with a typo; a missing or extra middle name is tolerated. A surname or a given name on its own is a No Match, because a Close Match would hand the full name to whoever typed one word. A legal entity needs every word to correspond (typos allowed) or at most one word of the registered name missing; with the legal-form toggle off, a name that differs only in its legal form is a Close Match. With the word-order toggle off, the same words in another order are a Close Match. 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, or nothing is left to compare (a name that is only a title). 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 outside the SEPA scheme scope or invalid, account not found, no usable name on file, or the Responding PSP unreachable.
There is no payee opt-out in the EPC scheme. The Instant Payments Regulation (Article 5c of Regulation (EU) No 260/2012 as amended) lets payers that are not consumers opt out when they submit payment orders as a package (bulk files); the Requesting PSP then sends no VOP request at all — that is not a NOAP response.
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 controls 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 — and disclose more names through CMTC.
Dates that matter
- 20 September 2026 — VOP rulebook v1.1, Inter-PSP API specification 1.1.1 and API Security Framework 2.1 took effect; the security framework is now mandatory for VOP, SRTP and SPAA participants using APIs.
- End of November 2026 — rulebook v2.0 scheduled for publication, 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.