Skip to main content

Introduction

The Verification of Payee (VoP) is a service that allows you to verify the beneficiary (creditor) identity during banking transactions. The main goal of VoP is to reduce the risk of errors and fraud in payment operations, ensuring funds are sent to the correct recipient.

How it works​

  1. Beneficiary identity check: when a payer initiates a payment, the system verifies whether the beneficiary name (or other identifiers such as a VERLEI and an IBAN) matches the banking data on record.
  2. Interaction between PSPs: the verification request is exchanged between the requesting PSP (e.g., the payer’s bank) and the responding PSP (the beneficiary’s bank). The responding PSP validates the data and returns a match outcome.
  3. Identification methods: different identification methods can be used for the beneficiary, including:
    • Name + IBAN (natural person)
    • Identifier code + IBAN (legal entity)

Benefits​

  • Error reduction: helps prevent mistakes in beneficiary details (e.g., typos in the name or IBAN).
  • Fraud prevention: reduces the risk of sending funds to the wrong recipient, mitigating payment fraud scenarios.
  • Compliance: supports banking regulations and EU directives, including eIDAS requirements for security and strong authentication.

In short, VoP is an essential tool to improve security, reliability, and efficiency in banking transactions by enabling accurate and secure beneficiary verification before processing the payment.

vop-schema

Response values​

The Verification of Payee (VoP) service returns an outcome that indicates the level of correspondence between the beneficiary provided by the requester and the banking/identification data held by the responding PSP. Correctly interpreting the response is key to deciding whether the payment can proceed safely or whether additional actions are required.

Below is the complete list of allowed values:

  1. Exact match (MTCH)

    • Description: the data provided in the verification request matches exactly what is recorded by the beneficiary’s bank.
    • Requester behavior: the payment can be authorized and continued without additional checks.

  2. Close match (CMTC)

    • Description: there is a partial correspondence between the data sent by the requester and what is stored by the responding PSP (e.g., partial match on beneficiary name and/or IBAN).
    • Requester behavior: the requester may decide not to proceed, or ask the payer/beneficiary to further confirm details. Additional checks may be required.

  3. No match (NMTC) - Description: the beneficiary data (name, IBAN, or other identifier) does not match what is recorded by the responding PSP. - Requester behavior: the requester should stop the transaction and inform the payer that the beneficiary details are incorrect, and collect the correct data before retrying.

  4. Verification check not possible (NOAP)

    • Description: the responding PSP is not able to perform the requested check (e.g., technical issues, data not available, regulatory/operational constraints).
    • Requester behavior: the requester should inform the payer that the verification could not be performed. The requester may offer the payer the option to retry the VoP check for the intended payment.

  5. System error (ERR)

    • Description: a technical error occurred (e.g., missing connectivity or internal processing issue).
    • Requester behavior: retry the operation or contact the service provider to resolve the technical problem.

Authentication via eIDAS certificate​

For VoP APIs, authentication and transaction security are critical to ensure data protection and that operations are executed only by authorized entities.

In financial contexts such as VoP, strong authentication aligned with eIDAS (Electronic Identification, Authentication and trust Services) is typically required.

Key characteristics of an eIDAS certificate:

  • an electronic certificate used to securely authenticate an entity
  • contains information such as the entity name (GURN) and an associated public key
  • issued by a trusted service provider recognized and certified at EU level

VoP APIs must be protected against unauthorized access. When interacting with these APIs, strong authentication is applied, typically via mutual TLS (mTLS). Main steps:

  1. Obtain the certificate - the entity that wants to access the VoP API must obtain a digital certificate issued by an eIDAS-compliant trust service provider - the certificate is issued together with a private key that must be kept secret and secure
  2. Certificate-based authentication - during the interaction, the calling entity (e.g., a bank/PSP) sends an API request - the system uses the caller’s eIDAS certificate (and the related private key) to perform mutual authentication in the TLS flow
  3. Exchange and validation - the server validates the certificate (trusted authority chain) and checks that the caller is present in the EDS lists 4. Transaction completion - if the certificate is valid, the request is processed and a response is returned - otherwise, access is denied or an authentication error is returned

Fabrick VoP​

Fabrick provides products and support to integrate VoP both on the requester side and on the responding side. Depending on your needs, refer to the relevant technical documentation.