Verification of payee is a pre-authorisation check with a refund attached to it. Article 5c of Regulation (EU) No 260/
What Article 5c actually obliges you to do
Article 5c(1) puts the duty on the payer's PSP. It offers the verification service, performs it immediately after the payer supplies the payee details, and completes it before the payer is offered the possibility of authorising the transfer. It does that regardless of the payment initiation channel used, and Article 5b(2) makes it free to every payment service user.
The scope is credit transfers in euro: Article 5c inherits Article 1(1) of the SEPA Regulation, as the European Commission's Q&
Article 5c(1) then splits into four cases, and most teams have designed only for the first. Point (a) is the name and IBAN check. Point (b) lets a legal-person payee be identified instead by a fiscal number, a European unique identifier or an LEI, where the payee's PSP holds that element too. Point (c) covers accounts maintained for multiple payees. Point (d) covers channels that do not require both the IBAN and the name.
Article 5c(8) shapes everything else. A PSP that has met Article 5c is not liable under Article 88 of PSD2 for a transfer executed to an unintended payee on an incorrect unique identifier. One that fails to comply, where that failure produces a defectively executed transaction, refunds the amount without delay and restores the debited account. Where the failure came from the payee's PSP or a payment initiation service provider, that party compensates the payer's PSP. Asked whether a malfunction of its own verification service counts, the Commission answered yes.
Response | What it means | What the payer's PSP does |
|---|---|---|
Match (MTCH) | After clean-up, the name is the one registered against the IBAN. | May tell the payer; no warning required. |
Close match (CMTC) | A small deviation. The responding PSP returns the name it holds. | Show that name and warn that the funds may reach another account. |
No match (NMTC) | Neither the match nor the close match criteria are met. | Notify and warn; the payer must still be able to authorise. |
Verification check not possible (NOAP) | No result was produced, or nothing arrived inside the execution time. | Tell the payer the check could not be performed, and warn. |
The dates that bind you, and the ones that do not
Article 5c(9) sets two. PSPs located in a member state whose currency is the euro had to comply by 9 October 2025. PSPs located in a member state whose currency is not the euro have to comply by 9 July 2027. The ECB's implementation table for the instant payments rollout puts verification of payee on exactly those two lines.
Before its own date a Polish PSP sending euro credit transfers carries no Article 5c duty, because paragraph 9 keys on where the PSP is located rather than on the currency. The responding side is another matter. The EPC made VOP adherence compulsory for SCT and SCT Inst scheme participants caught by the amended regulation, and ran a formal opt-out in 2025 for participants outside the euro area that were not yet impacted. A payee PSP that opted out is not reachable, so euro-area payers sending to its IBANs are told the check could not be performed.
The scheme runs its own calendar too. Rulebook version 1.1 was issued on 16 March 2026 and takes effect on 20 September 2026, with API specifications version 1.1.1 of 4 May 2026 alongside it. Version 2.0 is due in November 2026, intended to become effective in November 2027. A service going live on 9 July 2027 is built against version 1.1 and carries a scheduled change four months later.
The requesting side and the responding side
The obligation produces two services with different owners. The requesting side sits inside payment initiation and consumes an answer; the responding side reads the account master, produces it, and carries the liability for what it says.
On the requesting side the call is addressed PSP to PSP. The requesting PSP derives the account-holding BIC from the payee's IBAN, then reads its local copy of the EPC Directory Service for the endpoint registered against that BIC. Two details in the EPC's own clarification catch people out: the IBAN to BIC mapping is the requesting PSP's own problem, and the account-holding BIC is the BIC of the legal entity where the IBAN is domiciled, which can differ from the payment routing BIC a bank already uses. The directory is downloaded and held locally, so a stale copy produces routing failures that look like counterparty outages.
The call itself is a single POST to /
Underneath both roles, one internal service with one wrapper per system holds up better than verification logic spread across channels: the channels ask one question and render one answer, and the wrapper turns the account master's own model into the scheme's response codes. The integration layer keeps the dated scheme contract in one place.
Matching is decided by the payee's PSP
The EPC's recommendations for the matching processes open by saying that the responding PSP bears full responsibility for the outcome and stays free to apply its own criteria. Whoever owns your account master owns this decision.
The recommended sequence starts with clean-up rather than with an algorithm: ignore case, fold diacritics, strip non-alphabetic characters, drop honorifics, trim spaces. Matching then runs on the first and last name for a natural person, and on the legal or commercial name for a legal person.
A match is an exact result after clean-up. It also covers a fully correct first and last name of one holder of a joint account, and a commercial name in place of the legal name where the responding PSP has reliable commercial-name information. A close match covers a spelling deviation inside a level the responding PSP sets for itself, with Levenshtein distance given as the example, transposed letters, an initial instead of the first name, and same-phonetics substitutions; for legal persons, also words in the wrong order and common abbreviations. Everything else is a no match, and identification codes have no close match at all.
Two things follow. The tolerance is a liability decision taken inside the responding service, so it belongs in configuration a risk owner can move rather than in a release. And the EPC can revise these recommendations outside the rulebook change cycle, with new ones applicable at the earliest 90 calendar days after publication. The upstream limit is the account master: the EPC tells responding PSPs to ask payees for their exact and complete official name, which concedes that no matching rule repairs a name recorded badly at onboarding.
Building the layer between your channels and your core?
Our free practitioner guide sets out the orchestration-layer pattern we use for core banking integration: one middle-tier orchestrator, one wrapper per legacy system, and a build checklist.
Latency, availability and the log that settles liability
The scheme sets a maximum execution time of five seconds, preferably one second or less, measured from the moment the requesting PSP addresses the request to the moment it receives the response. Participants may agree shorter times bilaterally. Everything your own stack does before and after that window is extra, on a screen a payer is waiting on.
Availability is 24 hours a day on all calendar days of the year, in both roles, business continuity arrangements included. Planned maintenance windows are allowed, and the scheme has no process for announcing them to other participants, which is the practical reason to treat a silent counterparty as ordinary traffic.
The failure paths are specified more tightly than the happy path. A participant can publish several endpoints in the directory with priorities: priority 1 is the default and the rest are backups. The EPC has defined no standard retry policy, and the maximum execution time applies to every request whatever policy you choose. When no response arrives in time, the requesting PSP tells the payer the check could not be performed and warns that the funds may reach an account the payee does not hold. A response arriving after that must be discarded. HTTP 400 covers a malformed request, 401 an invalid certificate or a PSP missing from the directory, and 500 an internal failure.
The log turns those states into a defence. Liability under Article 5c(8) rests on which side failed, and the Commission's answer on an unreachable payee PSP is that liability follows where the technical problem occurred, in practice under the scheme's own rules. So each attempt needs its request identifier and timestamp, the endpoint used, the outcome code or the failure, the elapsed time, and what the payer saw and did.
What breaks first in a build like this
Five things go wrong in payment initiation work of this shape, roughly in this order.
- The name data. It has the longest lead time and no code repairs it: pooled accounts, trading names, joint accounts, initials-only records, transliterated names.
- The channels nobody listed. Article 5c(1) says every initiation channel: on-us transfers, standing orders, corporate host-to-host files, payment initiation service providers, the branch counter and paper orders taken with the payer present.
- Caching. A saved payee is verified again on every transfer, so a design that stores an outcome and reuses it is a compliance defect.
- The latency budget. The account master lookup usually spends it. Measure the responding path at the volume of your busiest payment hour before agreeing any bilateral time shorter than the maximum.
- Routing data. Every account-holding BIC you serve needs an endpoint against it in the directory, and your local copy needs a refresh schedule. A missing BIC surfaces as somebody else's failure.
Test in the same order. The EPC's API Reference Toolbox is the platform for interoperability tests, scheme compliance and self-certification: routing and verification mechanisms must self-certify on it, and directly connected PSPs are strongly recommended to do the same. The directory has carried a test environment alongside production since it went live on 2 September 2025.
Building verification of payee for 9 July 2027?
WislaCode builds regulated banking and payment software where the integration has to answer to a supervisor: channel wiring, scheme APIs, wrappers over the core, and the logging that decides liability.
What is verification of payee and why does it matter for banks?
It is a check that the payee name a payer supplies matches the name the receiving bank holds against that IBAN, run before the payer can authorise the transfer. Article 5c of the SEPA Regulation, as amended by the Instant Payments Regulation, makes it compulsory for credit transfers in euro and free to the payer. The commercial weight sits in Article 5c(8): a payer's PSP that fails to perform the check refunds the payer without delay where that failure produces a defectively executed transaction.
When does verification of payee become mandatory in Europe?
Article 5c(9) sets two dates. PSPs in member states whose currency is the euro had to comply by 9 October 2025. PSPs in member states whose currency is not the euro, Poland included, have to comply by 9 July 2027. Article 16(9) of the same regulation brings a member state forward if it adopts the euro before 9 April 2027, to within one year of adoption.
Which payments does the verification of payee requirement cover?
Credit transfers denominated in euro, instant and non-instant alike, for consumers and businesses. The European Commission's Q&A confirms that on-us transfers, where one institution holds both accounts, are in scope, and that the check applies to every transfer rather than once per payee. The exclusions are paper orders taken while the payer is absent, and an opt-out for packages of payment orders available to payment service users who are not consumers.
How does name matching work in a verification of payee check?
The payee's PSP performs the matching and carries the liability for the result. The EPC's recommendations describe a clean-up step first, ignoring case, diacritics, punctuation and honorifics, then an outcome of match, close match or no match, with a close match returning the name held on file. Each responding PSP sets its own tolerance, and the EPC gives Levenshtein distance as an example of how to do it.
What happens if a verification of payee check times out or fails?
The scheme sets a maximum execution time of five seconds. If nothing arrives, the requesting PSP tells the payer that the check could not be performed and warns that the funds may reach an account the payee does not hold. Article 5c(5) means the payer can still authorise, and a response that turns up after the payer has been told must be discarded. Where a loss follows, liability is decided by where the technical failure actually occurred.
Do smaller payment service providers also need to implement verification of payee?
The obligation follows the PSP rather than its size. The EPC states that SCT and SCT Inst scheme participants affected by the amended SEPA Regulation must adhere to the VOP scheme and register in the EPC Directory Service. A smaller PSP can appoint a routing and verification mechanism to carry the traffic and even to perform the checks, though the rulebook is explicit that outsourcing does not relieve the participant of its own liabilities.