Vendor Bank-Change Callback Script: Exactly What to Say

1. The vendor file. The phone number you are about to call should come from this — a prior signed engagement letter, an earlier invoice paid without dispute, the official "Contact us" line on the vendor's website you already used. Not the number printed in the email asking for the change. Attackers helpfully provide their own.
2. The change request itself. You need the proposed new account info in front of you so you can ask the vendor to read theirs back to you — not the other way around. Never tell them what you have on file; make them tell you.
3. A log entry, open. You will fill it in as you go (date, time, who you called, on what number, from what source, who answered, what they confirmed, who approved on your side). Doing it in the moment is the only way it survives an audit or insurer review later. The free vendor bank-change verification template has the layout.

The Association for Financial Professionals' 2025 Payments Fraud and Control Survey reported that 79% of organizations were targets of payments fraud attempts in 2024, with business email compromise still the dominant vector — exactly the scenario this callback exists to interrupt.

If the number on the change request is the same one you have in your vendor file, you still do not dial the one printed on the request. You dial the one in your file. The point of the callback is independence from the channel the request came in on. Email got compromised, the attacker controls the thread; if the attacker also got to type the "updated contact info" at the bottom, calling that number connects you to them.

If you cannot find an independent number — vendor never put one on an invoice, the website's contact line is the same as the one being requested, the engagement letter is silent — stop and route this to whoever in the firm owns vendor master data. Do not invent a number off Google's first result. The number has to come from a record you already had before the change request arrived.

When the person at the vendor picks up, you are doing three things in this order: identifying who you are (briefly), confirming who they are, and making them read the new details back to you.

The whole thing takes under three minutes. If it goes much longer it usually means the person on the line is improvising — which by itself is a flag.

A real AR contact at a real vendor will not be offended that you called. Most of them will appreciate it; their own fraud teams have been telling them to expect this for years. If you get genuine pushback, it's almost always one of three things, and none of them is a reason to skip the verification:

• "I don't have time for this." "Understood — I have one question and we're done." Then ask the bank name and last four.
• "Just use what we sent in the email." "Our procedure is to verify by phone before changing any payment details — it protects both of us. The bank name and last four is all I need."
• "Who told you to call?" "Our firm calls back any time vendor payment details change. It's a standard control."

If the person resists every version of the question and refuses to read back the account number, treat that as a failed verification. Do not pay.

The call is half the control; the record is the other half. Before you move on, log:

• Date and time of the call.
• The number you dialed and where you got it ("from invoice INV-4421 dated 2025-04-12," not "from the vendor file").
• Who answered (full name and role).
• What they confirmed (bank name, last four of the new account, effective date).
• Whether the confirmation matched the change request.
• Who approved the change on your side (and the second approver, if your firm requires dual sign-off — recommended even at a two-person firm; see vendor verification for bookkeeping firms).

A spreadsheet works. A tamper-evident log is better, because the value of the record is in its credibility months later when an insurer's adjuster or a client's auditor is reading it. See what auditors ask about vendor verification for the exact questions they tend to open with.

• The number is from the email. The most common silent failure. The change request includes a "we've also updated our phone" line, you dial it, "the vendor" enthusiastically confirms the new account, and the money is gone.
• You read the account number to them instead of the other way around. A vague yes from an attacker who never had the digits is treated as confirmation.
• You verified, but logged nothing. Doing the right thing and being able to prove you did it are different problems. The latter is what your cyber policy and your client's auditor care about — see does your cyber insurance require a callback to pay a vendor?
• You called the right vendor on the wrong contact. A real number for the AR clerk at HQ is fine; the cell number of "Mark, the new finance person" you only just got in this email thread is not independent.