How to handle payee name mismatch warnings with an AI agent

A close match, no match or failed check each need a plain explanation of what the result means and what the risk is. The agent gives it, helps the customer correct an obvious typo, and never encourages them past the warning. If anything suggests someone else is directing the payment, the agent stops and a fraud specialist calls the customer.

What is a payee name mismatch, and who owns the response?

Payee name verification checks the name a payer enters against the name on the receiving account before the payment is sent. In the EU, the Instant Payments Regulation requires payment service providers to verify the payee's name; the implications for agents are covered in Instant Payments Regulation verification of payee and AI agents. Other markets run similar checks.

The check returns one of four results. A match. A close match, often with the actual account name shown. No match. Or unable to check, when the receiving bank cannot answer. Each needs a different response. The control exists to catch two things: honest mistakes, and payments that a fraudster has persuaded the customer to send to an account that is not who they claim.

The head of payments owns the warning flow. Fraud owns the scam signals and the specialists who intervene. As the argument in name checks are only as good as what happens after a mismatch makes clear, the check itself is the easy part. For the wider frame, see our guide to AI agents in banking.

What does the agent do at each step, and at what depth?

1. Platform: runs the check. The agent does not run or interpret the matching; it receives the result. Evidence: result and timestamp.
2. Agent, depth 1: reads the context. Is this a new payee? Has the customer paid this account before? Is the amount unusual? Any open scam markers? Evidence: facts used.
3. Agent, depth 2: explains the result. In plain words, the same way every time: what the result means, and that if the name does not match, the money may go to someone other than intended and may not be recoverable. Evidence: the explanation given.
4. Agent, depth 2: offers a correction for close matches. If the customer recognises the returned name as the person they meant, they can update the payee name themselves. Evidence: correction made by the customer.
5. Agent, depth 1: listens for scam signals. "I was told the name would not match", "it is my adviser's account", "the bank told me to move my money", urgency, secrecy. Evidence: signals recorded.
6. Person, fraud specialist: intervenes on any signal. The payment is held and the customer is called. Evidence: held verdict and call record.
7. Customer: decides. Where no signal is present, the customer chooses whether to proceed, cancel or check with the payee, through their own authenticated channel. The agent does not decide for them. Evidence: the customer's decision.
8. Agent, depth 2: drafts follow-up guidance on how to confirm details directly with the payee. Evidence: message sent.

Which controls matter, and what evidence do they leave?

Neutral wording, approved by fraud. The agent cannot soften a warning or say "this happens a lot, it is usually fine". Evidence: explanation text matches the approved version.

The agent never proceeds for the customer. Confirming a payment after a warning is the customer's act. Evidence: confirmation comes from the customer's authenticated session.

Scam signals hold the payment. Evidence: held verdicts naming the signal.

Customer edits names, not the agent. If the agent changed payee names it would be changing who is paid. Evidence: payee name changes attributed to the customer. Whether an agent should ever add a payee itself is answered in whether an AI agent can add a new payee.

"Unable to check" is not a pass. Evidence: the same warning flow for no result as for no match.

What should you measure?

• Customers proceeding after no match, as a count over time.
• Scam reports on payments that proceeded after a warning. Each one is reviewed against the conversation.
• Close-match corrections, which show typos caught.
• Fraud interventions triggered by the agent's signal detection.
• Sampled conversations where the agent's wording drifted from the approved version.

Where does it usually go wrong?

The agent becomes reassuring. Asked "is it safe to go ahead?", it says yes. It should say it cannot confirm who owns the account.

Business names are dismissed. Trading names differ from legal names, so mismatches on business payments are waved through. Explain the difference and suggest confirming with the business.

Fraudsters pre-empt the warning. Customers are coached to expect a mismatch and to tell the bank it is fine. Coaching is itself the signal.

The warning repeats so often it stops working. If most payments show a warning, customers stop reading. Fix false mismatches at the source.

Explanations differ by channel. The app says one thing, the agent another. Use one approved wording; see whether an AI agent can handle a payee name mismatch for the wider position.