Callback verification for vendor payment changes

The rule, and why it carries so much weight

Everything inside a bank-change request can be produced by whoever controls the email: the logo, the signature block, a letter on letterhead, an invoice number that matches your records, and a phone number that rings someone ready to say yes. A number from your own records is the one part of the exchange the sender cannot edit. That is why the FBI's guidance on business email compromise tells you to "verify payment and purchase requests in person if possible or by calling the person to make sure it is legitimate" (FBI). The stakes are not small: the FBI's Internet Crime Complaint Center logged 24,768 business email compromise complaints in 2025, with about $3.05 billion in reported losses (IC3 2025 report).

Written as policy, the rule has three parts, and each one closes a gap:

• We place the call. An inbound call does not count, even from a number that looks right. Caller ID can be spoofed, and someone who rings you about the change is part of the request.
• To a number we had before the request arrived. Not the email body, not the signature block, not the letter attached to it, and not a "new direct line" offered in the same thread.
• And we can name who confirmed it. "Someone in accounts said it was fine" cannot be checked later. A name, a role and a time can.

Where a verified number comes from

In order of preference:

1. The vendor master record, set when the vendor was onboarded, ideally from a signed contract or a vendor setup form.

2. The signed contract or order form itself, if the master record has no number or you have reason to doubt it.

3. An invoice you received and paid before this request, ideally months earlier. Not one attached to the request, and not one from the same thread.

4. A number from an earlier call you placed, logged at the time, on which you reached the right person.

5. The vendor's main line, looked up yourself by typing their website address rather than following a link in the email. Ask for accounts receivable and note who you spoke with.

If the number on file turns out to be wrong or out of date, fix that first, as a change of its own: find the right number through one of the sources above, record where it came from, and only then make the bank-change call. Never update the phone number and the bank details from the same email.

Running the call

• Ask, do not read out. "Did your company ask us to change your bank details? Which bank, and what are the last four digits of the new account?" If you read the new details aloud and ask whether they are right, a hurried yes confirms nothing.
• Ask when and why. A genuine change usually has a plain reason, such as a new bank, a merger or a new legal entity, and a date it takes effect.
• If they did not send it, tell them on the call. The request may have come from their own compromised mailbox, and they will want to know today.
• If nobody answers, leave a message and keep the request pending. If they call back, thank them, hang up and dial the number on file again. A returned call is still an inbound call.
• Never accept "just reply to this email to confirm." A reply goes back to the mailbox that sent the request.

When the vendor simply forgot to tell you

Most of these requests are genuine: a vendor changes banks and someone in their finance team emails the new details. An MSP that gave each vendor a portal for payment changes put the logic plainly: "If any staff member gets a request in email we know it's either the vendor forgetting or a BEC attempt" (r/msp).

From the email alone you cannot tell those two apart, so the call is the same in both cases. A genuine vendor loses a few minutes. A vendor whose mailbox has been taken over hears about it from you, not from a payment that never arrived. It helps to tell vendors at onboarding that bank changes are confirmed by phone on the number in the contract, so the call is expected rather than awkward.

Recording the call so the rule can be checked

A rule nobody can check tends to drift: after a few dozen genuine requests, someone confirms one by replying to the email. A short record of every call keeps the rule visible, and it answers the question an auditor or insurer asks after a payment goes wrong: how do you know the number you called was the vendor's? One row per call is enough:

Keep only the last four digits of the new account in the record, never the full number.

If you send payments by ACH there is a rules reason as well. Nacha rule changes that took effect during 2026 require non-consumer Originators, for the first time, to have "processes and procedures that are reasonably intended to identify entries that are suspected of being unauthorized or authorized under False Pretenses". Nacha's own example of out-of-band authentication is a vendor who calls "to request a change to their routing and account information for future payments", verified with contact details from your own internal records (Nacha). A callback log does not make you compliant on its own, but it shows the procedure exists and is followed.

Records, not advice.

Where the callback rule usually breaks

• The number came from the request after all. Someone copied it from an email signature into the vendor record "to keep it current" a week earlier. Check where a number came from before trusting it.
• One person does everything. The person who received the email also makes the call and approves the change. A second approver who reads the call record catches a callback that was never independent.
• "Unreachable" quietly becomes "confirmed". After two days of voicemail, the change gets applied anyway. Unreachable means pending, however long that takes.
• A threshold. "We only call for payments over a set amount" invites requests just under it. The rule works best with no amount attached.

Questions

What if the vendor only has a general phone line?

Call it, ask for accounts receivable or whoever handles their banking, and record the name and role of the person who confirms. A main line you looked up yourself is still a number the requester did not supply.

The vendor insists on confirming by email only. What then?

Explain that your written policy confirms bank changes by phone on the number in your records, and offer to call any number from the contract. A vendor that refuses every call is a reason to hold the change, not to skip the rule.

Does a confirmed callback make the payment safe?

It is the strongest single step, not the only one. A second approver and a short cooling-off hold before the first payment catch what a call can miss. The six-step verification guide covers the full sequence, and the one-page policy template puts it in writing.

We already paid the new account and now suspect fraud. Where do we start?

Call your bank now, then work through the first ten minutes after a "banking details have changed" email.

Next step

BankChangeProof builds the callback rule into each request. When it is time to call, the only number it tells you to dial is one you verified yourself, from a contract or an earlier call, and if the email contains a different number it shows that number with a warning not to use it. You record when the call happened, who you spoke with and the outcome: a denied call flags suspected fraud, and an unreachable one keeps the request pending. The call record, approvals and hold end up in one evidence PDF per change. It does not place the call, check who owns the account, move money or connect to your accounting system. It is free for 10 vendors.