Who is accountable when a payment is redirected through a fraudulent email request?

Why This Matters for Security Teams

A fraudulent payment request is rarely just an email problem. It is a control failure that crosses messaging security, identity assurance, finance approvals, and business ownership. The practical question is not only who clicked or who processed the transfer, but who was responsible for confirming that the request was authentic before money moved. That is why accountability must be assigned to the process owner, not only to the technical team.

Security teams often treat this as a phishing issue and stop at mailbox protections, yet the damage usually happens after a legitimate user sees a believable message and follows a normal workflow. Strong controls such as DMARC, MFA, and conditional access matter, but they do not verify a changed bank account or an urgent request from a spoofed executive. NIST guidance on layered controls, including NIST SP 800-53 Rev 5 Security and Privacy Controls, reinforces the need for control ownership, separation of duties, and verification procedures around high-risk transactions.

In practice, many security teams encounter this only after a payment has already been redirected, rather than through intentional testing of the approval path.

How It Works in Practice

The accountable party is usually the business process owner for the payment or beneficiary-change workflow, supported by finance operations and security. That owner is responsible for ensuring there is a verification step that does not rely on the same channel as the fraud attempt. If the request arrives by email, the confirmation must happen through a known-good callback, a pre-registered contact path, or an out-of-band approval step with clear logging.

Operationally, the control set should cover the full chain:

• Email authentication and anti-spoofing controls to reduce impersonation risk.
• Identity checks for approvers, including MFA where access to payment systems is involved.
• Dual approval or segregation of duties for beneficiary changes and unusual transfers.
• Documented exception handling for urgent payments, with mandatory retrospective review.
• Audit trails that show who approved, who validated, and what evidence was used.

This is where identity and payment governance intersect. If a payment platform relies on shared inboxes, delegated mailbox access, or weak approval records, accountability becomes blurred and later investigation is harder. Where privileged access is used to update supplier data or release funds, PAM and strong entitlement governance matter because a compromised admin can bypass ordinary checks. The same logic applies to NHI governance when automation submits or approves workflow actions: the organisation still needs a named owner for the control, even if an agent or service account executes the task.

Authoritative control families such as NIST SP 800-207 Zero Trust Architecture support the idea that trust should be continuously validated, not assumed from email origin alone. These controls tend to break down when finance teams are allowed to override approval steps during end-of-month pressure because the exception path becomes the path of least resistance.

Common Variations and Edge Cases

Tighter payment controls often increase friction for finance operations, requiring organisations to balance fraud reduction against business speed. That tradeoff becomes visible in high-volume environments where urgent supplier changes, mergers, or payroll events create pressure to bypass standard checks. Current guidance suggests that exceptions should be rare, time-bound, and independently reviewed, but there is no universal standard for how many approvals is enough in every organisation.

In smaller organisations, one person may wear several hats, which makes separation of duties difficult. In that case, compensating controls become more important: stronger callback validation, supervisor review, and post-payment reconciliation. In larger environments, the risk shifts toward fragmented ownership, where email security, IAM, ERP administration, and finance each assume someone else owns the final verification step. That gap is exactly where fraudulent requests succeed.

There is also a growing intersection with agentic AI and automation. If AI tools help draft responses, route invoices, or flag exceptions, the organisation still needs a human owner for the decision to release funds. The control should verify the transaction, not merely the message. For broader alignment on control design and accountability, teams often map the workflow to identity assurance and transaction integrity principles rather than treating it as a pure email-security issue.

Related resources from NHI Mgmt Group

• Who is accountable when a fraudulent request is approved through a trusted channel?
• Who is accountable when fraudulent email causes a payment or data breach?
• Who is accountable when a customer is tricked into authorising a fraudulent payment?
• Who is accountable when an access request is approved through a ticket but later turns out to be inappropriate?