Why Scams Still Pass a Confirmation of Payee Match

TL;DR: Payee verification checks that the name a payer entered matches the account holder's name. It cannot tell you whether the payer is the legitimate account holder, stole the name, or coerced the account holder to give them that name. Because of this simple oversight, a scam can pass the check and keep running. Scam losses are identified and recorded as isolated incidents, but without insight into the scam network behind that incident, the same accounts, identities and devices can be used against you in the future. Identifying that network means understanding the five layers beneath a reported payment, or the "Scam Iceberg". The receiving account is the first place to look.

What percentage of your confirmed scam cases were linked to another case? Almost no institution can answer that from current reporting, because each case arrives as one clean payment: correct credentials, the right device and, where payee verification was live, a name that matched the account.

Knowing how your cases connect can help you identify potential mule accounts, scam networks and entry points that need stronger controls before losses continue. Your existing controls are the first place to look for that answer, because a control that checks one payment at a time cannot show how cases connect.

Confirmation of Payee is one of those checks: many institutions already run it, and it deserves credit for what it covers.

What Confirmation of Payee covers

Pay.UK reports that over 300 organizations have implemented the service for UK domestic payments, and that more than 2 million checks are completed every day. The check compares the name a payer entered with the account holder's name. Pay.UK describes the service as designed to help reduce misdirected payments, which makes it a dependable layer against money that lands in the wrong account by mistake.

A check runs when a payer sets up a new payee or changes the details of an existing payment, and Pay.UK says the service can be offered across these areas:

• Payment types: UK domestic CHAPS, Faster Payments and Bacs payments, both debit and credit.
• Account types: personal, business and joint accounts, including accounts that need a reference such as a building society roll number or a credit card number.
• Details checked: the payee name, sort code and account number, plus the account type and any reference the account requires.
• When it runs: new payees and amended details. Payments to existing recipients and standing orders may not be checked, although individual institutions can choose to check them.

The details the payer enters are compared with the details held on the account at the receiving institution. Confirmation of Payee is an API-based, peer-to-peer service with no central infrastructure, and a directory identifies the participating organizations, so the answer comes from the receiving institution's own account records. The payer then sees one of four results: a match, a close match that shows the actual account name to check, no match, or unavailable, for example after a timeout, a customer opt-out or an account that does not exist.

Across the payments and accounts it covers, the check confirms that the name entered matches the name on the receiving account. What it leaves unchecked still can affect your bottom line, however, and liability for scam reimbursement has increasingly shifted to the sending institution.

Where Confirmation of Payee stops

Confirmation of Payee compares the name a payer types with the name on the receiving account, so the result depends on where that name came from. In a scam, the payer is given the name to type, and it belongs to a mule account. If the check returns a match, the payment goes through.

The check covers only two steps in the middle: the payer entering the name, and the name matching the account holder's, and doesn't address other variables that can point to a scam or the network behind it:

• How quickly credits arrive compared with the purpose the account gave when it was opened.
• How quickly money leaves the account after a credit arrives.
• The ratio of money coming in to money going out over the account's life.
• How long the account sat dormant before its first large credit, judged against its stated purpose.
• Identity details, such as a name, address or phone number, that the account shares with other applications while the rest differs.
• Other accounts opened from or accessed by the same device or session.
• Where the money goes next, including onward transfers to further accounts, institutions and rails.
• Whether another institution has already reported the account.

None of these signals appear in a name match. The check also cannot tell whether the payer was given the name for an honest reason, so a match says nothing about what the account does next.

The receiving account is the first place to look, because every scam payment lands in one. How that account behaves once it is open and receiving money is Layer 1, the first of the five layers in the Guide “Can You See the Network Behind Your Scam Losses?”

Three things to record about your own controls

Coverage varies from one institution to the next, and the signals above are easier to test once you know where each of your own controls stops. A short written record of what yours includes gives you facts to work from before the next review.

Start with three questions:

1. Which payee verification service is live on which rails and payment types, because coverage can differ by payment type. Where the check is not live, a payer gets no name match at all.
2. Whether your fraud rules score inbound credits at all, or only outbound debits. Scam money arrives at the receiving institution as an inbound credit, and monitoring on the inbound side of an account shows what outbound monitoring cannot.
3. Whether your onboarding checks and your payment monitoring share any identifiers, or run on separate data. Without a shared identifier, you cannot measure the link between how an account was opened and the payment fraud that follows.

The third answer decides how much of the work you can finish with a join, a query that links records from different systems, and how much needs new work. If the two systems already share an identifier, you may be able to test the receiving account this quarter with data you hold. Note who owns each answer as well, because payee verification, fraud rules and onboarding often sit with different teams, and each needs to be part of the next step.

In practice, a gap in these answers looks like this: you learn that an account was a mule account only from an inbound fraud report sent by another institution, with no signal from your own monitoring before the report arrived. The three answers above show whether your own data could have raised a flag first.

Closing that gap matters beyond your own losses. Inbound monitoring protects other institutions' customers as well as your own, so the case for acting rests on repeat exposure and regulatory duty as well as direct loss avoidance.

What to examine next

Once you know where payee verification stops, the next layers to examine are identity assembly, device and session reuse, money movement and cash-out, and network coordination. FraudNet's guide “Can You See the Network Behind Your Scam Losses?” gives you three checks for each layer to run against your own cases, so you can see where your data already holds the answer and where it does not.

With identity, device and behavior brought together in one risk score through FraudNet's Customer Risk Intelligence solutions, your team operates from a centralized, orchestrated view of the receiving account.

To work through all five layers, download the Guide: Can You See the Network Behind Your Scam Losses? To see how FraudNet can help your team address the gaps you find, book a demo.