PSD3 requirements explained: a practical guide for payment service providers

PSD3 requirements explained means more than a revision of existing payment rules: firms need to consider governance, fraud controls, open banking, transparency and operational resilience together.

• PSD3 is proposed alongside the directly applicable Payment Services Regulation, with the final legislative position still subject to the EU process.

• Banks, fintechs and payment institutions should review authorisation, safeguarding, outsourcing and management controls.

• Fraud monitoring, authorised push payment liability and strong customer authentication are central areas of change.

• Open banking providers may face clearer access, interface and data-sharing expectations.

• Early gap analysis will help firms adapt without treating draft provisions as final law.

What PSD3 is and who it will affect

PSD3 is the proposed successor to the Second Payment Services Directive, developed to update the EU framework for payment services. It is being considered alongside the Payment Services Regulation, or PSR, which is intended to create more directly applicable and consistent rules across Member States. The proposals remain subject to the legislative process, so firms should distinguish between confirmed obligations and likely areas of change. A useful overview of the proposals is available in this PSD3 and PSR guide.

The relationship between PSD3 and the PSR

PSD3 and the PSR are designed to work as a combined framework rather than as two unrelated reforms. The directive is expected to deal with matters that require national implementation, including elements of authorisation and supervision, while the regulation is intended to apply more uniformly across the EU to core payment-service rules. That division could reduce differences in how firms interpret obligations from one country to another.

For compliance teams, the practical point is to read the two instruments together. A policy may need local transposition under PSD3 while the customer-facing payment rule sits in the PSR. Until the final texts and implementation timetable are settled, legal inventories should record the source and status of each proposed requirement.

Which payment services fall within scope

The framework is aimed at payment service providers, including banks, electronic money institutions and other regulated firms that provide payment services. Its subject matter includes payment initiation, account information, issuing and acquiring, money remittance, payment accounts and related customer protections. The precise treatment of exemptions and business models remains an area for close review as negotiations develop.

Marketplaces, platforms and firms using agents should examine whether their current structure depends on an exemption or a particular allocation of responsibilities. Scope is not determined only by how a product is marketed; the actual flow of funds, access to accounts and role performed for the customer matter as well.

The impact on banks, fintechs and payment institutions

Banks will need to assess how existing payment-account interfaces, fraud processes and customer communications fit the updated framework. Fintechs and payment institutions may face more detailed expectations around governance, safeguarding, access to accounts and supervision. The effect will vary with the services offered, the countries served and whether the firm operates through agents or outsourced providers.

The proposed rules also point towards a more level regulatory environment for bank and non-bank providers. That does not remove the need for proportionality, but it does make it harder to treat regulatory classification as a substitute for a careful assessment of operational risk.

Key differences from PSD2

PSD3 and the PSR build on PSD2 rather than discarding its central architecture. The direction of travel includes stronger fraud and reimbursement protections, more consistent application across the EU, clearer open banking arrangements and updated requirements for authentication and data sharing. Firms should therefore treat their existing PSD2 programme as a starting point, not as evidence of future compliance.

The main difference is cumulative. Customer protection, fraud intelligence, governance and technology controls increasingly overlap, which means separate workstreams may leave material gaps. This comparison of PSD2 and PSD3 provides further context, but the final legislation and technical standards will remain decisive.

Looking for a partner to gear up for PSD3? Get free quotations from our topVendors

New authorisation and governance requirements

Authorisation is likely to become a more substantial demonstration of how a payment business is controlled in practice. Applicants and existing institutions should expect scrutiny of ownership, management, safeguarding, risk management and operational arrangements. The detail will depend on the final texts and supervisory guidance, but the direction is clear: documentation must describe working controls, not simply aspirations.

A firm preparing now should bring legal, compliance, finance, operations and technology teams into the same assessment. That makes it easier to identify where a formal authorisation statement is not supported by evidence in systems, contracts or management reporting.

Applying for authorisation under the updated framework

Applicants will need a coherent account of their services, business model, governance arrangements and risk controls. Existing payment institutions should also consider whether a change in classification, service mix or group structure could trigger a new notification or authorisation assessment. The application file should be consistent with customer journeys and operational reality.

A useful discipline is to trace each significant statement in an application to an owner and a source document. This exposes gaps early, particularly where a control is performed by a group company or third-party provider rather than by the applicant itself.

Initial capital and safeguarding expectations

Capital requirements and safeguarding arrangements remain foundational protections for customers and the wider payment system. Firms should understand which funds are customer money, where they are held, how reconciliations operate and what happens if the institution becomes unable to provide the service. Finance teams should be able to explain the control chain without relying on an informal description.

