Watch for altered bank details, unusual urgency, secrecy, late-stage changes in an ongoing thread, or requests that bypass normal approval steps. A request becomes high risk when it combines financial action with pressure to avoid verification. The safest response is to pause and validate through a separate channel before any transfer occurs.
What warning signs make a payment request look like BEC?
A BEC payment request usually feels believable because it borrows a real business context, but the warning signs show up in the process, not just the wording. The strongest signals are a changed destination account, a request that arrives with urgency, and pressure to keep the transfer off the normal review path. When those factors appear together, treat the request as suspect until independently verified.
How BEC payment requests typically break normal controls
BEC works best when the attacker can insert themselves into an existing conversation or impersonate a trusted person, so the request often looks like a routine supplier invoice, executive instruction, or late-stage banking update. The weakness is usually not the payment system itself, but the human and process shortcuts around it, especially when staff rely on thread history, familiar names, or past payment patterns instead of separate verification.
Look closely at any request that asks you to ignore a standing approval step, accept a new bank account at the last minute, or treat a sensitive change as routine. Those are the moments where BEC attempts tend to become visible. A valid request can still be unusual, but a legitimate one should survive a pause, a callback, or a second-channel check without resistance.
For teams that want a broader view of scam patterns and payment controls, the Email Identity and BEC Guide is the natural starting point because it ties impersonation signs to the payment-verification controls that stop invoice fraud.
What separates a suspicious request from a normal exception
A legitimate exception usually has a traceable business reason, an approver who can be reached through known contact details, and documentation that fits the usual control environment. A BEC attempt often has the opposite profile: secrecy, compressed timing, unfamiliar account details, and a push to bypass established checks. Even when the language is polite, the process pressure is what makes the request dangerous.
Thread hijacking is another important clue. If the request appears inside an ongoing email chain, but the bank details, tone, or timing have shifted, treat that as a possible compromise rather than assuming continuity means authenticity. In practice, the safest interpretation is that continuity is only a convenience for the attacker, not evidence of legitimacy.
When the payment request is tied to invoice fraud or a manipulated supplier change, the attack pattern often matches the same operational signals seen in other payment scam. The Authorised Push Payment (APP) Fraud Guide is useful here because it explains the bank controls and warning patterns that make rushed transfers and verification avoidance so risky.
How to verify before money moves
The right response is to stop the transfer from becoming a time-sensitive decision. Verify the request through a separate channel that you already trust, such as a known phone number, a pre-existing vendor contact record, or a separate internal approval workflow. Do not reply only within the same email thread if the thread itself may be compromised.
Use verification to test the part that changed. If the request introduces a new bank account, confirm that account through an independent source of truth, not through the same message that introduced it. If the urgency is real, the sender should still accept verification without objecting to a reasonable delay. Resistance to verification is itself a useful signal.
For cases where the lure arrives through a deceptive message or a secondary channel, the QR Code Phishing (Quishing) Guide reinforces the same discipline: treat the delivery path as part of the risk, and validate outside the channel that may have been manipulated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Payment approval relies on controlled account and contact changes. |
| Recommendation — Restrict and review payment-related account changes before funds move. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | BEC succeeds when approval and payment actions bypass enforced process boundaries. |
| IA-2 — Identification and Authentication (Organizational Users) | Separate-channel verification depends on confirming the requester’s identity. | |
| Recommendation — Enforce approval boundaries so payment changes cannot bypass required checks. Require strong user authentication before accepting payment instructions. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | BEC-style abuse often mirrors unauthorized action through weak approval logic. |
| Recommendation — Validate that sensitive payment functions require explicit authorised approval. | ||
Practitioner Guidance
What to prioritise: Prioritise the combination of red flags rather than any single one. A request that is merely urgent may be legitimate; a request that is urgent, secretive, and paired with changed payment details deserves immediate challenge.
What to verify: Verify the bank change, the requester identity, and the approval path independently. If any one of those three cannot be confirmed through a trusted alternate route, treat the payment as unsafe until the issue is resolved.
Common mistake: Do not let a familiar email thread, executive tone, or supplier history substitute for fresh verification. BEC succeeds when teams mistake administrative familiarity for authenticity.
Practitioner takeaway: The most reliable BEC warning sign is not a strange message, but a trusted-looking payment request that tries to compress judgment, bypass verification, and move money before anyone can check the change.
Related resources from NHI Mgmt Group
- What are the signs that a payment scam is using social engineering rather than a normal customer request?
- What are the signs that a vendor payment request may be part of a third-party reconnaissance scam?
- What are the signs that a vendor payment request may be fraudulent?
- What are the warning signs that a tech support scam is in progress?