Payment diversion fraud is a scam that redirects a legitimate payment to a criminal-controlled account. It usually relies on impersonation, email compromise, or altered bank details in invoices, payment instructions, or supplier records, so the receiving account is changed before funds are transferred.
What Payment Diversion Fraud Means
Payment diversion fraud is not just a generic scam, it is a redirection attack on the payment process itself. The fraud succeeds when an attacker can change the destination account before money leaves the organisation, often by impersonating a supplier, a colleague, or a trusted intermediary.
Because the scheme targets routine payment workflows, it is dangerous precisely when staff expect the request to look ordinary. Small edits to banking details, invoice instructions, or approval emails can be enough to divert funds if the change is accepted without independent verification.
How Payment Diversion Fraud Usually Works
The common pattern is social engineering plus process manipulation. Attackers may compromise email accounts, spoof a trusted sender, or intercept a legitimate thread, then introduce revised bank details at the point where finance teams are preparing to pay.
In many cases the attacker does not need to steal credentials from the payment system itself. Exploiting trust in correspondence, supplier records, or payment urgency is often enough to cause a false transfer to a criminal-controlled account.
This is why payment diversion fraud often overlaps with business email compromise, invoice redirection, and supplier mandate fraud. The attack path may start in email, but the loss is realised in the payments function when the recipient account has already been changed.
Why It Is Hard To Spot In Time
Payment diversion fraud works best when the change looks plausible and lands inside an existing business process. A new account number, a revised sort code, or a last-minute “urgent” update can blend into normal accounts payable activity unless someone checks it against a trusted channel.
The fraud is especially effective when there is no out-of-band confirmation, weak segregation of duties, or too much reliance on a single email thread. The attacker benefits from speed, familiarity, and the assumption that payment instructions in a routine workflow are genuine.
Controls That Reduce Exposure
Defences should focus on verifying bank detail changes through a separate channel, using known contact details rather than the request itself. Payment holds, dual approval, supplier master data controls, and callback verification all reduce the chance that a changed account is accepted silently.
Finance teams also need a clear process for handling exceptions, because attackers often rely on pressure and urgency to bypass normal checks. Where payments are frequent or high value, stronger review of supplier changes and payment run controls is usually more effective than relying on user awareness alone.
For sector-specific guidance on the operational controls that matter most, Cybersecurity for Legal Firms Guide and Invoice Redirection and Supplier Bank Detail Fraud Guide are useful starting points, and Business Email Compromise Awareness for Finance Teams Guide adds the finance-team operating context behind the attack.
Risk and Threat Considerations
Payment diversion fraud creates direct financial loss, but the broader risk is control failure in the payment chain. Once a fraudulent account change is accepted, recovery can be difficult because the money may move quickly through mule accounts or be withdrawn before the error is detected.
Failure mechanism: The attacker abuses trust in payment instructions, supplier records, or email correspondence to replace the legitimate destination account before funds are released.
Impact: Organisations can lose funds, disrupt supplier relationships, and face weaker confidence in finance controls after a successful diversion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1566 — Phishing | Payment diversion fraud commonly begins with phishing or email compromise used to alter payment instructions. |
| T1114 — Email Collection | The fraud often relies on mailbox access or intercepted conversations to rewrite payment details. | |
| Recommendation — Map invoice and payment redirection activity to T1566 and monitor for credential theft and mailbox takeover. Detect mailbox access abuse and anomalous forwarding or conversation hijacking tied to payment requests. | ||
| CIS Controls v8 | CIS-14 — Security Awareness and Skills Training | Staff must recognise invoice redirection, supplier impersonation, and callback fraud patterns. |
| CIS-6 — Access Control Management | Payment diversion often succeeds when payment and supplier-data changes are not tightly controlled. | |
| Recommendation — Train finance and procurement teams to verify payment changes through independent channels. Restrict who can change supplier banking details and require approval for payment-sensitive changes. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The payment process depends on authenticating requesters and restricting who can change payee details. |
| DE.CM-09 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | Mailbox compromise and unauthorized access are common precursors to payment diversion fraud. | |
| Recommendation — Apply PR.AA-05 to verify request origin and limit who may amend payment instructions. Use DE.CM-09 to flag unauthorized access to finance mailboxes and supplier data. | ||
Related resources from NHI Mgmt Group
- What breaks when payment fraud controls assume a human is always the actor?
- Who is accountable when fraud starts on social media or SMS and ends in a payment?
- How should banks detect APP fraud when the customer is the one authorizing the payment?
- What do payment teams get wrong about behavioural intelligence in fraud detection?