What is business email compromise vendor payment fraud, and how do I prevent it?

A fraudster impersonates a real vendor — often by spoofing their email domain — and requests a change to bank account or payment details, redirecting a legitimate payment to an account they control. The FBI's IC3 calls this the single most reported category of cybercrime loss and recommends verifying any account-change request through a secondary channel, not the email that made the request.

By Zuny Fester, Head of Operations and Marketing

Reviewed by Zuny Fester

Published September 14, 2026Last reviewed September 14, 2026Editorial policy

Part of the accounts payable and invoice processing guide.

The tactic	A spoofed or lookalike vendor email domain requests a change from check to wire, or to a new bank account
What FBI IC3 calls it	"The $50 billion scam" as of its 2023 PSA, growing further by the 2024 update
Core prevention rule	"Use secondary channels and/or two-factor authentication to verify requests for changes in account information"
Domain check	Confirm the email domain matches the vendor's real domain — lookalike domains (e.g. co-pany.com vs. company.com) are common
Where funds increasingly land	IC3's 2024 update notes growth in funds routed through third-party payment processors and cryptocurrency exchanges before disappearing

How the fraud actually reaches AP

The scam rarely starts with a dramatic breach. It usually starts with an email that looks routine: a vendor's accounts receivable contact writing to say their bank has changed, please update the payment details for the next invoice. The FBI's IC3 describes exactly this pattern — "a fraudulent request for a change in payment type (frequently from check to wire transfer) or a change from one bank account to a different bank account under their control." Nothing about the invoice itself has to be fake for this to work; only the destination account needs to change.

The single control that stops most of it

IC3's own recommendation, repeated across its 2023 and 2024 advisories, is specific: "Use secondary channels and/or two-factor authentication to verify requests for changes in account information." In practice, that means a phone call to a number already on file — not a number provided in the email requesting the change — before updating any vendor's bank details. IC3 also recommends checking that "the sender's address appears to match who it is coming from" and that any URL in the email is genuinely associated with the vendor, since domain spoofing (a lookalike domain substituting one character) is a common technique.

Why this is getting harder to catch, not easier

IC3's 2024 update flags a shift in where stolen funds go: "In 2023, the IC3 saw a growth in BEC reporting where funds were sent directly to a financial institution housing custodial accounts held by third-party payment processors, or peer-to-peer payment processors, and cryptocurrency exchanges." Funds routed this way move and disappear faster than a traditional bank-to-bank wire, which shrinks the window to claw back a fraudulent payment once it's been sent — making prevention before the payment goes out the only reliable control.

Next step

Map the finance workflow with the most exposure and prove the automation path.

Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.

Book a workflow review

Checklist

Verifying a vendor bank-account change request

Never update bank/payment details based on an emailed request alone
Call the vendor's main line already on file — never a number given in the request itself
Confirm the sender's email domain exactly matches the vendor's known domain, character by character
Don't click any link in the request — type the vendor's known URL directly if verification is needed online
Log the change and who verified it before the next payment run uses the new details

Frequently Asked Questions

It helps but doesn't fully prevent it — IC3's guidance pairs 2FA with secondary-channel verification specifically because a fraudster doesn't need to compromise the vendor's actual email account if a convincingly spoofed lookalike domain fools the reader instead.

IC3 recommends reporting it at ic3.gov as soon as it's discovered — speed matters because funds routed through third-party payment processors or crypto exchanges can move and become unrecoverable quickly, per IC3's own 2024 trend data.

Yes — a convincing email with accurate details doesn't rule out compromise; it can mean the fraudster has real information about the relationship. The verification is about confirming the request through a channel the fraudster doesn't control, not about how legitimate the email itself looks.

Sources

Topic

AP & Invoice Processing

Accounts payable and invoice processing is the set of steps a vendor bill goes through between arriving at a company and turning into a payment: capturing what the vendor sent, checking it against wha…

Diagnostic

Why did we pay the same vendor invoice twice?

Almost always one of two things: the vendor exists as two separate records in your vendor master, so a duplicate-invoice-number check that only compares within one vendor ID never sees the second copy — or the invoice was entered twice by different people, because it arrived through two channels and each assumed they had the only copy.

Diagnostic

Why does one vendor show two different balances in AP aging?

The vendor almost certainly exists as two separate records in your vendor master file — created under slightly different names (a typo, a rebrand, a merger, a re-onboarding) — so bills and credits are split across both. AP aging reports by vendor record, not by real-world vendor, so it shows two partial balances instead of one true balance.

How-to

How do I maintain segregation of duties in an automated AP approval workflow?

Keep three roles distinct in the workflow itself: who can create or edit a vendor record, who can enter or submit a bill, and who can approve it for payment. Institutional guidance is explicit that authorizing a payment and the person who executes it shouldn't be the same individual — automation makes it easy to collapse these into one click, which is exactly the risk to design against.