Basic login confirms a user can enter an account. Strong customer authentication adds higher assurance for sensitive financial actions by combining multiple factors such as biometrics, one-time codes, and device signals. In open banking, that extra layer is used to reduce fraud, strengthen trust, and protect data-sharing flows when access or payment initiation carries higher risk.
Why strong customer authentication is not the same as a basic login
Basic login answers a narrow question: can this person enter the account? strong customer authentication answers a harder one: can this person be trusted for a sensitive banking action, under the current risk conditions, with enough assurance to reduce fraud? That difference matters because open banking often separates ordinary access from payment initiation and data-sharing consent.
In practice, strong customer authentication is not just a “better password” model. It is a higher-assurance check that usually relies on multiple factors or signals, and it is designed to make account access and transaction approval harder to abuse than a standard sign-in flow. That is why the same user may be able to browse an account after a simple login, but still need stronger verification before a bank will approve a payment or shared-data request.
The key practitioner distinction is that basic login establishes session entry, while strong customer authentication is tied to the trust level of the action. For open banking, the control objective is not merely proving familiarity with credentials, but reducing the chance that a stolen password, intercepted session, or social-engineered login can be turned into a high-impact financial action.
How open banking uses the extra assurance layer
Open banking introduces third-party access, consent-driven data flows, and, in some cases, payment initiation. Those are materially different from a normal account portal because the permission may extend beyond viewing information and into actioning value or authorizing data movement. Strong customer authentication is therefore used as a gate around the higher-risk step, not as a blanket replacement for every login event.
That distinction also explains why the user experience changes by context. A low-risk task may involve a lighter authentication path, while a payment or a new data-sharing consent can trigger step-up verification. The practical benefit is that the authentication challenge follows the risk of the action, which helps preserve usability where the risk is lower and add friction only where the consequence of misuse is higher. NIST AI Risk Management Framework is not the right governance lens here, but it illustrates the broader principle that assurance should match consequence. More directly, open banking implementations should be aligned to NIST SP 800-63 Digital Identity Guidelines when evaluating how assurance levels map to risk.
For practitioners, the important point is that strong customer authentication is part of a transaction trust model. It supports authorization decisions, consent integrity, and fraud reduction across the open banking journey, especially where a third party is relying on the bank to authenticate the customer at a meaningful assurance level.
What changes in fraud resistance, trust, and user impact
The operational difference shows up in three places. First, fraud resistance improves because an attacker needs more than a password to complete the protected action. Second, trust increases because banks and third-party providers can rely on a stronger signal that the user present is the intended account holder. Third, the user experience becomes more selective, since higher-assurance prompts are ideally reserved for the moments where the business risk justifies them.
That does not mean strong customer authentication is frictionless. It introduces dependence on the quality of the factors, the reliability of the device or channel, and the bank’s ability to distinguish genuine step-up events from noise. If the flow is poorly designed, users may see repeated prompts, fallback paths may become attractive to attackers, and the authentication process itself can become a source of abandonment or support burden. The control is effective when it reduces risk without becoming so intrusive that users try to route around it.
Practitioner takeaway: treat basic login as an entry check and strong customer authentication as a risk-based approval control. In open banking, the real design question is whether the authentication strength matches the consequence of the action, not whether the user can simply get into the account.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Open banking SCA is fundamentally about assurance levels and authentication strength. |
| Recommendation — Map sensitive banking actions to higher authenticator assurance and prefer phishing-resistant methods where possible. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The answer distinguishes ordinary sign-in from stronger authentication for protected actions. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Open banking involves customer and third-party user access rather than only internal staff. | |
| Recommendation — Enforce stronger authentication for access paths that can trigger sensitive banking actions. Apply stronger proofing and authentication for external users reaching regulated financial functions. | ||
| OWASP ASVS | V6 — Authentication | The topic directly concerns authentication strength, factor use, and step-up verification. |
| Recommendation — Verify that authentication strength increases for high-risk banking actions and consent changes. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Open banking access and payment flows are exposed if authentication is weak or bypassed. |
| Recommendation — Test that API-facing banking flows do not accept weak or replayable authentication. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Open banking needs controlled identity assurance across user and third-party access paths. |
| Recommendation — Define identity assurance requirements for customer and third-party banking access. | ||
Related resources from NHI Mgmt Group
- What is the difference between strong customer authentication and ordinary MFA?
- What is the difference between customer due diligence and strong customer authentication here?
- What is the difference between Strong Customer Authentication and PCI DSS for payment security?
- What is the difference between identity proofing and authentication in customer onboarding and login journeys?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
