Vendor Impersonation Fraud: How It Happens and How to Stop It

If you run accounts payable for clients in QuickBooks Online, vendor impersonation fraud is the most expensive mistake that can happen on an ordinary workday. It rarely looks like fraud. It looks like a routine note from a vendor you have paid for years: our bank account changed, please update it before the next run. This post covers how the scam actually works, five patterns worth recognizing, and the one control that stops most of it. It is informational, not legal, accounting, or Nacha advice.

Vendor impersonation is a form of business email compromise (BEC). The FBI's IC3 unit recorded $2.77 billion in reported BEC losses across 21,442 complaints in 2024, an average close to $129,000 per reported incident. A large share of those losses begin exactly where a bookkeeper sits: a request to change where a vendor gets paid.

How vendor impersonation fraud works

The mechanics are simple, which is why they keep working. An attacker gets a message in front of you that looks like it came from a real vendor, asking you to update that vendor's bank details. You update the vendor record. The next ACH payment lands in the attacker's account. By the time the real vendor calls asking where their money is, it has usually been moved out and is gone.

There are two common ways the message looks legitimate. In the first, the attacker has compromised the vendor's actual email account and replies inside a real thread, so the address, the history, and the tone are all genuine. In the second, they register a lookalike domain that is one character different from the real one. Either way, the signature and the back-and-forth feel normal, and nothing about the email itself gives the game away.

Source: FBI IC3 2024 Internet Crime Report.

Five patterns worth recognizing

1. The reply inside a real thread. The most convincing version. The email comes from the vendor's real address, inside a conversation you actually had, because the mailbox is compromised. You cannot spot this one by looking at the email.
2. The lookalike domain. One character off: an "rn" that reads as "m," a ".co" instead of ".com," an extra letter. Easy to miss when you are moving fast.
3. The urgency nudge. "Please update before the next payment run." "Our old account is closed as of today." Time pressure exists to stop you from verifying.
4. The new-vendor first invoice. A brand-new vendor with no payment history to compare against. Whatever banking details arrive are simply accepted, because there is no prior record to contradict them.
5. The official-looking form. A W-9 or an "updated banking form" PDF attached. It feels like documentation, but a form proves nothing about who actually controls the account on it.

The common thread: none of these can be reliably caught by reading the email more carefully. They are caught by stepping outside the email.

The one control that stops most of it

Out-of-band verification. When a vendor asks to change bank details, confirm the request through a channel you had before the request arrived, using a phone number already in your own records, not a number or reply-to address from the email itself.

This works because of a single asymmetry: a compromised mailbox will gladly reply "yes, that's correct" to your confirmation email, but it cannot answer a phone call placed to the number you already had on file. Call that known number, confirm the change is real, and read the new account details back digit by digit. For a high-value or unusual change, add a second person to approve it, so the same individual is not both editing the vendor's bank info and releasing the payment.

One honest limit, worth stating plainly: a callback confirms that a person you trust agrees the change is real. It does not independently prove that the new account is owned by the vendor. Treat the callback as the core layer, and add a second control for large or suspicious changes rather than relying on it alone.

Why a note in the memo field is not enough

Catching the fraud is half the job. The other half is being able to show, later, what you checked. If a payment is ever disputed, or a client's cyber-insurer asks how a bank change was verified, "it is in the memo field" is thin.

A line in the QuickBooks memo field is editable afterward by anyone with access, with no record of who wrote it or when. A defensible record holds more: the original request, the channel it arrived on, the channel you verified through, the timestamp, who confirmed it, and exactly what changed. Captured at the time, in a form that cannot be quietly edited later. For more on what counts as a durable record, see the audit-trail post.

Where Nacha Phase 2 fits

A line of regulatory context, since it comes up: Nacha's Phase 2 fraud-monitoring rule, now in effect, expects ACH originators and the providers in that chain to run a documented, risk-based process for identifying payments initiated by fraud. The rule does not mandate a specific method or certify any tool. A documented out-of-band vendor-verification step is one reasonable control to point to. Informational only; confirm specifics with your bank and CPA.

FAQ

Is a phone callback enough on its own?

It is the core control and it stops most of these, but be precise about what it proves. It confirms a known contact agrees the change is real; it does not prove the new account belongs to the vendor. For material or unusual changes, treat the callback as one layer and add a second approver.

What if the vendor only ever communicates by email?

Find another channel you can trust: a phone number from a prior invoice, a signed contract, or the vendor's own published website, and call that. Do not confirm by replying in the same email thread, because if that mailbox is compromised, the attacker answers.

Do I need software for this?

No. The manual checklist above works on its own and costs nothing. Software only matters for the record-keeping: BankChangeGuard logs the request, emails a one-time code to the contact you already had on file, and exports a tamper-evident PDF, so the documentation step happens automatically instead of being a memo nobody can defend. It does not move money, approve payments, or make anyone "Nacha-compliant"; the decision to release a payment stays with you and your bank.