Vendor Bank-Detail Changes: The Callback Control That Stops Payment Redirection, and How to Prove It Works

Of all the ways money is stolen from businesses, payment redirection is one of the plainest. A supplier you really pay "changes banks". An email, sometimes from the supplier's real but compromised mailbox, asks accounts payable to update the details before the next invoice. The invoice is genuine. The amount is expected. Only the destination is wrong, and by the time the real supplier chases payment, the money is gone.

The FBI's 2024 Internet Crime Report put reported business email compromise losses at about 2.77 billion dollars for the year, out of 16.6 billion dollars in total reported losses. Vendor bank-change fraud is one of the main ways that money moves.

The one control that matters most

There are many good practices around supplier fraud, but one does most of the work: before changing a vendor's bank details, accounts payable calls the vendor on the phone number already on file, not one in the request, and a second person approves the change. If that happens every time, most redirect attempts fail, whether they arrive by email, text, phone, or a cloned voice.

Almost every finance team says it does this. The useful question is whether it happens under pressure, from every person who can change vendor master data, every time.

How it fails in practice

• The callback uses the wrong number. The request includes "our new contact, please call to confirm". The clerk calls it. The fraudster answers.
• The real mailbox sends the fake request. When the supplier's email is compromised, every sender check passes. Only the callback catches it.
• Other channels skip the rule. The policy is written for email. A text, a portal message or a phone call from "the supplier's finance team" goes through a different path.
• The second approval is a click. The approver sees the same email the clerk saw and approves it. Dual approval only works if the second person checks the callback evidence, not the request.
• Exceptions become the process. Month-end, a key supplier, an angry call about a late payment. "Just this once" is when most of these losses happen.
• The vendor master has more editors than anyone thinks. Procurement, AP, an outsourced bookkeeper, a shared-service centre. The control is as strong as the least-trained person with write access.

Why proof now matters, not only the control

If your cyber-insurance application or renewal asks whether you verify changes to payment instructions out of band, read your social-engineering and funds-transfer cover with that answer in mind. Ticking "yes" on a form is easy. If a loss happens and the control was not actually followed, the gap between the answer and the practice is a problem for the claim and for the people who signed it. A dated record that the control was tested, and how staff responded, is a far better answer than a policy document.

A self-check your team can run

• Export the list of everyone who can change vendor bank details. Is it the list you expected? Include outsourced staff and system accounts.
• Pull the last 20 bank-detail changes. For each one, is there a record of who called whom, on which number, and who approved? If the record does not exist, assume the call did not happen either.
• Check where the callback number comes from. Is it locked in the vendor master from onboarding, or can it be edited in the same transaction as the bank details?
• Read the written procedure for channels other than email. Text, phone, supplier portal. Does the same rule apply?
• Look at the first payment after each change. Is it held, reviewed, or flagged as a payment to new details? This is the same setup-risk idea behind first-time payee fraud.
• Ask what happens when a supplier complains about a late payment because of the callback. If the honest answer is "we skip it for important suppliers", that is the gap.

What good evidence looks like

Whether or not you ever run a drill, make each bank-detail change leave a small, boring record: the request as received, the number called and where that number came from, the time of the call, the name of the person who confirmed, and the name of the independent approver. Store it with the vendor record, not in someone's inbox. Then review a sample each quarter, the same way you would sample any other key financial control.

That record does two jobs. It makes skipping the call visible, which on its own changes behaviour. And if a loss does happen, it shows exactly which step failed, which is what your insurer, your auditor and your board will ask first.

How Riskernel runs this as a fixed-scope assessment

The Vendor Bank-Change Drill tests whether the callback and second approval actually happen. With your consent, we send harmless, simulated bank-change requests by email, text and phone. No cloned voices or faces are used. We record what staff do with each one. You get a dated evidence letter built to answer cyber-insurance questions about social-engineering and funds-transfer controls, plus the findings behind it. Insurers and brokers can also run the drill across their insureds. Scope and fees are agreed on a short call.