Safeguarding evidence should include account structures, reconciliation frequency, exception handling and escalation. It should also address periods of operational disruption, when manual workarounds can create the greatest risk of inaccurate balances or delayed segregation.

Management responsibility and governance controls

Senior managers will need a clear view of the risks attached to payment services and the controls used to manage them. That includes defined responsibilities, appropriate reporting, conflicts-of-interest arrangements and evidence that material issues reach the right decision-makers. A governance chart is useful, but it does not replace regular challenge and documented decisions.

The practical test is whether management can identify the most important customer, fraud, liquidity, technology and outsourcing risks, then show how those risks are monitored. Clear accountability matters because responsibility cannot be transferred simply by assigning a task to another team.

Outsourcing, operational resilience and record-keeping

Outsourcing arrangements should be reviewed for audit access, service levels, incident escalation, data handling, business continuity and exit planning. A provider may perform an activity, but the regulated firm remains responsible for understanding the resulting risk. Records should make it possible to reconstruct important decisions, customer events and control failures.

The review should cover both major technology contracts and less visible dependencies, such as identity checks, cloud infrastructure, fraud data and specialist reconciliation services. topVendors provides a neutral directory for researching banking software, branch hardware and specialist services, which can support an initial supplier-mapping exercise without replacing formal due diligence.

Stronger fraud prevention and customer protection

Fraud is one of the most visible areas in the PSD3 and PSR proposals. The emerging approach combines prevention, information sharing, authentication and clearer routes to reimbursement. It also requires firms to understand the customer journey: a control that stops a fraudulent payment but creates unreasonable barriers for legitimate customers may still need redesign.

The proposals should be assessed alongside existing fraud obligations and applicable data-protection rules. Firms need evidence that controls are risk-based, consistently applied and reviewed when fraud patterns change.

Liability for authorised push payment fraud

Authorised push payment fraud occurs when a customer is manipulated into approving a payment to an account controlled by a fraudster. Proposed changes would extend attention to the roles of both the payer and payee payment service providers, with liability and reimbursement conditions set by the final rules. Firms should not assume that a customer’s authorisation alone will settle responsibility.

Operational teams should map how a suspicious payment is identified, paused, investigated and communicated. They should also define the evidence required when determining whether reimbursement applies, while avoiding language that suggests an outcome before the relevant facts and legal tests have been assessed.

Fraud monitoring and transaction risk analysis

Transaction monitoring should combine payment data with behavioural and contextual indicators where lawful and proportionate. The objective is not to reject every unusual payment, but to identify patterns that merit intervention before funds leave the customer’s control. Detection rules, thresholds and escalation routes should be documented and tested.

A practical fraud review can focus on four connected areas:

• the signals used to identify unusual payment behaviour;

• the point at which a payment is delayed or challenged;

• the information exchanged with relevant payment providers; and

• the record created for investigation, reimbursement and audit.

This sequence helps connect technology decisions with customer protection. It also highlights where a monitoring tool produces an alert but the operating model lacks staff, authority or evidence to act on it.

Strong customer authentication changes

Strong customer authentication is expected to remain a core safeguard, while the updated framework may clarify exemptions, delegation and the circumstances in which authentication controls can be applied. Firms should review both the technical mechanism and the customer explanation. Authentication must be secure, accessible and appropriate to the transaction risk.

Testing should include failed authentication, device changes, account recovery, unusual locations and assisted journeys. Particular care is needed where a third party performs part of the authentication process, since responsibilities and audit evidence must remain clear.

Customer communication and reimbursement processes

A reimbursement process should be understandable to customers and workable for staff. It should state how a customer reports a suspected fraud, what information is needed, how the case is assessed and when the customer receives an update. Internal service targets should reflect the applicable legal timetable once it is finalised.

Communications should avoid technical shorthand and should preserve evidence of what was sent, when it was sent and through which channel. That record is useful not only for disputes, but also for identifying recurring weaknesses in warnings, payment screens and support procedures.

Open banking and access to payment accounts

Open banking remains a central part of the proposed framework. Account information and payment initiation providers depend on reliable access to accounts, while account servicing providers must protect customers and systems from misuse. The balance is difficult: access cannot be made so restrictive that it prevents competition, but it must not weaken security or availability.

The operational questions are familiar even where the rules are still developing. Firms need to know who authenticates the customer, which data is shared, how consent is recorded and what happens when an interface fails.

Improving access to bank account information

