Why do email-based vendor payment scams still work in mature organisations?

They work because they imitate normal business process, not because they are technically sophisticated. When a fake invoice or bank-change request arrives inside a believable thread, people follow the workflow they already trust. Mature organisations fail when payment approval relies on the thread itself instead of separate verification.

Why This Matters for Security Teams

Email-based vendor payment scams succeed because they exploit business process, not just user error. A believable invoice, bank-change notice, or thread hijack can pass through mature organisations when approvals depend on the conversation trail instead of separate verification. That makes the control gap procedural: finance and security may have strong tooling, but the workflow itself still trusts email as evidence.

This is why broader identity and process governance matters. The NIST Cybersecurity Framework 2.0 emphasises governance, protection, and detection as connected outcomes, which is relevant here because payment fraud is rarely a single control failure. It is usually a chain of weak identity assurance, missing callback checks, and excessive trust in shared inboxes or delegated approvals. NHIMG’s Ultimate Guide to NHIs — The NHI Market also highlights how identity sprawl and process fragmentation create predictable exposure points that attackers can exploit through routine business channels.

In practice, many security teams encounter vendor payment fraud only after a legitimate-looking change request has already been processed.

How It Works in Practice

These scams work by blending into normal operations. Attackers either compromise an existing mailbox, spoof a vendor, or insert a fraudulent message into an active thread. The request then looks routine: “new bank details,” “updated remittance instructions,” or “urgent payment to avoid disruption.” Because the message matches expected business language, staff often focus on speed and continuity rather than independent validation.

That is why the right control is not better email filtering alone. Organisations need a payment verification process that is separate from the email channel itself. Current guidance suggests using out-of-band verification for any vendor bank change, dual approval for payment setup changes, and a known-good contact record that is maintained outside the invoice thread. If finance systems allow it, approval should require a fresh confirmation step tied to a trusted vendor profile, not the message content.

• Verify bank-change requests by calling a pre-registered number, not one included in the email.
• Require dual approval for new payees, amended bank details, and high-value payment exceptions.
• Monitor for mailbox takeover signals, such as forwarding-rule changes or unusual login locations.
• Keep vendor master data under change control, with separate review for identity and banking fields.

From a governance view, the NIST Cybersecurity Framework 2.0 is useful because it reinforces that protection and detection must cover both people and process, not just perimeter controls. The recent DeepSeek breach also illustrates a broader lesson: once identity or access artefacts are exposed, attackers move quickly to weaponise normal business trust. These controls tend to break down in highly decentralised procurement environments because vendor ownership, approver authority, and payment execution are split across too many systems and teams.

Common Variations and Edge Cases

Tighter payment controls often increase friction, requiring organisations to balance fraud resistance against operational speed. That tradeoff is real in finance teams that process large volumes, support urgent procurement, or work across regions with different banking norms.

Some environments need extra nuance. Shared service centres may rely on queue-based approvals, which makes callback verification harder. Multinational firms may face local constraints around who can confirm bank changes. Executive assistants and procurement specialists may also legitimately request rapid vendor changes, which attackers imitate well. There is no universal standard for this yet, but current guidance suggests defining exception paths in advance so urgency does not become a bypass.

The most common failure is treating a reply in the same thread as sufficient proof of legitimacy. That is especially risky when the mailbox is compromised, because the thread can include real history, real signatures, and real tone. Mature organisations reduce this risk by separating identity verification, payment authorisation, and message transport. When those functions collapse into one inbox, the scam becomes much easier to execute.

Security and finance leaders should therefore treat email as a notification channel, not a trust mechanism. The strongest programmes make bank-detail changes, invoice exceptions, and release authority independently verifiable, even when the request appears routine.

Related resources from NHI Mgmt Group

• Why does credential phishing still work in organisations with mature email security?
• Why do rules-based email controls fail against modern phishing and vendor impersonation?
• How should organisations prevent vendor email compromise from bypassing normal approval workflows?
• Why do executive impersonation scams work so well in large organisations?