EU Verification of Payee after 20 September 2026: rulebook 1.1 and the 2027 non-euro deadlines

What Article 5c requires, and from which date

Regulation (EU) 2024/886, the Instant Payments Regulation (published in the Official Journal on 19 March 2024), inserted Article 5c into the SEPA Regulation (EU) No 260/2012. We re-read the consolidated text on 2026-09-22. The clauses that set test scope:

• Article 5c(1), timing and channels. The payer's payment service provider (PSP) "shall perform the service ensuring verification immediately after the payer provides relevant information about the payee and before the payer is offered the possibility of authorising that credit transfer", and "regardless of the payment initiation channel used by the payer".
• Article 5c(1)(a), name and IBAN. Where the names do not match, the payer's PSP notifies the payer. Where they "almost match, the payer's PSP shall indicate to the payer the name of the payee associated with the payment account identifier".
• Article 5c(1)(b), legal persons. Where a channel accepts a fiscal number, a European unique identifier, or an LEI (Legal Entity Identifier) instead of the name, the payee's PSP verifies that data element against the account.
• Article 5c(5). Verification "does not prevent payers from authorising the credit transfer concerned."
• Article 5c(6). Non-consumers get "the means to opt out from receiving the service ensuring verification when submitting multiple payment orders as a package" and "the right to opt in at any time".
• Article 5c(7). Every notification under points (a), (b), or (c) carries the warning that authorising "might lead to transferring the funds to a payment account not held by the payee indicated by the payer."
• Article 5c(8), liability. Where the payer's PSP fails paragraph 1 and the failure results in a defectively executed transaction, it "shall without delay refund the payer the amount transferred". Where the payee's PSP caused the failure, that PSP compensates the payer's PSP.
• Article 5b(2). For payment service users (PSUs), the services in Article 5c "shall be provided to all PSUs free of charge."

The dates sit in three articles. Article 5c(9): PSPs in a euro Member State comply "by 9 October 2025", PSPs in a non-euro Member State "by 9 July 2027". Article 5a(8): non-euro PSPs receive instant credit transfers in euro by 9 January 2027 and send them by 9 July 2027, and until 9 June 2028 they need not send instant euro transfers from national-currency accounts "during the time when those PSPs neither send nor receive non-instant credit transfer transactions in euro with respect to such accounts." Article 5b(3): non-euro PSPs apply the charges rule by 9 January 2027.

What changed on 20 September 2026

The European Payments Council (EPC) scheme implements Article 5c between PSPs. Version 1.0 of the rulebook entered into force on 5 October 2025, per the EPC press release of 6 October 2025. On 16 March 2026 the EPC announced three documents effective 20 September 2026: rulebook 1.1, API specifications 1.1.1, and API Security Framework 2.1, which "will become mandatory as of 20 September 2026" for scheme participants using APIs.

From rulebook 1.1 (Annex III and sections 3.2.1, 3.3.2, 3.6.1):

• Attributes AT-C002 and AT-D002, the BICs of the responding and requesting PSP, allow "Only an 11 character ISO code".
• The IBAN plus identification code combination returns Match, No Match, or Verification check not possible. Close Match exists only for IBAN plus name.
• The maximum execution time is "5 seconds (preferably 1 second or less)". With no response in time, the requester is told the check was not possible, and a response received after that reply "must" be discarded.
• On No Match, Verification check not possible, or no response, the requesting PSP "Instantly informs" the requester of the misdirection risk. Wording is at the PSP's discretion.

From API specifications 1.1.1 (issued 4 May 2026): text types have a minimum length of 1 and "shall not start with whitespace"; timestamps "must include a timezone indicator" with milliseconds; error responses use application/problem+json; an identification code "not supported at EDS level" (EPC Directory Service) "should" get an HTTP 400 response, and a supported code not available for that payee "has to" return NOAP with HTTP 200.

Version 2.0 is next. The EPC consultation on change requests ran from 1 April to 30 June 2026, and its consultation document states approved changes will be "published in November 2026 with the intention that they become effective in November 2027."

Why Verification of Payee changes test scope

The money consequence is written into Article 5c(8): a check skipped in one channel turns a misdirected transfer into a refund owed "without delay" by the payer's PSP. The defects we look for:

• A channel without the check. The mobile app calls VoP and the bulk upload or the paper form does not. Article 5c(1) covers every initiation channel, and Article 5c(4) covers paper orders at receipt when the payer is present.
• Wrong screen order. The check fires after the authentication step, so the payer approves before seeing the result. The sequence against strong customer authentication is on our PSD2 SCA requirements page.
• A hard block on No Match. The payment button disappears, which breaks Article 5c(5).
• An 8-character BIC in routing data. A directory copy or legacy table holds SYNTNL2A, and the outbound request breaks the 11-character rule of rulebook 1.1.
• A late response shown to the user. The late Match overwrites "not possible" on screen.
• A VoP fee. A pricing table charges for the check, against Article 5b(2).

The name checked by VoP travels in the VoP request, and the creditor name travels separately in the ISO 20022 credit transfer, so a test compares both for the same payment; the message-side checks are on our ISO 20022 testing page. Name matching thresholds on the responding side behave like screening thresholds, and our sanctions screening false positive guide shows how we score a labelled name set.

What to test before 9 July 2027

The table is the case list we run for a requesting and a responding PSP. The data is synthetic; the IBAN below has a valid checksum and a fictional bank code. In the requesting-side rows, the responding PSP is a stub that returns the code in the row; the leading-space row runs against the responding PSP's API.

POST /vop/v1/payee-verifications HTTP/1.1
Content-Type: application/json
X-Request-ID: 3f2b8c1e-7a4d-4e5b-9c6f-2d8e1a0b4c7d
X-Request-Timestamp: 2026-09-21T09:14:03.217Z

{
  "party": { "name": "Halvorsen Ingrid" },
  "partyAccount": { "iban": "NL90SYNT0123456789" },
  "partyAgent": { "financialInstitutionId": { "bicfi": "SYNTNL2AXXX" } },
  "requestingAgent": { "financialInstitutionId": { "bicfi": "SYNTDEFFXXX" } }
}

For PSPs in non-euro Member States, run the matrix against the RVM (Routing and/or Verification Mechanism) chosen for 9 July 2027, and run the instant receive tests before 9 January 2027. For euro-area PSPs, the rows on BIC length, timestamps, and error formats are the regression set for 20 September 2026. We deliver this matrix, with stubs and evidence, as part of payment rails testing. For AP platforms that submit packages, the opt-out and opt-in paths are the main scope; our AP and AR automation page covers their payment runs.