Verification of Payee

Introduction

This guide provides comprehensive information about the Verification of a Payee (VoP) feature, including key concepts and the required API endpoints to integrate it into your banking solution.

What is Verification of a Payee?

Verification of a Payee (VoP) is an account name-checking service designed to enhance customer confidence when initiating SEPA Credit Transfers (SCT) or SEPA Instant Credit Transfers (SCT Instant). VoP helps reduce fraud and misdirected payments by verifying that the recipient’s name and IBAN match. It is mandated by the European Payments Council (EPC) and follows the standards outlined in the Verification of a Payee Rulebook. VoP is mandatory for all:

  • SEPA Credit Transfers (SCT)
  • SEPA Instant Credit Transfers (SCT Inst)
  • Associated payment types such as Scheduled Transfers and Batch Transfers
info

For Batch Transfers, your business customers may choose to opt out of the VoP service. However, you are still obligated to:

  • Inform the customer about the risks of sending payments without verification.
  • Allow opted-out customers to opt back in to the VoP service at any time.
  • Provide flexibility for bulk transactions while ensuring customers retain control over their verification preferences.

How It Works

VoP is required before a customer can authorise a payment. During the process:

  1. The customer enters the recipient’s full name and IBAN.
  2. Solaris forwards this information to the recipient’s bank using the VoP schema.
  3. The recipient bank checks if the details match and returns a result to Solaris.
  4. Solaris then relays the result back to your application.

Possible VoP Results

MATCH :The recipient’s name and IBAN match exactly with the records at the recipient’s bank.
CLOSE_MATCH :There is a minor discrepancy between the entered name and the account holder’s actual name. The recipient’s bank returns the correct name, which Solaris passes on to you. You must notify your customer of the result and display the correct account name provided by the recipient’s bank.
NO_MATCH :The provided name does not correspond with the IBAN at all. You are required to inform your customer immediately that the transfer may be directed to an incorrect or unintended recipient if they proceed.
VERIFICATION_NOT_POSSIBLE :The verification process could not be completed. This may be due to an invalid IBAN, technical errors, or issues with the recipient’s bank or the VoP schema. You are required to inform your customer immediately that the transfer may be directed to an incorrect or unintended recipient if they proceed.

note

The recipient bank is solely responsible for determining the match. Solaris cannot influence or guarantee the matching logic used. However, all SEPA-region banks follow the EPC's recommended matching rules.

Product Flow for Verification of a Payee

To view a larger version of this diagram, right-click on the image and click "Open in a new tab."

Diagram: Verification of Payee product flow

Initiating Verification of a Payee:

Initiation of the Verification of a Payee should always be prior to creating a credit transfer. It can be performed by calling the POST Verification of a Payee endpoint as specified in the URL below:

Request URL

Copy
Copied
POST /v1/verifications-of-payee

In the request body provide the following mandatory attributes:
name: the full name of the recipient
IBAN: the IBAN of the recipient

Request Example

Copy
Copied
{
    "iban": "DE89370400440532013000",
    "name": "John Doe"
}

In the response, Solaris will provide you with the unique verification of a payee identifier, the name of the payee you verified, the result of the verification, when the verification of a payee was created and until when it's valid.

Response Example

Copy
Copied
{
    "id": "123e4567-e89b-12d3-a456-426614174000",
    "payee": {
        "iban": "DE89370400440532013000",
        "name": "John Doe"
    },
    "result": {
        "status": "CLOSE_MATCH",
        "suggested_name": "John M. Doe",
        "error_reason": "string"
    },
    "created_at": "2025-04-16T12:34:56Z",
    "expires_at": "2025-04-16T12:39:56Z"
}

You then must display the result of the verification of a payee to your customer, who can then decide, whether they want to continue with the credit transfer creation, adjust the input (for instance in case of a CLOSE_MATCH maybe the customer wants to perform the verification of a payee again), or discard the creation of the credit transfer.

Validation Rules

When a credit transfer is initiated, Solaris performs validation checks on the verification_of_payee_id included in the request. To ensure a seamless customer experience and prevent transfer failures, the following rules must be observed:

  1. The verification_of_payee_id must exist and be recognized by the Solaris system.
  2. Each verification_of_payee_id is single-use only. Once it has been included in a credit transfer request and received by Solaris, it is marked as consumed and cannot be reused in future transactions.
  3. The ID is valid for 20 minutes from the time of its creation. Any attempt to use an expired ID will be rejected. This time-bound validity ensures the relevance and security of the verification result.

Error Handling

If the verification_of_payee_id is missing, invalid, expired, or already used, Solaris will return a 400 Bad Request error. This indicates that the credit transfer request has failed due to an issue with the provided verification ID. Always validate the status and age of the verification_of_payee_id before submitting the transfer request to avoid errors and improve the customer experience.

Risk Ownership:

In cases of reported fraud related to a Verification of Payee (VoP) result, risk ownership depends on the origin of the issue:

  • If the issue is caused by Solaris or the recipient bank (e.g. an incorrect match result or a technical failure), the responsible party will bear the associated costs.
  • If a correct VoP result is returned—such as NO_MATCH, VERIFICATION_NOT_POSSIBLE

    1. Present the result to your customer.
    2. Clearly communicate that authorising the credit transfer may result in funds being sent to an account not held by the intended recipient.
  • In case of a CLOSE_MATCH partner is obliged to display the correct name that is sent as a part of the API response to the customer.
attention
  • If you fail to provide this warning and the customer completes the transfer, you assume liability for any resulting loss.
  • If the warning was properly communicated and the customer still proceeded, the customer bears the associated risk and costs.
  • If you include a valid verification_of_payee_id when initiating the credit transfer, we assume the VoP result was accurately presented to the customer and they made an informed decision to proceed. In such cases, Solaris bears no liability.

Retrieving the result of a Verification of a Payee:

You can retrieve the result of previously performed Verification of a Payee id by its unique identifier. You can do so by calling the below mentioned GET Verification of Payee endpoint in the request URL.

Request URL

Copy
Copied
GET /v1/verifications-of-payee/{id}

In the response, Solaris will provide you with the unique verification of a payee identifier, the name of the payee you verified, the result of the verification, when the verification of a payee was created, until when it's valid as well as with the information on which process the vop was used, in case it was used.

Response Example

Copy
Copied
{
    "id": "123e4567-e89b-12d3-a456-426614174000",
    "payee": {
        "iban": "DE89370400440532013000",
        "name": "John Doe"
    },
    "result": {
        "status": "CLOSE_MATCH",
        "suggested_name": "John M. Doe",
        "error_reason": "string"
    }
    "created_at": "2025-04-16T12:34:56Z",
    "expires_at": "2025-04-16T12:39:56Z"
}

Sandbox Testing

To simulate various results on sandbox for Verification or Payee id, please provide the below mentioned values when calling the POST Verification of a Payee endpoint:

VoP Result Name IBAN
MATCH "John M. Doe" "DE30110101990000000001"
CLOSE_MATCH "John Doe" "DE30110101990000000001"
NO_MATCH "John" "DE30110101990000000001"
VERIFICATION_NOT_POSSIBLE "John M. Doe" Any other valid IBAN on Sandbox that is not "DE30110101990000000001"