# Vendor Bank Account Change Verification Steps

- Author: PreciseBankFlow (https://www.precisebankflow.com)
- Published: 2026-01-27
- Updated: 2026-01-27
- Category: Internal controls over cash
- Canonical: https://www.precisebankflow.com/blog/vendor-bank-account-change-verification

> Vendor bank account change verification: independent callbacks, waiting periods, test payments and red flags in an email asking to switch banks.
Vendor bank account change verification means confirming a request to pay a vendor at a new bank account through a channel the requester did not supply. Call the vendor on a number already in your files, have a second person approve the change, hold the first payment for review, and keep a record of every step.

## Why vendor bank account change verification matters

Vendor bank account change verification matters because a fake change request lets a thief collect a real payment. The business owes the money, the invoice is genuine and the approval is honest. Only the destination account is wrong, so every other payment control passes and the vendor is still unpaid afterward.

### How the scheme runs

The pattern is usually some form of business email compromise. Someone gains access to, or imitates, a mailbox at the vendor or at your own company. They watch for an invoice cycle, then send a polite note saying the vendor has changed banks and asking that future payments go to the new account. The note may include a letter on letterhead or a voided check for the new account.

The FBI's Internet Crime Complaint Center describes business email compromise as a scheme aimed at people who make legitimate funds transfers, and its [IC3 public service announcement on business email compromise](https://www.ic3.gov/PSA/2023/PSA230609) advises using secondary channels or two-factor authentication to verify requests to change account information. That advice is the core of every procedure below: the confirmation must travel by a route the requester does not control.

### Who loses

When the payment lands in the fraudster's account, the vendor still has an open invoice. Unless the bank can recover the funds quickly, the business usually ends up paying twice, once to the thief and once to the real vendor. Speed of detection matters, but verification before payment is far cheaper.

## Red flags in an email asking to switch vendor bank details

Red flags in an email asking to switch vendor bank details include urgency, a change of country or bank name that does not fit the vendor, a sender address that differs slightly from the usual one, and a request to keep the change quiet. Any one of them means the request gets the full callback, even if it looks routine.

### Signs in the message

- **A near-match sender address.** One letter changed, a different domain ending, or a free email service in place of the vendor's own domain.
- **Reply-to that differs from the sender.** Replies would go somewhere other than the address shown.
- **Urgency tied to a payment.** "Please update before Friday's payment" or "our old account is frozen."
- **New bank in an unexpected place.** A local supplier suddenly banking in another state or country, or an account in an individual's name.
- **Attachments that prove nothing.** A bank letter or voided check can be forged as easily as an email.
- **Pressure not to call.** "Our phones are down, email only" is a reason to call, not a reason to skip it.

### Signs in the timing

Requests that arrive just before a large payment, at quarter end, or while the usual contact is on leave deserve more scrutiny. So do requests that arrive soon after a change of staff at either company, because the people involved are less likely to recognize an odd tone.

None of these signs is proof. Plenty of genuine changes arrive by email. The point is that the signs raise the level of checking; they never lower it below the minimum procedure.

## The independent callback for a vendor bank change: which number, which questions?

The independent callback is a phone call to the vendor using a number from your own records, such as the original contract, a prior invoice from before the request, or the vendor's public website. Never use a number in the change request. Ask the contact to confirm the change and the new details without reading them out first.

### Choosing the number

Use the number in this order of preference:

1. The number on file in the vendor master from before the request arrived.
2. The number on a contract or onboarding form signed when the vendor was set up.
3. The main number on the vendor's public website, reached through a search rather than a link in the email.

Never use a phone number from the email signature, the attached letter or a follow-up message, because the person who sent the request controls those.

### Asking the right questions

Let the vendor supply the details. Read the last four digits of the old account, and ask the vendor to read you the full new routing and account numbers. If the person on the phone hesitates, says they need to check, or asks you to read the numbers to them, stop and escalate.

Then confirm the reason for the change, the effective date and the name of the person who authorized it at the vendor. Write down the name of the person you spoke to and the time of the call.

### The verification procedure, step by step

1. Receive the request and log it, unchanged, in the vendor file.
2. Do not edit the vendor master yet.
3. Call the vendor on an independently sourced number and confirm the new details as above.
4. Send a confirmation to the vendor's address on file, not by replying to the request.
5. Enter the change in the system, attaching the call record and the confirmation.
6. Have a second person approve the change after reviewing the record.
7. Flag the vendor for a review of the first payment to the new account.

## Waiting periods and test payments after a vendor bank change

A waiting period holds the first payment to a changed account for a set number of days, such as five business days in this example, so the vendor or your own staff have time to notice something wrong. A small test payment can confirm the account exists, but it does not prove the vendor owns it.

### Setting a waiting period

Pick a waiting period that fits your payment cycle, write it in the policy, and apply it to every change. During the wait, a short confirmation sent to the vendor's original email or postal address gives the real vendor a chance to say they made no such request. For critical suppliers that you cannot delay, rely on a stronger callback and a senior approver instead.

### What a test payment does and does not show

A test payment of a few cents or dollars, followed by the vendor confirming the amount, shows that the account is open and that the person you spoke to can see it. If the account belongs to the fraudster, though, and you reached the fraudster by phone, the test passes. A test payment adds value only on top of a genuine independent callback.

### Watching the first real payment

Flag the first payment to any changed account for review before release. The releaser confirms the change record exists and the approval was by someone other than the person who entered it. After the payment, confirm with the vendor that they received it. If the first sign of trouble is the vendor asking about a missing payment weeks later, the money is much harder to recover, so an early confirmation limits the loss.

## Who should approve a vendor bank account change in the system?

A vendor bank account change should be entered by one person and approved by another, and neither should be able to release payments alone. Accounts payable clerks often hold all three powers in small systems. Splitting them, and reviewing a log of every change, stops both outside fraud and an employee redirecting payments to their own account.

### Separating the steps

| Step | Who performs it | Evidence kept |
| --- | --- | --- |
| Receive and log the request | Payables clerk | Original email or letter, unchanged |
| Callback to the vendor | Someone other than the clerk, if staff allows | Call record: number used, source of number, person reached, time |
| Enter the change | Payables clerk or vendor master administrator | System audit trail |
| Approve the change | Controller or manager | Approval in the system or a signed form |
| Review the change log monthly | Someone outside payables | Initialed change report |

The values in the "Who performs it" column are an example for a small team; a larger finance department will add a dedicated vendor master role.

### The insider version

An employee who can change bank details and release payments can redirect a real vendor's payment to their own account for a month, then switch it back. The monthly change log, read by someone outside payables, catches the switch even when it has been reversed. Insider schemes on company cards leave a different trail; [employee credit card misuse patterns](/blog/employee-credit-card-misuse) covers how those show up on card statements.

### Testing whether the control works

Auditors and reviewers ask about this control directly. A good [internal control questionnaire for cash](/blog/internal-control-questionnaire-for-cash) includes questions on who can change vendor bank details and how changes are verified. In a public company, vendor master changes are often a key control, and [SOX controls for cash](/blog/sox-controls-for-cash) lists the evidence testers ask to see for it.

## When the vendor's own mailbox sends a fraudulent bank change

The vendor's own mailbox can send a fraudulent bank change when an attacker has taken over a real account at the vendor. The sender address is genuine, the email thread is real, and the tone matches. Only an independent callback catches this case, which is why the procedure never accepts the sender address as proof.

### Why the usual checks fail here

Checking the sender domain, the signature block and the reply-to all pass, because the attacker is writing from the vendor's real system. The attacker may even reply to your confirmation email and approve their own change. The phone call to a number from your own records is the only step that reaches a person the attacker does not control.

### If a payment already went to the wrong account

Act within hours, not days:

1. Call your bank's fraud line and ask it to recall the payment and contact the receiving bank.
2. Notify the real vendor by phone and agree how to handle the open invoice.
3. Freeze the vendor record so no further payments go out.
4. File a complaint with the FBI's Internet Crime Complaint Center and keep the reference number.
5. Preserve the emails, headers and attachments for the investigation and your insurer.

After the immediate response, review the statement for any other payments to the same account. [PreciseBankFlow](/) can extract the statement lines and match them to the payment register, which makes it quicker to confirm whether the fraudulent account received anything else.