Frequently asked questions

The security model of the EPC VOP API is built on mutual authentication using a Qualified Web Authentication Certificate (QWAC) issued for use in the PSD2 Open Banking  on client side (VoP Requesting PSP) a

The security model of the EPC VOP API is built on mutual authentication using a Qualified Web Authentication Certificate (QWAC) issued for use in the PSD2 Open Banking  on client side (VoP Requesting PSP) a

The security model of the EPC VOP API is built on mutual authentication, using a Qualified Web Authentication Certificate (QWAC) issued for use in the PSD2 Open Banking  on client side (VoP Requesting PSP)

For the codes such as BANK, CBID, CHID, CINC, COID, CUST, DUNS, EMPL, GS1G, TXID, BDID and BOID, ISO 20022 does not provide explicit format validations. 

Priority 1 URI should always be used by the Requesting PSP as the “default” URI. 
URI(s) with lower priorities may be used e.g. as alternative backup reachability endpoints, in case Priority 1 URI is not reachable.  

•    The rulebook does not say that the calculation requires a subtraction between the requested date-time and the responding date-time.

As described in detail in the VOP API specifications and the

A VOP scheme participant should not try to send VOP requests to non VOP scheme participants (e.g., based outside the Eurozone of the EEA or outside the EEA).

All VOP scheme participants must at least support the inter-PSP API specifications set by the EPC. This ensures SEPA wide reachability and interoperability.

As specified in the VOP scheme rulebook, the Requesting PSP must instantly communicate the VOP response to the Requester (Payer) as provided by the Responding PSP.

This means one QWAC PSD2 certificate (and one NAN) would be shared within a community of VOP scheme participants, and be used to identify, authenticate and authorise all VOP scheme participants of the same community, when acting

The EPC Verification Of Payee (VOP) scheme is designed to allow the payment service providers (PSPs) in the European Economic Area (EEA) to comply with the new regulatory requirements outlined in the EU Instant Payments Regulation (IPR) within the

The role is not relevant for the VOP scheme. The Responding PSPs should not check this information.

The API “Verification of Payee” is only dedicated to the inter-PSP’s space.

The Timestamp (attribute AT-T056) is always set by the Requesting PSP.

The final EDS technical specifications will be published by the EPC at a later stage, expected within Q1-2025.

Note that the provided list of error codes does not cover other situations:

1. Background: services that can be offered by PIs

The string types (such as Max35Text, Max70Text etc.) in the OpenAPI specs differ from the ISO 20022 standard types of the same names, where min length is prescribed to be 1.

At the moment, only inter-PSP API specifications were published, and it is not foreseen to publish ISO20022 messages for the customer-to-bank space.

1. Background: services that can be offered by EMIs

The VOP API WB decided to not include the HTTP 403.

According to the IPR, the Requesting PSP must notify the Requester about the outcome of the VOP check. It is up to the Requesting PSP to decide how to comply with this requirement.

For liability related questions, please refer to the Regulation (EU) 260/2012 as modified by the Regulation (EU) 886/2024 (Instant Payments Regulation - IPR), and to the Clarification of requirements of the

The standard approach is to use content type of "application/problem+json", which allows the client to clearly inform that the problem detail structure is provided.

All current and future SEPA Credit Transfer (SCT) and/or SEPA Instant Credit Transfer (SCT Inst) scheme participants affected by the amended SEPA Regulation provisions on verification of payee must adhere to the VOP scheme and register into and fu

1. Background

The aim of this document is to provide clarifications about the BIC (Business Identifier Code) to be used to corre

We believe that this is a mandatory field consequently it should be added specific message code. Could you please clarify what code should be used in these cases?

For SCT/SCT Inst scheme participant EMIs and PIs, the same principles of which under Q&A III.1 apply. SCT/SCT Inst scheme participant PIs and EMIs located in the Eurozone are required to offer a VOP service as of 9 October 2025.

In the second half of 2025 the Verification Of Payee Working Group will look into the possibility to give guidance about the bulk process.

The VOP scheme rulebook will be effective on 5 October 2025. As of that date, in principle any PSP able to comply with all the rules specified in this rulebook can adhere.

Legal background

If the validation of the requesting PSP (via the check BIC / NAN) is valid therefore the response should be HTTP 200 – “partyNameMatch”: “NOAP” (Verification Not Possible).

