EPC FAQ:  —  Verification Of Payee scheme  —  Last updated: 17/07/2025

Could you please share additional information regarding the ‘Business Identification Code’ (+++AnyBIC mentioned in 4.2.1 of API Specifications doc.) referred as an alternative identifier to perform VOP validation? Which type of identifier and/or standard (if any) should be considered for this field?

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

EPC FAQ:  —  Verification Of Payee scheme  —  Last updated: 17/07/2025

In case of problem with the format of the X-Request-Timestamp attribute, should the RVM send a FORMAT_ERROR or a TIMESTAMP_INVALID code?

Our recommendation is to use TIMESTAMP_INVALID.

EPC FAQ:  —  Verification Of Payee scheme  —  Last updated: 25/08/2025

In the response payload, we have the field type that should have an URI reference [RFC3986] that identifies the problem type. Will the EPC provide the URI references to be used in each problem?

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

EPC FAQ:  —  Verification Of Payee scheme  —  Last updated: 17/07/2025

We would like to have more information about the usage of the party.identification.organisationId.others field. When should it be used and how will it work?

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.

EPC FAQ:  —  Verification Of Payee scheme  —  Last updated: 17/07/2025

Is it possible to send examples of the response payload in case of error (http 400 and http 500)? For example, what value should be put in the attribute CODE in case of http 500?

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

EPC FAQ:  —  Verification Of Payee scheme  —  Last updated: 17/07/2025

In case of a misdirected request (the IBAN does not belong to the PSP that receives the request), should the PSP return the message ‘Verification Not Possible’?

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).

EPC FAQ:  —  Verification Of Payee scheme  —  Last updated: 27/08/2025

Verification Of Payee API Specifications lists some of the error cases identified and provides the corresponding error codes. However, there is not a message code in two cases (Certificate items and Internal Server Error).

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?

EPC FAQ:  —  Verification Of Payee scheme  —  Last updated: 17/07/2025

The VoP API specification (Chapter 4.4) prescribes the usage of RFC 7807 Problem Detail structure, but links it with Content-type "application/json".

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.

EPC FAQ:  —  Verification Of Payee scheme  —  Last updated: 17/07/2025

Is it correct to treat authorization issues with HTTP 401, while this should typically be done with HTTP 403?

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

EPC FAQ:  —  Verification Of Payee scheme  —  Last updated: 17/07/2025

Could minLength=1 be used for all string attributes in the OpenAPI specs, except for the cases where it clearly makes sense to differentiate between "not provided" and "empty".

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.

Subscribe to