Confirmation of Payee and the fight against fraud

Confirmation of Payee, known as CoP, is a service that checks whether the name entered by the payer matches the name on the account that the sort code and account number identify, and it is now a standard part of the UK payment journey. When a customer sets up a new payee, the bank sends the name, sort code and account number to the payee bank, which returns one of four responses, the name matches, the name is a close match and the correct name is shown, the name does not match, or the account cannot be checked. The payer then decides whether to proceed. A no match response is a strong warning sign, because it often means the sort code or account number was typed wrong, or the payer is being tricked into paying a fraudster. The four responses each need a different user experience, and the analyst must design all four. A match proceeds silently, because the name and the account agree. A close match shows the correct name and asks the payer to confirm, because the payer may have misspelled the name or used a nickname. A no match shows a clear warning that the name does not match the account, and asks the payer to check the details by a trusted route before proceeding. An account that cannot be checked, because the payee bank does not support Confirmation of Payee or the account type cannot be checked, shows a neutral message that the check could not be completed, and asks the payer to be careful. A warning the customer clicks through without reading is no warning at all, so the no match screen must be impossible to miss and hard to dismiss. The matching logic is more subtle than a simple string comparison. The payee bank compares the name the payer typed with the name on the account, allowing for differences in case, spacing, punctuation and common abbreviations, and for the difference between a personal name and a business name. A payment to a business must match the business name, not the name of the person who runs it. A payment to a joint account must match one of the account holders. A payment to a trading name must match the trading name where the bank holds it. The analyst should confirm with the Confirmation of Payee provider which matching rules apply, and should test the edge cases: a hyphenated surname, a business with a trading name, a joint account, and a name with an accent. The reimbursement rules for authorised push payment fraud are a second layer of protection that the analyst must understand. Under the rules set by the Payment Systems Regulator, which took effect on 7 October 2024, banks must reimburse victims of authorised push payment fraud in defined circumstances, with the cost shared equally between the sending and receiving banks, a 50-50 split. The maximum reimbursement is 85,000 pounds per claim, and the bank must reimburse within five business days of the claim. The rules have exceptions, for example where the customer acted with gross negligence, where the payment was to an account the customer controlled, or where the claim is a civil dispute rather than a fraud, but the general principle is that the victim is protected. This changes the economics of fraud for banks: preventing a fraudulent payment is cheaper than reimbursing it, so banks invest heavily in warnings, in checks, and in slowing down payments that look risky. A worked example shows how the reimbursement works. A customer is tricked into sending 20,000 pounds to a fraudster's account through Faster Payments. The customer reports the fraud to their bank, and the bank investigates. The fraud is confirmed as authorised push payment fraud, and the customer is not grossly negligent. The sending bank reimburses the customer 20,000 pounds within five business days, and then recovers 10,000 pounds from the receiving bank under the 50-50 split. The receiving bank bears 10,000 pounds because it held the fraudster's account and should have detected the mule activity. The analyst must record the evidence for the claim: the Confirmation of Payee result, the warning shown, the customer's decision, and the timestamps, because that record is what the bank needs to assess the claim and to recover its share. CoP also shows how a payment system evolves to meet a new threat. Faster Payments was built for speed, and speed made fraud harder to stop, because a payment that settles in seconds cannot be recalled. The industry responded not by slowing the system down, but by adding a check before the payment is sent, so that the customer has the information they need to make a good decision. The lesson for the analyst is that fraud prevention belongs at the start of the flow, not at the end. A warning shown after the money has gone is useless; a warning shown before the customer confirms the payment can save them. The best payment designs make the safe choice the easy choice, and CoP is a good example of that principle in action. Other fraud controls sit alongside Confirmation of Payee, and the analyst should design for them as a set. Velocity checks catch a burst of payments to new payees in a short time. Device checks catch a payment from a device the customer has never used. Behavioural checks catch a payment that does not match the customer's normal pattern, for example a large payment to a new payee at 3am. Payee risk scoring flags accounts that have received fraud reports before. The analyst should confirm with the fraud team which controls apply to each payment type, what happens when a control triggers, and whether the payment is stopped, slowed or flagged for review. A payment that is stopped must tell the customer why, and a payment that is slowed must tell the customer when it will complete. The analyst checklist for Confirmation of Payee and fraud has five items. First, the four CoP responses, each with a designed user experience and a recorded result. Second, the reimbursement rules, with the 85,000 pound maximum, the 50-50 split and the five business day deadline stated in the operations manual. Third, the evidence record, capturing the CoP result, the warning shown, the customer's decision and the timestamps for every payment to a new payee. Fourth, the other fraud controls, with the trigger and the action for each one. Fifth, the customer communication for a stopped or slowed payment, stating what happened, why, and what the customer should do next. A fraud design that answers all five is a design that protects the customer and protects the bank.