The supplier's new bank details came by email

Start from the bad ending

Run this one as a pre-mortem. Imagine it's six weeks from now. Your longtime packaging supplier calls, polite but puzzled: their last two invoices haven't been paid. Your finance lead checks. Both were paid, on time, to the new account the supplier asked you to switch to last month.

Except the supplier never asked. Someone else did.

Nothing about this is exotic. The FBI's Internet Crime Complaint Center has been warning businesses about it for years under the name business email compromise, and its advice is the same plain advice we'll get to below. The interesting question for a pre-mortem isn't whether it can happen. It's which of your steps let it through.

How it probably happened

Walk back from the phone call. Here are the likely stories, and most businesses have at least two of them.

The email looked right. It came from the supplier's real address, because their mailbox had been taken over, or from one letter off. It quoted a real invoice number. It arrived as a PDF on letterhead.

The change went straight into the vendor record. The accounts payable clerk who received it updated the bank details in the accounting system that afternoon, as they'd done for genuine changes before.

The same person changed it and paid it. Nobody else looked at the vendor record. The payment run went out under the same login.

The callback used the wrong number. Someone did call to confirm. They called the number in the email signature. A friendly voice confirmed everything.

The approver saw a total, not a change. The weekly payment run showed forty payees and a sum. Nothing on that screen said "first payment to new bank details."

Automation did its job. The new invoice-reading tool picked up the bank details from the PDF and filled them in. It was built to save typing, and it did.

The payment run did exactly what it was told. The mistake happened three weeks earlier, in a form nobody thought of as a payment.

Separate the change from the payment

The fix starts with one idea: a change to someone's bank details is a different event from paying them, and it deserves its own path.

Verify through a channel you already had. Call the supplier using the phone number from your own records, from before the request, and speak to someone you know or can verify. Never use contact details from the request itself. That's the core of the IC3 advice: use a secondary channel to verify changes in account information.

Two people, two steps. One person records the requested change. A second person approves it after the callback. The person who approves a change shouldn't be the person who releases the next payment run alone.

Hold the first payment. For a set window after details change, flag the first payment to the new account in the payment run, or hold it until someone confirms again. Make the flag impossible to miss on the approval screen.

Tell the supplier through the old route. Send a confirmation to the contact you had on file before the change: "We've updated your bank details as requested on the 14th." If they didn't ask, you'll hear about it quickly.

Write down who may ask. Agree with key suppliers, in advance, who on their side can request a change and how they'll do it. Then an email from anyone else is an exception by definition.

What automation should do here, and what it shouldn't

This is exactly the kind of work business automation is good at, as long as it's pointed the right way.

Automation should notice the change. When an invoice or email carries bank details that don't match the vendor record, it should stop, open a task, and show the old and new details side by side. It should freeze payments to the new details until the task is approved. It should send the confirmation to the old contact. It should put the first-payment flag on the run.

What it shouldn't do is apply new bank details from an inbound email or an extracted PDF on its own. Document extraction is useful for invoice lines and amounts. It is the wrong tool for deciding where money goes. If a vendor's payment details can change without a person and a callback, your fastest path is also the fraudster's.

Log every change: who requested it, who called whom on which number, who approved, when the first payment went out. When the puzzled phone call does come, that log is the difference between a ten-minute answer and a week of reconstruction.

Rehearse it once

Pre-mortems work best when you test the fixes. Pick a quiet week and run a drill with your finance team's agreement: someone senior sends an internal test request to change a real supplier's details, written the way a real one would be. Watch what happens. Does the clerk start the callback path? Does the approval screen flag it? Does any tool try to apply it automatically?

Put the bad-day steps in the same drill. If money has already gone to the wrong account, IC3's guidance is to contact the bank that sent the payment as soon as you recognize the fraud and ask for a recall or reversal, then file a complaint at ic3.gov with the banking details. Write down today who makes that call, which bank contact they use, and where the payment records live, so nobody is searching for a phone number while the window closes.

Whatever happens, you'll learn more from one drill than from a policy document. Fix what it shows, then run it again after the next tool change.

Put this into practice

Pull the last ten changes to supplier bank details in your accounting system. For each, can you see who requested it, how it was verified, which number was called, and who approved it? If the answer is a shrug, that's your project.

We build business automation that saves the typing without moving the decision. If supplier changes in your company still run on trust and an inbox, talk to us.

Related work: Sutton|Place.