Account information services should be able to obtain the data needed for the service the customer has requested, subject to consent, security and the applicable legal boundaries. Better access does not mean unrestricted access. The provider must limit collection and use to a legitimate, documented purpose.

Firms should review consent screens, expiry rules, revocation handling and customer explanations. They should also consider whether the information returned is timely and complete enough for the service to function without repeated or unnecessary requests.

Rights and responsibilities of account servicing providers

Account servicing providers are responsible for maintaining secure payment-account access and for supporting legitimate third-party activity under the relevant framework. They should have clear procedures for refusing, restricting or restoring access when there is a genuine security concern. Those procedures need consistent evidence, rather than unexplained technical decisions.

Third-party providers, in turn, should meet authentication, consent, data minimisation and incident-handling expectations. A cooperative operating model reduces friction, particularly when a customer is trying to resolve an access problem involving more than one provider.

API performance and interface requirements

Interface performance affects both compliance and customer experience. Firms should monitor availability, response times, error rates, authentication failures and the quality of incident communication. A technically live interface can still be unsuitable if it regularly returns incomplete information or creates repeated customer authentication loops.

The monitoring model should distinguish a local application fault from an account-servicing interface problem. That distinction supports faster remediation and gives compliance teams a more reliable record when assessing whether access is being provided on fair and consistent terms.

Access to financial data beyond payment accounts

The wider policy discussion includes access to financial data beyond payment-account information. Any expansion raises questions about consent, purpose limitation, security, commercial arrangements and the responsibilities of each participant. Firms should not treat a broad data-access ambition as permission to collect information before the legal basis and technical standards are clear.

A sensible preparation step is to catalogue the data the business already holds, the parties that receive it and the customer choices attached to it. This creates a controlled starting point if further financial-data rules are introduced.

Transparency and customer rights

Clear information is a compliance control, not merely a presentation issue. Customers need to understand fees, exchange rates, payment timing, account access and the route to challenge an error. Firms should assess these points across contracts, digital screens, statements, notifications and support conversations.

The assessment should include customers who use assisted or non-digital channels. A disclosure that is technically complete but difficult to find or understand may not deliver the practical transparency the framework seeks.

Clearer information about fees and exchange rates

Payment providers should present charges and exchange-rate information in a way that allows customers to make an informed decision before a transaction is completed. Cross-border payments can involve more than one fee or conversion point, so the customer journey should identify the relevant components without creating misleading certainty.

Product teams should compare the information shown at quotation, authorisation and settlement. Differences between those stages need a clear explanation, especially where the final amount depends on a rate or charge applied by another participant.

Rules for payment account access and statements

Payment-account information should be provided in a form that customers can use and retain. Statements and notifications need to identify transactions, charges and relevant dates clearly enough for a customer to spot an error. The design should also support authorised representatives and customers who need an alternative format.

Operational owners should test statements against the underlying ledger and customer-support scripts. This can reveal inconsistencies that are easy to miss when legal text, interface design and transaction data are managed separately.

Protecting vulnerable and financially excluded customers

Customer protection should account for disability, limited digital access, language needs, financial distress and susceptibility to fraud. Proportionate safeguards may include assisted channels, accessible authentication methods, clearer warnings and staff escalation routes. These measures should be designed into the service rather than added only after a complaint.

Testing with representative customer groups can expose practical barriers. It can also help firms distinguish a necessary security step from an avoidable source of exclusion, which is especially valuable when authentication and fraud controls are being redesigned together.

Handling complaints and dispute resolution

Complaint procedures should be easy to locate, consistently recorded and connected to the relevant payment event. Staff need authority to identify urgent fraud or access issues, while specialist teams need enough information to assess liability and remediation. The process should preserve a clear chronology from the first report to the final response.

Management information should go beyond complaint volumes. It should show recurring causes, resolution times, reopened cases, reimbursement decisions and the customer journeys associated with disputes. Those findings can feed directly into product, fraud and control improvements.

Security, technology and operational compliance

PSD3 preparation involves more than updating a compliance manual. Payment providers depend on applications, identity services, data stores, communication channels and external technology providers that must work together securely. The compliance question is whether the firm can demonstrate control over that chain, including during disruption.

Technology and compliance teams should use a shared inventory of systems, data, owners, dependencies and recovery arrangements. This gives senior management a practical view of where a failure could affect payment execution or customer access.

Cybersecurity and incident reporting obligations

Firms should maintain processes for identifying, classifying, escalating and reporting significant security incidents. The process should connect technical detection with legal assessment and customer communication. It should also define who can make decisions outside normal business hours.