The EDS related documentation will be published progressively in March and April 2025.

The VOP Rulebook states that the maximum execution time for the Requesting PSP to get the VOP Response is 5 seconds, and preferably 1 second or less.

The section 4.4 Eligibility for participation of the VOP scheme rulebook outlines which entities can adhere to this scheme.

The RVMs are transparent from a VOP scheme rulebook perspective but technically, they need to be registered in the EDS to act on behalf of the scheme participants.

The HTTP code is sufficient, the VOP API WB agreed to change the YAML to reflect this.

Consistently with the Rulebook, the ORD as set in the EDS and ROP may not be set at any date earlier than 5 October 2025 (the effective date of the VOP scheme).

A PSP that is planning to use an RVM in the future and to rely on this RVM for EDS registration and update can ignore the email received with its access to the EDS for the time being.

Supporting the combination, A is mandatory, but combination B is optional. The scheme participants do not have to support one (or several) identifier code(s) from the beginning; they can update the EDS whenever they are ready.

The API Reference Toolbox (ART) will be used for VOP interoperability tests, VOP scheme

The “Generic Organisation Identification” element must be used when the party is identified using an identification other than the LEI or BIC, i.e. TXID, etc.

There are two main options for onboarding into the EDS:

In practice, due to the architecture of the VOP scheme and its API, adherence by non-EEA PSPs (apart from the case of a non-EEA SCT/SCT Inst scheme participant parent adhe

Background

More details about the role of RVM and the related conditions will be published by the EPC at a later stage, expected within Q1-2025.

Alternatively, could the URIs from the Mozilla Developer Network (MDN) be used?

The EPC cannot provide any legal advice about compliance with legal regulations. Each scheme participant and market operator (including RVMs) must conduct their own compliance evaluations.

The VOP process presents a challenge for certain factoring solutions, specifically those involving "half-disclosed factoring”, since in these cases, the payer is unaware of the factoring process and only receives an invoice from

Our recommendation is to use TIMESTAMP_INVALID.

From a practical point of view, the counter starts when the VOP request is initiated by the requester and materialized via the VOP request Timestamp (attribute AT-T056).  It is then up to each scheme participant to agree wi

Priority 1 URI should always be used by the Requesting PSP as the “default” URI. 

Both addresses can be changed at any time by sending an updated Schedule Information to the Adherence Agreement (Annex H2) to the EPC.

Yes, a VOP scheme participant can provide an email address of its RVM in the major incident reporting contact email address.

This attribute can be used when the party (subject of the verification) has a BIC code that can be used to identify it, and such BIC is sent in the VOP request by the requesting PSP.  The BIC used

There is no process to inform other scheme participants about planned maintenance foreseen in the VOP scheme.

The EPC does not have the possibility to monitor this.

The EDS is actually based on two sub-systems.

As previously communicated each VOP scheme participant is uniquely identified in the ROP and in the EDS only by one BIC (the “participant BIC”), provided during the VOP scheme adherence process in the Schedule to the Adherence A

Our recommendation is to use the code “NOAP”.

In these cases, the response code is sufficient and self-explanatory, there is no need for a detailed error code.  

We followed the definition described in ISO20022, the “identification” has the Datatype “Max256Text”

i.e. source ISO20022_MDRPart2_PaymentsInitiation_2023_2024_v1 (page 341)

• VOP Response will include NOAP code in case of Matching not possible for the responding application for any reason, with HTTP code 200.
• In case of technical problems, the Responding PSP wil

Regarding the Unstructured remittance information field, we have the following questions:

Following the specifications described in the “Verification Of Payee API Specifications” document, the VAT number value must be inserted in the “identification” attribute, and it is mandatory that the value “TXID” be used as the

From the EPC point of view, you only need one certificate, which is for production. However, when it comes to testing VOP, there are different scenarios depending on your choice to work with an RVM or not.

PSPs are required to use a QWAC PSD2 certificate when sending a VOP Request for authentication by the Responding PSP.

The VOP API specifications include a number of timestamp fields in the headers and body. The format of these timestamps does not allow for trailing zeroes for milliseconds.

As mentioned in the VOP scheme API specifications, only the Latin characters set should be transported in the inter-PSP API messages, through UTF-8.  This restriction has been agreed in order to overcome the complexity that