Task Sheriff

Vendor bank detail changes: a verification workflow that stops payment fraud

By Donna Shay · November 2, 2026

Category: accounting-operations

A changed bank account is the cheapest way to redirect a payment. Here is a step-by-step change workflow, from request to first payment, with the automated checks and the human ones.

Key takeaways

  1. The problem A forged email asking to change a supplier's bank account can redirect a real payment, and the change request often passes through the same inbox it came from.

  2. Core insight Verify the change at three points: when it is requested, when it is saved, and before the first payment to the new account.

  3. Practical outcome Route every bank change through a separate verifier, call back on a known number, hold the first payment, and log each step.

Say an accounts payable clerk gets an email from a known supplier: "Our bank has changed, please update our details before Friday's run." The signature is right. The tone is right. The account is new. If the clerk updates the vendor master and the run goes out, the money is gone before the real supplier calls to ask why it was not paid.

The challenge this solves

Payment redirection works because it asks for a small, routine change. The FBI's Internet Crime Complaint Center reported business email compromise losses of close to $2.8 billion in 2024, and nearly $8.5 billion over 2022 to 2024, according to Nacha's summary of the IC3 report. Those are rounded figures from that summary, and they cover all BEC, not only supplier bank changes.

Basware, in its post on acquiring Trustpair, argues that payment fraud is now an identity problem: is the supplier real, does the account belong to them, and is the money going where it was meant to? It also cites ACFE data that 75 percent of anti-fraud professionals report more generative AI document fraud, and 7 percent say their organization is more than moderately prepared. Those are Basware's reported numbers. We can say the question is a good one without adopting every claim around it.

The same post notes that Nacha's 2026 rules push US ACH users to run documented, risk-based fraud checks. Read the rule text at nacha.org/rules and ask your bank what applies to your volume.

How a controlled change process works

The principle is simple. The person who receives the request must not be the person who confirms it, and the confirmation must not travel through the channel the request used. Automation helps by doing the checks that need no judgment and by holding payments, and people do the check that needs a human voice.

What the workflow needs

  • A change request record. Every change starts as a ticket with the requester, the channel, and the old and new details. No ticket, no change.
  • Two roles. One person enters the change. A different person verifies it. The same split we describe for approval workflows.
  • A trusted contact list. Phone numbers come from the original onboarding record, never from the email that asked for the change.
  • A payment hold rule. The first payment to a new or changed account waits until a second check clears.
  • A log. Who asked, who entered, who verified, how, and when.

A walkthrough, from request to first payment

  1. Log the request. The clerk opens a ticket and attaches the original message. The vendor master stays unchanged.
  2. Run automatic checks. Compare the new details with the old. Flag a change in country, bank, or currency, a change close to a payment run, an account number that appears on another vendor, and a request that came from an address outside the domain on file. A flag raises the level of review. It does not decide.
  3. Call back. The verifier calls the number from the onboarding record and confirms the account details aloud. A reply to the same email thread is not verification.
  4. Apply the change. The verifier, not the requester's contact, approves. The system records the approval against the ticket.
  5. Hold the first payment. Pay a small test amount, or require a second approval, before the full payment goes to the new account.
  6. Look back. After the next close, review the changes made in the period and check each against its ticket.

What to measure

Do not publish a savings figure you cannot back. Track counts you can read straight from the log:

  • Bank changes per month, and how many passed the call-back on the first try.
  • Changes flagged by the automatic checks, and how many were real.
  • Payments held, and how long the hold lasted.
  • Changes found without a ticket during the look-back. This number should be zero.

For a view on how vendor records cause wider errors, see our guide to automating the accounts payable process.

Your next step

This week, pull the last ninety days of bank changes from your vendor master. For each, find the ticket and the call-back note. Each change you cannot match is the first gap to close, and it needs no new software to fix.

This article is general operational guidance. It is not legal, audit or security advice, and your bank and your insurer may set their own requirements.