Who is accountable when fraud controls create too much friction?

Accountability usually sits across fraud operations, IAM, product and customer experience leadership because friction is a governance outcome, not just a tuning issue. If controls are causing avoidable abandonment, the organisation needs ownership for the decision logic, the supporting data and the customer impact. That is why fraud governance must be shared.

Why This Matters for Security Teams

When fraud controls create too much friction, the issue is no longer only detection performance. It becomes a governance and accountability problem that affects conversion, customer trust, and the consistency of risk decisions. Security and fraud leaders need to know who owns thresholds, exceptions, step-up challenges, and complaint handling, because those choices shape both loss rates and legitimate user experience. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that control operation, monitoring, and oversight must be assigned, not implied.

The most common mistake is treating friction as a narrow tuning problem inside a fraud engine. In practice, the bad outcome usually comes from weak ownership across policy, product design, identity verification, and customer support. If no one is responsible for the full decision path, teams optimise one metric while damaging another. That is especially true when fraud controls depend on identity signals, device reputation, or step-up authentication that can also block valid users.

In practice, many security teams encounter this only after abandonment, complaints, or manual review backlogs have already exposed the gap in ownership.

How It Works in Practice

Accountability should follow the decision lifecycle, not just the tool that enforces it. Fraud operations typically define the risk logic, but IAM may own authentication steps, product teams may own user journeys, and customer experience or operations may own remediation and escalation. Clear accountability means each group knows which part of the control chain it owns, what evidence it must retain, and how it will measure harm versus protection.

A practical model is to define a decision register for the main friction points. That register should record the control objective, the trigger, the expected user impact, the fallback path, and the approver for overrides. For higher-risk journeys, such as payments, account recovery, or payout changes, teams should also define who can suspend a rule, who can approve an exception, and who reviews false positives. This is where governance becomes operational rather than theoretical.

Best practice is to connect control ownership with monitoring. For example, if step-up authentication is generating too many abandons, the owning team should review event logs, complaint data, and conversion metrics together. If identity verification is used, the risk team should also confirm that verification outcomes are explainable and that support teams can see why a user was challenged. That helps prevent hidden policy drift and improves auditability.

• Assign a named owner for each friction point, including thresholds and exceptions.
• Track false positives, abandonment, and manual review rates alongside fraud loss.
• Document escalation paths for customer complaints and urgent control changes.
• Review whether IAM, fraud, and product teams are using the same risk signals consistently.

Where identity assurance is involved, teams should also consider the relationship between fraud controls and identity governance. NIST SP 800-63 Digital Identity Guidelines is useful here because it helps distinguish assurance, authentication, and recovery decisions that often get blended together in friction-heavy journeys. These controls tend to break down in high-volume consumer environments with rapid product releases because ownership changes faster than policy, telemetry, and support processes can be updated.

Common Variations and Edge Cases

Tighter fraud control often increases operational overhead, requiring organisations to balance loss reduction against abandonment, support load, and customer trust. There is no universal standard for exactly how much friction is acceptable, so governance needs to reflect product risk, regulatory exposure, and customer profile rather than a single enterprise-wide threshold.

In high-risk financial flows, a stricter control may be justified if it is paired with fast escalation and clear recovery steps. In low-risk consumer journeys, the same control may create unnecessary drop-off. Current guidance suggests that the accountable owner should be the business function that can change the policy, fund the control, and accept the residual risk. That may be fraud, IAM, product, or a shared governance committee, but it should never be ambiguous.

There is also an important edge case when fraud controls are outsourced or embedded in a platform. The vendor may operate the system, but accountability for the customer experience and risk outcome remains internal. If the organisation cannot explain why a legitimate user was blocked, support and compliance teams will absorb the consequence even if the control was technically working as designed. CISA Identity and Access Management guidance is helpful for framing how access decisions, assurance, and operational governance need to stay aligned.

For organisations subject to financial resilience requirements, friction-heavy controls should also be reviewed against resilience and customer outcome obligations. DORA overview is relevant where control instability or poor escalation creates operational risk. The practical rule is simple: if a fraud control changes user behaviour, then the accountable owner must also own the business impact.

Related resources from NHI Mgmt Group

• What breaks when access controls create too much friction?
• How should fintech teams embed fraud controls without creating too much customer friction?
• What breaks when identity controls create too much friction for teams?
• Why do identity controls fail when they create too much friction?