Join our Newsletter — 33% off our NHI Course

PSD3

PSD3 is the European Union’s proposed third Payment Services Directive, intended to update payment security, competition and fraud controls beyond PSD2. Its exact requirements depend on final legislation and implementation, so organisations should track changes to authentication, open banking access and liability rules rather than assume current PSD2 controls will remain sufficient.

PSD3 in the payments security stack

PSD3 matters because it is meant to reshape how payment providers handle authentication, access to open banking interfaces and fraud liability. It is best understood as a legislative update to the security and trust model around payments, not just a compliance refresh.

For organisations, the practical question is how the proposed directive may alter security expectations that were built around PSD2. That includes stronger customer authentication journeys, third-party access governance, transaction integrity and the division of responsibility when fraud occurs.

What PSD3 changes conceptually

PSD3 sits in the regulatory layer above implementation detail. It signals that the EU expects payment security controls to evolve as fraud techniques, API ecosystems and account-to-account payments mature. The core issue is not a single control, but the relationship between authentication, access and liability in a more connected payment environment.

That makes PSD3 especially relevant to banks, payment institutions, fintechs and open banking participants. If the final text tightens expectations, existing PSD2-era assumptions about strong customer authentication or interface governance may no longer be enough.

Where organisations need a broader control baseline for authentication, auditability and access management, NIST SP 800-53 Rev 5 Security and Privacy Controls remains a useful reference point for building those mechanics into policy and operations.

How PSD3 affects payment and open banking architecture

The proposal is important because payment security does not live only in the checkout flow. It reaches into APIs, consent handling, delegated access and the systems that decide whether a transaction should be trusted. In practice, PSD3 pushes organisations to think about payments as an identity and authorization problem as much as a financial one.

This is also why open banking implementations need careful review. When access is granted through APIs or delegated user journeys, weak authentication, poor entitlement handling or brittle fraud checks can create exposure that is difficult to unwind later. For teams already aligning payment APIs to a security baseline, the OWASP API Security Top 10 is a useful companion for understanding common failure modes such as broken authorisation and insecure API exposure.

Organisations that operate across multiple payment rails should also track how PSD3 interacts with other resilience and access obligations, especially where third parties, service providers or platform dependencies are part of the payment path. The direction of travel is toward tighter evidence that the right actor, the right session and the right transaction are being approved.

Preparing for change before final text lands

PSD3 should be treated as a moving target until the legislation is final and implementation guidance settles. The safest posture is to map current controls to the likely regulatory themes, then identify where authentication, fraud monitoring, third-party access and liability handling depend on assumptions inherited from PSD2.

That review should include open banking interfaces, consent records, customer authentication paths, dispute workflows and fraud escalation logic. It is also sensible to watch vendor and regulator guidance closely, because implementation obligations may differ from the high-level policy language in the directive itself.

For organisations handling payment credentials, session material or cryptographic trust dependencies, NIST SP 800-57 Key Management can help frame where key lifecycle controls may become relevant to supporting security design.

Risk and Threat Considerations

PSD3 is associated with material exposure because payment controls are only as strong as the weakest authentication, API and fraud-control path. If organisations assume PSD2-era measures will remain sufficient, they may understate both regulatory drift and the attack surface created by more interconnected payment ecosystems.

Failure mechanism: Fraudsters and other attackers exploit weak authentication, API abuse, session compromise or inconsistent liability handling to move money, impersonate users or bypass controls in payment journeys.

Impact: The result can be unauthorized transfers, failed fraud recovery, customer harm, operational remediation cost and regulatory non-compliance when the implemented control set no longer matches the final directive.

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-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST SP 800-53 Rev 5 IA-2 — Identification and Authentication (Organizational Users) PSD3 may tighten expectations for customer and staff authentication around payment security.
AC-2 — Account Management PSD3 affects delegated access, consent and account access governance in payment ecosystems.
Recommendation — Strengthen authenticated payment and admin flows with verifiable identity checks and session controls. Review who can access payment capabilities and revoke stale or excessive access promptly.
OWASP API Security Top 10 API2 — Broken Authentication PSD3 affects open banking and payment API trust, where authentication failures create direct exposure.
Recommendation — Harden payment and open-banking APIs against weak or bypassed authentication.
OWASP ASVS V10 — OAuth and OIDC PSD3 intersects with open banking flows that depend on delegated authorization and federation.
Recommendation — Verify delegated payment journeys use strong, well-validated OAuth and OIDC patterns.
CIS Controls v8 CIS-6 — Access Control Management PSD3 raises the importance of controlling access paths that influence payment execution and fraud exposure.
Recommendation — Restrict and review access to payment systems, APIs and fraud-sensitive workflows.

Practitioner Guidance

Governance implication: Treat PSD3 readiness as a cross-functional ownership problem spanning payments, security, fraud, legal and product teams. The important judgement is not whether a control exists, but whether it still satisfies the final regulatory intent once the directive is settled.

Practitioner takeaway: Build a traceable view from each payment control to the PSD3 theme it is meant to satisfy, then update that mapping as the legislation and national implementation details mature.