The message
A factory we work with sent a routine update on a seasonal program — the corrected packing list for a bulk shipment, the final payment invoice, a question about freight. At the bottom, one additional note: their finance team was standardizing the company bank account, and could all future payments be arranged to the new account, since the old one would no longer be used for receiving funds.
There was nothing strange about it. We had been working in that thread for months. The invoice was expected, the amount was right, the packing list matched the cartons. The account change read like housekeeping.
We verified it anyway, by phone, on a number we already had. It was legitimate.
That outcome is not the interesting part. The interesting part is that we could not have known that from inside the thread — and neither could you.
Why apparel sourcing is a target
Business email compromise works best where four conditions overlap, and overseas apparel production has all four.
Payments are large, recurring, and expected. A deposit and a final payment per PO, several POs per season, five figures at a time. Nobody blinks at an invoice.
The counterparty is offshore. Funds move by international wire. Once a wire lands in an overseas account and is withdrawn, there is no chargeback, no dispute window, no insurer of last resort.
Communication is informal and asynchronous. Threads run across Slack, email, and WeChat, in a shared second language, across a twelve-hour time difference. Slightly odd phrasing is normal. Requests arriving overnight are normal. “Please confirm today” is normal.
The relationship is warm. After a year of samples and approvals and shipping crises, you trust the person on the other end. That trust is the asset being stolen. Fraudsters don’t break into a relationship — they wait inside one.
The typical attack is not a spoofed lookalike domain sent cold. It is a compromised mailbox at the factory, a coordinator’s or an accountant’s, sitting quietly for weeks. The attacker reads the thread. They learn the invoice numbering, the greeting style, the sign-off, the name of the person who approves payment, and the week of the month the final payment usually goes out. Then they send one message, in the real thread, from the real address, at the right moment.
There is nothing to catch. The message is authentic in every respect except its intent.
Why the usual instincts fail
“It came from the right address.” In a mailbox compromise, it did.
“It’s the same thread we’ve been using all season.” So is the fraud. That’s the method.
“I’d notice if the writing seemed off.” You wouldn’t, reliably. Everyone’s writing seems slightly off in a cross-language thread, and attackers copy the register from the thread itself.
“They’d never ask for something unusual.” They didn’t. A company changing banks is ordinary and boring, which is exactly why it’s the chosen pretext.
“I replied to the message and they confirmed.” You confirmed with the attacker. Replying in-thread verifies nothing at all. This is the single most common way brands lose the money — the verification and the fraud travel through the same compromised channel.
The verification protocol
One rule underneath all of it: verify through a channel the requester did not choose.
-
Never accept a banking change in the thread it arrived in. Not by reply, not by a confirming email, not by a Slack thumbs-up. Treat the thread as untrusted the moment banking details appear in it.
-
Call a number you already had. From your own vendor file, a prior contract, or a business card — never the number in the signature block of the message requesting the change. Attackers update signature blocks.
-
Speak to a person you have spoken to before, and recognize the voice. Ask them to state the change themselves rather than confirming yours. “What’s changing on your side?” is a better question than “Are you switching to Bank X?” — the second one hands them the script. Assume voice cloning is possible on a short call; a live back-and-forth about something only the real person would know is worth thirty seconds.
-
Require the change on company letterhead, signed, from a named finance contact — with the legal entity name on the account matching the entity on the invoice and the PO exactly. A beneficiary name that differs even slightly from the contracting entity is a stop.
-
Apply a two-person rule. Whoever verifies is not whoever releases the payment. This one control defeats most of the attack surface, because it requires the attacker to compromise two independent people rather than one mailbox.
-
Send a small test payment first, and confirm receipt by phone before the balance moves. The cost of a test wire is trivial against the exposure.
-
Enforce a cooling-off period. No account change takes effect on the same day it’s requested, no matter what deadline is attached to it. Urgency is a tactic, not a fact.
Red flags worth naming
None of these prove fraud. Any of them should escalate a request from routine to verified-by-phone.
- The change arrives bundled with an invoice, rather than as a standalone notice from finance
- The new account is in a different country than the factory, or in a different name than the contracting entity
- The account is at a bank in a jurisdiction the vendor has no operations in
- There’s pressure to use the new details for an invoice already in flight
- The request explains itself (“standardizing,” “audit,” “our old bank is closing”) without your having asked
- Reply-to differs from the sender address, or the message arrives outside the sender’s normal working hours
- Follow-up pressure comes from a second address or a new person copied in
- Any resistance to a phone call, or a request to keep it to email
If a payment has already gone out
The first twenty-four hours decide the outcome.
- Call your bank immediately and request a wire recall — ask specifically for a SWIFT recall and, in the US, ask whether the FBI’s Financial Fraud Kill Chain applies. Recovery rates are meaningful within hours and collapse after that.
- Report to law enforcement. In the US, file with the FBI’s IC3 the same day; that filing is what activates the kill chain.
- Call the factory on a known number and tell them their mailbox may be compromised. They may have other customers being worked in parallel and no idea.
- Preserve everything — full email headers, Slack exports, the invoice files. Don’t delete the thread.
- Notify your insurer. Crime and cyber policies often cover funds transfer fraud, but usually with a notification window measured in days.
- Then fix the process, not the person. Someone following a normal workflow was targeted by a professional. Blaming the individual guarantees the next incident gets reported late.
Controls to put in place before you need them
Most of this is cheap and can be done in an afternoon.
- Bank details live in a controlled vendor master file, not in whatever email is most recent
- Every vendor has a verified voice contact on record for financial changes, captured at onboarding
- Banking changes have a written procedure with a named approver, and it’s part of vendor onboarding so the factory expects the friction
- Payment release requires two people
- Contracts include a clause stating that banking changes are only effective on out-of-band verbal verification, and that payment to unverified details does not discharge the obligation
- Anyone who can initiate a wire has seen a real example of this attack
The rule
Verify every banking change by voice, on a number you already had, with a second person releasing the payment — every time, including the times it’s obviously fine.
The request in our thread was genuine. We still made the call. If you only verify the requests that feel wrong, you have no control at all — because the ones designed to take your money are the ones designed to feel right.




