> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.redpincompany.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.redpincompany.com/_mcp/server. # UK Confirmation of Payee (CoP) Regulations This guide explains how to handle various [UK Confirmation of Payee (CoP)](https://www.wearepay.uk/what-we-do/overlay-services/confirmation-of-payee/) 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**](/api-reference/customers/api-integration/recipients/add-a-new-recipient) Runs a CoP check with the recipient’s bank when a new UK recipient is added. * [**Update Recipient API**](/api-reference/customers/api-integration/recipients/update-a-recipients-account) Re-validates details whenever an existing UK recipient is updated. * [**Create Payment API**](/api-reference/customers/api-integration/payments/create-payment) 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](/api-guide/regulatory-guides/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: **`Create/Update Recipient Response`** ```json title="Create/Update Recipient Response" { "code": "ANNM", "description": "Payee's Bank has performed the matching and confirms it is not a match", "recipient_check": { "request_identifier": "123456789", "event_id": "AG-435435454435" } } ``` **`Create Payment Response`** ```json title="Create Payment Response" { "code": "550e8400-e29b-41d4-a716-446655440091", "description": "Recipient Verification Error", "details": { "recipients": [ { "code": "ANNM", "description": "Payee's Bank has performed the matching and confirms it is not a match", "recipient_id": "REC-001", "recipient_check": { "request_identifier": "123456789", "event_id": "AG-435435454435" } }, { "code": "PANM", "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.", "recipient_id": "REC-002", "recipient_check": { "request_identifier": "123456790", "event_id": "AG-435435454436" } } ] } } ``` 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 **`Create/Update Recipient Request`** ```json title="Create/Update Recipient Request" { "... previous payload ...", "confirm_recipient": { "customer_action": "override", "request_identifier": "123456789", "event_id": "AG-435435454435" } } ``` **`Create Payment Request`** ```json title="Create Payment Request" { "... previous payload ...", "recipient_details": [ { "recipient_id": "REC-001", "amount": { "currency": "EUR", "value": 50000 }, "payment_reference": "PROPERTY_DOWN_PAYMENT", "confirm_recipient": { "customer_action": "override", "request_identifier": "123456789", "event_id": "AG-435435454435" } }, { "recipient_id": "REC-002", "amount": { "currency": "EUR", "value": 25000 }, "payment_reference": "PROPERTY_CLOSING_COSTS", "confirm_recipient": { "customer_action": "override", "request_identifier": "123456790", "event_id": "AG-435435454436" } } ] } ``` 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:** ```json { "code": "ANNM", "description": "Payee's Bank has performed the matching and confirms it is not a match", "recipient_check": { "request_identifier": "123456789", "event_id": "AG-435435454435" } } ``` **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:** ```json { "code": "MBAM", "description": "Payee's Bank has performed the matching and confirms it is a close match", "recipient_check": { "request_identifier": "123456789", "suggested_recipient_name": "John Doe", "event_id": "AG-435435454435" } } ``` **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:** ```json { "code": "BANM", "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.", "recipient_check": { "request_identifier": "123456789", "event_id": "AG-435435454435" } } ``` **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:** ```json { "code": "PANM", "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.", "recipient_check": { "request_identifier": "123456789", "event_id": "AG-435435454435" } } ``` **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:** ```json { "code": "BAMM", "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", "recipient_check": { "request_identifier": "123456789", "suggested_recipient_name": "John Doe", "event_id": "AG-435435456435" } } ``` **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:** ```json { "code": "PAMM", "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", "recipient_check": { "request_identifier": "123456789", "suggested_recipient_name": "John Doe", "event_id": "AG-435435456435" } } ``` **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:** ```json { "code": "AC01", "description": "Account does not exist in the Payee Bank's books", "recipient_check": { "request_identifier": "123456789", "event_id": "AG-435435456435" } } ``` **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:** ```json { "code": "IVCR", "description": "The Payee's Bank was unable to locate the customer account based on the secondary reference data contained within the payment reference field", "recipient_check": { "request_identifier": "123456789", "event_id": "AG-435435456435" } } ``` **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:** ```json { "code": "OPTO", "description": "Payee has been opted out of the CoP service by the Payee's Bank", "recipient_check": { "recipient_identifier": "123456789", "event_id": "AG-435435456435" } } ``` **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:** ```json { "code": "CASS", "description": "The Payee's account has been switched using the Current Account Switch Service (CASS)", "recipient_check": { "request_identifier": "123456789", "event_id": "AG-435435456435" } } ``` **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:** ```json { "code": "SCNS", "description": "The Payee ASPSP has incorrectly received a CoP request for a sort code that does not belong to then", "recipient_check": { "request_identifier": "123456789", "event_id": "AG-435435456435" } } ``` **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:** ```json { "code": "ACNS", "description": "Account not supported for CoP by the Payee's ASPSP", "recipient_check": { "request_identifier": "123456789", "event_id": "AG-435435456435" } } ``` **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