Concept and mechanism
Verification of payee compares payer-provided data with data associated with the account at the payee’s PSP. Match, close match, no match, and verification not possible have different meanings. An HTTP200 can carry any business result defined by the API; it should not automatically become a positive match. Verification supports the payer’s decision without constituting payment authorization or execution. VOP version 1.1 became effective on September 20, 2026. The service has a purpose linked to actual payments and should not be treated as a general account-holder discovery directory. Technical API access alone does not create a right to collect and reuse data.
Guided application
Data quality also depends on address mapping and message usage rules. EPC hybrid format uses structured country and town fields; structured elements should not be repeated in free-text address lines. Do not invent a town merely to satisfy a schema. A project should identify data origin, transformation, and semantic validation, testing missing fields and incorrect content. Validation-subset XSDs replace neither production ISO namespaces nor all business rules. A test matrix covering VOP outcomes, customer messaging, XML structure, and scheme conditions prevents acceptance being reduced to HTTP responses and well-formed files.
Example: the interface receives close match but displays account confirmed because HTTP is 200. Correct mapping and test the customer decision path, including unavailable verification and no response.
Common pitfalls
HTTP treated as financial outcome; match treated as authorization; schema treated as complete conformance; invented field values.
Related topics: Instruments, participants, and settlement · Timing, confirmations, and late outcomes · Mandates, Core, and B2B
Validate structure, meaning, and the decision presented to the user.
Reference: Verification Of Payee rulebook publication · DR Payments and SEPA professional assessment2026.10