Verify a Vendor's Bank-Change Request Before You Pay It

A vendor you pay every month sends a short email: their bank has changed, and they would like the next payment routed to a new account. A remittance form is attached, the logo looks right, and the sender is the accounts-receivable contact you have emailed before. Updating the vendor master and moving on feels like routine accounts-payable housekeeping. It is also one of the most expensive requests an AP team can get wrong, because the whole purpose of the message may be to redirect your payment into a criminal's account.

The safe answer is narrow, and it does not depend on how convincing the email looks: do not change the banking details on file or release a payment to a new account until you have verified the request out of band. Call the vendor back on a phone number you already hold from a prior invoice or the contract — never a number, email, or link supplied in the request itself — confirm the change with a person you can identify, and have a second person approve it before any payment uses the new account. Everything else in this article supports that callback; nothing replaces it.

This is a different job from the fraud work a bank's own team does with scoring models, which is the subject of why banks still lose money despite AI fraud detection, and it is narrower than deciding what to automate first in accounts payable. Here the target is one event in your payables process — a change to where a supplier's money goes — and the control is a verification procedure, not a model.

See how a finance-operations engagement maps payment controls onto your AP and ERP.

Why this fraud lands in accounts payable now

Business email compromise (BEC) is the umbrella for scams that use a compromised or spoofed email account to redirect a legitimate payment. The FBI's Internet Crime Complaint Center puts the global exposed dollar loss from BEC at about $55.5 billion between October 2013 and December 2023, and its public alert tells organizations to "use secondary channels and/or two-factor authentication to verify requests for changes in account information," in its alert on business email compromise. Exposed loss combines attempted and actual fraud and is a cumulative global figure, not a single year's realized loss; but the mechanism it describes — criminals asking a business to send money to an account they control — is exactly the vendor bank-change request.

The teams that see these attempts most are treasury and AP. The Association for Financial Professionals, in its 2025 Payments Fraud and Control Survey, reported that BEC was the most common method behind attempted or actual payments fraud in 2024, that 60% of practitioners saw an increase in vendor impersonation specifically, and that wire transfers were the primary payment target, in its briefing for treasury professionals. That is a self-reported survey of finance practitioners and skews toward larger organizations, so read it as a description of where attempts concentrate rather than a precise rate; the shift it names, from impersonating an executive to impersonating a supplier, is what moves the risk onto the AP desk.

The verification procedure competitors skip past

Most published guidance agrees on the core control. The Government Finance Officers Association, in its guidance on electronic vendor fraud, tells organizations to confirm payment-information changes by telephone to a known number rather than by email, to require both the old and the new account details on any change request, and to separate the person who enters a vendor change from the person who approves it. That is the right foundation. What most guides — and most software walkthroughs — leave out is what happens when the callback does not cleanly confirm, and how to keep a legitimate supplier from waiting a week. The procedure below fills those gaps. It is a control method, not a guarantee that fraud cannot occur.

Two branches matter most and are usually missing. The first is the failed callback. When you cannot reach a known contact, the correct action is to do nothing to the account on file and continue any due payments to the previously verified details, because a fraudulent request loses its value the moment it cannot redirect money. The second is urgency. A message that presses for same-day payment before an account supposedly closes is applying the exact pressure the FBI describes; treat urgency as a reason to slow down, and give the AP team a named person — usually the controller — who can authorize an exception only after a live verification, never as a way around it.

A worked example

The following example is illustrative; the vendor, contacts, and amounts are assumptions, not a client case. Northaven Mechanical is a facilities contractor you pay by ACH. On a Tuesday an email arrives from Northaven's usual billing address: their bank has changed, please route Friday's $84,200 progress payment to a new account, and a completed change form is attached. The AP clerk freezes the change and pulls the phone number from the signed contract on file — not the number in the email signature, which differs by two digits. The contract number reaches Northaven's office manager, who has no record of any banking change and confirms the current account is unchanged. The clerk holds the change, leaves Friday's payment routed to the verified account, and forwards the email to the controller. Northaven's own IT later finds the billing mailbox had been accessed by an outsider. Nothing was lost, and the only reason is that the verification used a number the fraudster did not control.

Weigh that against the cost of the control. Suppose a mid-size AP team processes roughly 40 vendor-master changes a month, and past experience says about 5% of them are bank-detail changes: that is 40 × 5% = 2 callbacks a month, a few minutes each. Two short phone calls is the price of not sending $84,200 to a stranger. The workload is small precisely because bank-detail changes are rare — and that rarity is also why a busy clerk can be tempted to wave one through.

Where automation helps, and where a person must decide

Software earns its place on the enforcement and detection side of this control, not the judgment side.

No product prevents BEC on its own; it enforces the workflow and surfaces signals. A system that lets the same person enter and approve a change, or that treats its own pending flag as if it were verification, gives false comfort. Even the AP-automation platforms that market a callback feature say as much when they add that you should still confirm independently through a trusted channel.

What to measure, and what makes it fail

Track a few numbers that show the control is running, not just installed. The share of bank-detail changes verified by callback before the first payment on the new account tells you whether the freeze is holding. The verification cycle time, from request to approved change, tells you whether legitimate suppliers are being made to wait. The count and age of held changes tells you whether escalations are being worked or quietly abandoned. Keep these apart from any fraud-loss figure: zero losses in a quarter is not proof the control works, only that no attempt got through, and a single mishandled change can undo a clean year. A pilot of this control fails in predictable ways — one person both entering and approving changes, a callback placed to the number in the request, or urgency used to skip verification — and every one of those is a process choice, not a software gap.