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

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?

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.

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.

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.

The Open API specification prescribes the mandatory "code" attribute in VerificationOfPayeeError with a fixed set of codes (FORMAT_ERROR, CLIENT_INVALID, CLIENT_INCONSISTENT, TIMESTAMP_INVALID).

The OpenAPI specification defines the service URL as "/vop/v1/payee-verifications". Could the "Inter-PSP" VoP services be differentiated from internal (PSU->PSP) VoP services? For example, it would help to assume URL such as "/vop/fi2fi/v1/payee-verificat

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

Is it mandatory for the scheme participants to support all the VOP request types (i.e., both combinations A and B) described in section 3.2 of the VOP scheme rulebook?

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.