The transition from PSD2 to PSD3 and the new Payment Services Regulation (PSR) marks a significant shift in how access to payment account data is governed across Europe. While much of the discussion has focused on improving competition and customer experience, the implications for Account Servicing Payment Service Providers (ASPSPs) run much deeper.

At its core, PSD3/PSR reinforces a fundamental requirement: only regulated and authorised parties should be able to access payment account data, and that access must be fair, secure and demonstrable. For ASPSPs, this raises important questions around identity, authorisation, permissions and ongoing oversight.

In this Q&A, we explore the questions our customers are asking most as they prepare for PSD3/PSR and what “good” looks like when it comes to safeguarding account data whilst enabling compliant access.

Q: What is PSD3/PSR changing about who is allowed to access account data?

A: PSD3/PSR reinforces a clear principle: only regulated and authorised providers may access payment account data, and they must be able to do so without discrimination.

For ASPSPs, this raises the bar on being able to accurately identify the accessing party, confirm their authorisation status, understand which jurisdictions they are permitted to operate within and ensure access is limited to what they are entitled to, no more and no less.

Why it matters: If access must be granted fairly, then verification, not friction, becomes the primary control.

Q: Why is continuous real-time third-party risk management more important under PSD3/PSR?

A: Under PSD2, many ASPSPs relied on point-in-time checks (e.g. at onboarding).
PSD3/PSR increases expectations around ongoing compliance.

ASPSPs need confidence that:

• The third party (ie.TPP or financial institution) is

• Still authorised at the time of the account access request

• • Their authorisation has not been withdrawn, limited, or suspended
  • Their passporting status remains valid
• The requesting entity matches the authorised legal entity

Authorisation status is no longer static; access decisions must reflect the current regulatory reality.

Q: How does PSD3/PSR affect how we treat different types of third parties?

A: PSD3/PSR aims to reduce ambiguity around access rights, but that doesn’t remove complexity for ASPSPs.

ASPSPs still need to:

• Distinguish between AISPs, PISPs, Credit Institutions and other regulated entities
• Enforce service-specific access (e.g. AIS or PIS)
• Validate that the TPP is requesting data within its permitted scope

For ASPSPs: Access control must be role and permission aware, not just identity-based.

Q: What are “prohibited obstacles” and why do they matter for access controls?

A: PSD3/PSR strengthens the concept of prohibited obstacles (measures that unfairly hinder authorised providers).

This puts pressure on ASPSPs to:

• Remove unnecessary friction
• Avoid discriminatory controls
• Ensure security measures are objective, proportionate and justifiable

Crucial distinction: Strong verification of who is accessing data is acceptable; arbitrary barriers are not.

Q: How does this change the way we should think about API access controls?

A: As PSD3/PSR streamlines access models and focuses on dedicated interfaces, the API becomes the primary control point.

That means ASPSPs need to:

• Validate the third-party certificates against authoritative regulatory sources
• Confirm the third-party legal entity identity
• Check the third-party permissions and roles before every data release
• Apply controls consistently across all endpoints

In practice: Access control expands beyond enabling account holders to provide clearly informed consent for account access to establishing machine-verifiable trust checks to determine the identity and regulatory permissions of the third party.

Q: What does the new customer permission dashboard mean for ASPSPs?

A: PSD3/PSR introduces the expectation that customers can see and manage which third parties have access to their accounts.

For ASPSPs, this creates new obligations:

• Accurately link permissions to the correct regulated entity
• Ensure permissions are revoked immediately and effectively
• Enable the third party to monitor the status of consent grants
• Notify third parties of changes to, or revocation of, consent grants
• Avoid situations where customers see unclear or misleading third-party identities

Bottom line: You can’t show customers meaningful permission data unless you can reliably identify the regulated entity behind each access request.

Q: How should ASPSPs handle changes to a TPP’s regulatory status?

A: Regulatory status can change due to:

• Withdrawal or suspension of authorisation
• Changes in scope
• Passporting updates
• Corporate restructuring

Under PSD3/PSR, ASPSPs need confidence that:

• Access is automatically aligned with the 3^rd party’s current regulatory status
• Formerly authorised entities lose access immediately
• There is no reliance on manual reviews or delayed updates

This is a key risk area if the third-party authorisation data is not continuously monitored.

Q: How can ASPSPs ensure they always make the correct account access decisions?

A: PSD3/PSR’s focus on trust and fraud reduction increases scrutiny on entity matching.

ASPSPs must be able to demonstrate that:

• The technical identity maps to the correct regulated organisation
• The organisation is authorised for the specific activity being requested

Q: What evidence do ASPSPs need to retain for regulators?

A: Under PSD3/PSR, ASPSPs should expect to evidence that:

• Access decisions were based on objective regulatory checks
• Only authorised and appropriately permissioned entities accessed data
• Access denials were non-discriminatory and justified
• Monitoring and controls operate on an ongoing basis

This makes auditability as important as access itself.

Q: What does “good” look like for ASPSPs under PSD3/PSR?

A: From an access-control perspective, strong compliance looks like:

• Real-time verification of authorisation and permissions
• Automated detection of status changes
• Consistent enforcement across all APIs
• Clear linkage between regulated entities, their permissions, and permitted jurisdictions
• Defensible, auditable access decisions

In short: ASPSPs move from managing access flows to proving regulated trust at scale.

Ultimately, PSD3/PSR pushes ASPSPs beyond managing access flows and towards proving trust.

Point-in-time checks, manual reviews and assumptions about third parties are no longer enough. Regulators, customers and counterparties increasingly expect access decisions to reflect the current regulatory reality, supported by clear evidence.

Whilst the vast majority of access requests will come from properly authorised and well-intentioned providers, robust controls are designed to identify and stop the small proportion of unauthorised or misrepresented access attempts that create disproportionate risk.

For ASPSPs, the opportunity is clear: build confidence that every access request is legitimate, permissioned and auditable and turn compliance into a foundation for trust.