When a supplier changes their bank details, who checks?
An email arrives from a supplier you have paid for three years. Same signature, same tone, same person's name. They have changed banks, here are the new details, could you use them for this month's invoice.
Everything about it is ordinary, which is the point. This is the most profitable fraud in commercial email, and the reason it works is that no part of a normal payment process is designed to catch it.
How big is this, really?
Large enough to be worth a paragraph of numbers, all from the FBI's Internet Crime Complaint Center rather than from anybody selling a solution.
Business email compromise produced $3.046 billion in reported losses in 2025 - the second-largest loss category in the report, behind investment fraud, and the most financially destructive threat aimed specifically at businesses. Across the last three years the total approaches $8.5 billion.
The number that matters operationally is a different one: 86% of BEC losses moved by wire transfer or ACH. Those rails clear fast and reverse badly. By the time a payment is identified as fraudulent, the money has usually gone somewhere it cannot be recalled from.
And the barrier to entry has dropped. The 2025 report logs AI-related fraud for the first time, with 22,364 complaints and $893 million in losses. The practical effect on this particular scam is that the tell everyone was taught to watch for - broken English, odd phrasing - is gone.
Why your accounting system will not save you
Here is the part small businesses find genuinely surprising.
Accounting platforms record a change to a supplier's bank details as an ordinary edit. Some notify - and the notification behaviour is worth checking carefully, because it can be close to useless. Xero users have raised exactly this: the platform notifies the person who made the change, which means an attacker who has got into one user's account gets the alert about their own edit, and nobody else does.
That is not a flaw unique to one product. It reflects what accounting software is for. It is a system of record, and a system of record faithfully recording a change is doing its job. Detecting that the change was fraudulent is a different job, and one nobody assigned to anything.
So the gap sits precisely where the money leaves: between "supplier details updated" and "payment sent", with no check in between.
The control that works, and why it is not software
The defence is embarrassingly low-tech, and every bank, insurer and auditor recommends the same one: call the supplier back on a number you already had.
Not the number in the email. Not the number in the signature. The number in your records from before the change request arrived. Confirm the change with a human voice, then make it.
Two details do the actual work:
The number must come from your own records. An attacker who can send the email can also put their own phone number in it, and a callback to the fraudster is theatre. This is the step most often skipped, because the number is right there in the message.
The verification must happen out of band. Replying to the email confirms nothing - if the mailbox is compromised, you are asking the attacker whether the attacker is genuine. Different channel, every time.
So what is left for automation?
If the control is a phone call, the honest answer is that automation cannot perform it. What automation can do is make sure the call is never forgotten, which is the actual failure mode. Nobody decides to skip verification; they simply do not notice that anything needs verifying.
Worth building:
| Trigger | Automated action | Human action |
|---|---|---|
| Supplier bank details edited | alert to a second person, not the editor | verify by callback |
| Payment queued to changed details | hold, flag as unverified | release after verification |
| New supplier added | alert to the approver | verify before first payment |
| Invoice from a known supplier with new details | flag against payment history | verify |
The pattern is the same in each row: the machine notices and interrupts, the person decides. That division matters. An automation that verified bank details by itself would be a system that can be fooled at scale, which is worse than the problem it replaced.
The high-value piece is the first row - the alert going to somebody other than the person who made the change. It closes the exact gap described above, it takes an afternoon to build against most accounting APIs, and it is the single cheapest fraud control a small business can add.
The policy half, which costs nothing
Software cannot supply the part that actually prevents losses. Four rules, worth writing down and telling your team:
- Bank detail changes are never actioned from an email alone. No exceptions for urgency - urgency is the pressure the fraud runs on.
- Verification is by callback to a number from your records.
- Whoever verifies is not whoever changes. Two people, always. In a business too small for two people, the owner is the second pair of eyes.
- A change plus a payment on the same day gets extra scrutiny, because that combination is the shape of the scam.
Rule three is the one that fails in practice, and it fails for a sympathetic reason: in a small company one person genuinely does everything. If that is your situation, the alert has to go to the owner, and the owner has to treat it as a real interruption rather than a notification to dismiss.
What to do this week
- Find out what your accounting system does when supplier bank details change. Who gets told? Test it - do not read the documentation and assume.
- If the answer is "only the person who changed it", that is your gap, and it is now a known one.
- Write the four rules above into your payment process and tell whoever pays suppliers.
- Check your supplier records hold a phone number that predates any recent change request. If they do not, collect one now, while nothing is urgent.
That last one takes an hour and is the difference between having a control and having a policy that cannot be followed.
If you want your payment process examined alongside the rest of your admin, that is what the process audit is for: $299, three business days, and a written account of where the gaps are - including the ones that are not worth automating, which knowing when not to automate covers in general.