How to verify new payees on high-value payments with an AI agent

New and changed payees are where payment fraud lives, so the agent checks every one before a high-value payment can be released. It traces how the details arrived, runs a payee name check where available, compares them with the supplier's history, and drafts the callback. A named person calls a number already on file, records the result and releases.

What is payee verification, and who owns it?

A high-value payment to a new beneficiary, or to an existing one whose bank details have just changed, is the moment fraudsters aim for. The classic pattern is an email, apparently from a supplier or a senior executive, saying that bank details have changed or that an urgent payment is needed. The payment goes, the real supplier is never paid, and the money is gone within hours.

In a bank, payment operations owns verification for customer payments, and treasury owns it for the bank's own. In a corporate, accounts payable usually does. Whoever owns it, the process has the same core: check where the details came from, confirm with someone you already know through a channel you already trust, and only then pay.

What are the steps?

1. Agent, depth 1: detects new or changed payees. Any payment above the high-value threshold to a payee added or changed within your look-back period.
2. Agent, depth 1: traces the source. How the details arrived: a portal entry, an email, a letter, an invoice. Whether the request came from a contact already on file, and whether the sender's address matches theirs exactly.
3. Agent, depth 1: runs a payee name check where the scheme offers one. In the EU, the Instant Payments Regulation requires payment service providers to verify the payee's name.
4. Agent, depth 1: compares with history. Previous payments to this supplier, its master data, the invoice, the country of the new account against the supplier's country.
5. Agent, depth 2: drafts the callback. The phone number from the master record, never from the request, and the questions to ask.
6. Person: makes the callback. And records who they spoke to, the number used and the answer.
7. Agent, depth 1: applies first-payment rules. A cooling-off period or a lower limit on the first payment to a new payee, if your policy sets one.
8. Person: releases. Only once the callback is on file.

Which controls apply, and what evidence does each leave?

Contact details from master data only. The callback number comes from records that existed before the change request. If the request itself supplied a new phone number, that number is not used. Evidence: the master record version used.

Callback before release. The release step checks for a filed callback result. A payment without one is refused, and the verdict names the bound that decided. Evidence: the callback record, with the caller's name and the time.

Name check results attached. Match, close match or no match, shown to the person releasing. A no-match is not overridden by the agent.

Source trail. The email headers or portal log showing where the change came from. Small differences in a sender's address are among the most useful signals.

First-payment limits in the bounds. Your first-payment rules sit in the customer's own limits, so the minimum chain applies them automatically.

The high-value payment release checklist sets out what the releasing person should see on screen before they act.

What should you measure?

• High-value payments to new payees released with a callback on file. Should match one for one.
• Callbacks that found the change was not genuine. The clearest evidence the process works.
• Name check mismatches, and how each was resolved.
• Payments delayed by verification, and by how long.
• Fraud losses on payments to new payees. Each loss is reviewed to find the step that failed.

Where does it usually go wrong?

Calling the number in the email. The fraudster answers. This is the single most common way callbacks fail. The agent's script must carry the master data number, and the person must use it.

Urgency. "The CEO needs this paid before the close of business." Urgency is a fraud signal, not a reason to skip a step. The agent should flag urgent language in the request.

Small differences missed. A domain with one letter changed, or a reply-to address that differs from the sender. The agent is good at spotting these; make sure its findings are on the release screen.

Verification of the wrong thing. Verifying a customer's own identity is a different control from verifying the person they are paying. Whether an agent can verify a customer's identity documents is a separate question with its own certificate.

Trusting documents over channels. An invoice on the supplier's letterhead with new bank details is still just a document. The principle is the same one that applies when an agent verifies income from bank statements: a document is a claim, and you confirm it through a source you already trust.

The general bounds for bank agents are in AI agents in banking.

Where Pryme fits

In Pryme, the payee checks are certified through Attest on your own past cases, including real attempts at payment diversion. Details in an email or invoice arrive through the Pryme Context Protocol as external claims, and an external claim cannot authorise a payment. The release capability stays with people, and every verdict is filed.