Vendor Bank Change Verification Rule

Use this framework whenever a vendor, supplier, contractor, landlord, broker, service provider, or other payee requests a change to bank details or payment instructions. This includes changes to the bank account number, routing number, ACH instructions, wire instructions, payment method, remittance destination, payment contact, payment-portal details, or the payment instructions printed on an invoice.

The trigger is not the invoice amount. The trigger is the change itself. Even a small vendor bank change should be verified, because the same control gap that allows a $5,000 fraudulent payment can allow a $250,000 one later.

A supplier appears to request updated bank details. The request may come from a compromised supplier email account, a look-alike domain, an altered invoice, a forged payment-instruction letter, a fake payment-portal link, a person impersonating the vendor, or an internal employee forwarding the request without checking it.

The accountant updates the bank details and pays the next invoice. The invoice may be real. The goods or services may be real. The fraud is the payment destination. The company often discovers the problem only when the real vendor says the invoice is still unpaid.

For SMEs this is especially dangerous because finance teams are small. The same person may receive invoices, update vendor records, prepare payments, and talk to vendors — so classic segregation of duties does not exist. The practical defense is not bureaucracy. It is independent verification before payment.

No vendor bank-detail change can be used for payment until it is verified through an independent, previously known contact method. The verification cannot rely on the email, phone number, link, or document included in the bank-change request itself.

Any vendor bank-detail or payment-instruction change must be verified out-of-band, using a contact source already known to the company, before the change is entered, approved, or used for payment.

Owner: CFO, controller, finance lead, or the accountant responsible for the vendor master and payment setup.

Approver: CFO, controller, owner, or designated finance reviewer.

For a two-person finance team, the person who receives or enters the change should not be the only person approving it. If full segregation is impossible, the second person should at minimum review the evidence of independent verification before the first payment is released.

This control runs on a simple checklist. It does not require a vendor-management system.

Step 1 — Freeze payment until verified

When a bank-detail change arrives, do not pay the vendor using the new account. Mark the vendor “bank change pending verification.” If the accounting system has no such status, track the pending change in Excel or Google Sheets.

Step 2 — Verify through an independent contact source

Use a contact method that existed before the change request arrived.

Acceptable sources: the phone number from the original vendor-setup file; contact details from the signed contract; the approved vendor master record; the vendor’s official website found by manual search; a known relationship contact used in prior dealings; or a verified vendor portal reached independently, not through a link in the request.

Do NOT use: the phone number in the bank-change email; a reply to the same request; a link in the request; contact details on the changed invoice or attachment; or “confirmation” from the same person who sent the change.

Step 3 — Ask a direct verification question

Confirm the specific change — not a vague “is everything okay?” Confirm the vendor name, old payment method, new bank name, last four digits of the new account where appropriate, effective date, reason for the change, and payment run affected.

“We received a request to change your payment instructions. Before we update anything, I need to verify it using our existing contact records. Can you confirm whether your company requested this bank change, the effective date, and the new bank name?”

Step 4 — Save evidence

Keep the date of verification, the person contacted, the contact method used, the source of that contact method, who performed the verification, who approved it, a summary of the confirmation, the first payment date after the change, and a copy of the original request.

Step 5 — Review the first payment

The first payment after a bank-detail change must get a second check before release. The reviewer compares the payment file against the saved verification evidence. For larger payments, require controller, CFO, or owner approval before release.

Suggested SME Tracker

A simple tracker with these columns is enough:

Red Flags

Treat the change as high risk if any of these appear:

• Urgent request to update bank details right before a payment run.
• Vendor says the old account is closed or unavailable.
• Request lands close to a large invoice due date.
• Email domain is slightly different from the vendor’s normal domain.
• New bank account is in a different country, state, or entity name.
• Supplier refuses a phone call or independent verification.
• Request asks for secrecy or asks finance to bypass the normal process.
• Invoice format changed unexpectedly.
• Payment terms changed at the same time as bank details.
• Contact person is new or unknown.
• Request uses a link to update payment information.
• An internal employee pressures finance to “just pay it.”

One red flag does not prove fraud. It means the payment should not be released until independent verification is complete.

Vendor bank-change fraud is dangerous because the payment can look completely legitimate — a real vendor, a real invoice, a real amount due, a normal payment cycle, a believable email thread. Only the bank destination is fraudulent.

The scale is not theoretical. In its 2024 Internet Crime Report, the FBI’s IC3 attributed roughly $2.77 billion in losses to Business Email Compromise across 21,442 complaints in a single year — the second-largest loss category in the report — and these are only the cases that were reported.

If a redirected payment is released, the company can face direct cash loss, pressure to pay twice because the real vendor is still owed, slow or no recovery, a damaged supplier relationship, insurance-claim disputes, and lost owner confidence in finance. The control has a high return because the cost is low: a five-minute call can prevent a six-figure payment redirection.

This framework stops working when:

• Finance uses the phone number or email provided in the change request itself.
• The same person receives, verifies, enters, approves, and pays the change with no second review.
• Vendor-master changes are made after payment has already gone out.
• The company verifies the invoice but not the bank account.
• Urgent requests are allowed to bypass the process.
• Evidence is not saved.
• First payments after a bank change are not reviewed.
• Payment files are uploaded to the bank without checking for recent bank-detail changes.

If the company cannot segregate duties, the fallback is documented independent verification plus a first-payment review by a second person.

Practical SME Version:

For a company with one CFO/controller and one accountant:

1. Accountant receives the bank-change request.
2. Accountant marks the vendor “pending verification.”
3. Accountant verifies the change using a known phone number or contact source — not the request itself.
4. Accountant saves the verification notes.
5. CFO/controller reviews the notes before the first payment to the new account.
6. First payment is released only after that review.

If the CFO/controller receives the request directly, the accountant or owner performs or reviews the independent verification before payment. The goal is not enterprise vendor governance. It is one hard rule:

No verified bank change, no payment