A supplier you've worked with for five years sends an invoice like every month. Same email address, same signature, same tone. Only the bank account number in the message is different — "please pay to the new account, the previous one is being closed". The transfer goes out on Friday afternoon. On Monday the real supplier calls asking when you're going to pay. That's when you realise the money went to someone else entirely.
This isn't a hypothetical scenario. It's the most expensive attack on SMEs today — business email compromise — and unlike phishing with a crooked bank logo, nothing here looks suspicious. In one of our projects, a 30-person construction subcontractor from Silesia lost 187,000 PLN on a single transfer like this. They recovered 62,000 PLN after months of correspondence with banks and police. The rest was gone.
This post isn't about "training people to be vigilant". Vigilance doesn't scale. This post is about how to build a simple procedure that stops even a tired Friday-afternoon bookkeeper from sending money to the wrong account.
Anatomy of the attack
The modern version of this scam usually goes like this. The attacker breaks into your supplier's mailbox — usually via a stolen password or phishing, no MFA. For a few weeks they only read. They learn how the supplier writes, how they sign emails, when invoices go out, who on your side approves them. They already know invoices arrive on the 25th to Anna in accounting, and Anna doesn't call back — she just books.
When the moment arrives, the attacker sends a real invoice from the real mailbox, with one change: the bank account number. Sometimes swapped in the email body, sometimes in the PDF. Sometimes they send a polite "heads-up" a week earlier — "we're notifying you of a change of bank account" — on company letterhead, with a scan of the owner's signature. The invoice with the new account that follows looks entirely natural.
There's no suspicious domain. No weird attachment. SPF, DKIM, DMARC — all pass, because the email really does leave the supplier's server. Anti-phishing filters won't react. That's why the attack works so well: technically everything is fine, only reality has been swapped underneath.
Why SME processes fail here
At a large corporation, changing a supplier's payment details goes through procurement, verification in a vendor register, and manager approval. At a 20–40 person SME, that chain is usually missing. The invoice reaches the bookkeeper by email, the bookkeeper books it, the owner signs the transfer in online banking — often without looking at the account number, because "it's from Nowak, we've been paying him for five years".
Three assumptions that fall apart in practice:
- "I'll recognise it from the email address" — the attacker is writing from that address, because they have access to that mailbox.
- "If something's off, the supplier will call" — they won't, because from their side everything looks fine, the invoice was sent normally.
- "The bank will block a suspicious transfer" — it won't. A transfer to a domestic account, for an amount consistent with your history, does not look suspicious to a bank.
You're not missing a "detection tool". You're missing one step in the process: independently verifying the bank account change through a channel different from the email that requested it.
The "callback" procedure: one rule you write into your policy
The only rule that works, and that the attacker can't route around, sounds like this: every change of a supplier's bank account must be confirmed by phone, on a number from the vendor record in your ERP — not from the signature in the email.
For a 20–50 person company, in practice it looks like this:
- The person entering the invoice compares the account number with the one on file in the vendor record in the ERP (Comarch Optima, Subiekt, enova365 — doesn't matter which).
- If the number differs: the transfer is held until verification.
- Verification is a phone call to the supplier's number from your CRM/ERP — never from the email, never from the "notice of account change". A conversation with a specific contact person, not with a general receptionist.
- After confirmation: the account number is updated in the vendor record in the ERP, with a short note ("change confirmed by phone on 12 Sep 2026 with Mr. Kowalski, +48 xxx xxx xxx").
- Only then does the transfer go out.
Two supporting mechanics:
- VAT white-list verification in the ERP — automatic check that the new account is registered on the official list. If it isn't, the transfer either goes to the old account or waits for confirmation. Comarch Optima, enova365 and Subiekt have had this for years; you just switch it on.
- Amount thresholds with a second pair of eyes — for transfers above, say, 20,000 PLN: two-person signature in online banking. It costs nothing and cuts off most attacks, because a second person notices different things from the first.
That's it. You don't need a SOC, an EDR or an expensive "anti-BEC" tool. You need one sentence in your policy and a "bank account confirmed by" field in the supplier record.
The first 30 minutes after detection
Suppose the transfer went out anyway. Every minute matters — literally. The money usually lands in a "mule" account and is withdrawn or forwarded within hours. Order of operations:
- Call your own bank's business hotline and request a transfer recall. Get the case number. For SEPA and domestic transfers the chance drops with every hour — after 24 hours it's a few percent.
- Contact the recipient's bank (you'll see it on the transfer confirmation) — directly, asking them to freeze the funds on the account.
- File a police report — the duty prosecutor can issue an order to secure funds faster than a routine case would. Get the case number.
- Report to CSIRT NASK (incydent.cert.pl) — even if it's "just" money, the incident gets correlated with other reports and can help trace the whole campaign.
- Notify the real supplier — their mailbox is compromised, every other customer of theirs is at risk. It's not a fun call, but a necessary one.
- Rotate passwords on your own accounting and management mailboxes and switch on MFA anywhere it isn't on yet. If the attacker reached your supplier, the same route could reach you.
At that Silesian company, a fast recall through the bank and a police report within 3 hours froze part of the money in the mule account before it was withdrawn. The rest was already abroad and gone. Without that first hour, the recovered 62,000 PLN wouldn't have come back either.
A short checklist for this week
You don't need a quarter-long project to close this risk. In a week, the minimum you can do is:
- Write the callback procedure into your internal policy — one paragraph, signed off by management.
- Fill in the ERP contact-phone fields for your 10 largest suppliers (if they're not there).
- Enable VAT white-list verification for domestic transfers — if you use Comarch Optima or enova365, it's a checkbox.
- Introduce a second person for transfers above a threshold — set with management, typically 10–20k PLN for 20–50 person companies.
- Turn on MFA on accounting and management mailboxes (if it isn't on) — that closes the door the attackers used against your supplier.
- Hold a 15-minute meeting with accounting, show them a real example email, and say: "from today, every account change — phone call from ERP, not from email".
That's a few hours of work. One transfer not sent to a fraudster pays that cost back many times over in a year.
What next
Payment fraud against suppliers isn't a problem that's about to disappear — quite the opposite, in the last two years these attacks have clearly accelerated. Attackers noticed that SMEs move enough cash to lose hundreds of thousands on a single transfer, and have processes simple enough to let it through.
If you want to check what your payment procedure actually looks like and where the holes are — instead of waiting for a fake "Nowak" to reach out — get a second pair of eyes on it. The first call is free and takes half an hour.
Vigilance doesn't scale. What scales is one field on the supplier record: "bank account confirmed by phone by".