Business Email Compromise Red Flags: Payment Change Requests, Vendor Fraud, and Escalation Steps

Overview

Business email compromise, often shortened to BEC, is a broad category of fraud built around trust, timing, and impersonation. The attacker does not always need malware or a dramatic breach. Sometimes the only goal is to insert one convincing message into an existing business process and get a payment rerouted, credentials harvested, or sensitive data disclosed.

That is why BEC prevention works best when it is tied to operations, not treated as an email problem alone. The highest-risk moments tend to happen where money, urgency, and authority meet: accounts payable workflows, vendor onboarding, executive approvals, payroll changes, legal requests, and cross-border transactions. In those moments, the right question is not just “Is this email malicious?” but “Does this request fit our approved process?”

Use this article as a standing checklist before acting on any payment-related email. It is especially useful for teams that process invoices, manage vendor records, approve wire transfers, or support shared mailboxes such as accounts payable or procurement.

The core principle is simple: do not trust a payment change request just because it appears to come from the right person. Verify the request using a second channel and the contact information already on file, not the details provided in the message itself.

If your team also handles invoice fraud generally, see Fake Invoice Email Scams: Current Examples, Business Risks, and Verification Workflow for a related workflow focused on invoice-specific attacks.

Checklist by scenario

This section gives you scenario-based checklists you can return to before approving, processing, or escalating a request.

Scenario 1: A vendor asks to change bank account or payment details

This is one of the most common and costly vendor payment fraud patterns. The email may reference a real supplier, a real invoice cycle, or a real employee name. Sometimes the attacker has monitored prior conversations and replies inside an existing thread. Treat all banking changes as high risk until verified.

• Pause the request immediately. Do not update vendor records or release payment based on email alone.
• Check whether the request matches your standard process. If your process requires a form, ticket, portal update, or signed approval, do not bypass it because the message sounds urgent.
• Validate the sender carefully. Review the full email address, reply-to field, display name, and domain spelling. Look for swapped letters, extra words, or lookalike domains.
• Do not use phone numbers or links in the message. Call the vendor using the number already stored in your system of record or contract file.
• Use a known contact and ask specific questions. Confirm the exact change requested, the effective date, and whether the organization recently changed banking institutions.
• Require dual approval for bank changes. A second reviewer should confirm that the request was independently validated.
• Document who verified the request and how. Keep a note in the vendor record or ticket so future reviewers can trace the decision.
• Delay payment if verification is incomplete. A short delay is safer than a misdirected transfer that may be difficult to recover.

Scenario 2: An executive or manager requests an urgent transfer

Executive impersonation works because the message is designed to override normal hesitation. It may stress confidentiality, urgency, travel, legal sensitivity, or the need to bypass ordinary approval paths. Even if the sender appears to be a real leader, urgent payment requests deserve separate verification.

• Treat unusual urgency as a fraud signal. “Need this in the next 10 minutes” or “I am in a meeting, just do it” should increase scrutiny, not reduce it.
• Compare the request to normal executive behavior. Is this person usually involved in direct payment instructions? Do they normally message through this channel?
• Verify through a separate communication path. Call, message through an approved internal system, or confirm with an executive assistant using existing contact details.
• Check approval thresholds. If the amount exceeds a defined limit, require the standard two-person or committee approval no matter who appears to request it.
• Review payment destination details. New beneficiary accounts, foreign accounts, or last-minute destination changes are strong reasons to stop and verify.
• Escalate immediately if pressure is applied to bypass policy. Real leaders may be impatient; they should not need you to ignore control requirements.

Scenario 3: An existing email thread suddenly shifts to payment instructions

Some BEC attacks are convincing because they begin inside a legitimate conversation. If an attacker has access to a mailbox or has replayed a thread using stolen content, the email may contain accurate references, signatures, and tone.

• Ask whether the change makes operational sense. A routine discussion turning into a new payment destination deserves review.
• Inspect thread history. Look for subtle inconsistencies such as missing participants, changed reply-to addresses, or a jump from one domain to another.
• Watch for language drift. Small changes in tone, formatting, punctuation, or signing style can matter when viewed in context.
• Confirm with a known party outside email. Use phone or a trusted collaboration platform to verify the latest instruction.
• Consider account compromise. If the message truly came from a known account, the sender may be compromised rather than impersonated.

If you suspect compromised accounts rather than a standalone payment scam, it is worth reviewing credential misuse risks alongside email fraud. A useful companion resource is Credential Stuffing Attacks Explained: How to Spot Them and Protect Your Accounts.

Scenario 4: Payroll or direct deposit changes from an employee

Payroll teams face a similar scam pattern: a message appears to come from an employee asking to update direct deposit details quickly. Attackers may target shared HR or payroll inboxes and time the request near pay dates.

• Do not process direct deposit changes from email alone. Require the approved HR or payroll workflow.
• Verify identity using existing employee records. Contact the employee through known internal channels.
• Apply extra care near payroll deadlines. Attackers often rely on time pressure to reduce verification.
• Flag requests that ask for secrecy or exceptions. Normal payroll changes should not require covert handling.

Scenario 5: Legal, audit, or confidential document requests tied to payment activity

Not every BEC attempt seeks a transfer immediately. Some attacks begin by requesting tax forms, vendor master data, invoice histories, or executive contacts. That information can later support more convincing fraud.

• Limit what is shared before verification. Basic metadata can still help an attacker map your payment environment.
• Check whether the requester is authorized for the data. Internal familiarity is not the same as business need.
• Verify any request that combines urgency and secrecy. “Do not call me” is a significant warning sign.
• Escalate if sensitive financial or identity data is involved. What looks like a document request may be the first phase of a larger fraud attempt.

