How should financial institutions implement Strong Customer Authentication without creating high drop-off rates?

Design SCA as a journey, not a gate

strong customer authentication works best when the institution designs for completion as well as assurance. The practical question is not whether the flow technically satisfies a rule, but whether customers can move through it quickly, on the right channel, with a clear fallback when the first method fails. For customer authentication design patterns that reduce abandonment, the Customer IAM (CIAM) Guide is a useful starting point.

In practice, that means choosing factors that are easy to use under real conditions, such as a passkey, app-based approval, or a device-bound method, rather than defaulting to clumsy steps that create delay at the exact moment a customer is trying to pay or log in. NIST’s guidance on authenticator assurance and phishing-resistant authentication in NIST SP 800-63 Digital Identity Guidelines is a good reference point for balancing assurance and usability.

The most important design principle is channel fit. A bank should not force the same authentication journey on every transaction, every device, and every customer segment if that adds friction without improving real assurance. A well-implemented SCA flow keeps the factor challenge proportionate to risk, so low-risk journeys remain fast while higher-risk events trigger step-up verification only when justified.

What reduces drop-off in mobile and web flows

Drop-off usually comes from avoidable friction, not from authentication itself. Long redirects, poorly timed SMS codes, confusing recovery steps, and repeated prompts across the same session all increase abandonment. Customers are far more likely to complete a flow when the method is familiar, the prompt is immediate, and the handoff between banking app, browser, and device feels consistent.

Mobile flows often benefit from push, passkey, or in-app approval because they reduce typing and context switching, while web flows need robust browser support and a clean recovery path if the primary device is unavailable. The most effective programs test both journeys under realistic conditions, including weak connectivity, older devices, and interrupted sessions, because friction often shows up only outside the lab.

Financial institutions should also treat fallback and recovery as part of the main design. If the backup path is materially harder than the primary path, customers will fail at the exact moment they need help. That is why mature identity programmes, such as NHIMG’s Passwordless and Passkeys Guide and MFA Guide, place as much emphasis on recovery and method choice as on the challenge itself.

Make resilience and channel independence part of the control

SCA fails when the control is tied too tightly to one device, one app, or one delivery channel. Institutions should expect customers to lose access to a phone, change devices, or encounter temporary service disruption, and they should build authentication that still works without weakening assurance. This is where multi-channel design matters: the institution needs a secure alternative path, not a duplicate of the same brittle one.

Channel independence also matters for security. A flow that depends on a single SMS code or a single push approval can be disrupted by SIM swap, notification fatigue, or device compromise. That is why higher-assurance implementations increasingly favour phishing-resistant methods and stronger recovery discipline, especially for high-value accounts or high-risk transactions.

For that reason, banks should test not just whether customers can authenticate, but whether they can do so after device loss, number change, browser failure, or account recovery events. The control should remain usable when the primary path is unavailable, otherwise the institution ends up trading one kind of risk for another.

Risk and Threat Considerations

The main risk is that an SCA design that looks compliant on paper creates abandonment in practice, pushing customers toward unsupported workarounds, repeated retries, or support-assisted recovery. A second risk is that weak fallback logic becomes the easiest attack path, because adversaries often target recovery, fatigue, or delivery-channel weaknesses rather than the primary factor challenge.

Failure mechanism: Friction accumulates when the authentication step is slow, inconsistent, or poorly matched to the channel, while attackers exploit recovery paths, notification prompts, or weaker backup methods to bypass stronger controls.

Impact: The institution gets both worse conversion and weaker security, because genuine customers drop out while attackers concentrate on the least resistant part of the journey.

Practitioner Guidance

What to prioritise: Start with the journeys that carry the most value and the most abandonment risk, usually log-in, payment confirmation, and account recovery. If those three are solid, the rest of the SCA programme usually becomes easier to govern.

What to verify: Test the complete path on real mobile devices and desktop browsers, not just the preferred flow. Verify that customers can complete the journey after device change, poor connectivity, session timeout, and a failed first factor.

Decision rule: If a step-up method increases abandonment more than it reduces fraud exposure for a given transaction type, reserve it for higher-risk events and simplify the default path.

Practitioner takeaway: The winning SCA design is the one customers can complete reliably under normal conditions, because security that routinely interrupts completion often drives both user loss and unsafe fallback behaviour.

Related resources from NHI Mgmt Group

• How should financial institutions implement strong customer authentication for open banking without creating avoidable user friction?
• How should payment organisations implement strong customer authentication without creating unnecessary checkout friction?
• How should financial institutions implement PSD2 SCA without creating excessive customer friction?
• How should financial institutions implement open banking APIs without weakening customer authentication and consent controls?