Why does PSD2-style open banking increase the need for stronger identity and authentication controls?

Why PSD2-Style Open Banking Raises the Bar for Identity Assurance

PSD2-style open banking expands the number of parties that can initiate data access and payment flows, so the security model can no longer depend on the bank’s own app, branch, or portal as the only trusted channel. That changes the identity problem from simple login protection to proving who is acting, what they are allowed to do, and whether consent is still valid at the moment of use. It also makes credential reuse, consent replay, and third-party weakness much more consequential. For practitioners, the key issue is that access now depends on stronger verification across multiple trust domains, not just inside one institution.

That is why strong customer authentication is not just a compliance feature. It is the mechanism that makes access decisions harder to impersonate, harder to reuse, and easier to bind to a specific transaction or request. The broader the ecosystem, the more attractive weak identities become to attackers and the more valuable short-lived, step-up, and transaction-aware controls become.

In practice, teams often discover the weakness only after a third-party integration, consent flow, or delegated access path has already been abused.

How Identity and Authentication Change in Practice

Open banking shifts authentication from a single-channel login event to a distributed trust decision. A bank may still authenticate the customer, but it must also assess the third-party provider, the scope of consent, the payment context, and the risk of account takeover or request manipulation. That is a materially different operating model from traditional online banking, where the institution can rely more heavily on its own user interface, session controls, and internal fraud checks.

Strong identity controls matter here because open banking creates more opportunities for an attacker to reuse a stolen credential, intercept a poorly protected consent flow, or exploit a weakly governed third party. Transaction-level authentication reduces that reuse risk by making each high-value action dependent on the current context, not only on a previously established session. This is one reason regulators and implementers treat multifactor and dynamic linking as more than procedural overhead: they are compensating controls for an ecosystem with more actors and more indirect trust.

Practically, the most important design choices are:

• Bind approval to the specific payment or data request instead of granting broad session trust.
• Use step-up authentication when risk increases, rather than assuming one login is sufficient for all actions.
• Keep consent, authentication, and authorization distinct so that a valid consent record does not become a blanket access grant.
• Reduce the value of stolen credentials by limiting reuse windows and relying on short-lived tokens where possible.

Current guidance suggests that the control objective is not simply to make login harder, but to make delegated access verifiable, contextual, and revocable across the full request path. For teams aligning governance and implementation, the strongest reference point is the NIST SP 800-53 Rev 5 Security and Privacy Controls, which helps map identity assurance to access control and session protection expectations. NHIMG’s Ultimate Guide to NHIs is also useful because open banking exposes a similar lifecycle problem: once a credential or token can be reused outside the original trust boundary, the blast radius expands quickly. These controls tend to break down when third-party apps, consent brokers, and account access paths are treated as if they all share the same assurance level.

Common Variations and Edge Cases in PSD2-Style Models

Tighter authentication often increases friction, so organisations have to balance user experience against the risk of account takeover and payment fraud. That tradeoff becomes more visible when a customer uses multiple devices, when a payment journey is fragmented across redirect flows, or when a third-party provider acts on behalf of the customer in ways that are hard to explain in a single login screen.

One common edge case is over-reliance on consent alone. Consent proves permission was given, but it does not prove the current requester is still legitimate, nor does it guarantee the request still matches the original intent. Another is weak third-party assurance: if the app, API client, or credential handling is poor, the bank can authenticate correctly and still lose control of the access path. That is why current guidance increasingly treats identity assurance, consent integrity, and third-party governance as linked but separate problems. The issue is not only whether authentication happened, but whether it happened at the right moment, for the right action, and through a trustworthy intermediary.

For banks and fintechs, the practical edge case is that controls must degrade gracefully without silently falling back to weaker assumptions. If step-up authentication is bypassed for convenience, or if a long-lived token is allowed to stand in for fresh user intent, the model starts to resemble static trust again. The strongest programmes keep the authentication event tightly coupled to the requested action and make exceptions visible, bounded, and reviewable.

Risk and Threat Considerations

Open banking materially increases exposure to account takeover, consent replay, and third-party compromise because it broadens the number of systems and actors that can touch sensitive account and payment flows. The risk is not limited to a weak password; it includes delegated access paths that can be abused even when the bank’s own primary channel remains intact.

Failure mechanism: Attackers typically target stolen credentials, intercepted consent journeys, weak API clients, or overbroad tokens, then reuse that trust to initiate payments or pull account data through a legitimate-looking path. If authentication is not bound tightly to transaction context, the same proof of identity can be replayed across requests.

Impact: The result can be unauthorised transfers, exposure of financial data, fraudulent third-party actions, and loss of confidence in the open banking ecosystem. At scale, weak assurance also makes it harder to distinguish genuine customer activity from delegated abuse.

Practitioner Guidance

What to prioritise: Treat the highest-risk journeys first: payment initiation, account aggregation, and any third-party flow that can move money or expose sensitive account data. Those are the points where weak assurance has the clearest blast radius and where step-up controls should be hardest to bypass.

What to verify: Confirm that consent, authentication, and authorization are independently enforced. A valid consent record should not be accepted as proof that the current request is safe, current, or still aligned to the original user intent.

Decision rule: If a request can be replayed, delegated, or completed by a third party without fresh context, treat the control as too weak for open banking and require stronger binding to the specific transaction or access event.

Practitioner takeaway: The real goal is not merely stronger login assurance, but stronger trust binding across a distributed payment and data-sharing chain, because that is where open banking changes the attack surface most.

Related resources from NHI Mgmt Group

• Why do digital banks need stronger identity controls when they expand Open Banking and API ecosystems?
• Why does authentication complexity increase security risk even when controls are stronger?
• Who is accountable when identity controls fail in open banking ecosystems?
• Why do open banking models increase identity and fraud risk in regulated environments?