PSD2 is a European Union rule set that governs electronic payments and opens bank account access to approved third parties with customer consent. It requires strong customer authentication, secure API access, and tighter controls around payment initiation and account information services to reduce fraud and improve competition.
What PSD2 means for payment security
PSD2 is best understood as a rule set that changes who may connect to bank accounts and under what conditions. For security teams, that means the issue is not only payment compliance, but also consent, third-party access, authentication strength, and the trust boundary around account data and payment initiation.
It matters because PSD2 shifts access from a closed banking interface to an approved, regulated ecosystem. That creates a security obligation to distinguish legitimate third parties from abuse, and to ensure that access is authorized, traceable, and limited to the customer-approved purpose.
Strong customer authentication and secure access
The most visible security requirement under PSD2 is strong customer authentication, which is designed to make account access and payment approval harder to misuse. In practice, this means the authentication flow must resist replay, credential theft, and simple password compromise, especially for high-risk actions.
The broader access model also includes secure interfaces for account information and payment initiation services. The PSD2/PSD3 Strong Customer Authentication Guide is the most direct reference for the detailed rules around SCA, exemptions, and third-party provider access.
Third-party access, APIs, and operational trust
PSD2 is also an API governance problem. Banks and payment providers have to expose account data and payment functionality through controlled interfaces, which makes authentication, request validation, and entitlement checks central to the design. If those controls are weak, the result can be unauthorized account access even when the front-end experience looks compliant.
The operational scope extends beyond the API itself to the surrounding security model, including customer consent, registration of approved third parties, logging, and the ability to prove what was accessed and why. The Financial Services Identity Security Guide is useful here because it ties PSD2 to the wider identity and access controls used in banking and payments.
Why PSD2 changes fraud and control expectations
PSD2 was written to reduce fraud while increasing competition, so it raises the bar for both prevention and accountability. Security teams need to assume that approved access paths will be targeted by credential theft, consent abuse, API abuse, and transaction manipulation, especially where account data and payment authority intersect.
That is why the security conversation around PSD2 should include not just authentication strength, but also access review, interface hardening, audit evidence, and resilience of the controls that sit between the customer, the bank, and the third-party provider. For implementation detail on the access and security expectations that sit around PSD2 in regulated financial environments, the EBA ICT and Security Risk Guidelines Guide is a strong companion reference.
Risk and Threat Considerations
PSD2 creates a concentrated trust boundary: approved third parties can reach sensitive payment and account data, so any weakness in authentication, consent handling, or API controls can turn a compliance feature into an abuse path. The main risk is not abstract regulatory failure, but unauthorized access, fraudulent initiation, or misuse of a legitimate access channel.
Failure mechanism: An attacker can exploit weak customer authentication, stolen credentials, poor API authorization, or manipulated consent flows to impersonate a legitimate user or third party and act through a trusted interface.
Impact: The result can be fraudulent payments, unauthorized account visibility, degraded customer trust, and control failures that are harder to detect because the activity appears to come through an approved PSD2 pathway.
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 | Digital Identity Guidelines | PSD2 relies on strong customer authentication and assurance of user identity. |
| Recommendation — Apply NIST 800-63 assurance and phishing-resistant authentication to strengthen PSD2 login and payment approval flows. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | PSD2 APIs depend on robust authentication for account and payment access. |
| API5 — Broken Function Level Authorization | PSD2 third-party access must be limited to the functions a customer approved. | |
| Recommendation — Harden API authentication to prevent unauthorized access to PSD2 account and payment functions. Enforce function-level authorization so third-party providers can only invoke permitted PSD2 actions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | PSD2 payment access depends on secure management of authenticators and credentials. |
| AC-3 — Access Enforcement | PSD2 requires access decisions to enforce consent and scope at the point of use. | |
| Recommendation — Rotate, protect, and revoke authenticators used in PSD2 customer and third-party access paths. Enforce consent-scoped access rules for PSD2 account information and payment initiation requests. | ||
Practitioner Guidance
Why practitioners should care: PSD2 is not only a legal framework, it is a control-design requirement for payment access. Teams should treat the regulated interface as a high-value trust boundary and validate that authentication, consent, and authorization are aligned end to end.
Common misunderstanding: Passing a compliance review does not automatically mean the access model is secure in practice. If API entitlement, third-party registration, and customer authentication are managed separately, the overall flow can still fail under real attack conditions.
Practitioner takeaway: The strongest PSD2 implementations make it easy to show who accessed what, under whose consent, and through which approved channel, because that evidence is often what separates a controlled open-banking flow from an exposure.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org