Who is accountable when online banking approvals are compromised?

Why This Matters for Security Teams

When online banking approvals are compromised, the issue is rarely a single broken control. It is usually a gap across authentication, transaction approval, fraud detection, and evidence of policy enforcement. That means accountability must be assigned by control owner, not by incident noise. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it separates access control, auditability, and incident response into distinct responsibilities.

Security teams often get this wrong by treating approval compromise as either an IAM-only problem or a fraud-only problem. In practice, a compromised approval can originate from stolen session tokens, weak step-up authentication, social engineering, poor device binding, or an approval workflow that lacks strong transaction binding. If the control chain is not explicit, every team assumes another team owns the gap, and remediation slows down. That creates audit exposure as well as customer loss. In practice, many security teams encounter approval compromise only after disputed transactions have been completed, rather than through intentional detection design.

How It Works in Practice

Accountability should be mapped to the control layer that failed, then escalated through an incident owner who can coordinate across teams. IAM is typically accountable for identity assurance, enrollment, lifecycle governance, step-up authentication, and the integrity of approval entitlements. Fraud is accountable for risk scoring, anomalous transaction detection, confirmation workflows, and manual review when signals do not fit normal customer behavior. Security operations is accountable for detection, correlation, and response when approval channels are abused. Compliance is accountable for demonstrating that the bank can prove control effectiveness, not just claim it.

This is where good control design matters. A bank should be able to answer whether the approval required a strong customer authenticator, whether the approval was bound to the specific transaction, whether device and session risk were assessed, and whether alerts were triggered when approval patterns changed unexpectedly. Where AI-assisted detection is used, current guidance suggests that model decisions should be auditable and subject to human review in high-impact cases. That is especially relevant when approval workflows are influenced by agentic or automated decisioning, because authority to act must remain bounded and reviewable.

• Define separate owners for identity proofing, customer authentication, transaction authorisation, and fraud monitoring.
• Require evidence that each approval is tied to a specific transaction, not just to a logged-in session.
• Log the approval context, including device, risk score, step-up method, and reviewer action.
• Test whether alerts trigger when approval velocity, geography, or device posture changes.

For institutions building stronger detective control, the Anthropic first AI-orchestrated cyber espionage campaign report is a reminder that automated abuse can scale quickly when workflows trust the wrong signal. These controls tend to break down when legacy banking platforms separate authentication from authorisation, because the approval path cannot be fully traced end to end.

Common Variations and Edge Cases

Tighter approval controls often increase customer friction and review overhead, requiring organisations to balance fraud reduction against abandonment and support cost. That tradeoff is real, especially in retail banking, where one-time step-up challenges can disrupt legitimate payments. The right answer is not always maximum friction; best practice is evolving toward risk-based, transaction-specific assurance.

There is no universal standard for this yet, but the pattern is consistent: low-risk approvals may use lighter controls, while high-value or unusual approvals should require stronger authentication, richer telemetry, and explicit evidence retention. In branch-assisted or call-centre-assisted banking, accountability often extends further because the human verifier becomes part of the approval chain. In open banking or third-party initiated payments, the bank may share responsibility with the payment initiator, the identity provider, or the platform operator, depending on the local legal model.

For regulated environments, compliance teams should verify that policy maps cleanly to operational practice, not just to written standards. If transaction approval is compromised through a trusted device, a valid login alone is not enough to prove control failure was resolved. The question is whether the institution can show who approved what, under which conditions, and with what assurance level. That evidence trail is what turns shared accountability into actionable accountability.

Related resources from NHI Mgmt Group

• Who is accountable when a compromised AI agent misuses delegated access?
• Who is accountable when a banking chatbot gives bad advice or exposes data?
• Who is accountable when a compromised identity system disrupts public services?
• Who is accountable when an AI agent triggers a banking error or compliance breach?