How should financial institutions implement strong customer authentication for open banking without creating avoidable user friction?

Why This Matters for Security Teams

Open banking authentication is not just a login problem. It is the control point where banks, payment initiators, and third-party providers have to prove that the person approving access and the device or session used to approve it are trustworthy enough for the requested action. If the flow is too strict, users abandon it or seek workarounds. If it is too weak, the bank creates an easy path for account takeover, consent abuse, and fraudulent payment initiation.

Current guidance suggests that strong customer authentication should combine possession, knowledge, and inherence in a way that is tied to the actual transaction rather than treated as a generic sign-in step. That is why standards such as NIST SP 800-63 Digital Identity Guidelines and control frameworks like NIST SP 800-53 Rev 5 Security and Privacy Controls matter here: they support authentication strength, session integrity, and risk-based step-up decisions. The practical challenge is that open banking has to be secure without becoming a conversion killer.

In practice, many security teams encounter authentication friction only after abandonment rates rise or fraud losses expose that the default journey was not binding the customer to the transaction.

How It Works in Practice

The best implementation starts with dynamic linking. The authentication event should cryptographically bind the approval to the specific payee, amount, and transaction context so the user can see what is being authorised and the system can verify that the approval cannot be replayed for a different request. That principle is consistent with NIST SP 800-63 Digital Identity Guidelines, which emphasise assurance, binding, and phishing-resistant techniques where possible.

To keep friction low, institutions usually combine a primary login with step-up checks only when risk rises. Examples include unusual device posture, high-value transfers, new beneficiary setup, changed geolocation, or abnormal consent patterns. The higher the risk, the stronger the interaction. For lower-risk actions, the flow should remain lightweight and consistent. A mobile app can serve as the secure execution environment, but only if the approval path is protected against overlay attacks, malware, and session hijacking.

• Use possession-based factors that are device-bound, not reusable across devices.
• Bind consent and payment approval to the exact transaction details.
• Apply step-up authentication only when risk signals justify it.
• Prefer phishing-resistant authenticators over knowledge-only factors.
• Shorten session lifetime after sensitive actions instead of demanding repeated logins.

For implementation depth, NHI Management Group’s Ultimate Guide to Non-Human Identities is useful because the same governance principle applies: access should be bound to identity, context, and lifecycle rather than left as a static permission. That lesson is reinforced by incident reporting such as the Zacks Investment Research breach, where weak identity boundaries can have wide downstream effects. These controls tend to break down in legacy open banking stacks that cannot bind device, session, and transaction context in real time because the authentication layer is separated from the payment execution layer.

Common Variations and Edge Cases

Tighter authentication usually increases user effort, so institutions have to balance fraud reduction against abandonment, accessibility, and regulatory consistency. There is no universal standard for every customer journey, especially when older banking channels, third-party aggregators, and national eID schemes all coexist.

One common edge case is when a bank relies on app-based approval but the customer has a low-trust device or no smartphone. In that case, current guidance suggests offering equivalent high-assurance alternatives rather than silently dropping to weaker flows. Another is recurring consent: users often expect the first consent grant to be strong, but subsequent low-risk access may need less friction if the consent scope remains narrow and the risk score stays low. That is where policy tuning matters more than one-time MFA design.

Financial institutions also need to watch for brittle fallback paths. SMS-based verification may still exist in some environments, but it is increasingly treated as a weaker option, not a preferred control. Best practice is evolving toward phishing-resistant authentication, risk-based step-up, and clear transaction confirmation screens. The broader lesson is that strong customer authentication succeeds when it protects the customer’s intent without making every interaction feel like a suspicious one. The Twitter Source Code Breach shows how compromised identity workflows can amplify damage once trust is lost, even if the initial access path looked routine.

Related resources from NHI Mgmt Group

• How should payment organisations implement strong customer authentication without creating unnecessary checkout friction?
• How should security teams implement stronger authentication without creating more user friction?
• How should security teams implement context-aware authentication without creating too much user friction?
• How should organisations implement two-factor authentication in high-risk digital services without creating unnecessary user friction?