Finance Index
What is business email compromise (BEC) and how does it target the payment step?
Reference guide to bec payment diversion fraud, including payment timing, method choices, control points, reconciliation, and vendor communication.
Business email compromise is a fraud where an attacker uses a spoofed, lookalike, or genuinely compromised email account to send convincing payment instructions - typically a vendor "updating" bank details or an executive "urgently" requesting a wire. It targets the payment step specifically because that's where money moves, and because a legitimately approved invoice can still be diverted at payout if the destination details are swapped.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Business email compromise (BEC) | Business email compromise is a fraud where an attacker uses a spoofed, lookalike, or genuinely compromised email account to send convincing payment instructions - typically a vendor "updating" bank details or an executive "urgently" requesting a wire. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Vendor impact | Callback verification, done correctly: call a phone number you already have on file for the vendor - never the number in the email or on the new invoice - and confirm the change with a known contact. | Keeps vendor records and payment decisions reliable. |
| Does account takeover beat "check | In a true account takeover, the fraudster controls the vendor's real inbox, so the domain is legitimate, the thread is real, and prior emails check out. | Keeps evidence clear and reduces control risk. |
| Payment impact | Stop, don't reply to the email, and call a known-good number on file (not one supplied in the request) to confirm with a real contact; the timing right before a big payment is itself a red flag, not a coincidence. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| What is callback verification | Independent confirmation by phone using a number from your own records, to a named vendor contact, documented with who you spoke to and when - using the email's number or a number on the suspicious invoice defeats the entire control. | Keeps evidence clear and reduces control risk. |
How do I verify a vendor bank-detail change request is really them?
Callback verification, done correctly: call a phone number you already have on file for the vendor - never the number in the email or on the new invoice - and confirm the change with a known contact. Treat any change request as suspect by default, especially if it arrives near a large scheduled payment, carries urgency, comes from a new sender or domain, or asks you to bypass normal process. The alert or red flag is a trigger to verify, not permission to proceed.
Why does account takeover beat "check the domain" training?
In a true account takeover, the fraudster controls the vendor's real inbox, so the domain is legitimate, the thread is real, and prior emails check out. Domain-inspection training catches lookalike spoofs but not takeover. The control that survives takeover is out-of-band verification of the bank-detail change through a separate, known channel - because the email channel itself is compromised.
We got an email from a vendor changing bank details right before a large payment - how do I verify?
Stop, don't reply to the email, and call a known-good number on file (not one supplied in the request) to confirm with a real contact; the timing right before a big payment is itself a red flag, not a coincidence.
What is callback verification and what's the correct procedure?
Independent confirmation by phone using a number from your own records, to a named vendor contact, documented with who you spoke to and when - using the email's number or a number on the suspicious invoice defeats the entire control.
What are the red flags of a fraudulent payment-change request?
Urgency, a new sender or lookalike domain, a subtle change in tone or phrasing, timing just before a large payment, requests to bypass process or keep it confidential, and new banking details in a different country or at a different bank.
What payment-stage verification should happen even when onboarding was clean?
Re-check at execution time: confirm the destination details still match the vendor's history, because a clean onboarding doesn't protect against a later takeover or a swapped invoice - verification is an event you repeat, not a box you tick once.
What is invoice redirection / payment diversion fraud and how big is the problem?
Fraud that reroutes a legitimate payable to the attacker's account by altering banking details; BEC and related diversion consistently rank among the costliest cyber-enabled crimes, with reported losses in the billions annually and most organizations targeted at some point.
What do average BEC losses look like and how many companies get hit?
Per-incident losses commonly run from tens to hundreds of thousands of dollars, and the large majority of organizations report attempted payment fraud each year - exact figures vary by survey, but the direction is consistently up.
Our ceo's email was spoofed asking AP to urgently wire funds - the payment hasn't gone out - what do we do?
Do not send; verify the request through a known channel directly with the executive, preserve the email and headers as evidence, report it to IT/security, and use the incident to reinforce that no payment skips verification regardless of who appears to be asking.
How do we train AP to resist authority-pressure fraud without paralyzing real urgent payments?
Give staff explicit permission and a fast path to verify any payment regardless of seniority, define a documented emergency process with independent approval, and make clear that following verification policy is never a fireable offense - removing the fear is what defeats the pressure.
What is account takeover vs spoofing?
Spoofing forges the sender so the email only looks like the vendor; takeover means the attacker actually controls the vendor's real account. Takeover is harder to catch because every surface check passes - which is why out-of-band verification matters more than inbox inspection.
How can we detect a payment about to go to an account that doesn't match the vendor's history?
Compare the proposed destination against the vendor's known account and history at payment time and flag mismatches for review - Stampli's integrity controls do exactly this for bank account, routing, and related fields before the change is trusted.
What fraud-prevention capabilities should we require in payment software?
Bank-detail change detection and alerting, comparison of payment signals against vendor history, review/approval gating on sensitive changes, segregation of invoice and payment approval, validation that blocks payments on missing or unverified details, and a complete audit trail - with honest "raises signals, doesn't guarantee" framing.
Stampli perspective
Stampli's payment-integrity controls compare new or changed payment signals - bank account, routing number, billing address, sender email, sender domain - against the vendor the system already knows, and surface the risk inside the payment workflow before the change is trusted; sensitive changes can require review or approval before they become usable for payment. These controls raise and route risk signals; they don't guarantee detection, and they're designed to trigger your trusted-channel verification, not replace it.