A supplier you have paid for years sends an invoice. The format is right, the amounts are right, the signature block is right. One thing has changed: the bank account. The email may come from the supplier's genuine address, because the supplier's mailbox has been compromised and the message really was sent from it.
Why technical checks do not catch it
When the mail originates from the real account, SPF, DKIM and DMARC all pass. There is no lookalike domain to notice. Attackers who have been reading the mailbox for weeks know the tone, the schedule and the amounts, and often reply within an existing thread. Detection has to come from process, not from filtering.
The control that works
Any change to payment details is verified by voice, on a number you already have on file from before the request, with a named person you have spoken to before. Never a number in the new email. Never a reply to the thread. This single rule prevents the overwhelming majority of these losses, and it costs a two-minute phone call.
Supporting controls
- Dual authorisation for any change to a payee's bank details, by two different people.
- A first payment to any new account limited to a small verification amount.
- Account-name checking services where your banking system offers them.
- A standing note on invoices telling customers you will never change bank details by email.
If a payment has gone
Call your bank immediately and ask for a recall on the basis of suspected fraud. Contact the genuine supplier by phone — not email — because their mailbox may still be compromised and their other customers are likely receiving the same request. Preserve the full email headers, not just the visible message; investigators need them.
Then review your own mail security: enforce multi-factor authentication, check for forwarding rules and mailbox delegations an attacker may have created, and look at sign-in logs for unfamiliar locations.