How to verify supplier bank detail changes with an AI agent before anyone pays

Freeze first, verify second, pay last. The agent detects the change request, holds every pending payment to that supplier, assembles the evidence and drafts a callback to the number already on file. A named person makes the call and approves the change, a second person enters it, and nothing is paid to the new account until both have acted.

What is this process, and who owns it?

A supplier bank detail change is a request to send future payments to a different account. It is the single most common route for invoice fraud, because one convincing email can redirect months of payments. The process exists to prove that the request came from the supplier and that the new account belongs to them.

The accounts payable manager owns the procedure. The person who maintains the vendor master file should sit outside accounts payable, so that no one who pays suppliers can also change where the money goes. The agent does the gathering and the drafting. It never edits the vendor master, which is why supplier bank detail changes are where finance agents must stop.

What are the steps, and who acts at each one?

1. Agent, depth 1: detects the request. It reads email, the supplier portal, scanned letters and notes of phone calls, and flags anything that asks for new payment details, including requests buried in an invoice footer. Every such request is marked as external information.
2. Agent, depth 3: holds pending payments. It places a hold on unpaid invoices for that supplier. A hold is routine and reversible, and it stops the next payment run from paying either the old or the new account until the question is settled.
3. Agent, depth 1: compiles the evidence. It compares the sender address with the contact details on file, looks for look-alike domains, checks whether other supplier details (email, phone, contact name) changed in the weeks before, and notes whether large invoices are about to fall due.
4. Agent, depth 1: checks the payee name on the new account through a name verification service where your bank or market offers one, and records the result.
5. Agent, depth 2: drafts the callback. The script and the phone number both come from the vendor master as it stood before the request arrived. A number in the email, the letterhead or the signature is never used.
6. Person, accounts payable verifier: makes the call. They speak to a known contact, ask them to confirm the account details read back from the request, and record who confirmed and when.
7. Person, finance manager: approves or rejects the change on the evidence pack.
8. Person, vendor master administrator: enters the change. This is a separate person from the approver.
9. Agent, depth 3: releases the hold once the change is recorded, and marks the first payment to the new account for review in the next payment run.
10. Agent, depth 2: drafts a confirmation to the supplier's previous known contact, so a real supplier who did not ask for a change finds out quickly.

Which controls matter, and what evidence does each leave?

The request cannot authorise anything. An emailed instruction is external information, the weakest kind. It can start the process but cannot change a record or release a payment. Evidence: the provenance class stored with each request.

Contact details come from before the request. The callback number is read from a snapshot of the vendor master taken before the request was received. Evidence: the snapshot reference on the callback script.

Two people, two roles. The approver and the person who edits the vendor master are different people, and the agent is neither. Evidence: the user identities on the approval and the record change.

Holds are visible. Every held invoice shows why it is held and who can lift it. Evidence: the hold reason and the person who lifted it.

Instructions inside the request are ignored. "Please update today and do not call, our phones are down" is content to be assessed, not an instruction to follow. Evidence: the agent's note flagging pressure language as a risk signal.

Use the supplier bank detail change verification checklist as the approver's sign-off sheet so that each decision covers the same ground.

What should you measure?

• Time from request to decision, so genuine suppliers are not left unpaid for weeks.
• Requests rejected or withdrawn, and how each was spotted.
• Callbacks where the supplier denied making the request. Each one is a stopped fraud and should be reviewed.
• Payments that reached a new account without a completed evidence pack. The target is none.
• Requests the agent missed and that a person found later, by channel.

Where does it usually go wrong?

The callback uses the fraudster's number. The most common failure. A plausible phone number in a signature block gets called and the fraudster confirms their own request. Lock the source of the number.

A payment file was already built. The change is verified properly, but a payment file generated earlier still carries the old or the new account. Check files awaiting release, not only invoices.

The change arrives in pieces. The contact email is changed one week, the bank details the next, and each change looks harmless on its own. The agent should read the supplier's recent change history every time.

Urgency from someone senior. A message that appears to come from a director asks for the change to be rushed. The procedure does not change because of who is asking.

Staff bank details are handled differently. The same attack works on employee bank details; apply the same discipline when you check payroll changes before the payroll run with an AI agent.

Where Pryme fits

In Pryme, a change request reaches the agent stamped as external, and an external claim cannot authorise a payment. Updating supplier bank details is outside the agent's role scope, so an attempt is refused and filed. The callback, approval and entry are recorded against named people. More on this in AI agents for finance: books you can audit.