Payment redirection fraud is a scheme in which an attacker persuades a finance team to send money to an altered account or bank destination. It relies on subtle changes to routine payment instructions and weak verification steps, making out-of-band confirmation and approval segregation critical controls.
Expanded Definition
Payment redirection fraud is a socially engineered payment compromise that targets the accounts payable or treasury workflow rather than the payment system itself. The attacker’s objective is to change the beneficiary, bank account, or remittance instruction so that a legitimate transfer is diverted to an unauthorized destination. It is often discussed alongside business email compromise, but that label can be too broad: payment redirection fraud is specifically about the final movement of funds, not just the email or identity compromise that enabled it.
Definitions vary across vendors and incident-response playbooks, but the core pattern remains consistent: an apparently routine payment request is altered in a way that looks plausible enough to survive cursory checks. Strong control design therefore depends on dual verification, segregation of duties, and trusted callback procedures. NHI Management Group treats this as an identity and process integrity problem as much as a fraud problem, because the attacker exploits weak approval authority and inconsistent handling of payment instructions. Authoritative control mapping is most often drawn to NIST SP 800-53 Rev 5 Security and Privacy Controls, particularly around access, authorization, and procedural safeguards.
The most common misapplication is treating the fraud as a pure email security issue, which occurs when teams harden inboxes but fail to validate changed bank details through an independent channel.
Examples and Use Cases
Implementing payment redirection fraud controls rigorously often introduces friction in procurement and finance, requiring organisations to weigh payment speed against confirmation overhead and stronger approval discipline.
- A supplier sends an urgent notice asking accounts payable to update remittance details before the next invoice run. The change is accepted because the email thread looks familiar, but the bank account now belongs to the attacker.
- A finance manager receives a message that appears to come from a chief executive requesting a confidential wire transfer. The payment is made to a new destination without a separate callback verification.
- A legitimate vendor account is compromised and used to submit revised banking instructions through a normal purchasing relationship. The fraud succeeds because the organisation trusts the communication channel more than the payment-control process.
- A treasury team processes a change request after seeing a scanned letterhead and a correctly signed email. No one verifies the change with a pre-established contact method or independent approver.
- Security teams align controls to guidance from the UK NCSC guidance on business email compromise and similar fraud advisories, because many payment redirection cases begin with a deceptive message but end with a funds transfer.
Why It Matters for Security Teams
Payment redirection fraud exposes a gap between technical security and business-process assurance. Even when MFA, email filtering, and endpoint controls are in place, an attacker who can influence payment instruction handling may still succeed if approvals are informal or if staff treat change requests as routine. That is why security teams need to understand this term as part of fraud prevention, identity verification, and workflow governance, not merely as an awareness-training topic.
The risk is amplified in organisations that rely on shared mailboxes, outsourced finance operations, or agentic automation that can initiate or prepare payments. Where an AI agent or workflow assistant has execution authority, the approval boundary must remain explicit and reviewable. Controls from the CISA guidance on business email compromise and related financial crime reporting and advisories from FinCEN reinforce the need for verification, segregation, and timely escalation. Organisations typically encounter the operational reality of payment redirection fraud only after a transfer has cleared and recovery depends on banks, law enforcement, and control evidence, at which point the term becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Covers access control and authorization discipline that helps prevent altered payment instructions. |
| NIST SP 800-53 Rev 5 | AC-2 | Account management supports restricting who may request or approve payment changes. |
| ISO/IEC 27001:2022 | A.5.15 | Access control policy underpins segregation and authorization for payment changes. |
Restrict payment-master data changes to named, reviewed, and periodically recertified roles.
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?
