Vendor Bank-Detail Change Verification Procedure

The most common way businesses lose money to email fraud is simple: someone posing as a vendor emails "our bank details have changed — please update before the next payment." The invoice is real, the vendor is real, the email looks right. Only the account is wrong. Once the payment goes out, recovery is rare.

Two numbers, both from primary sources:

• The FBI's IC3 reported $2.77 billion in business email compromise (BEC) losses in 2024 (FBI IC3 2024 Internet Crime Report).
• 79% of organizations experienced attempted or actual payment fraud in 2024 (AFP 2025 Payments Fraud and Control Survey).

The universally recommended control is not software. It's a phone call: before changing any vendor's payment details, call the vendor back on a number you already trusted before the request arrived, and write down what happened. The problem is that almost nobody does this consistently, and almost nobody can prove they did it — which matters, because cyber-insurance applications and client auditors increasingly ask for a documented procedure.

This document is that procedure, written out so a firm can adopt it as policy today.

This procedure applies to any request to change how a vendor gets paid, for the firm itself or any client whose payables the firm handles, including:

• Bank account or routing number changes (ACH/wire)
• Switching payment method (e.g., check to ACH or wire)
• Changes to remittance email addresses or payment portals
• Changes to the mailing address where checks are sent
• New payment details for a "new" entity claiming to replace an existing vendor (mergers, "new billing company," factoring arrangements)

It applies regardless of how the request arrives: email, phone call, invoice footer, vendor portal message, text, or a client forwarding "something the vendor sent."

One rule above all: no payment is sent to new details until this procedure is complete. If verification can't be completed, payments continue to the old details or are held.

Never verify a change request using contact information contained in, or arriving with, the request itself.

The phone number in the email signature, the "call us to confirm" number on the new invoice, the contact in the attached letterhead — all of it is assumed compromised, because if the request is fraudulent, those were supplied by the fraudster. Verification must use a contact sourced independently.

Acceptable sources for the callback number (in order of preference):

1. The phone number already in your accounting system or vendor file from before the request arrived
2. The number on a previously paid (pre-request) invoice or the signed contract
3. The vendor's main line from their official website — found by typing the company name into a search engine yourself, not by clicking any link in the request
4. A number provided directly by the client's owner/manager who has an established relationship with the vendor

Never acceptable as verification:

• Replying to the email that made the request (you may be replying to the fraudster)
• Any phone number, email, or link contained in the request
• A text message or voicemail exchange
• "Confirmation" from the same email thread, even if the tone is convincing

Call the vendor on the independently sourced number. Ask for accounts receivable, the billing department, or your known contact. Then:

"Hi, this is [your name] from [firm name] — we handle accounts payable for [client name]. We received a request to change the payment details we have on file for you, and our procedure is to verify any change by phone before we update anything.

First — can you confirm that [vendor company name] actually requested a change to its payment details recently?"

If no: stop. Do not share what the request contained. Tell them the details you received do not appear to have come from them, suggest they alert their own team, and follow Section 6 (red-flag handling).

If yes, continue:

"Thank you. To verify, could you read me the new account details from your side? I won't read out what we received — I need to hear it from you."

This direction matters. Have the vendor state the new bank name, routing number, and account number (or remittance address) to you. Never read the received details aloud and ask "is that right?" — a wrong-but-confirmed answer tells you nothing, and you may be feeding details to the wrong person.

"And can I confirm who at your company authorized this change, and your name and role?

Last one: are your old account details now closed, or still active?"

Note every answer as they give it.

What counts as confirmation — all four required:

1. You reached the vendor through an independently sourced number (Section 2)
2. A named person, in a role that would plausibly know (AR, billing, finance, owner), confirmed the change was genuinely requested by their company
3. The details the vendor stated match the request exactly — every digit
4. You recorded the call in the verification log (Section 5)

What does NOT count as confirmation: an email reply (any email reply), a reply in the original thread, a callback to a number from the request, a text, a voicemail, "the vendor's email looked legitimate," or partial matches ("the account matched but the routing number was different — probably a typo." It is not a typo until the vendor says so on a verified call).

