Fake invoices and changed bank details: how to check before you pay

In brief: the most expensive fraud for a small or medium company is usually not an attack that encrypts the servers. It is an e-mail announcing that a supplier has changed bank account. It breaks nothing, it convinces someone. The defence is not a product, it is a payment procedure everyone follows.

How it works, step by step

1. Someone gets into a mailbox. Yours or, just as often, your supplier’s. Usually through a reused password or a fake sign-in form.
2. They read, changing nothing. For weeks. They learn who approves payments, what amounts are normal, how people speak to each other, when invoices go out.
3. They prepare the ground. They create a rule that quietly moves messages containing words like “invoice” or “payment”, so the real mailbox owner never sees the exchange. They register a near-identical domain with one letter changed.
4. They step in at exactly the right moment. When a genuine invoice is about to be paid. They send the same invoice, same letterhead, same amount, with one thing altered: the bank account.
5. They add urgency. A plausible reason for the change, a request to settle it today, sometimes a plea for discretion because “it is an internal matter”.

Why competent people fall for these

Because nothing in them is false except the bank account. The invoice is real. The amount is the expected one. The exchange continues an existing thread. The person writing uses the usual phrasing, because they have been reading it for months.

Training of the “do not click suspicious links” kind does not help here, because there is no link and nothing looks suspicious. The only thing that stops the fraud is a rule applied regardless of how convincing the message is.

Signals that justify holding the payment

• The sender’s address differs by one character from the usual one: a doubled letter, an rn in place of an m, a changed domain ending.
• The reply address is different from the sender address shown.
• The bank account is in a country other than the one the supplier operates in, or at a payment institution rather than their usual bank.
• The account holder’s name does not exactly match the company name on the invoice.
• Time pressure appears, however politely, or a request not to discuss it with colleagues.
• The change is presented as temporary, because of an audit, a frozen account or a merger.
• A director asks for an urgent payment outside the normal process, from a phone, because they are “in a meeting”.

The procedure that stops it

The core rule is one sentence: a change of bank details is never actioned through the channel the request arrived on. The rest is detail.

1. Verification on a second channel, always. Call the supplier on the number from the contract or your own records, never the number in the e-mail announcing the change.
2. Speak to a person you know, not to whoever answers a new number.
3. Dual approval above a threshold you set. Two different people, one of whom explicitly checks the account, not just the amount.
4. The first payment to a new account is a small one, confirmed by phone with the supplier before the rest is transferred.
5. Changes to bank details are recorded, with the date, the person who confirmed and the verification method. If there is no record, there is no change.
6. The same rule applies in reverse. Tell your customers you never change bank details by e-mail, and put that sentence on your invoices.

The procedure has to be written down and has to apply to the owner as well. A rule the boss skips when in a hurry is not a rule, and attackers know exactly who to impersonate.

What to configure technically

• Two-step authentication on every mailbox, with no exemption for management. Most compromises start with a password, not with a vulnerability.
• Alerts when new forwarding or message-moving rules are created. This is the classic sign of a compromised mailbox and can be detected automatically.
• Blocking automatic forwarding to external addresses.
• SPF, DKIM and DMARC configured correctly on your domain, so that nobody else can send messages in your company’s name.
• Visible tagging of messages from outside, so a message that looks internal is immediately seen not to be.
• Periodic review of delegated permissions on shared mailboxes such as billing or office.

All of this is done in Microsoft 365 with licences you most likely already hold. The problem is usually not a lack of tools, it is that nobody has turned them on.

If the money has already gone

The first hours matter most, because funds are moved on quickly into other accounts.

1. Call the bank immediately and ask for the payment to be stopped or recalled. Ask them to contact the beneficiary bank as well.
2. File a report with the police. You will need the case number both for the bank and for any insurer.
3. Change the passwords of the accounts involved and end active sessions.
4. Look for forwarding rules created in the affected mailboxes and check what other messages were sent from them.
5. Notify the supplier and the other partners in the exposed correspondence, because the attack usually continues towards them.
6. If the company falls within the scope of NIS2, check whether the incident is significant and observe the reporting deadlines.

What we do and what stays with you

PRO IT configures the technical side: two-step authentication, access policies, alerts for forwarding rules, the SPF, DKIM and DMARC records, external message tagging and the anti-fraud protection that comes with the cybersecurity service. If you do not know what is switched on today, the IT audit tells you in writing.

The payment procedure stays with you, because it is an organisational decision rather than a technical one. No IT provider can prevent a transfer approved by a person who had the right to approve it.