Accountability usually spans security, identity, finance, and business operations because the failure sits in the workflow, not a single tool. Security may monitor signals, but finance owns payment controls and business leaders own approval discipline. Frameworks that support this view are the ones that tie access, verification, and segregation of duties together.
How accountability splits when BEC and investment fraud hit the workflow
The losses usually do not sit with one team because the fraud path crosses messaging, identity, payment, and approval controls. Security helps detect impersonation and account compromise, but the teams that own payment release, beneficiary verification, and exception handling are accountable for stopping the money movement. That division matters because fraud controls fail when they are treated as a technical alert problem only.
In practice, accountability should follow the control point. If the weakness is spoofed email or mailbox takeover, the security and identity owners need to harden authentication and monitoring. If the weakness is a rushed wire, a changed payee, or an overridden approval, finance and business process owners need to own the control design, enforcement, and evidence.
Where investment fraud is involved, the accountable group also includes the business function that approves trades, client instructions, or disbursements. The key question is who can stop a transaction before value leaves the organisation, not who notices the fraud after the fact.
Why security, finance, and business leaders all own part of the control
BEC and investment fraud are workflow failures, so accountability should be split across the teams that create exposure and the teams that can still interrupt the transaction. Security owns detection, alerting, and the technical controls around email and identity. Finance owns payment controls, vendor and beneficiary changes, and segregation of duties. Business leaders own approval discipline, escalation behaviour, and whether staff are allowed to bypass the control path under pressure.
This is why the most useful control design combines verification with authority. Email Identity and BEC Guide is a good fit for the message-authentication and payment-verification side of the problem, while finance owns the last gate before funds move. If either side assumes the other is “handling it,” the organisation ends up with a gap between detection and decision.
Accountability also has to follow the approval chain. If a manager can override a payment control, that manager owns the risk of the override, even when finance executes the transfer. If a mailbox is compromised and a fraudulent instruction is accepted, the control owner for identity or email protection shares accountability for the failed precondition. The practical rule is simple: the team that can prevent the loss at the last safe point should be named accountable for that point.
What good ownership looks like for fraud loss reduction
Good ownership starts with explicit handoffs. Security should own suspicious-login review, mailbox compromise signals, and impersonation detection. Finance should own payment verification, call-back procedures, beneficiary-change checks, and dual approval for high-risk disbursements. Business operations should own who can approve, what counts as an exception, and when a request must be escalated rather than accelerated.
The ownership model is stronger when the control evidence is also owned. A team should be able to show who approved the payment, how the payee change was verified, what alert or challenge occurred, and who accepted the exception. Without that evidence trail, accountability becomes a post-incident debate instead of an operating discipline.
For larger organisations, the right model is usually shared accountability with one named control owner per step. That keeps security from being blamed for money movement decisions it does not control, while also preventing finance from treating fraud as a pure technical issue. The useful outcome is not a single owner for the entire fraud problem, but clear ownership for each control that can stop the loss.
Risk and Threat Considerations
BEC and investment fraud succeed when impersonation, urgency, and approval shortcuts line up. The risk is not just financial loss, it is also the breakdown of trust in payment and instruction workflows, especially when staff believe a request is “verified enough” because it arrived through a familiar channel.
Failure mechanism: Attackers exploit mailbox compromise, spoofed instructions, or social engineering to reach the approval step, then rely on weak segregation of duties, rushed overrides, or poor beneficiary verification to push value out before challenge or reversal.
Impact: The organisation can lose funds, miss the chance to stop fraudulent transfers, and inherit longer-term control weakness because the same workflow may be reused for future abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | BEC loss reduction depends on proving user identity before approvals or payment actions. |
| IA-9 — Service Identification and Authentication | Payment and email controls often rely on non-human systems that must authenticate reliably. | |
| AC-5 — Separation of Duties | Fraud losses fall when approval, release, and reconciliation duties are split across teams. | |
| Recommendation — Enforce strong user authentication before approving payments or changing beneficiaries. Authenticate service-to-service payment and email controls before trusting automated actions. Separate approval, release, and reconciliation duties for high-risk transactions. | ||
Practitioner Guidance
What to prioritise: Assign a named owner for each fraud-prevention control point, not just for the incident response process. The accountable owner should be the team that can stop the transaction before settlement, which is often finance for payments and business operations for approvals.
What to verify: Check whether every high-risk payment, payee change, or investment instruction has a documented verifier, a challenge step, and a clear exception rule. If staff can bypass any of those steps without traceable approval, the ownership model is incomplete.
Practitioner takeaway: Reduce fraud losses by mapping accountability to the last meaningful control, then making security, finance, and business leaders answerable for the parts of the workflow they can actually stop.
Related resources from NHI Mgmt Group
- How should security teams prioritise controls when phishing, BEC, and investment fraud are driving the largest cyber losses?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities at scale?
- How should security teams govern non-human identities for compliance?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org