Strong customer authentication can create friction because every additional challenge adds time, confusion, or abandonment risk to the payment or sharing flow. In open banking, the challenge is not whether authentication is needed, but how to apply it in a way that preserves trust without degrading conversion. Teams should treat usability as part of the control design, not an afterthought.
Why SCA Can Feel Frictional in Open Banking
strong customer authentication is not just a compliance checkbox in open banking, it is part of the customer journey. Every step-up prompt creates a pause, and the pause can become abandonment if the customer does not understand why it is happening, cannot complete it quickly, or is forced through repeated challenges across the same session. Good design therefore treats trust, latency, and continuity as part of the control, not as separate usability issues.
That is why the same control can feel smooth in one flow and clumsy in another. A well-timed challenge on a higher-risk payment may be barely noticeable, while an extra prompt during consent, account linking, or frequent re-authentication can interrupt the user at the exact point where conversion matters most. The security objective remains the same, but the operational cost is borne by the customer experience.
In practice, friction often comes from poor calibration rather than from authentication itself. If challenge rules are too broad, customers see unnecessary prompts; if they are too weak, the organisation drifts into a compliance-only posture that ignores the actual attack surface. The design problem is to match the challenge level to the risk, session state, and transaction context without making legitimate users feel punished for completing a payment or sharing data.
What PSD2 Compliance Changes About the Authentication Design
PSD2 pushes teams to prove that the authentication is strong enough for the payment context, while open banking pushes them to keep the experience usable enough that people will actually complete the journey. Those goals are not in conflict, but they do force a more disciplined design. The practical question becomes whether the implementation supports step-up only where it adds security value, rather than turning every interaction into a full re-authentication event.
The strongest implementations usually reduce friction by reusing authenticated context sensibly, keeping sessions bounded, and limiting repeat prompts when the customer has already proven control of the account. They also separate low-risk and high-risk events so that not every action inherits the same burden. For payment providers and account information services, this is where policy, UX, and identity controls need to be designed together.
For teams that need a deeper control baseline, the Financial Services Identity Security Guide covers how PSD2, SCA, and broader financial identity obligations intersect with privileged access, third parties, and payment risk. When the concern is customer-facing authentication specifically, the Customer IAM guide is the more direct lens because it focuses on customer authentication, consent, recovery, and step-up patterns.
Where Friction Becomes a Security Problem
Friction is not only a conversion issue, it can become a control problem when users respond by abandoning the flow, reusing weak habits, or routing around the intended journey. If a process feels too heavy, people are more likely to tolerate insecure workarounds, retry loops, or repeated recovery steps that create a larger attack surface than the original authentication challenge. That is especially relevant in open banking, where the goal is to preserve trust at the edge of the transaction, not just at login.
NIST SP 800-63 Digital Identity Guidelines is useful here because it frames assurance, authenticator strength, and phishing resistance as design choices rather than a single binary rule. In practice, that means teams should be asking whether the user experience supports the assurance level they need, or whether the control is so awkward that it becomes operationally fragile. If the flow is hard to complete, the weakest part of the system may be the user’s path through it.
The same pattern shows up when organizations let repeated challenges accumulate across channels or sessions. Once users experience a pattern of unnecessary prompts, support calls rise, abandonment increases, and attackers gain more opportunities to exploit recovery, social engineering, or token theft around the edges of the intended control. In other words, poor usability can indirectly increase attack pressure on the very control it was meant to strengthen.
Risk and Threat Considerations
Excessive or poorly timed authentication friction can drive customers toward unsafe behaviours, including repeated retries, password reuse, recovery abuse, or acceptance of prompts they no longer scrutinise. It can also create operational pressure to weaken the control later, which is a common path from compliance intent to degraded security.
Failure mechanism: The authentication journey becomes so intrusive or repetitive that legitimate users either abandon it or the business relaxes the control to protect conversion, reducing the practical value of SCA.
Impact: Attackers benefit from confused users, overused recovery paths, and lower-quality authentication decisions, while the business absorbs lower completion rates, higher support load, and weaker trust in the channel.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 sets the technical controls, while ISO/IEC 27001:2022 and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | SCA and customer authentication hinge on assurance, authenticators, and step-up design. |
| Recommendation — Apply assurance-level design to balance phishing resistance, step-up, and user completion. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Open banking SCA is an access control decision about when and how users are challenged. |
| A.8.5 — Secure authentication | The topic centers on strong authentication methods and their operational friction. | |
| Recommendation — Define access rules that challenge only when the transaction context justifies it. Use secure authentication methods that preserve assurance without unnecessary user friction. | ||
| PCI DSS v4.0 | 8.4 — Identification and Authentication for Access to System Components | Payment authentication friction maps to strong authentication expectations in payment flows. |
| Recommendation — Enforce strong authentication while minimizing unnecessary repeated challenges. | ||
Practitioner Guidance
What to prioritise: Design SCA around the transaction risk, not around a generic “always challenge” rule. The best first move is to identify which steps truly need step-up and which can safely reuse authenticated state.
What to verify: Confirm that the customer can understand why a challenge is being requested, complete it quickly on the intended device, and finish the journey without being pushed into recovery or support. If that is not true, the control is probably too costly for the flow.
Decision rule: If an authentication prompt does not materially reduce fraud or account abuse at that point in the journey, simplify it. If it does reduce risk, keep it, but tighten the sequence so the customer only sees it when the context justifies the interruption.
Practitioner takeaway: SCA works best when teams treat usability as part of assurance design, because a control that is technically strong but operationally brittle will eventually be bypassed in practice.
Related resources from NHI Mgmt Group
- How should financial institutions implement strong customer authentication for open banking without creating avoidable user friction?
- Why do open banking programmes need both consent management and strong customer authentication?
- What is the difference between strong customer authentication and basic login in open banking?
- How should organisations implement strong customer authentication for PSD2?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
