Open Banking PSD2 is a regulatory framework that lets customers securely share banking data and initiate payments through authorised third parties. Under PSD2, banks expose standardised APIs, and access depends on strong customer authentication, consent, and tightly controlled identity and authorization mechanisms for people, applications, and delegated services.
What Open Banking PSD2 Actually Introduces
Open Banking PSD2 turns bank data access and payment initiation into a regulated, API-mediated trust relationship. The security challenge is not just API exposure, it is proving who is allowed to access what, under which consent, and with what level of assurance.
That makes PSD2 more than a banking interoperability story. It is a control model for delegated access, where the bank remains responsible for the integrity of authentication, authorization, consent handling, and the boundary between the customer, the third party, and the account.
Why PSD2 Depends on Strong Identity and Authorization
PSD2 works only when the parties involved can be reliably distinguished and constrained. The bank must verify the customer strongly, recognise the authorised third party, and enforce narrow, auditable permissions for each API call or payment action.
In practice, this means access decisions depend on a chain of trust: customer authentication, consent artefacts, application identity, and controlled delegation. If any link is weak, the openness that makes the model useful can also become the route for fraud, misuse, or unauthorised disclosure.
For the regulatory and assurance side of that chain, see the PSD2/PSD3 Strong Customer Authentication Guide.
Open Banking APIs, Consent, and Third-Party Access
PSD2 standardises how banks expose account data and payment initiation capabilities through APIs, which reduces fragmentation but also creates a common attack surface. A secure implementation has to keep consent current, scope access tightly, and make sure the third party can only do what the customer explicitly approved.
That is why API security, authorization design, and lifecycle controls matter so much here. Open banking failures often come from overbroad scopes, poor consent revocation, weak application registration, or failure to bind the right actor to the right action.
For a broader view of the identity and governance implications in banking and payments, the Financial Services Identity Security Guide is the most relevant internal reference.
How Organisations Reduce PSD2 Exposure in Practice
Organisations usually reduce PSD2 exposure by controlling API inventory, limiting what is published to external parties, and verifying that third-party access paths match the intended business use. They also need clear evidence for customer consent, delegated authority, and transaction-level authorization.
Operationally, the most important question is not whether an API exists, but whether it is correctly registered, monitored, and constrained. Good implementation also means reviewing certificate handling, revocation paths, exception handling, and how customer support processes handle disputed or stale consent.
Standards for digital identity help here because PSD2 security depends on strong authentication and trustworthy federation. The external NIST SP 800-63 Digital Identity Guidelines are useful for the assurance side, and the OpenID Connect Core 1.0 specification is relevant where identity assertions and federation are part of the flow.
Failure Modes and Practitioner Focus Areas
PSD2 problems usually emerge when organisations treat openness as a front-end integration issue instead of a regulated trust boundary. Weak consent handling, permissive scopes, brittle exception handling, and insufficient monitoring can all turn a compliant interface into a fraud path.
Common misunderstanding: Open banking does not mean “open access”. Every request still needs the right authentication strength, the right authorization, and a defensible record of why the action was allowed.
Practitioner note: Treat third-party access as a lifecycle, not a one-time onboarding event. The real security test is whether permissions, consent, and trust relationships still hold after accounts, software, and business arrangements change.
Risk and Threat Considerations
PSD2 expands the number of parties that can reach sensitive financial data or payment functions, so the main risk is trust boundary failure. If identity binding, consent validation, or API authorization is weak, attackers and fraudulent intermediaries can abuse otherwise legitimate access paths.
Failure mechanism: Overbroad scopes, weak authentication, stale consent, or poor third-party registration can let an unauthorised party act with the appearance of legitimacy, especially when API monitoring does not detect abnormal request patterns.
Impact: The result can be data exposure, unauthorised payment initiation, account misuse, customer fraud, regulatory breach, and difficult post-incident attribution because the activity may look like approved partner traffic.
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 and risk surface, while NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL/AAL/FAL — Digital Identity Assurance and Federation Levels | PSD2 depends on strong authentication and trusted federation for third-party access. |
| Recommendation — Apply the relevant assurance and federation requirements to validate customer authentication and delegated access trust. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Open banking APIs rely on strong authentication and token handling for sensitive financial access. |
| API1 — Broken Object Level Authorization | PSD2 access must enforce object-level limits on accounts, payments, and data views. | |
| Recommendation — Strengthen API authentication and token handling before exposing bank or payment endpoints. Enforce object-level authorization so third parties can only reach explicitly approved financial resources. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | PSD2 implementations depend on controlled lifecycle handling for authenticators and trust material. |
| AC-3 — Access Enforcement | PSD2 requires policy-driven enforcement of who may access banking data or initiate payments. | |
| Recommendation — Manage authenticators and related trust material across issuance, storage, rotation, and revocation. Enforce access rules at the service boundary so consent and authorization are checked on every request. | ||
Practitioner Guidance
Governance implication: PSD2 should be owned as a cross-functional control surface, not only by API teams. Security, fraud, legal, operations, and customer experience all influence whether consent, authentication, and delegated access remain trustworthy.
What to watch for: Repeated consent resets, unusually broad third-party permissions, exception-heavy onboarding, and weak visibility into who approved what are all signals that the open banking model is drifting away from its intended control design.
Related resources from NHI Mgmt Group
- Why do standard OAuth patterns fall short for open banking and PSD2?
- Why does PSD2-style open banking increase the need for stronger identity and authentication controls?
- Why does customer consent become a strategic risk factor in PSD2 and open banking models?
- How should financial institutions reduce client-side fraud risk under PSD2 and open banking?