The EU Instant Payments Regulation requires a payment service provider to check that the payee's name matches the account before the payer authorises a euro transfer. An AI agent can prepare the payment and run the check, but it cannot decide what to do on a mismatch. That choice belongs to the payer, or a named person acting for them.
What does verification of payee require?
The Instant Payments Regulation requires providers that offer euro credit transfers to offer instant ones, and to provide a payee verification service. Before the payer authorises, the payer's provider sends the payee's name and account identifier to the payee's provider, which checks them against its records. The check covers regular euro credit transfers as well as instant ones. Our explainer on what payee name verification is sets out the basics.
The result comes back in seconds and falls into one of four outcomes:
- Match. The name fits the account.
- Close match. The name is nearly right, and the payer is shown the name actually held on the account.
- No match. The name does not fit the account.
- Check not possible. The payee's side could not verify.
After a close match, no match or failed check, the payer is told and may still choose to authorise. The rule informs the payer's decision; it does not make it for them. If the provider fails to run the check properly and the payer suffers a loss as a result, the provider can be liable. Business customers sending payments in bulk can, in some cases, opt out of the check.
Who does it apply to?
Payment service providers in the EU that offer euro credit transfers: banks, e-money institutions and payment institutions. Their customers, consumers and businesses alike, receive the result. Because the check is a provider duty, a business that uses an agent to prepare its payments is relying on its bank's service, while a bank that uses an agent in its own payment operations must make sure the agent does not bypass the check. For the broader context, see what instant payments are.
What changes when an agent prepares the payment?
The check was designed around a person reading a warning and pausing. An agent reads the warning as data. Unless its bounds say otherwise, it may treat "close match" as good enough, correct the name to whatever the payee's bank returned, and proceed.
That is the specific risk. A close match on a fraudulent account often looks like a typo. An agent optimised to complete payments will "fix" it. A person, shown the actual name, might notice it is a different company altogether.
So the design rules are simple:
- The agent may prepare the payment and request the verification at depth 2 or above.
- On a match, the payment continues within the agent's other bounds.
- On a close match, no match or check not possible, the agent stops. It must not change the payee name to the one returned, and it must not authorise.
- The payment is held for the payer, or for a named person with authority over the payment, with the result and the context in front of them.
Our piece on verification of payee mismatches goes further into what the agent may say and record.
How do you meet the requirement with an agent in the flow?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Check runs before authorisation | Agent cannot reach authorisation without a stored verification result | Verification result attached to each payment record |
| Payer is informed of the result | Mismatch result and the returned name shown to the payer or approver, unedited | Display record and approver view |
| Payer decides on a mismatch | Close match, no match and not-possible results hold the payment for a named person | Hold record with decision and decider |
| Agent cannot alter the payee | The agent has no permission to overwrite payee names after a check | Permission configuration and blocked attempts |
| Bulk opt-outs are deliberate | Any opt-out for batch payments approved by a person and reviewed | Opt-out records with approver |
| Irreversibility is respected | The verified payment then meets amount, new-payee and authentication controls | Verdict record showing every bound checked |
Mismatches also feed operations. Repeated close matches on the same supplier suggest stale master data, which a person should fix at source. Our playbook on how to handle instant payment exceptions with an AI agent covers the follow-up work.
What will a supervisor or auditor ask?
- Can any payment reach authorisation without a verification result?
- Show us three close-match payments. Who decided, and what did they see?
- Can the agent change a payee name after the check?
- Which customers have opted out of verification for bulk payments, and who approved it?
- How do you know the agent presents the result to the payer unaltered?
- After verification, what other controls apply before money moves?
What does the rule not cover?
Verification of payee checks names, not intentions. A payer who is tricked into paying a fraudster's correctly named account gets a match. The check does not replace fraud monitoring, authentication or limits, which our piece on instant payments and irreversibility controls covers. It does not apply to non-euro payments under this Regulation, though other markets run their own name-checking services. For what banking agents may do more broadly, see AI agents in banking.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
In Pryme, a verification result arrives at the agent stamped as an external claim, and an external claim cannot authorise a payment. Any result other than a match turns the verdict to held, naming the person who must decide. The agent has no capability to rewrite a payee name, so the safe path is also the only path.
Questions people ask
Can an agent proceed on a close match if the amount is small?
Not on its own authority. A close match is exactly where fraud hides, and small amounts are often tests. Hold it for the payer or a named person.
Does a match mean the payment is safe?
No. It means the name fits the account. The payer may still be paying a fraudster whose account is correctly named, so other controls must still run.
Who is liable if the agent skips the check?
The provider has the duty to run the check, and it can bear the loss when it fails to. Designing the agent so it cannot skip the check protects the provider as much as the payer.