How to Prevent Direct Deposit Fraud

How the scam runs

Someone emails whoever handles payroll — at a company your size, often the owner or a single bookkeeper — claiming to be an employee. New bank, switched credit unions, please update my direct deposit before the next run. The details are correct because they came off LinkedIn and your own website. The tone is right. Sometimes the display name is spoofed, sometimes it's a lookalike domain with one letter transposed, and sometimes the employee's actual mailbox has been compromised and the message is genuinely from their account.

Friday's payroll pays a mule account. The money is moved out within hours. The real employee finds out on payday, at which point you owe them their wages a second time, because “we already paid it to a criminal” is not a defense against a wage obligation.

The timing is deliberate. Requests land mid-week, close enough to the run to create urgency, far enough out to be processed as routine. A surprising number arrive on Friday afternoon before a holiday weekend, when nobody is going to call anyone to check.

Why your spam filter finds nothing

Because there's nothing there. No attachment, no malicious link, no malware, no exploit. It's a short, polite, well-written email making an ordinary administrative request. Every technical control you own is looking for technical badness and correctly reporting that it found none.

The tell isn't in the message. The tell is that this person has never emailed payroll before, is asking for something they've never asked for, and the reply-to doesn't match the from. That is a behavioral judgment, which is precisely why the tools that catch this are behavioral rather than signature-based, and why security awareness training has diminishing returns here. The sloppy tells people were trained to look for are gone.

The callback rule

One control does most of the work, costs nothing, and takes ninety seconds: every request to change banking details gets confirmed by voice, at a phone number you already had on file.

The details matter more than the headline, and this is where implementations quietly fail:

• The number comes from your records, never from the request. A phone number in the signature of the email asking for the change is part of the attack. This is the single most common way a callback procedure gets defeated — it was followed, and it called the fraudster.
• Voice, not email.Replying to ask “is this really you?” sends the question to whoever controls the mailbox. If the account is compromised, they will answer yes. Text is better than email and worse than a call.
• No exceptions for people you know well.A twelve-person company where everyone is friendly is the exact environment this scam is built for, because a rule that gets waived for familiar names isn't a rule. Make it procedural and boring: it applies to the founder too.
• Write it down and tell the team it exists. Partly so the person doing payroll has cover to slow down a request marked urgent, partly because a documented procedure is what your crime policy will ask about later.

Four things that back it up

The callback is the load-bearing control. These reduce what gets through when someone is rushed or out sick:

• Notify the old account, not just the new one. When banking details change, send a confirmation to the address and phone already on file. If the request was fraudulent, the real employee finds out days before payday instead of after it.
• Impose a change window. Banking changes take effect for the run afternext, not the imminent one. Urgency is the scam's only real weapon, and a stated waiting period removes it without inconveniencing anyone who genuinely switched banks.
• Push changes into employee self-service with MFA.If your payroll platform supports employees updating their own details behind multi-factor authentication, that's strictly better than an email to a human — it moves the attack from “write a convincing email” to “defeat MFA.”
• Review the change log. Every direct deposit change in the period should trace back to a request you can point at. This is already part of the payroll audit checklist, and it catches the inside version of this fraud as well as the outside one.

If it already happened, the first hours decide it

Money sent to a mule account is recoverable for a short window and then it isn't. Call your bank immediately and ask for a recall or a SWIFT indemnity, then file with the FBI's IC3 — their Recovery Asset Team can freeze funds at the receiving institution, and it works far more often within the first 72 hours than after. Do that before you start the internal post-mortem. The full reporting order covers who to call and in what sequence.

Then pay the employee. Their wages are still owed, and delaying while you investigate creates a wage problem on top of a fraud loss.

Where software actually fits

After the callback, not instead of it. Behavioral email security models what normal looks like for each sender and flags the message that doesn't fit the pattern — a first-time request to payroll from an address that doesn't quite match, arriving from an unusual place.

The reasonable starting point for most small businesses costs nothing: Sublime is free for the first 100 mailboxes with no MX change, and if you're on Microsoft 365 Business Premium you may already own Defender for Office 365 with its anti-phishing and impersonation policies switched off. Check that before buying anything. The full comparison, including the premium hands-off options, is in payroll diversion and BEC protection software.

One note on insurance

Standard employee dishonesty coverage often doesn't pay for this, because nobody inside your company was dishonest — you were tricked into sending money voluntarily. That's social engineering fraud, it usually sits under a separate and much smaller sublimit, and many policies condition it on having exactly the callback procedure described above. What the coverage actually pays for goes through the gaps. Worth reading before you need it rather than during the claim.