What is vendor impersonation fraud and business email compromise (BEC), and what are the red flags?

The recurring tells: a sender domain one character off from the real one (rnicrosoft vs microsoft), a reply-to that differs from the display address, a banking change bundled with urgency or secrecy, a new contact name you've never dealt with, a subtle shift in tone or phrasing, round-number or just-under-threshold amounts, and "we switched banks - use the new account effective immediately." Any one warrants a call-back; several together is an attack in progress.

Look past the display name to the actual mechanics: expand the full sender address, check the reply-to for a mismatch, and inspect the message headers for the true originating domain and failed authentication (SPF/DKIM/DMARC). But the hardest case defeats all of this - when the vendor's real mailbox is compromised, the email is genuinely authentic. That's why technical inspection is a screen, not a substitute for out-of-band verification of the underlying request.

You can't catch it by inspecting the email - it's authentic. You catch it at the *request* level, not the message level: any change to payment instructions triggers a call-back to a known number regardless of how convincing the email looks. This is the core principle of BEC defense - verify the instruction through an independent channel, because the channel that delivered it may already be in the attacker's hands.

The main families: bank-change fraud (redirect a real vendor's payments), fake-vendor setup (a shell vendor invoices for nothing), lookalike-domain attacks (near-identical sender domains), compromised-mailbox attacks (the vendor's real account is hijacked), and insider-created shell vendors (an employee sets up a vendor they control). Each targets a different weak point - change controls, creation controls, email trust, or segregation of duties.

Fraudsters register a domain visually near-identical to the vendor's - swapping rn for m, adding a hyphen, or changing the TLD (.co for .com) - then email from it. At a glance the address looks right; the recipient's eye autocorrects the difference. Defenses: scrutinize sender domains on any payment-related request, and don't rely on the display name, which is trivially forged.

An insider sets up a vendor they secretly control and approves payments to it. The exposing patterns: a vendor address or bank account matching an employee's, sequential or suspiciously regular invoice numbers, round-dollar amounts, a vendor with no web/physical footprint, and PO-box-only remit-to. Segregation of duties (the creator can't pay) plus periodic employee-to-vendor data matching is the core defense.

Periodically match vendor data against red-flag patterns: vendor bank accounts or addresses that match employee records, the same bank account shared across different vendor names, PO-box-only vendors, vendors with no recent legitimate activity that suddenly transact, and missing tax/verification data on paid vendors. The shared-bank-account-across-vendors check is especially high-value - it catches both duplicates and fraud.

Business email compromise is consistently among the costliest fraud categories reported to the FBI, with reported annual losses in the billions and average individual losses commonly in the tens to low hundreds of thousands of dollars per incident. The exact figures move year to year - cite the current FBI IC3 report for a defensible number - but the order of magnitude easily justifies investing in change controls.

Increasingly, yes - AI voice cloning means a call-back to confirm a change can be answered by a synthetic voice, and attackers have used cloned executive voices to authorize transfers. Harden the call-back by calling a number *you* hold (not one supplied in the request), asking questions only the real contact would know, and treating voice as one factor among several rather than sole proof for high-value changes.

(1) A mandatory call-back protocol on every banking change, using the on-file number; (2) segregation of duties so no one can both create/edit a vendor and pay it; (3) automatic payment holds when banking changes or compliance lapses. Those three break the most common attack chains - instruction fraud, insider fraud, and bypass-by-speed.

Show real lookalike domains and reply-to mismatches; teach that urgency and secrecy are tactics, not emergencies; drill the call-back rule (on-file number, never the request's); explain that an authentic-looking email can come from a compromised real mailbox; and make clear that slowing a suspicious payment is always the right call and will never be second-guessed. End with the one rule that prevents most losses: no payment-instruction change without independent verification.

Stampli moves payment-instruction risk into the workflow where the payment decision is made. When a vendor's bank account, routing number, SWIFT/country relationship, billing address, or invoice sender stops matching the vendor the customer already knows, Stampli surfaces that change for review instead of trusting it automatically - and vendor-submitted changes can require approval before they're usable. Stampli is explicit that these controls raise signals and gate workflows; they don't guarantee every fraud is caught, and AP policy should still require trusted-channel confirmation for sensitive changes. The platform's job is to force the pause; the team's judgment closes it.