UK Confirmation of Payee (CoP) Regulations

This guide explains how to handle various UK Confirmation of Payee (CoP) mismatch errors returned by our APIs.

The goal is to ensure your application can:

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

Where CoP Checks Apply

CoP checks are automatically triggered for UK recipients across the following API flows:

• Create Recipient API Runs a CoP check with the recipient’s bank when a new UK recipient is added.

• Update Recipient API Re-validates details whenever an existing UK recipient is updated.

• Create Payment API Performs a new CoP check if:

  • More than 6 months have passed since the last check, or
  • The payment_reference provided in recipient_details is new or differs from the one already stored for that recipient.

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

Resolve a Confirmation of Payee Mismatch

Anytime we run a Confirmation 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, will need to display the error to the user, ask them for the best course of action, and then repeat the initial request, now using the request_identifier and the event_id provided with the error payload, to complete the action.

Here is a sample error payload:

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

Details of each case are outlined below. Regardless of the case, once an action is selected by the user, the follow up request should look like the following:

New request body

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

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

Case 1: No match

Error code: ANNM

Sample response:

1
{
2
  "code": "ANNM",
3
  "description": "Payee's Bank has performed the matching and confirms it is not a match",
4
  "recipient_check": {
5
    "request_identifier": "123456789",
6
    "event_id": "AG-435435454435"
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 above, with confirm_recipient.customer_action: "override"

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

Case 2: Close match

Error code: MBAM

Sample response:

1
{
2
  "code": "MBAM",
3
  "description": "Payee's Bank has performed the matching and confirms it is a close match",
4
  "recipient_check": {
5
    "request_identifier": "123456789",
6
    "suggested_recipient_name": "John Doe",
7
    "event_id": "AG-435435454435"
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:

If the user chooses to accept the suggestion, repeat the request as described above, with confirm_recipient.customer_action: "update"

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

Case 3: Recipient is a Business account

Error code: BANM

Sample response:

1
{
2
  "code": "BANM",
3
  "description": "Payer's Bank indicated that the payer intends to pay a personal account, but the actual account is a business account and the name matches.",
4
  "recipient_check": {
5
    "request_identifier": "123456789",
6
    "event_id": "AG-435435454435"
7
  } 
8
}

How to handle it:

You must inform the user that the name was matched, but the account is a Business account and not a Personal account. The user has the option to update the recipient type to Business, or continue with the original details they provided:

If the user chooses to update the recipient type, repeat the request as described above, with confirm_recipient.customer_action: "update"

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

Case 4: Recipient is a Personal account

Error code: PANM

Sample response:

1
{
2
  "code": "PANM",
3
  "description": "Payer's Bank indicated that the payer intends to pay a business account, but the actual account is a personal account and the name matches.",
4
  "recipient_check": {
5
    "request_identifier": "123456789",
6
    "event_id": "AG-435435454435"
7
  } 
8
}

How to handle it:

You must inform the user that the name was matched, but the account is a Personal account and not a Business account. The user has the option to update the recipient type to Personal, or continue with the original details they provided:

If the user chooses to update the recipient type, repeat the request as described above, with confirm_recipient.customer_action: "update"

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

Case 5: Recipient is a Business account, and account name is a close match

Error code: BAMM

Sample response:

1
{
2
  "code": "BAMM",
3
  "description": "Payer's Bank indicated that the payer intends to pay a personal account, but the actual account is a business account and the name is a close match",
4
  "recipient_check": {
5
    "request_identifier": "123456789",
6
    "suggested_recipient_name": "John Doe",
7
    "event_id": "AG-435435456435"
8
  }
9
}

How to handle it:

You must inform the user that the name was a close match, display the suggestion, and also that the account is a Business account and not a Personal account. The user has the option to update the recipient type to Business, and accept the name suggestion, or continue with the original details they provided:

If the user chooses to update the recipient name and type, repeat the request as described above, with confirm_recipient.customer_action: "update"

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

Case 6: Recipient is a Personal account, and account name is a close match

Error code: PAMM

Sample response:

1
{
2
  "code": "PAMM",
3
  "description": "Payer's Bank indicated that the payer intends to pay a business account, but the actual account is a personal account and the name is a close match",
4
  "recipient_check": {
5
    "request_identifier": "123456789",
6
    "suggested_recipient_name": "John Doe",
7
    "event_id": "AG-435435456435"
8
  }
9
}

How to handle it:

You must inform the user that the name was a close match, display the suggestion, and also that the account is a Personal account and not a Business account. The user has the option to update the recipient type to Personal, and accept the name suggestion, or continue with the original details they provided:

If the user chooses to update the recipient name and type, repeat the request as described above, with confirm_recipient.customer_action: "update"

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

Case 7: Incorrect account number

Error code: AC01

Sample response:

1
{
2
  "code": "AC01",
3
  "description": "Account does not exist in the Payee Bank's books",
4
  "recipient_check": {
5
    "request_identifier": "123456789",
6
    "event_id": "AG-435435456435"
7
  }
8
}

How to handle it:

You must inform the user that the account does not exist. The user has to update the details in order to proceed with payment.

Case 8: Invalid reference number

Error code: IVCR

Sample response:

1
{
2
  "code": "IVCR",
3
  "description": "The Payee's Bank was unable to locate the customer account based on the secondary reference data contained within the payment reference field",
4
  "recipient_check": {
5
    "request_identifier": "123456789",
6
    "event_id": "AG-435435456435"
7
  }
8
}

How to handle it:

You must inform the user that the reference number is invalid. 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 above, with confirm_recipient.customer_action: "override"

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

Case 9: Opted out of Confirmation of Payee

Error code: OPTO

Sample response:

1
{
2
  "code": "OPTO",
3
  "description": "Payee has been opted out of the CoP service by the Payee's Bank",
4
  "recipient_check": {
5
    "recipient_identifier": "123456789",
6
    "event_id": "AG-435435456435"
7
  }
8
}

How to handle it:

You must inform the user that the recipient has chosen not to use Confirmation of Payee checks. 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 above, with confirm_recipient.customer_action: "override"

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

Case 10: Account has been switched

Error code: CASS

Sample response:

1
{
2
  "code": "CASS",
3
  "description": "The Payee's account has been switched using the Current Account Switch Service (CASS)",
4
  "recipient_check": {
5
    "request_identifier": "123456789",
6
    "event_id": "AG-435435456435"
7
  }
8
}

How to handle it:

You must inform the user that the recipient has switched accounts and these details are no longer valid. The user has to update the details in order to proceed with payment.

Case 11: Sort code not supported

Error code: SCNS

Sample response:

1
{
2
  "code": "SCNS",
3
  "description": "The Payee ASPSP has incorrectly received a CoP request for a sort code that does not belong to then",
4
  "recipient_check": {
5
    "request_identifier": "123456789",
6
    "event_id": "AG-435435456435"
7
  }
8
}

How to handle it:

The user should be informed that Confirmation of Payee could not be carried out because the recipient’s sort code doesn’t support this check.

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

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

Case 12: Account type not supported

Error code: ACNS

Sample response:

1
{
2
  "code": "ACNS",
3
  "description": "Account not supported for CoP by the Payee's ASPSP",
4
  "recipient_check": {
5
    "request_identifier": "123456789",
6
    "event_id": "AG-435435456435"
7
  }
8
}

How to handle it:

The user should be informed that Confirmation of Payee isn’t supported by the recipient’s financial institution.

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

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