What is the difference between PSD2 and the earlier payment rules that focused mainly on transfers and card payments?

PSD2 goes beyond earlier payment rules by regulating online and mobile payments, along with the services built around them. Earlier frameworks mainly covered bank transfers, direct debits, and card-based payments. PSD2 also formalizes new roles such as payment initiation and account information services, which changes both competition and security expectations across the market.

How PSD2 Changed the Scope of Payment Regulation

PSD2 widened the regulatory lens from a narrow focus on transfer and card rails to the broader digital payment ecosystem. That matters because regulation now has to address not only the movement of funds, but also the channels, interfaces, and service layers that sit on top of those payments.

Under the earlier regime, the core concern was whether the payment itself was authorised, executed correctly, and settled safely. PSD2 adds a second layer of scrutiny around the services that initiate or aggregate payment activity, which is why online and mobile payment journeys are part of the picture rather than an afterthought.

Why the New Service Model Matters

PSD2 introduces roles that did not sit at the centre of earlier payment rules, especially payment initiation and account information services. Those roles matter because they separate the customer interface from the account-holding bank, creating a more open ecosystem with more participants and more potential points of failure.

That shift changes the security expectations as well as the market structure. When third parties can initiate payments or pull account data through regulated interfaces, controls have to cover consent, authentication, API access, data minimisation, and the integrity of the service relationship, not just the payment instrument itself.

What Practitioners Need to Watch in the Transition

The practical difference is that PSD2 is not only about payment instruments, it is about payment access. Earlier rules were enough when the main question was how to govern transfers, direct debits, and cards; PSD2 is designed for environments where apps, aggregators, and embedded services can sit between the customer and the bank.

That broader scope is why PSD2 is often discussed alongside stronger customer authentication and regulated access to account data. The compliance burden is less about adding one more rule for banks and more about defining a safer operating model for digital payment ecosystems.

Risk and Threat Considerations

Expanding payment access creates a wider attack surface. The more third parties, APIs, and consented data flows involved, the more important it becomes to control impersonation, abuse of delegated access, and failures in interface security.

Failure mechanism: Weakly governed payment initiation or account information access can let an attacker exploit stolen credentials, consent misuse, or insecure API integration to trigger unauthorised activity or expose sensitive account data.

Impact: The result can be fraud, privacy loss, customer harm, regulatory exposure, and trust damage across the whole payment chain, not just at the bank that holds 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 and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP API Security Top 10	API2 — Broken Authentication	PSD2 expands regulated payment access through APIs and third-party services.
	API5 — Broken Function Level Authorization	Payment initiation and information services depend on correct action-level authorization.
	API8 — Security Misconfiguration	PSD2-style open banking relies on correctly configured exposed interfaces.
Recommendation — Harden API authentication for payment initiation and account information access. Enforce function-level authorization on all payment and account-data operations. Review exposed payment APIs for insecure defaults, weak transport, and unsafe exposure.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Digital payment access depends on secure credential and token lifecycle controls.
	AC-6 — Least Privilege	PSD2 service roles should only access the minimum payment and account data required.
Recommendation — Manage and rotate authenticators used for payment access and delegated services. Limit third-party and application permissions to the minimum needed for each payment function.

Practitioner Guidance

What to prioritise: Treat the new service layer as part of the payment control environment, not as a simple front-end integration. The key question is whether consent, authentication, and transaction boundaries remain enforceable when a third party sits in the flow.

What to verify: Confirm that the relevant access path is limited to approved purposes, that permissions are time-bounded, and that the institution can trace who initiated the action and on what basis. If you cannot attribute the request cleanly, the control model is too weak for PSD2-style access.

Practitioner takeaway: The real change is not just broader payment coverage, it is the need to govern payment activity as a multi-party digital service with explicit access, consent, and accountability controls.