What are the signs that a banking authentication journey is becoming too friction-heavy?

Why Banking Authentication Feels Heavy Before It Becomes a Problem

A banking authentication journey becomes too friction-heavy when customers start hitting repeated prompts, unnecessary re-verification, or inconsistent step-ups for actions they expect to complete quickly. The practical warning is not just inconvenience. It is the point where security controls begin to interfere with core banking tasks such as checking balances, moving money, or approving payments, and the friction starts shaping customer behaviour rather than protecting it.

This matters because authentication is supposed to be risk-sensitive, not transactionally punitive. If every login, device change, or payment request is treated as high-risk, the bank can end up creating avoidable abandonment, call-centre load, and customer workarounds. The issue is often not that controls are absent, but that they are not tuned to the real risk of the action being performed.

For governance context, NIST’s control catalogue is useful when a journey needs to be tied back to authentication, session, and access control decisions, while current banking practice also needs to balance customer experience against stronger fraud detection. In practice, teams usually notice the problem only after users have already adapted by slowing down, switching channels, or giving up on the flow entirely.

How Friction Shows Up in the Journey

The strongest signal is mismatch: low-risk actions start feeling like high-risk events. That often happens when rules are written around control coverage rather than user context, so the same step-up logic appears across every channel, every device, and every customer segment. A healthy journey distinguishes between routine access and unusual behaviour; a heavy one treats both as equally suspicious.

Common friction patterns include repeated MFA prompts in the same session, forced re-entry of credentials after short idle periods, SMS fallback that slows down legitimate users, and step-up checks that are triggered by small, predictable changes such as switching from app to browser. When that happens, customers do not necessarily see “security.” They see a system that is unreliable or overly cautious.

• Logins that succeed technically but still create complaints or support contacts.
• Session timeouts that are shorter than the time needed to complete common tasks.
• Authentication prompts that increase on trusted devices without a clear risk reason.
• Step-up requests that interrupt everyday transactions more often than exceptional ones.

A useful design principle is to align friction with material risk, not with organisational anxiety. If the bank cannot explain why a prompt appeared, customers usually cannot justify why they should tolerate it. That is why clear risk-based policies, device trust signals, and transaction context matter more than simply adding another verification layer. The NIST guidance on security controls is helpful here, and frameworks such as ISO/IEC 27001 emphasise that control design should be systematic rather than ad hoc. The best journeys make high-risk events visible without turning ordinary banking into a checkpoint maze.

These controls tend to break down in legacy environments where channel logic, fraud tooling, and customer identity rules are maintained separately, because the journey accumulates prompts that no single team owns.

Where the Friction Threshold Gets Misread

Tighter authentication often improves visibility, but it also raises the cost of ordinary customer actions, so banks have to balance fraud resistance against operational drag. The hard part is that “more secure” is not always “safer” if the result is abandoned sessions, channel switching, or customers moving low-value activity to a less controlled path.

One common mistake is treating every increase in challenge rate as evidence of stronger protection. In reality, a challenge spike may simply mean the risk engine is over-triggering, device trust is too brittle, or the fallback path is failing. Another edge case is high-value banking: some friction is justified there, but it should be concentrated where the consequence is material, not spread uniformly across every action.

When leaders review the journey, they should look for whether friction is targeted, explainable, and proportionate. If the same user can be challenged repeatedly within minutes for the same device and same context, the bank is probably optimising for control reassurance rather than authentic risk reduction. Standards-based control mapping can help, but the operational test is simpler: do legitimate customers complete routine banking without feeling punished?

For deeper reading on the control backdrop, NIST SP 800-53 Rev 5 Security and Privacy Controls is the most direct external reference from the supplied sources, and the NHIMG guide on Ultimate Guide to NHIs is useful for understanding how identity control sprawl often creates unnecessary friction across authentication workflows.

Risk and Threat Considerations

Friction-heavy authentication is not only a usability problem. It can create security exposure when customers begin bypassing intended controls, reusing weaker channels, or escalating to support in ways that weaken assurance. In banking, the risk is often that excessive challenge design pushes legitimate activity toward behaviours that are easier to spoof, easier to socially engineer, or harder to monitor consistently.

Failure mechanism: When authentication is over-applied, users may migrate to fallback paths, accept unsafe convenience workarounds, or become desensitised to prompts. That reduces the value of step-up controls because the system is no longer distinguishing genuine risk from routine activity, and attackers can benefit from the confusion created by inconsistent verification patterns.

Impact: The bank can end up with higher abandonment, more service demand, weaker trust in prompts, and a control environment that is easier to socially engineer because customers no longer view authentication requests as meaningful signals.

Practitioner Guidance

What to prioritise: Start by separating high-friction moments into “necessary step-up” and “avoidable journey defect.” If customers are struggling at routine tasks, fix the journey logic before adding more authentication factors.

What to verify: Check whether prompts are driven by actual transaction risk, device reputation, or anomaly signals, rather than by broad rules that fire on every minor context change. If the bank cannot justify the challenge in one sentence, the rule is probably too blunt.

What good looks like: Routine access should feel almost invisible on trusted contexts, while genuinely sensitive actions still trigger clear, explainable friction. Good control design leaves customers with confidence, not suspicion.

Practitioner takeaway: The real test is not whether authentication is stricter, but whether it is strict only where the risk justifies the interruption.

Related resources from NHI Mgmt Group

• What are the signs that an MCP deployment is becoming too permissive?
• What are the signs that DORA compliance is becoming unsustainable under manual processes?
• What are the signs that AML and CFT onboarding controls are too weak?
• What are the signs that a legacy identity management platform is becoming hard to govern?