What to double-check

These are the red flags and validation points teams should review every time, regardless of scenario.

Sender and domain details

• Display name matches but the actual address is different.
• Reply-to address points somewhere unexpected.
• Domain uses a lookalike spelling, added word, or different top-level domain.
• External message appears to imitate internal formatting or signatures too closely.

Request quality and timing

• The change arrives just before a payment deadline, holiday, quarter close, or weekend.
• The request insists on urgency, confidentiality, or procedural exceptions.
• The requester discourages phone verification or says they are unavailable for a call.
• The message introduces a new bank account, especially without prior notice.

Process consistency

• The request bypasses vendor management, procurement, treasury, or ticketing steps.
• Supporting documentation is missing, unusually formatted, or inconsistent with prior records.
• The amount, destination, or payment type differs from normal patterns.
• The approver is outside the usual chain or the request arrives through an unusual mailbox.

Technical and operational context

Technical controls can support human review, but they do not replace it. Email authentication, mailbox alerts, forwarding rules monitoring, and identity protections are useful guardrails. Still, a message can pass technical checks and remain fraudulent if the request itself is unauthorized or manipulated.

For that reason, the most reliable double-check is procedural: confirm requests using a trusted second channel, record who performed the verification, and require a second approver for high-risk changes. If your organization discovers mailbox compromise or wider security issues while investigating a BEC attempt, your incident review may need to expand. See Security Incident Timeline Tracker: Major Cyber Incidents and Outages This Year and Ransomware Incident Watch: Confirmed Cases, Tactics Used, and Public Impact for broader incident context.

Escalation steps when a request looks suspicious

1. Stop the transaction. Put the payment, vendor change, or account update on hold.
2. Preserve the evidence. Save the email with headers if possible, note timestamps, and capture the requested account details.
3. Notify internal owners. At minimum this may include accounts payable, treasury, procurement, security, and the request owner.
4. Verify via known contacts. Contact the vendor, executive, or employee using previously recorded contact details.
5. Check for account compromise. Review whether the sender’s account may have been accessed or abused.
6. Search for related activity. Look for similar requests to other staff, recent forwarding rules, or login anomalies.
7. If money was sent, act immediately. Work through your bank and internal incident process without delay. Recovery options are time-sensitive.
8. Reset and secure affected accounts if compromise is suspected. Password resets, session review, MFA checks, and mailbox rule inspection may all be appropriate.

Teams dealing with exposed credentials should also review Password Leak Checker Guide: How to Confirm Exposure and Secure Accounts Fast.

Common mistakes

The easiest way for a payment change request scam to succeed is for a team to assume someone else has verified it. These are the mistakes that show up repeatedly in real-world workflows.

• Trusting brand familiarity over process. A known vendor name or executive signature does not prove the request is valid.
• Calling the number in the suspicious email. That only verifies the attacker can answer the phone.
• Relying on one reviewer. Dual control matters most when the message looks routine.
• Treating urgency as proof of legitimacy. Fraud often depends on compressing decision time.
• Skipping documentation. If no one records who confirmed a change, the control becomes hard to audit and easy to bypass later.
• Updating master records before full verification. Once a vendor record changes, later staff may assume the new details are approved.
• Focusing only on malware indicators. Many BEC emails are plain text and technically simple.
• Ignoring near misses. A stopped scam is still valuable incident data. Review how it got close and what control worked or failed.

Another frequent mistake is to isolate BEC from broader fraud and identity risk. Attackers who gather employee data, leaked credentials, or financial identifiers may move between payment fraud and identity abuse. For adjacent recovery planning, these guides may help: What to Do After a Data Breach: A Step-by-Step Response Guide for Individuals, Identity Theft Warning Signs Checklist: Early Clues, Fast Checks, and Recovery Priorities, and Credit Freeze vs Fraud Alert: Which Protection Step Makes Sense After Identity Exposure?.

When to revisit

This checklist is most useful when it is reviewed before high-risk periods and after any workflow change. Revisit your BEC prevention process at these times:

• Before seasonal planning cycles. End-of-quarter activity, year-end close, holiday staffing gaps, and major procurement periods can all increase pressure and reduce scrutiny.
• When workflows or tools change. New ERP systems, shared mailbox changes, finance automation, ticketing changes, and vendor onboarding redesigns can open gaps.
• After staffing or role changes. New approvers, temporary coverage, or reorganizations often create uncertainty around who owns verification.
• After a near miss or suspicious request. Update scripts, approval steps, and mailbox routing based on what the incident revealed.
• When adding new vendors or payment rails. Cross-border payments, new banks, and alternative settlement methods deserve specific review.

A practical quarterly review can be short and still effective. Confirm your known vendor contact list is current, test your callback procedure, review who can change payment records, verify dual approval thresholds, and remind staff that no email alone can authorize a banking change. If possible, run a tabletop exercise using one recent scam pattern and one compromised-mailbox scenario.

For teams building an operational playbook, a simple final rule works well: pause, verify, document, escalate. Pause any unusual payment request. Verify it through a trusted second channel. Document the validation and approval trail. Escalate quickly if anything does not fit the process. That habit is often what separates a routine interruption from a preventable financial loss.

If your organization handles other impersonation-driven scams, you may also want to review Bank Impersonation Scam List: Common Scripts, Spoofed Numbers, and Verification Rules and Package Delivery Text Scams: Current Messages, Fake Tracking Links, and Safe Response Steps for verification patterns that carry over well to business environments.