VOP Matching Recommendations v2.0: Character Sets and Joint Accounts
On 3 November 2026 the European Payments Council (EPC) published version 2.0 of EPC288-23, the VOP matching recommendations that guide a Responding payment service provider (PSP), the payee’s PSP, on whether a payee name counts as a Match, a Close Match or a No Match under the Verification Of Payee (VOP) scheme. That answer drives what the payer’s PSP must show before the payer authorises a credit transfer under Article 5c of the SEPA Regulation, the duty inserted by Regulation (EU) 2024/886 and covered in our SEPA Instant Payments Regulation guide.
Against version 1.0 of 10 October 2024, the new text adds a character-set section, adds conversion of the name recorded in the Responding PSP’s system into limited Latin before matching and rewords the joint-account Match scenario. It also covers how PSPs and Routing and/or Verification Mechanisms (RVMs) handle messages outside the limited Latin character set, including where a contractual arrangement allows other characters.
Related reading: Verification of Payee 2.0: What the Next-Generation VoP Scheme Standard Means for EU PSPs
VOP dates that frame version 2.0
- 10 October 2024: EPC288-23 version 1.0 issued, alongside version 1.0 of the VOP scheme rulebook (EPC218-23).
- 5 October 2025: the VOP scheme rulebook entered into force, ahead of the 9 October 2025 Article 5c compliance date for PSPs in euro-area Member States.
- 20 September 2026: rulebook version 1.1, published on 16 March 2026, became effective.
- 3 November 2026: EPC news release on version 2.0 of the recommendations; the document is dated November 2026.
- November 2026: publication of rulebook version 2.0 planned, per the EPC news item of 15 June 2026; confirm the current date on the EPC VOP page.
- 9 July 2027: Article 5c compliance date for PSPs in Member States whose currency is not the euro.
The EPC says the new recommendations accompany rulebook version 1.1. Rulebook version 2.0 runs on its own track, and an EPC news item of 15 June 2026 reported its implementation as expected in 2027 or later, subject to regulatory alignment.
The main changes in EPC288-23 version 2.0
The EPC news item summarises the update as “additional guidance on the character sets”. Reading the two PDFs side by side shows smaller edits as well, several of which change matching behaviour.
| Topic | Version 1.0 (10 October 2024) | Version 2.0 (November 2026) |
|---|---|---|
| Character-set section | None | New section II: limited Latin through UTF-8 as the general rule, with request and response use-case tables |
| Accents in data clean-up | Change diacritics in the received name unless the Responding PSP can compare, with listed equivalences | Convert the name recorded in the Responding PSP’s system into limited Latin before comparing, for the purpose of the comparison |
| Leading and trailing spaces | Truncate them | Recommendation text: a VOP message carries no leading or trailing spaces; truncate any still received before matching |
| Natural-person Match scenario (a) | Exact first name and correct last name of at least one of the account holders | Exact first name and exact last name of at least one and the same account holder |
| Identification-code outcomes | Match, No Match, verification check not possible, or code not supported/known | Match, No Match, or verification check not possible (rulebook v1.1 was already effective from 20 September 2026) |
The Close Match scenarios, the data-minimisation wording, the review process and the disclaimer read the same in both versions apart from section renumbering.
Limited Latin by default: the new character-set section
Section II restates a rule from section 3.1 of the VOP inter-PSP API specifications: as a general rule, only the limited Latin character set travels in inter-PSP API messages, through UTF-8. VOP requests and responses must contain only those characters, and the PSPs, or the RVMs acting for them, do the conversion. For the conversion itself, section 3.1 refers to the EPC217-08 best-practice and conversion-table documents and adds conversions for certain characters that the XML-oriented EPC217-08 table leaves out because they have another usage in JSON messages.
The contract condition matters for any PSP that relies on an RVM. The document says an RVM can only convert characters when that is contractually agreed with the PSP, and that a message containing non-Latin characters with no contractual arrangement between the PSPs must be rejected and not forwarded or processed further. The use-case tables put it in broader terms: an RVM whose contract with its PSP includes conversion converts the message into limited Latin, and every other RVM or PSP in the chain rejects a message not received in the limited Latin character set. The test is the limited Latin set, so accented letters, which the document treats as “extended” characters, also fall outside it.
Where a Requesting PSP or its RVM and a Responding PSP or its RVM have a contractual arrangement, the document says it is allowed to send any Latin or non-Latin character set within UTF-8 and to match against extended Latin or non-Latin characters without converting. Which characters that covers depends on what the arrangement provides, and the document expects participants making such deals to check that their RVMs know about them and that the RVM contracts allow the extra characters. The reject-and-do-not-forward wording and the limit on RVM conversion are the recommendations’ own: section 3.1 of the API specifications (version 1.1.1) sets the general rule that, unless otherwise agreed, only a limited set of Latin characters may be exchanged in inter-PSP API messages, and lets PSPs exchange additional characters by prior agreement. The recommendations are guidance that sits outside the VOP scheme rulebook, which refers to them in its section 3.2.1.
Data clean-up now includes converting the recorded name
Version 1.0 told the Responding PSP to change diacritics in the name received from the Requesting PSP unless it could compare them, and listed equivalences for accented letters and ligatures. Version 2.0 no longer carries that list. It says the Responding PSP should convert the payee name as recorded in its system into limited Latin characters before matching, to compare it with a request name that is also in limited Latin. Normalising for comparison is separate from changing the customer master record.
Where a matching engine compares strings without suitable normalisation or transliteration, differences between a limited-Latin request and the stored name may lead to additional Close Match or No Match outcomes; the result depends on the comparison logic the Responding PSP implements. Recital 21 of Regulation (EU) 2024/886 names diacritics and different transliterations as reasons a name might only almost match, so the conversion step affects how many of those cases reach the Close Match test.
Other clean-up examples remain: case is ignored, non-alphabetic characters other than numbers are removed (EPC217-08) unless the Responding PSP can compare them, and honorifics are removed unless it can use them. On spaces, the recommendations say a VOP message carries no leading or trailing spaces, and any still received are truncated before matching. This clean-up list sits in the recommendations, which do not form part of the VOP scheme rulebook. Section 3.1 of the VOP inter-PSP API specifications (version 1.1.1), which describe themselves in section 1 as a binding supplement to the rulebook, separately provides that values of the Max35TextVop to Max500TextVop text types shall not start with whitespace; it sets no equivalent trailing-space rule.
Joint accounts and legal persons: same-holder Match wording
Version 1.0 describes this Match scenario by the exact first name and correct last name of at least one of the account holders. Version 2.0 asks for the exact first name and exact last name of at least one and the same account holder, which makes the same-holder relationship explicit. Neither text says in terms how a first name from one joint holder and a surname from another is treated.
The general scope statement in section III now covers accounts held by one or more legal persons; the sentence setting the scope of the Close Match scenarios still refers to accounts held by a legal person. A commercial-name Match still depends on the Responding PSP being able to rely on commercial-name information from internal or trusted external sources.
The Close Match list is untouched: spelling errors within a level the Responding PSP sets, with Levenshtein distance as the document’s example, still count as small deviations, and name length must still be weighed when judging one.
Discretion stays with the Responding PSP
Version 2.0 keeps the accountability rule: the Responding PSP bears full responsibility for the matching outcome and remains free to apply different criteria. It may set stricter Close Match criteria for legal-person names than for natural persons, or the reverse. The discretion has a floor: supporting every response type and related reason code in the rulebook is mandatory.
For issues between participants, the EPC’s optional guidelines VOP WG 007-26 of 28 April 2026 list “wrong application of the Latin character set and/or character cleaning” by a PSP or RVM among the possible issues behind a false Close Match, with contact to the Responding PSP or its RVM as the recommended action.
When the VOP matching recommendations v2.0 can apply
The EPC’s 3 November 2026 announcement does not specify an application date for EPC288-23 version 2.0. Section V, unchanged from version 1.0, is the governance procedure for reviewing the recommendations outside the regular rulebook change cycle, and it says new or amended recommendations apply at the earliest 90 calendar days after the updated document is published on the EPC website, with an exception for emergency changes. The EPC presents version 2.0 as following its 2026 change management cycle.
Counting 90 calendar days from 3 November 2026 gives 1 February 2027 (a calculation, not an EPC date), and it does not establish a confirmed application date. The application timing therefore remains unresolved, and PSPs should obtain confirmation from the EPC before using 1 February 2027 as an implementation milestone.
Frequently Asked Questions
Can a Responding PSP return a Close Match on an LEI or VAT number that is one character off?
No. The recommendations state that no Close Match is possible on identification codes: the result is a Match on an exact match, a No Match, or verification check not possible. The recommendations apply this route where the payee is a legal person, the Requesting PSP’s payment initiation channel lets the payer submit an unambiguous identification code instead of the name, and the data element is available in the Responding PSP’s internal system. Section 3.2 of rulebook v1.1 turns that condition into a pre-send check: before sending the VOP request, the Requesting PSP must verify that the data element is available in the Responding PSP’s internal system, and it could check this in its local current copy of the EPC Directory Service. Article 5c(1)(b) likewise has no almost-match limb for these data elements.
On a joint account, does the name returned with a Close Match reveal the other holder?
It should not. The Responding PSP provides only name information about the counterparty named in the request and does not disclose other holders of that account number. The document strongly recommends data minimisation here, and recital 21 of Regulation (EU) 2024/886 asks for the almost-matching name to be shown in a way that complies with the GDPR.
If our RVM performs the matching for us, does the responsibility move to the RVM?
The use-case tables recognise matching outsourced to the Responding PSP’s RVM, yet the document places full responsibility for the outcome on the Responding PSP and names no RVM exception. Under Article 5c(8), where a failure occurs because the payee’s PSP did not meet its Article 5c obligations, the payee’s PSP compensates the payer’s PSP for the resulting financial damage.
Related Articles
- Verification of Payee 2.0: What the Next-Generation VoP Scheme Standard Means for EU PSPs: rulebook version 1.1 and the VOP 2.0 change-request consultation.
- SEPA Instant Payments Regulation: A Practical Guide for Luxembourg PSPs: Regulation (EU) 2024/886 duties and deadlines by entity type.
- EPC Register of Participants: The 20 November 2026 Adherence Cutoff: the extra December 2026 adherence cycle and its readiness date.
- EPC Instant Credit Transfer Scheme Selector: SCT Inst or OCT Inst?: which instant scheme rulebook an instant euro transfer runs under.
Key Takeaways
- RVM contracts: confirm whether each contract includes character conversion, because the use-case tables decide who converts and who rejects on that term.
- Application timing: the EPC has not announced an application date for version 2.0, so confirm the timetable with the EPC.
- Change suggestions: Responding PSPs may write to the PSMB at any time; it reviews them at its February, April, September or October meeting.
Sources and References
- EPC news, “EPC publishes updated recommendations for matching processes under the VOP scheme” (3 November 2026): europeanpaymentscouncil.eu
- EPC288-23 Version 2.0, EPC Recommendations for the Matching Processes under the VOP Scheme Rulebook (November 2026): EPC PDF
- EPC288-23 Version 1.0 (10 October 2024): EPC PDF
- Regulation (EU) 2024/886 of 13 March 2024 as regards instant credit transfers in euro, inserting Article 5c into Regulation (EU) No 260/2012 (recitals 20 to 23): EUR-Lex
- EPC, Verification Of Payee scheme rulebook (EPC218-23), versions 1.0 and 1.1: EPC document library; version 1.1 (issued 16 March 2026, effective 20 September 2026): EPC PDF
- EPC103-24 Version 1.1.1, Verification Of Payee Inter-PSP API Specifications (issued 4 May 2026, effective 20 September 2026): EPC PDF
- EPC, Verification Of Payee scheme page and evolution calendar: europeanpaymentscouncil.eu
- EPC press release EPC266-25, “The Verification Of Payee scheme rulebook now into force” (6 October 2025): EPC PDF
- EPC news, “RVM MSG reviews VOP progress and advances VOP 2.0 discussions” (15 June 2026): europeanpaymentscouncil.eu
- EPC, VOP WG 007-26 Version 1.0, Guidelines to support an optional exchange of data sets (28 April 2026): EPC PDF
Planning VOP matching changes without a confirmed date
The edits to test against current matching and routing logic are the recorded-name conversion, the handling of messages outside the limited Latin set absent a contractual arrangement, and the same-holder wording for joint accounts. The EPC has not specified an application date in its 3 November 2026 announcement. PSPs should assess the changes against their existing obligations under rulebook v1.1, while confirming the implementation timetable for the recommendations. The EPC news item of 15 June 2026 planned publication of the separate rulebook version 2.0 for November 2026, so the current date needs confirming on the EPC VOP page.
Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.