Payment redirect fraud is a scheme that convinces a target to send funds to a new or controlled bank account instead of the real vendor account. It commonly relies on urgent invoice language, altered banking details, and a believable business pretext to bypass normal review.
Expanded Definition
Payment redirect fraud is a trust abuse scheme that diverts a legitimate payment flow to an account controlled by the fraudster. It often appears as a supplier bank-change request, a revised remittance instruction, or an urgent invoice correction that is designed to bypass the normal verification path.
The term is narrower than generic payment fraud because the key issue is not a counterfeit card, stolen checkout session, or account takeover. The attacker is trying to change the destination of an otherwise valid transfer. In practice, the fraud succeeds when staff treat a payment instruction as administratively routine and do not independently confirm the change with a trusted channel. That boundary matters because the control failure is usually in verification and approval, not in the payment rail itself.
Security teams and finance teams use the term differently in some organisations. Some classify it under business email compromise, while others treat it as a vendor-master-data integrity issue. The most accurate reading is that it is both a social engineering problem and a payment-control problem.
Examples and Use Cases
Payment redirect fraud shows up in routine commercial workflows rather than in obviously malicious systems. The pattern is usually simple, but the surrounding pretext is designed to look operationally normal.
- A fake supplier email asks accounts payable to update banking details before an “overdue” invoice is processed.
- A fraudster impersonates a project manager and requests that a final milestone payment be sent to a different account.
- A compromised mailbox is used to intercept a real vendor thread and insert revised remittance instructions into an active conversation.
- A change to bank details is accepted from an unverified attachment or portal message without callback validation.
- A finance workflow allows a single approver to both receive the request and approve the payment, reducing review depth and making redirection easier.
The trade-off is speed versus assurance: the faster an organisation can process supplier changes, the more it needs out-of-band verification to avoid sending funds to an attacker-controlled destination.
Security Implications
The main security problem is not just loss of money. A successful redirect can undermine trust in payment controls, expose weaknesses in supplier onboarding, and reveal that approval workflows are too easy to imitate or override. The fraud often leaves minimal technical evidence because the payment itself may be authorised by a human who believed the request was legitimate.
Common failure conditions include weak identity verification for vendor changes, mailbox compromise, approval fatigue, and poor segregation between invoice receipt and payment approval. Once the payment is sent, recovery is difficult because the transfer may be immediate, partially irreversible, or fragmented across downstream accounts. The blast radius can include cash loss, audit findings, strained supplier relationships, and follow-on fraud if the attacker learns how the organisation validates payments.
A useful practitioner observation is that the first suspicious signal is often a process mismatch, not a malware alert: a bank-detail change that arrives through an unexpected channel, outside a normal workflow, or with unusual urgency.
Domain and Governance Relevance
Payment redirect fraud matters because it sits at the intersection of finance operations, identity trust, and governance over who can authorise a payment destination change. In NHI-heavy environments, the same pattern can affect machine-initiated payouts, platform settlement accounts, or API-driven treasury workflows if service accounts and automated approvals are allowed to update payment details without strong human verification.
That makes the issue relevant to vendor-master integrity, segregation of duties, and approval design as much as to email security. Organisations that rely on a single inbox, a single approver, or a single system of record create a fragile trust chain. NHIMG treats this as a control-assurance problem: the question is whether a requested redirection can be independently verified before money moves. NIST SP 800-53 Rev. 5 is a useful reference point for access control, auditability, and transaction integrity expectations around sensitive financial workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | Payment redirects succeed when request authority is weakly verified. |
| Recommendation — Enforce strong requester verification before approving destination changes. | ||
| CIS Controls v8 | 5 — Account Management | Vendor and approver identity changes need controlled ownership and review. |
| 6 — Access Control Management | Fraud depends on excessive approval power and weak separation of duties. | |
| Recommendation — Restrict and review who can modify payment recipient details. Separate request, verification, and approval authority for payment updates. | ||
| MITRE ATT&CK | T1656 — Impersonation | The fraud commonly relies on impersonating vendors or executives. |
| Recommendation — Map impersonation attempts to T1656 and monitor for payment-related social engineering. | ||
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?
