What are the signs that an open banking authentication approach is too rigid for real users?

A rigid authentication approach usually shows up as higher abandonment, slower completion times, and more customer frustration during consent or payment steps. If the process feels safer but causes users to disengage, the implementation is overcorrecting toward control at the expense of usability. The better signal is whether security is reducing fraud without breaking the expected customer journey.

How to tell when authentication is too rigid for real users

Rigid authentication tends to reveal itself in the journey, not just in the policy. If users hesitate at consent prompts, abandon flows more often, or need repeated retries to finish a payment or account-linking step, the control is probably asking for more friction than the risk justifies. The key question is whether the control is still proportionate to the action being protected.

A better way to judge rigidity is to compare the security intent with the actual user path. Financial Services Identity Security Guide is useful here because banking and payments controls have to balance strong customer authentication with customer completion, especially where consent or payment approval is time-sensitive. If the control interrupts the task so often that users stop trusting the flow, it is no longer behaving like a control, it is behaving like a barrier.

Look for signals that the authentication step is dominating the experience rather than protecting it. Common signs include users switching channels, asking support to bypass the process, saving incomplete applications, or treating the step as something to rush through rather than understand. Those are practical indicators that the design is out of step with expected behaviour for low-risk actions, familiar devices, or repeat customers.

Where open banking friction becomes a control problem

In open banking, friction is not automatically bad, but it has to match the risk of the transaction, data access, or payment authority involved. If the same verification burden is applied to every action, regardless of value, device confidence, or customer familiarity, the approach starts to look rigid. Modern authentication patterns should support step-up where needed, not force the highest-friction path everywhere.

That is why the strongest designs distinguish between a difficult login and a difficult outcome. Workforce Identity Security Guide and Passwordless and Passkeys Guide both reflect a practical lesson that applies to open banking too: stronger authentication should reduce fraud without making normal access feel punishing. When users can complete secure sign-in quickly, the control is more likely to be adopted and less likely to be bypassed or resented.

Another sign of rigidity is when the process fails to recognise context. A returning user on a trusted device should not face the same interruption as an unfamiliar device, risky geolocation, or first-time consent event. If the system cannot vary the challenge based on risk, it will either overburden low-risk users or underprotect high-risk situations.

What practitioners should watch for in the data and in the help desk

Operational evidence often shows rigidity before policy reviews do. If support tickets rise around consent failures, if conversion drops after an authentication change, or if authentication time increases without a corresponding fraud reduction, the control is probably too blunt. NIST SP 800-63 Digital Identity Guidelines is relevant because it frames assurance as a balance between authenticator strength, usability, and the level of confidence needed for the transaction.

The same logic applies to implementation choices. A rigid approach often uses one fixed method for every customer, every device, and every step, even when the business process only needs stronger proof at a narrow point. That can lead to avoidable drop-off, weaker recovery behaviour, or risky workarounds such as repeated retries, shared devices, or support-assisted shortcuts.

Another useful check is whether the authentication design creates new failures during recovery. If users can get in only when everything goes perfectly, but cannot recover quickly when a device is replaced, a session expires, or a step-up challenge fails, the process is too brittle for real-world use. In banking contexts, brittle recovery is often where frustration becomes abandonment.

Risk and Threat Considerations

Overly rigid authentication can push users into weaker habits, including abandonment, repeated retries, or reliance on support channels that become attractive to social engineers. The security risk is not only lost conversion, it is also the temptation to create exceptions that quietly weaken the control.

Failure mechanism: The authentication design applies the same burden in situations with different risk levels, so users encounter unnecessary friction, support workarounds, or unsafe recovery behaviour instead of completing the intended secure journey.

Impact: Organizations can see lower completion rates, higher support demand, and more pressure to introduce bypasses or exception handling that erode the original security intent.

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, NIST CSF 2.0 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	Open banking auth hinges on assurance, step-up, and usability balance.
Recommendation — Align assurance level to transaction risk and reduce unnecessary user friction.
NIST CSF 2.0	PR.AA-05 — Identity Management, Authentication, and Access Control	Open banking auth must enforce access without overburdening legitimate users.
Recommendation — Tune authentication controls to the access context and user journey.
ISO/IEC 27001:2022	A.8.5 — Secure authentication	Rigid auth is a design issue in authentication control selection and operation.
Recommendation — Review authentication methods so they are secure, usable, and proportionate.
OWASP ASVS	V6 — Authentication	The question is about how authentication design affects real-user completion and resistance.
Recommendation — Validate that authentication flows are strong enough without creating avoidable drop-off.

Practitioner Guidance

What to prioritise: Measure the point at which friction starts changing behaviour. Abandonment rate, completion time, retry volume, and support-assisted recovery are more useful than opinions about whether the process “feels secure.”

What to verify: Check that the authentication challenge varies with the risk of the action, not just the fact that an action exists. High-assurance steps belong where value, sensitivity, or anomaly actually increases.

Common mistake: Treating maximum friction as maximum security. In open banking, the better control is the one users can complete consistently while still preventing fraud.

Practitioner takeaway: If security improves on paper but real users stall, abandon, or ask for help to get past the flow, the control is too rigid and needs risk-based adjustment, not more friction.