No. Supplier bank details are the field payment fraud targets most, and a change request almost always arrives as an external claim. An AI agent can log the request, compare it with the master file, pause payments to that supplier and draft the call-back. A person verifies through a known contact, and a second person approves the change.
Why does this field get special treatment?
Every other supplier field can be wrong without losing money. A misspelt address delays a letter. A wrong bank account sends the next payment, and every payment after it, to someone else. Fraudsters know this, so they impersonate suppliers by email, often from a lookalike domain or a compromised mailbox, and ask for details to be updated shortly before a large invoice falls due.
The request itself proves nothing. A letter on headed paper, a PDF bank confirmation and a friendly phone call from a number in the email are all external evidence. That is why supplier bank detail changes are where finance agents must stop: the agent's job is to slow the change down and gather evidence, not to make it.
What may the agent prepare?
- Log the request. Record who asked, through what channel, from which address, and what changed.
- Compare with the master file. Show the old and new details side by side, with when the old details were last verified.
- Check the surrounding signals. A sender domain that differs from the one on file, urgency, a change of bank country, or an invoice due soon are flagged.
- Freeze payments. Put a hold on payments to that supplier until the change is resolved. A hold is protective and reversible, so the agent may place it at depth 3.
- Draft the call-back. Prepare the verification request using the contact already on file, never the one in the request.
- Prepare the master file change. Draft it at depth 2 for a person to approve once verification is complete.
What it does not do is edit the bank details, release a held payment, or treat any reply that comes through the requesting channel as confirmation.
Which step keeps the separation of duties?
Two steps, done by two people. One person verifies the change by calling the supplier on a number taken from the master file or an earlier contract, and records who they spoke to. A second person, who did not take the call and does not release payments, approves the change to the master file.
The agent is neither. It may prepare both steps, and the supplier bank detail change verification checklist sets out what each person must record. The split matters because a single insider who can both verify and approve can redirect payments with no one else involved.
An illustrative example
Take a manufacturer's accounts payable team. On a Thursday, an email arrives from the finance contact of a long-standing parts supplier. It says the supplier has moved banks and asks for payment of the 85,000 invoice due on Monday to go to the new account.
The agent logs the request and finds three signals. The sender's domain has one letter different from the domain on file. The new account is in a different country from the old one. And the request names the specific invoice due in the next payment run.
The agent freezes payments to the supplier, drafts a call-back request using the phone number from the original supplier contract, and sends both to the AP lead. The AP clerk calls that number. The supplier's finance manager confirms they have not changed banks. The request is recorded as attempted fraud, the payment runs to the original account, and the mailbox is reported to IT.
What controls make it safe?
- The agent has no write access to bank fields. Enforce this in the system, not only in the agent's instructions.
- External claims cannot change payment data. An email, a PDF or a call from a number in the request is external. It can start the process, never finish it.
- Call-back from the master file. The verifier uses a contact that existed before the request.
- A cooling-off period. New details are not used for the first payment until a set time has passed or the supplier confirms receipt of a small test payment.
- Two named people. Verifier and approver are different, recorded, and outside the payment release role.
- Everything filed. The request, signals, call record and approval are kept together.
The process in full is in how to verify supplier bank detail changes before anyone pays. The same thinking applies on the customer side, as covered in whether an AI agent can update a customer's payment details, and across finance in AI agents for finance: books you can audit.
Questions people ask
What if the supplier calls us to report the change?
Treat the call as the start of the process, not the verification. The verifier still calls back on a number already on file, even if the caller sounds familiar.
Can the agent verify bank details through a bank account check service?
It can run a name check where one is available and report the result. A match is useful evidence but does not replace the call-back, because a fraudster can open an account in a similar name.
Should a new supplier's first bank details follow the same rules?
Yes. Onboarding is the other point where false details enter the master file, and the same independent verification applies.