SEPA Verification of Payee (VoP) Regulations

This guide explains how to handle Verification of Payee (VoP) mismatch errors for EUR payments in the SEPA region.

VoP checks serve as a vital safeguard for verifying account names, ensuring that payments within the EUR market (SEPA region) are routed to the correct recipients.

The goal is to ensure your application can:

• Detect when a VoP mismatch occurs
• Guide the end user with clear instructions
• Safely retry the request using the details returned in the error response.

Where VoP Checks Apply

VoP checks are automatically triggered for EUR recipients in the SEPA region in the following API flows:

• Create Recipient API - Runs a VoP check with the recipient’s bank when a new EUR (SEPA) recipient is added.

• Update Recipient API - Re-validates details whenever an existing EUR (SEPA) recipient is updated.

• Create Payment API - With the new regulation, in addition to verifying EUR (SEPA) recipient details when a recipient is created or updated, we are also required to repeat the Verification of Payee (VoP) check when a payment is created.

Note: VoP checks apply only to EUR recipients in the SEPA region. Other recipients are not affected by VoP; for UK recipients, see the CoP guide.

Resolve a Verification of Payee Mismatch

Anytime we run a Verification of Payee check and a mismatch occurs, an error is returned. In most cases, you will be able to resolve the issue by asking the user for feedback - more details below.

Based on the type of error, you need to display the error to the user, ask them for the best course of action, and then repeat the initial request using the request_identifier and event_id provided with the error payload.

Here is a sample error payload:

1
{
2
    "code": "NMTC",
3
    "description": "Payee's Bank has performed the matching and confirms it is not a match.",
4
    "recipient_check": {
5
        "request_identifier": "FR4010096000402181369432U54",
6
        "event_id": "AG-1757583881611"
7
    }
8
}

Details of each case are outlined below. Depending on the user’s selected action (override or update), the appropriate follow up request should be constructed as described in the following sections.

The sections below outline the details of each type of mismatch and how to handle it.

Case 1: No Match

Error code: NMTC

Sample response:

1
{
2
    "code": "NMTC",
3
    "description": "Payee's Bank has performed the matching and confirms it is not a match.",
4
    "recipient_check": {
5
        "request_identifier": "FR4010096000402181369432U54",
6
        "event_id": "AG-1757583881611"
7
    }
8
}

How to handle it:

You must display the error message to the user. The user has the option to continue anyway, or to update the details.

If the user chooses to continue anyway, repeat the request as described below, with confirm_recipient.customer_action: "override"

New request body for customer_action: “override”

1
{
2
  "... previous payload ...",
3
  "confirm_recipient": {
4
    "customer_action": "override",
5
    "request_identifier": "FR4010096000402181369432U54",
6
    "event_id": "AG-1757583881611"
7
  }
8
}

If the user updates the details, repeat the flow from the beginning

Case 2: Close Match

Error code: CMTC

Sample response:

1
{
2
    "code": "CMTC",
3
    "description": "Payee's Bank has performed the matching and confirms it is a close match.",
4
    "recipient_check": {
5
        "request_identifier": "FR4010096000402181369432U54",
6
        "suggested_recipient_name": "Olivier Bernard",
7
        "event_id": "AG-1757583918308"
8
    }
9
}

How to handle it:

You must display the suggestion to the user. The user has the option to accept the suggestion, or continue with the original details they provided:

When calling the Create Recipient or Update Recipient endpoints, setting confirm_recipient.customer_action to “update” and name to the suggested_recipient_name from the response will accept the suggestion without performing another VOP check.

This option is not available in the Create Payment API, recipients which receive this response can be updated using the Update Recipient call.

New request body for customer_action: “update”

1
{
2
  "... previous payload ...",
3
  "name": "Olivier Bernard",
4
  "confirm_recipient": {
5
    "customer_action": "update",
6
    "request_identifier": "FR4010096000402181369432U54",
7
    "event_id": "AG-1757583918308"
8
  }
9
}

If the user chooses to continue anyway, repeat the request as described below, with confirm_recipient.customer_action: "override"

New request body for customer_action: “override”

1
{
2
  "... previous payload ...",
3
  "confirm_recipient": {
4
    "customer_action": "override",
5
    "request_identifier": "FR4010096000402181369432U54",
6
    "event_id": "AG-1757583918308"
7
  }
8
}

Case 3: Not Applicable / VoP Check Not Possible

Error code: NOAP

Sample response:

1
{
2
    "code": "NOAP",
3
    "description": "Verification Check not possible.",
4
    "recipient_check": {
5
        "request_identifier": "FR4010096000402181369432U54",
6
        "event_id": "AG-1757584072094"
7
    }
8
}

How to handle it:

The user should be informed that verification check is not possible. The user has the option to update the details, or continue with the original details they provided:

If the user chooses to continue anyway, repeat the request as described below, with confirm_recipient.customer_action: "override"

New request body for customer_action: “override”

1
{
2
  "... previous payload ...",
3
  "confirm_recipient": {
4
    "customer_action": "override",
5
    "request_identifier": "FR4010096000402181369432U54",
6
    "event_id": "AG-1757584072094"
7
  }
8
}

If the user updates the details, repeat the flow from the beginning