Supplier bank detail changes are where finance agents must stop

A request to change a supplier's bank details is one of the most common routes to payment fraud, so it is exactly where a finance agent should stop acting and start verifying. The agent can check the request, gather evidence and hold everything related to it. Updating the details, and releasing any payment to the new account, stays with people.

Why are bank detail changes so dangerous?

Because they turn a legitimate payment into a theft without changing anything else. The invoice is real. The supplier is real. The amount is right. Only the destination has changed, and once money has gone to the wrong account it is often impossible to recover.

The usual pattern is simple. A fraudster gains access to a supplier's email, or creates a convincing look-alike address, and writes to the customer's accounts payable team: "We have changed banks; please update our details for future payments." Sometimes a letter on headed paper is attached. Sometimes the request arrives just before a large payment is due. Sometimes it follows weeks of genuine correspondence the fraudster has been quietly reading.

People are fooled by these requests regularly, which is why most firms already have a call-back control. Agents introduce a new risk: an agent that processes supplier correspondence efficiently may update the details faster than any person would, with no instinct that something is wrong.

Why must an emailed request never be enough?

Because email is external. A message from outside the firm, however convincing, has no verified sender: the address may be spoofed, the account compromised, the attachment forged. In provenance terms, it is the weakest class of fact. A firm that would not let an external claim authorise a payment should not let one change where payments go, since that achieves the same thing one step earlier.

For an agent, the rule is mechanical. A bank detail change request arriving by email, through a web form, in a PDF or in an invoice footer is an external claim. The agent records it, flags it and holds. It does not update the supplier master, and it does not pay to the new account.

The question of whether an AI agent can change supplier bank details is answered no, for this reason.

What can the agent check?

A great deal, and doing so makes the person's verification faster and more thorough. The agent can:

• compare the sender's address with the supplier's known contacts, character by character;
• check whether the request came from the same domain as previous correspondence, and whether the domain is new;
• look for timing signals, such as a request arriving shortly before a large payment is due;
• compare the new bank details with the supplier's country, name and history;
• check whether the new account has been seen before for any other supplier;
• confirm the payee name against the account where the payment system offers verification of payee, as in the EU where the Instant Payments Regulation requires payment providers to verify the payee's name;
• gather the supplier's contact details from the firm's own records, not from the request, for the call-back.

A supplier bank detail change verification checklist turns these into a consistent set of checks, and the full process is in how to verify supplier bank detail changes with an AI agent before anyone pays.

What stays with a person?

Two people for the update is common practice and worth keeping: one verifies, another approves the change. The agent's checks support both.

What about payments already scheduled?

This is where agents can prevent losses that people sometimes miss. When a change request arrives, there may already be payments to that supplier in the next run. If the change is processed by one team and the run is prepared by another, the run may go out to the new account before anyone verifies it, or to the old account after a real change, causing a different problem.

The agent can see both. On receiving a request, it should identify every scheduled payment to that supplier and hold them all until the change is verified or rejected. That hold is a verdict in its own right, recorded with the reason, so the payment approver knows why the supplier's payments are paused.

The agent should also check after the fact. If a verified change has been made, the next reconciliation should confirm that payments went to the new account and were received. The habits that make reconciliation where finance agents earn trust apply here too: a payment to a supplier that the supplier later says it never received is the clearest sign of a successful fraud.

Why is this a good test of an agent's design?

Because it combines everything that matters: provenance, bounds, holds and recording. An agent that handles bank detail changes well treats external facts as weak, refuses to act on them alone, holds related actions, prepares verification for a person, and records every step. One that handles them badly will act on whatever it reads.

It is also a case where traceability protects the firm. Every figure and every bank detail the agent uses should trace back to a source the firm trusts, as argued in a finance agent's figures must trace to an entry. A bank account number whose only source is an email has failed that test.

Where Pryme fits

In Pryme, the Pryme Context Protocol marks emailed requests and invoice attachments as external facts, and an external claim cannot authorise a payment. Changes to supplier bank details and payments to new accounts are held for named people by the customer's limits, and every hold is filed with its reason. This is how AI agents for finance: books you can audit handles one of finance's highest-risk moments.