A verification of payee mismatch is the payment system telling you the name and account do not fit. An AI agent must treat it as a stop, not a puzzle. It may gather context and present the result unaltered, but the decision to proceed, correct or cancel belongs to the payer or a named person with authority.
What does the rule require on a mismatch?
The EU Instant Payments Regulation requires payment service providers to check the payee's name against the account before the payer authorises a euro credit transfer. Our explainer on what payee name verification is covers the mechanism. The check returns a match, a close match (with the name actually held on the account), no match, or a result that the check was not possible.
On anything but a match, the provider must tell the payer, and the payer may still choose to authorise. The rule does not block the payment. It moves the decision, with better information, to the payer. Our piece on the Instant Payments Regulation and verification of payee sets out the full requirement.
That design choice is why an agent must stop. The regulation hands the mismatch to a human judgement on purpose. An agent that resolves it on its own has removed the safeguard the rule created.
Who does it apply to?
The duty to run the check and inform the payer falls on payment service providers offering euro credit transfers. The decision on a mismatch falls on the payer. In practice that means three kinds of named person, depending on whose agent it is:
- A consumer's own agent: the consumer decides, on their own device.
- A business's finance agent: the person with payment authority under the business's approval policy decides.
- A provider's operations agent: a named payments officer decides, within the provider's procedures.
Other markets, including the UK, run their own name-checking services. The principle below applies to each of them.
Why must a mismatch stop the agent?
Because the most dangerous mismatches look harmless. Invoice redirection fraud works by giving a payer new bank details for a supplier they already pay. The fraudster's account is in a name that is close to the supplier's, or a trading name, or an individual's name with a plausible story. The verification result is a close match or no match, and the payee's provider returns the real account name.
An agent optimised to finish payments will reach for an explanation. "Close match: 'Northside Supplies Ltd' versus 'Northside Supply Limited'. Likely formatting difference. Proceeding." Sometimes that reasoning is right. When it is wrong, the money is gone in seconds.
A person can do things the agent cannot safely do. They can phone the supplier on a number from their own records. They can recognise that the returned name belongs to a different business. They can notice that the change request arrived the same week as a new invoice format. Our answer to whether an agent can handle a payee name mismatch gives the short version: it can prepare the case, not close it.
What may the agent do, and what must it not do?
The agent may: - hold the payment and route it to the named decider; - show the verification result and returned name exactly as received; - gather context: past payments to this payee, when the details changed and where the change came from; - draft a call-back request to the payee using contact details from verified records; - record the outcome and update supplier data once a person confirms.
The agent must not: - authorise or release the payment; - edit the payee name to match the returned name; - contact the payee using details from the same invoice or email; - treat a close match as a match; - add the account as a new trusted payee.
Adding payees is its own question, covered in our answer to whether an agent can add a new payee. The short version is that an agent may draft a new payee for approval but not commit one.
How do you meet the requirement with controls that hold?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Mismatch reaches a person | Any result other than a match sets the payment to held, routed to the named decider | Hold record with decider identity |
| Payer sees the true result | Result and returned name displayed unaltered | Captured display content |
| Agent cannot resolve on its own | No capability to edit payee names or release held payments | Permission configuration; blocked attempts |
| Context is gathered from trusted sources | Agent cites past payments and master data with their sources | Context pack attached to the hold |
| Decision is recorded | Decider's choice and reason recorded before release or cancellation | Decision log |
| Patterns are reviewed | Repeated mismatches on the same supplier trigger a master data review | Review tickets and outcomes |
Our playbook on how to handle payee name mismatch warnings with an agent walks through the steps.
What will a supervisor or auditor ask?
- Can any agent release a payment after a close match or no match?
- Show us three held payments: what the decider saw, what they decided and why.
- Where did the agent's context come from in each case?
- Can the agent change a payee's name or bank details?
- How do you spot suppliers with repeated mismatches?
What does the rule not cover?
A mismatch check catches the wrong name. It does not catch a fraudster who has opened an account in the right name, or a payer persuaded to pay a scam. Those need fraud monitoring, limits and authentication. The check also does not apply to non-euro payments under the EU Regulation. For the wider set of payment controls, see our guide to what AI agents in banking may and may not do.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Is a close match on a well-known supplier safe to pay?
Not without a person checking. Fraudsters choose names that look close to real suppliers. A call-back on a number from your own records settles it quickly.
Can the agent learn which mismatches are harmless?
It can flag patterns for review, such as a supplier whose trading name always triggers a close match. A person should fix the master data rather than letting the agent treat the warning as noise.
What if the decider is unavailable and the payment is urgent?
Route it to a named deputy under your approval policy. Urgency is a common pressure tactic in payment fraud, so the hold should not lift on its own.