The invoice that asks you to change the bank details

The most expensive invoice fraud is rarely a forged document. It is a real invoice from a real supplier, arriving from a real mailbox, with one line changed: the account number. The goods were delivered, the amount is correct, the signature is the one you have seen for years. That is why the person who pays is the target, and why looking harder at the document does not catch it.

How does the request actually arrive?

Three routes account for most of it, and none requires forging anything.

• The supplier's mailbox, taken. Their account is phished — the NCSC's phishing guidance describes the pattern — and the attacker reads the thread, waits for an invoice that is due, and replies to it with new bank details. The message comes from the supplier's own address, keeps the signature block and the history, and adds one small request to an existing payment.
• A lookalike domain. Registered one character or one extension away from the real one, with the display name copied exactly. The inbox shows the supplier's name; the address behind it is not theirs.
• A reply-chain hijack. An old thread is captured and replayed with one message added at the bottom. The history above it does the persuading.

The common element: the message does not ask for money. It asks to update a record — a smaller request, arriving inside a routine.

Why is the person who pays the right target?

Because accounts payable has both the authority to act and the pressure to be quick. The request lands as an administrative errand on a payment-run day, from a supplier the team has known for years, about an account nobody doubts.

That position is exposed three ways: the payer can change the vendor master without asking anyone, is measured on paying on time, and is often the only person who ever sees the bank details.

The sums are large because one change redirects every future payment, and the timing is chosen for it: end of month, the day before a holiday, the week the supplier's finance contact is plausibly unreachable.

What does document checking catch, and what does it miss?

Invoice controls examine the document; a bank-detail change leaves it intact, so the change passes.

Signal	A forged invoice	A change of bank details
Layout and letterhead	Usually wrong somewhere	The genuine invoice, untouched
Order, quantity, tax	Often invented to fit	Correct, and already approved
Sender address	An unknown domain	The supplier's own mailbox
What it asks for	Payment	An update to a record

Which control actually works?

One: a callback to a number you already had, not a number that arrived with the message. The number comes from the vendor master, the signed contract, a statement you received last quarter, or a switchboard you have dialled before. The call confirms three things — that the supplier intends to change the account, the new details read back digit by digit, and the name of the person confirming them.

A callback works where a reply does not, because a compromised mailbox answers "yes, that is us" within minutes, and where the number in the signature does not, because that number belongs to whoever wrote the message.

It is not proof: a supplier whose phone line is also compromised, or an insider there, defeats it. It defeats the ordinary case, which is most of the loss.

What has to be true for that control to survive a busy week?

Four conditions, and it fails on the first one that is missing.

1. The verified number exists before the request does. If it has to be found, it will be taken from the email; it belongs in the vendor master from onboarding.
2. The rule has no exceptions. Not for the oldest supplier, not for the one the owner plays football with, not for the change that arrived on the last day of the quarter. Fraud lands on the account everyone trusts, because that is the account worth taking.
3. The person who calls is not the person who received the email, wherever the team is large enough for two people. One person doing both is a single point of failure with extra steps.
4. A payment can be held without anyone's permission. If pausing a transfer needs a manager's approval and the manager is travelling, the deadline wins. Basic authentication discipline is the other half: a shared finance login means the person who acted cannot be identified afterwards.

What internal rule makes it stick?

Write it as a payment instruction, not as an invoice exception, because exceptions get triaged and instructions do not:

No bank detail changes on the strength of an email. The change is made by the finance lead after a callback to the number recorded in the vendor master, the details are read back digit by digit, and the call is logged with its date, the number dialled and the name of whoever confirmed. The first payment to the new account is confirmed with the supplier through a second channel before the following run.

Two smaller rules carry it. The conversation may continue while the payment is frozen; freezing is the default, not an escalation. And an unconfirmed change expires, so the old details stay and the invoice waits.

Where this goes wrong

• The callback goes to the number in the email. Signature, body, or a "new finance contact" mobile. All three belong to the attacker by construction.
• Confirmation by reply, or by display name. "Can you confirm these details?" gets a yes from the compromised mailbox; the inbox shows a name while the address behind it is one character away.
• The change is verified and the payment is not. The vendor master is updated correctly, then the payment file is generated from an export taken the week before.
• The refund variant. An overpayment is claimed, with a request to return the difference to a third account. Money leaves rather than arrives, and the amount is smaller, so it clears a lower approval limit.
• Silence read as consent. No reply from the supplier by Thursday, so the change is applied to keep the run on schedule.

What this does not cover

This is a control description, not legal or insurance advice, and nothing here recovers a transfer that has already left. It does not address collusion inside your finance team, which needs separation of duties. It cannot distinguish a fraudulent change from a genuine one, and it must not try: a rule that blocks real supplier changes is bypassed within a month. Card fraud, cheque fraud, and the supplier's own account being taken over are separate problems. The control lowers the loss; it does not make fraud impossible.

We build the vendor master and the payment path so that a change of account is a workflow with a name and a record, not an email somebody acted on at four in the afternoon.