Who is accountable when fraud controls and identity controls are split?

Accountability sits with the team that owns the combined customer trust decision, not with whichever function sees the alert first. In mature programmes, IAM, fraud, and digital product teams share control design, but one owner must define policy thresholds, evidence requirements, and escalation paths.

Why This Matters for Security Teams

When fraud controls and identity controls are split, the real risk is not just duplicated tooling. The risk is a broken trust decision: one team may approve access because identity checks pass, while another blocks the same action because the transaction looks fraudulent. That gap creates inconsistent enforcement, slower response, and weak auditability. NIST frames this as a governance problem as much as a technical one in the NIST Cybersecurity Framework 2.0.

For NHI-heavy environments, the problem is amplified because machine identities often outnumber human identities by 25x to 50x, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs. If fraud and identity signals are not joined at the decision point, policy becomes fragmented: security sees privilege, fraud sees behaviour, and product sees conversion. In practice, many security teams encounter the accountability gap only after a disputed payout, account takeover, or blocked legitimate customer journey has already created operational and customer impact.

How It Works in Practice

Accountability should sit with the team that owns the combined customer trust decision, but execution usually spans IAM, fraud, risk, and digital product. The practical model is a shared control plane with a single policy owner. That owner defines when identity assurance is sufficient, when behavioural fraud signals override it, and what evidence is required before step-up checks, blocking, or case escalation. The operational goal is to make the decision consistent at the point of request, not after an incident review.

In mature programmes, this often means aligning identity events and fraud events to the same workflow. Identity systems provide authentication strength, device posture, session integrity, and entitlement data. Fraud systems contribute velocity, anomaly, and transaction context. The decision layer evaluates both in real time and applies policy thresholds that are explicit, measurable, and reviewable. Current guidance suggests this is best handled as policy-as-code with clear ownership, because ad hoc analyst overrides quickly become inconsistent.

Useful control points include:

• One accountable owner for the trust policy, even if multiple teams contribute signals.
• Shared severity definitions for account takeover, synthetic identity, and suspicious session activity.
• Documented escalation paths for false positives, appeal handling, and customer recovery.
• Joint tuning of thresholds so fraud detection does not silently weaken identity assurance.

NHIMG research shows that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, which makes split accountability even more dangerous when privileged service identities can trigger customer-facing workflows. The same discipline should be informed by lessons from the 52 NHI Breaches Analysis and the broader control guidance in the Ultimate Guide to NHIs — Standards. These controls tend to break down when fraud and IAM operate on different case-management systems because no one can prove which threshold governed the final decision.

Common Variations and Edge Cases

Tighter joint governance often increases review overhead, requiring organisations to balance stronger trust decisions against slower operations and higher coordination cost. That tradeoff is especially visible in high-volume consumer flows, where too many manual handoffs can hurt conversion or create abandonment.

There is no universal standard for this yet, but current guidance suggests three common patterns. First, some organisations place accountability with IAM for access-related decisions and with fraud for transaction-related decisions. Second, others create a trust or risk function that owns both. Third, some use a federated model where IAM and fraud each own a domain but a single executive resolves policy conflicts. The federated model can work, but only if decision rights are explicit.

Edge cases matter. Shared accounts, delegated access, service-to-service workflows, and API-driven checkout flows often blur the boundary between identity and fraud. In those environments, a customer may look legitimate while the underlying session or credential is compromised, or a legitimate identity may trigger a fraud block because the device or transaction pattern is unusual. The best practice is evolving toward unified policy evaluation rather than separate approvals, especially where there is material financial exposure or regulatory review. For teams mapping the problem to broader governance, the Top 10 NHI Issues is a useful reminder that fragmented ownership usually becomes a lifecycle problem as much as a detection problem.

Related resources from NHI Mgmt Group

• Who is accountable when identity security controls fail across IAM, PAM, and NHI programmes?
• Who should be accountable for modernising identity controls in critical industries?
• Who should be accountable for workforce identity verification controls?
• Who is accountable when AI-driven fraud bypasses identity controls?