Bank routing fraud is a type of payment manipulation in which an attacker convinces a target to send funds to a different account than the one originally intended. It commonly appears in invoice fraud and supplier impersonation schemes, where the attacker inserts new payment details into an otherwise legitimate business conversation.
What Bank Routing Fraud Is
Bank routing fraud is payment redirection: a criminal changes the destination account details in an otherwise legitimate payment request so funds are sent to the attacker instead of the intended recipient. It most often rides on trusted business processes.
How It Works in Practice
The fraud usually begins with access to a real conversation, invoice thread, or supplier workflow. The attacker then inserts revised banking instructions, often by impersonating a vendor, hijacking email, or exploiting weak approval controls so the change looks routine.
This makes the fraud effective because the payment still appears operationally valid. The victim is not being asked to send money to a fake invoice so much as to send real money to the wrong account, often at the moment when internal staff are expecting a payment change.
Why It Is Hard to Spot
Routing fraud succeeds by abusing trust, timing, and familiarity. The request may reference a real purchase order, a real supplier name, or a real project milestone, which reduces suspicion and makes rushed finance teams more likely to approve the transfer.
It is especially dangerous when payment changes are handled outside a structured verification process. Small edits to account numbers, routing numbers, or beneficiary details can be easy to miss if teams rely on email alone or accept last-minute changes without out-of-band confirmation.
Business and Security Consequences
The immediate impact is financial loss, but the broader consequence is loss of process integrity. A successful routing fraud incident can also trigger vendor disputes, delayed deliveries, recovery work, and internal friction over who approved the change.
Because the attack exploits a legitimate business relationship, it can be difficult to unwind after payment release. Recovery often depends on speed, bank cooperation, and whether the transfer can be recalled before the funds are withdrawn or layered onward.
Risk and Threat Considerations
Bank routing fraud is risky because it targets a control point where trust and payment execution meet. Once altered instructions are accepted, even a strong accounting process can move money to the wrong destination before the deception is detected.
Failure mechanism: The attacker either compromises a communication channel, impersonates a trusted party, or inserts fraudulent banking details into an established payment workflow so the destination account is changed without a reliable second verification.
Impact: Funds are transferred to the attacker, the legitimate counterparty goes unpaid, and the organisation may face direct loss, delayed operations, dispute resolution, and reputational damage.
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 NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Bank routing fraud often hinges on abused credentials or inbox access that enable payment-detail changes. |
| AU-6 — Audit Review, Analysis, and Reporting | Tracing who changed routing details and when is central to detecting and investigating redirection fraud. | |
| Recommendation — Protect payment-change workflows with strong credential lifecycle controls and rapid revocation when compromise is suspected. Review payment-change logs quickly to identify unauthorized beneficiary edits and suspicious approval patterns. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | This fraud is reduced by limiting who can edit beneficiary details and by enforcing approval separation. |
| Recommendation — Restrict and review access to vendor-master and payment-change functions. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Where payment detail changes occur through portals or APIs, improper authorization can let an attacker alter routing data. |
| Recommendation — Enforce function-level authorization on payment-update endpoints and administrative workflows. | ||
Practitioner Guidance
What to watch for: Treat any bank detail change as a high-risk event, even when the request appears to come from a known contact. The most important control question is whether the new payment instruction was verified through a separate channel that is already trusted for that supplier.
Governance implication: Finance, procurement, and AP teams should own a clear step for validating account changes, because ad hoc exception handling is where this fraud most often succeeds. The best controls are procedural consistency and friction at the moment of payment redirection.
Related resources from NHI Mgmt Group
- Why do exposed passport and bank details increase downstream fraud risk?
- How should security teams prevent common bank fraud scenarios in digital workflows?
- Who is accountable when bank fraud results from poor data security and access governance?
- Who is accountable when impersonation fraud succeeds in a regulated bank?
