Who is accountable when a BEC attempt turns into a fraudulent transfer?

Accountability usually spans finance, security, and the business owner of the process. The practical test is whether the organisation defined verification steps, trained users on exceptions, and enforced a clear stop point before money or access could be moved on trust alone.

Why This Matters for Security Teams

A fraudulent transfer rarely starts as a payments problem. It usually begins as a trust failure in identity, approvals, and exception handling. When business email compromise moves from message spoofing to money movement, the question is not only who clicked or approved, but who owned the control design, who monitored the transaction path, and who had authority to stop it. That makes accountability a cross-functional issue, not a single-team blame exercise.

Current guidance suggests that organisations should treat transfer controls as part of cyber risk governance, especially where email, finance workflow, and privileged access intersect. The control gap is often larger than leaders expect: in the Ultimate Guide to NHIs, NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which is relevant because attacker-controlled accounts and automation can accelerate fraudulent movement once trust is lost. Alignment with NIST Cybersecurity Framework 2.0 helps frame the issue as governance, protection, detection, and response rather than a narrow fraud event.

In practice, many security teams encounter the accountability question only after treasury has already released funds and investigators are reconstructing who was supposed to verify what.

How It Works in Practice

Accountability should be assigned to the process owner, not just the person who executed the transfer. In a mature control model, finance owns the payment workflow, security owns identity and detection controls, and the business owner approves the business justification for exceptions. That split matters because BEC attacks exploit gaps between systems, not just gaps in staff awareness.

Practically, the organisation needs a defined chain of responsibility for each transfer stage:

• Request validation: confirm the requester, account history, and business reason.
• Out-of-band verification: use a second channel for any change in payee, bank detail, or urgency claim.
• Approval control: require separation of duties so the same person cannot request and release funds.
• Exception handling: document who can override the rule, under what conditions, and how overrides are reviewed.
• Post-event response: preserve logs, freeze related accounts, and notify banks quickly if a transfer is suspected to be fraudulent.

This is where NHI governance matters even in a human-fraud scenario. Attackers often pivot through shared mailboxes, service accounts, automation tokens, or workflow integrations, so the organisation must know which identities can initiate or approve actions. The Ultimate Guide to NHIs is useful here because it ties identity inventory, privilege reduction, and lifecycle control to practical containment. For the broader response model, NIST Cybersecurity Framework 2.0 supports mapping these controls to roles, monitoring, and incident response objectives.

These controls tend to break down when payment approvals depend on informal email threads, ad hoc executive exceptions, or shared inboxes because there is no enforceable stop point before release.

Common Variations and Edge Cases

Tighter transfer controls often increase operational friction, so organisations must balance speed against the cost of a delayed legitimate payment. That tradeoff becomes most visible in urgent acquisitions, payroll exceptions, and supplier onboarding, where business pressure can erode the normal verification path.

There is no universal standard for accountability in every BEC-to-fraud case, but current guidance suggests three recurring patterns. First, if the attacker used compromised credentials or a malicious inbox rule, security may own the root-cause investigation while finance owns the failed control execution. Second, if a manager bypassed a required callback or approval step, the business unit may bear process accountability even if security tooling was sound. Third, if no formal verification process existed, executive accountability may extend to whoever approved the control design and risk acceptance.

Two common exceptions deserve attention. One is third-party payment platforms, where accountability can be shared with a vendor but cannot be outsourced entirely. The other is automation-driven transfers, where an NHI or workflow token initiates the action. In those cases, the organisation should treat the token or service account as an identity subject to governance, not as a neutral technical detail. For deeper identity lifecycle context, the Ultimate Guide to NHIs reinforces why privilege and revocation discipline matter even when the initiating actor is not human.

Related resources from NHI Mgmt Group

• Who is accountable when identity governance is delivered through a managed service?
• Who is accountable when an employee leaks a secret into an AI prompt?
• Who is accountable when a fake company tenant is used to solicit employee activity?
• Who is accountable when a third-party education platform breach exposes institutional data?