If any digit differs, treat it as unverified and start over with the vendor on the phone.

The person who performed the callback does not, alone, put the change into effect.

• A second person reviews the completed log entry — request saved, number source noted, confirmation details recorded — before the payment details are updated in the accounting or bill-pay system.
• In a solo practice, the second approver is the client's owner or designated manager: send them the log entry and get a written "approved" (email is fine for the approval step — the approval isn't the verification, it's the sign-off on it).
• The approver's name and date go in the log.

The point is simple: a change of payment details is never one person's unrecorded decision.

For each change request, keep:

1. The request itself — save the original email (with full headers if possible) or note the date/time and content of the call. Save it even if the request turns out to be fake; especially if it turns out to be fake.
2. Date and time the request was received, and through what channel.
3. Who appeared to send it — name, email address (exactly as written — see red flags), company.
4. What was requested — old details replaced by new (record last four digits only; see log-sheet note on full account numbers).
5. The callback — date/time, the number you called, where that number came from (this is the question an examiner asks), who answered (name and role), and what they confirmed.
6. Outcome — verified / not verified / pending / confirmed fraudulent.
7. Approvals — who verified, who approved, dates.
8. System update — date the details were changed in the accounting system, by whom.
9. First payment check — note when the first payment under the new details cleared and the vendor confirmed receipt. An unprompted "we didn't receive payment" after a change is a signal worth its own log entry.

A procedure that isn't recorded is, for an insurance application or an auditor, a procedure that didn't happen. The record is the deliverable.

None of these proves fraud; each one means slow down and verify with extra care:

• Urgency or pressure. "Please update before Friday's payment run," "the old account is frozen," "this is holding up our payroll." Manufactured deadlines are the single most common feature of fraudulent requests.
• Changed contact details in the same request. New bank details AND a new phone number/contact person in the signature. The new phone number is supplied so your "verification call" goes to the fraudster.
• Lookalike domains. vendor-inc.com vs vendorinc.com, .co for .com, swapped letters (rn for m). Read the sender's address character by character, and compare to a previously received genuine email.
• Reply-to mismatch. The visible sender looks right but the reply-to is a different address.
• A new contact person you've never dealt with, especially one who "just joined the billing team."
• Requests timed near a payment date — fraudsters who've read a compromised mailbox know your payment schedule.
• Switch to personal-account patterns — a company vendor switching to an account under an individual's name, or a different account-holder name than the vendor's legal name.
• Method switching — a long-standing check or portal vendor suddenly insisting on wire transfer.
• "Email only, please" — any resistance to phone verification ("our phones are down," "I'm traveling, just confirm by email") is itself a red flag.
• Formatting tells — slightly-off logo, unusual phrasing from a familiar contact, an invoice template that doesn't match prior ones.
• An international account for a domestic vendor, or a bank in a state/country with no connection to the vendor.

If a request fails verification or the vendor says "we never sent that": do not reply to the request. Save everything. Inform the client immediately. The client (or firm, if it's the firm's own vendor) should consider notifying their bank, reporting to the FBI's IC3 (ic3.gov), and alerting the real vendor that their identity is being used — their email may be compromised. Log the incident like any other case, marked "confirmed fraudulent."

Keep one log per client (or one firm-wide log with a client column). A spreadsheet or a printed sheet both work. Columns:

Storage: one folder per case holding the saved request, any attachments, and call notes; the log row points to the folder. Retain for at least your standard workpaper retention period. Full bank account numbers live only in the accounting system, never in the log or the case folder.

1. Replace the bracketed names and add your firm's letterhead.
2. Walk the team through it once — fifteen minutes; the callback script is the part to practice aloud.
3. Tell clients you've adopted it. One sentence in your next client email: "Effective this month, any change to a vendor's payment details goes through a documented callback verification before we update anything — this may add a day to changes, and that's deliberate." Clients tend to read this as care, not friction.
4. Review annually: check the log is actually being used, and that callback numbers in your vendor files are being kept current (a stale vendor file makes Section 2 slow).
5. If a cyber-insurance application asks whether you have a documented procedure for verifying payment-detail changes — this document, plus a log with entries in it, is what "yes" looks like.