Incident exercises are useful because they reveal delays that policy documents conceal. Scenarios should include a compromised credential, unavailable payment infrastructure, a third-party outage and suspected data loss, with evidence captured for subsequent review.

Protecting payment credentials and personal data

Payment credentials and personal data require controls across collection, transmission, storage, access and deletion. Teams should understand which data is necessary for a service, who can view it and how access is revoked. Security measures should be proportionate to the risk but consistently applied.

The same customer journey can involve authentication data, transaction details and fraud indicators. Data-protection, security and product owners should therefore assess the journey together, rather than assuming that separate policies automatically produce a complete control environment.

Managing third-party technology providers

Third-party risk management should cover selection, onboarding, oversight, incident handling and exit. Contracts should support access to relevant records, appropriate cooperation during investigations and continuity if the provider fails. Concentration risk also deserves attention where several critical services depend on the same technology ecosystem.

A supplier register should identify the service provided, the data involved, the criticality of the dependency and the latest assurance evidence. topVendors’ periodically verified supplier information can help professionals begin market research, while contractual and regulatory assessment must remain the firm’s responsibility.

Preparing systems for regulatory audits

Audit readiness is the ability to produce reliable evidence without reconstructing events from scattered emails. Firms should preserve policies, approvals, test results, incident records, access logs, reconciliations and supplier reviews according to a defined retention approach. Evidence should be linked to named controls and accountable owners.

A small sample review can be revealing. Select a payment, an authentication event, a fraud alert and a supplier incident, then test whether the firm can explain what happened, who acted, what evidence was retained and whether the outcome was communicated properly.

How businesses should prepare for PSD3

Preparation should be staged and evidence-led because the final framework may still change. Firms can begin with controls that are already relevant under PSD2 and then overlay the areas where PSD3 and the PSR are expected to add detail. This avoids both complacency and expensive redesign based on an early draft.

The aim is not to claim compliance before the rules are final. It is to create a fact base, identify decisions that depend on the final text and improve controls that are likely to remain important regardless of the final wording.

Mapping current PSD2 controls against proposed requirements

Start with a control inventory covering authorisation, safeguarding, authentication, fraud, open banking, complaints, transparency, outsourcing and incident management. For each control, record its owner, evidence, affected systems and legal source. Then mark whether the proposed change appears to retain, clarify, extend or potentially replace the existing expectation.

This approach makes uncertainty visible. It also prevents teams from treating a policy document as complete when the underlying process, system setting or supplier contract has not been checked.

Identifying gaps in fraud, authentication and safeguarding

Gap analysis should test operating effectiveness as well as written design. Review fraud scenarios, reimbursement cases, authentication exceptions, customer warnings, reconciliations and access permissions. Include borderline cases, because those often expose unclear responsibility between teams or providers.

The results can be grouped by customer impact, regulatory significance, implementation effort and dependency. That gives management a more useful prioritisation method than a long list of unranked observations.

Updating policies, contracts and customer journeys

Policy changes should be translated into contracts, procedures, product requirements and customer communications. Pay particular attention to terms with third-party providers, liability language, consent notices, reimbursement instructions and service-continuity commitments. A legal amendment that never reaches the interface or operating procedure is not an effective implementation.

Run the review across the full journey from onboarding to payment, dispute, account closure and data deletion. Customer-support teams should be involved, since they often encounter the practical effects of unclear wording first.

Building a realistic implementation roadmap

A roadmap should separate actions that can start now from those dependent on the final text or technical standards. It should assign accountable owners, funding assumptions, delivery milestones, testing points and escalation routes. Dependencies between fraud, authentication, data, legal and technology workstreams should be explicit.

A simple prioritisation structure can help turn analysis into delivery:

• stabilise controls with known customer or security weaknesses;

• prepare evidence and ownership for likely supervisory questions;

• design changes that depend on final legal or technical wording; and

• schedule customer testing before major interface or process changes.

After the list has been agreed, management can review progress by outcome rather than by the number of meetings or documents completed. topVendors can also act as a neutral research point when teams are comparing relevant banking technology and specialist service categories, without replacing procurement controls.

Monitoring the final legislation and national transposition rules

Regulatory monitoring should identify the responsible owner, authoritative sources, review frequency and method for distributing updates. The final PSD3 text, the PSR, technical standards and national transposition measures may not arrive as one single instruction. Firms operating across borders should record where local implementation creates a different deadline or process.

Keep a decision log showing which assumptions were made, when they were reviewed and what evidence supported them. That record will help the business adjust its roadmap as the legislative position develops, rather than restarting the entire analysis each time a proposal changes.