Following the political agreement reached in November 2025, the technical trilogue work on the Payment Services Regulation has been completed and a draft agreement text has been finalised. A silent procedure has been launched at EU level to confirm the agreed text, ahead of formal adoption and legal-linguistic review. Publication in the Official Journal is expected in the second half of 2026. Once published, the PSR enters into force 20 days later, with general application 21 months after that, and the Verification of Payee provisions taking effect at the 27-month mark.

For banks and PSPs, this agreed text provides a sufficiently stable foundation for operational planning. What follows is a detailed analysis of what the PSR requires across its key areas of impact, from fraud liability and open banking to strong customer authentication and cross-sectoral cooperation, drawn directly from the draft agreement text.

Raoul Mulheims and co worker

For readers new to this topic, our earlier article Navigating the shift from PSD2 to PSR and PSD3 explains the structural decision to split the framework between a directly applicable Regulation (the PSR, covering conduct-of-business rules) and a Directive (PSD3, covering licensing and supervision). Our analysis of the themes that emerged during the trilogue negotiations provides further context on how the agreed text reached its current form.

There is, however, more to come. Much of the operational detail will be shaped by the EBA’s regulatory technical standards and guidelines, which are to be delivered over the 9 to 21 months following entry into force. We will continue to cover those developments as they emerge.

In this article

The second Payment Services Directive (PSD2) fundamentally reshaped the European financial landscape, ushering in the era of Open Banking. Now, the European Union is preparing for the next significant evolution with a new legislative package: the Third Payment Services Directive (PSD3) and the Payment Services Regulation (PSR).

  1. Fraud prevention and liability — Transaction monitoring becomes a direct liability trigger. Payee-side fund interception. The spoofing refund right and its procedural safeguards. Gross negligence assessment. Consumer spending controls.
  2. Open banking and APIs — The dedicated API as the sole access channel. Performance, functional, and data parity requirements. The consent dashboard. Prohibited obstacles.
  3. Verification of Payee — Extended to all non-euro credit transfers. Liability for absent or defective verification. Non-consumer opt-out.
  4. Strong Customer Authentication — Two-inherence exception. Accessibility as a core obligation. Expanded SCA triggers. Wallet and TSP liability.
  5. Cross-sectoral obligations — Telecoms, platforms, hosting providers, mandatory fraud data sharing, and the Commission Platform on Combatting Fraud.
  6. Timeline and compliance preparation — Phased RTS deadlines. Priority areas for banks: API parity, transaction monitoring, consent dashboard, fraud data sharing, internal governance, and training.
1. PSR fraud prevention and liability: what changes for banks

The PSR’s fraud provisions represent a fundamental redesign of how responsibility is distributed across the payment chain, built on a core premise: payment service providers have more means than consumers to prevent fraud, and they must demonstrate that they have used them.

1.1 Transaction monitoring as a direct liability trigger

Under PSD2, the regulatory technical standards required PSPs to have transaction monitoring mechanisms in place, primarily as a component of the SCA framework and as a prerequisite for relying on certain SCA exemptions such as transaction risk analysis. The PSR takes a materially different approach. It establishes transaction monitoring as a standalone obligation for both the payer’s and the payee’s PSP, with explicit and direct financial consequences for non-compliance.

The payer’s PSP must monitor prior to execution. The payee’s PSP must monitor before making funds available. Each side draws on a defined but distinct set of data: the payer’s PSP assesses behavioural and account characteristics, transaction history, device data, payee identifiers, and intelligence received through fraud sharing arrangements; the payee’s PSP analyses payee account history, incoming transaction patterns, payer name, and shared intelligence.

Where a PSP does not apply transaction monitoring and the relevant transaction turns out to be fraudulent, the payer must be refunded by their PSP. If the failure lies on the payee side, the payee’s PSP must compensate the payer’s PSP. The quality, auditability, and coverage of monitoring systems are therefore directly connected to financial exposure.

The EBA is mandated to develop regulatory technical standards specifying the detailed requirements for these mechanisms, drawing on environmental and behavioural characteristics, transaction patterns, and authentication data. Data processed for monitoring purposes may be retained for a maximum of five years after the end of the customer relationship, consistent with the retention period under the Anti-Money Laundering Regulation.

Where a PSP fails to apply transaction monitoring and the transaction turns out to be fraudulent, that PSP bears the financial loss. Monitoring is no longer a supervisory expectation alone, it is a direct liability trigger.

1.2 Payee-side fraud intervention under the PSR

The PSR introduces a layered mechanism for the payee’s PSP to intercept suspected fraudulent incoming payments. The distinction between its two tiers has direct operational consequences.

At the first level, where the payee’s PSP has “objectively justified reasons to suspect” that a credited or incoming transaction is fraudulent, it may decide not to make the funds available and to return them to the payer’s PSP. This is a discretionary power. The suspicion may be grounded in the PSP’s own transaction monitoring or in other relevant information, but the regulation is clear that a VoP mismatch alone does not constitute sufficient grounds, and that the mere fact that a payment order is unusual does not automatically give rise to a fraud suspicion.

At the second level, where the evidence is “clear and incontrovertible”, the language shifts from discretionary to mandatory: the payee’s PSP must withhold the funds and return them. Failure to act at this higher threshold creates liability: the payer bears no financial loss (unless the payer acted fraudulently), and the burden of proof that there was no breach rests on the payee’s PSP.

For instant credit transfers, the payee’s PSP must notify the payer’s PSP of the refusal and return of funds within 10 seconds of receiving the payment order. The payer’s PSP must then immediately restore the payer’s account to its pre-transaction state and inform the payer (and, where relevant, the PISP) that the funds were not made available due to fraud prevention measures.

Banks acting as receiving PSPs will need monitoring systems capable of real-time risk assessment on incoming payments, governance frameworks that define the boundary between the two evidentiary thresholds, and operational processes for the notification chain that runs from payee’s PSP to payer’s PSP to payer.

1.3 The PSR spoofing refund right

The PSR creates a refund right for consumers who are manipulated by a fraudster using communication channels attributed to the consumer’s own PSP: the PSP’s telephone number, email address, website, or mobile application. The scope intentionally excludes broader social engineering scenarios such as investment scams, romance fraud, or impersonation of government authorities or other entities.

The procedural framework is prescriptive. The consumer must notify the PSP without undue delay and file a police report. The PSP then has 15 business days, from receiving both the notification and the police report, to either refund in full or provide written reasons for refusal, identifying the available dispute resolution bodies. A refusal is permissible only where the PSP has objectively justified reasons to suspect fraud or gross negligence on the part of the consumer.

A central safeguard in the assessment process is the following: before concluding that the consumer acted with gross negligence, the PSP must proactively and unambiguously invite the consumer to provide information about the circumstances. The consumer’s failure to respond does not, in itself, support a finding of negligence. Nor can the consumer be expected to provide evidence beyond what they can reasonably be expected to have (for example, voice call recordings cannot be demanded). Successful completion of SCA does not constitute proof that a transaction was authorised or that the consumer was negligent. The burden of proof remains on the PSP throughout.

If a PSP concludes that the consumer acted fraudulently, it must communicate the reasons for that conclusion to the relevant national authority.

Successful completion of strong customer authentication does not constitute proof that a transaction was authorised or that the consumer was negligent. The burden of proof remains on the PSP throughout.

1.4 Gross negligence assessment under the PSR

The regulation sets out a non-exhaustive list of factors to be considered when assessing gross negligence. These include the complexity and innovativeness of the fraud; the techniques used to steal credentials; whether the consumer has previously been targeted by the same type of fraud; whether the PSP met its fraud awareness obligations; whether specific, directed warnings or interventions were offered by the PSP and not heeded; the vulnerability profile of the consumer; and the adequacy of the steps taken by the consumer to protect their credentials.

The regulation avoids a rigid definition. The EBA is encouraged (though not mandated by a specific deadline) to issue guidelines on the factors that should weigh in this assessment. In the interim, the standard will remain a matter of informed judgement, and PSPs should be developing their internal assessment frameworks in anticipation.

1.5 Consumer spending controls

The PSR gives consumers additional tools to manage their own exposure. PSPs must offer customers the ability to set per-method and per-instrument spending limits, adjustable on a per-transaction or periodic basis, at the customer’s sole discretion. PSPs may not unilaterally change these limits.

To protect against scenarios where a victim is manipulated into raising their own limits, any increase requested through a remote channel is subject to a default four-hour delay before taking effect. Consumers may adjust this delay or opt out entirely, but any such change is itself subject to the delay period in place and requires strong customer authentication. The same four-hour delay and multi-channel notification logic applies to the remote activation of mobile payment applications on new devices, with an exception for the initial establishment of the customer relationship.

2. Open banking under the PSR: API performance, data parity, 
and the consent dashboard

PSD2 established the principle that banks must open their payment account data to authorised third-party providers. The PSR converts that principle into a set of measurable, enforceable, and operationally specific obligations.

Open Banking APIs, performance, functionality, data information parity, and user journey

2.1 Dedicated API as the sole open banking access channel

The permanent fallback mechanism is removed. AIS and PIS providers must access payment account data exclusively via the dedicated interface. ASPSPs that obtain a new authorisation must have their dedicated interface operational within three months.

The regulation clarifies that ASPSPs may voluntarily offer additional or premium interfaces, but TPPs have no right to demand access through any channel other than the dedicated interface.

2.2 PSR API performance parity requirements

The dedicated interface must offer availability and performance that are at least equal to those of the interface available to the ASPSP’s own payment service users. API response times must not be longer than those of the customer-facing interface.

This is made measurable through a mandatory quarterly reporting obligation: ASPSPs must publish statistics on the availability and performance of their dedicated interface, alongside comparative figures for their customer interface, on their website.

Unplanned unavailability is presumed when five consecutive requests receive server error responses or no response within 30 seconds. The EBA must deliver draft RTS on optimal recovery time standards within nine months of entry into force, calibrated to incident severity, the number of customers impacted, and the types of TPP functionality affected.

For planned maintenance, ASPSPs must provide at least one month’s advance notice, with downtime normally scheduled between midnight and 06:00, except for emergency changes.

With the removal of the fallback interface, the dedicated API becomes the sole point of access for third-party providers. The PSR makes the quality of that interface a measurable, reportable, and enforceable obligation.

2.3 Functional parity for open banking APIs

The minimum functional requirements for the dedicated interface extend substantially beyond single payment initiation. The API must support standing orders (placement and revocation), future-dated payments (initiation and revocation), payments to multiple beneficiaries, and payments to any payee rather than only those on the payer’s beneficiary list (unless the same restriction exists in the customer interface).

PISPs must be able to choose which authentication procedure is presented to the payer where the ASPSP offers more than one. Before initiating a payment, PISPs must be able to verify the account holder’s name, unique identifier, and available currencies. Once a payment is initiated, the ASPSP must provide the PISP with ongoing status updates until the payment is executed or rejected, rather than only a one-time confirmation after initiation.

2.4 Data parity

The dedicated interface must provide AISPs with at least the same payment account and transaction data available in the customer interface (excluding sensitive payment data). The baseline includes the unique identifier, account holder’s full name, currencies, balance, and pending transactions visible in the customer channel.

The account holder’s full name and unique identifier are explicitly excluded from the definition of sensitive payment data for AIS and PIS purposes.

2.5 PSR consent dashboard requirements

ASPSPs must provide a user-facing dashboard, integrated into their own interface, through which customers can monitor and manage their TPP data access consents. The dashboard must display the TPP name, the account to which access has been granted, the purpose and validity period of the consent (including the date when the consent was given), the categories of data shared, and the dates on which data was actually accessed.

The dashboard must allow withdrawal and, within a 48-hour window, re-establishment of consents. It must maintain a record of withdrawn and expired consents for two years. Following withdrawal, the TPP must cease accessing the data and delete it without undue delay (though not before the 48-hour re-establishment window has passed). The PSP and the TPP must cooperate to ensure the information on the dashboard is accurate and available without undue delay.

The regulation is explicit about what the dashboard must not be. It prohibits deterring or discouraging language that might dissuade users from using TPP services. The ASPSP must not prompt users to withdraw consents, and must not design or operate the dashboard in a manner that “deceives, manipulates, or directs the payment service user to grant consents that are not in the user’s best interest, or in a manner that materially distorts or impairs the user’s ability to make free and informed decisions.”

The ASPSP must not design or operate its consent dashboard in a manner that deceives, manipulates, or directs the payment service user to grant consents that are not in the user’s best interest.

2.6 Prohibited obstacles to open banking

The PSR includes a non-exhaustive list of twelve specific prohibited obstacles. Among the most operationally significant: restricting PIS to a pre-approved beneficiary list (unless the same restriction applies in the customer channel); requiring more SCA steps than in the direct channel; imposing additional steps in the user journey during redirection or decoupled authentication; failing to support all authentication procedures available to the customer; and requiring two separate SCA events in a PIS-only journey where the PISP already transmits all necessary payment information.

Fraud-prevention measures and GDPR compliance are not automatically classified as prohibited obstacles, but they lose that protection if they constitute one of the specifically listed obstacles. In practice, this means that such measures must be justified on a case-by-case basis, remain proportionate, and be applied equally to TPP-initiated services and to the ASPSP’s own comparable services. Blanket blocking of TPP access on fraud or GDPR grounds remains prohibited.

3. Verification of Payee under the PSR

The PSR extends the name-matching verification requirement to all credit transfers not already covered by the Instant Payments Regulation (which mandates VoP for euro credit transfers). The PSR applies the same verification framework, by cross-reference, to non-euro credit transfers.

The service must be provided free of charge and before the payer authorises the transaction. Where the service is absent or malfunctions, the payer’s PSP is liable and must refund the resulting losses without delay. Where that failure is attributable to the payee’s PSP or a PISP, the responsible party must compensate the payer’s PSP.

Non-consumer payment service users may opt out of VoP when using automated dedicated payment channels or protocols. They can also agree contractually that VoP is applied after authorisation, with automatic execution in defined matching outcomes. This provides appropriate flexibility for bulk payment and treasury workflows, where manual pre-authorisation verification would be impractical.

These provisions apply 27 months after entry into force, roughly six months after general application.

Understanding the regulation is the starting point. Acting on it is what matters. The second part of this analysis translates the PSR’s requirements into a concrete preparation agenda – covering the priority areas where work should already be under way, the governance and operational changes that cannot wait for the EBA’s technical standards, and a full breakdown of the implementation timeline.

4. Strong Customer Authentication under the PSR

The PSR does not redesign SCA, but rather clarifies, extends, and tightens the existing framework in targeted areas.

The most significant change permits, under specific conditions, the use of two elements from the inherence category (for example, fingerprint combined with facial recognition), enabling passwordless and tokenless authentication flows. However, the two elements must be independent of each other, and the ASPSP must be able to demonstrate this to its competent authority. The EBA will issue guidelines on how to assess that independence, due 18 months after entry into force.

SCA accessibility is elevated to a core obligation. PSPs must ensure that SCA methods are adapted to all customers, including persons with disabilities, older persons, and those without access to a smartphone. At least one non-smartphone SCA method must be available free of charge, unless the customer has contractually agreed to a mobile-only service package.

The regulation also clarifies additional SCA triggers beyond payment initiation: the creation or replacement of tokens for payment instruments (including enrolment of cards in digital wallets), modifications to spending limits, password changes, and updates to contact information all require SCA.

Pass-through digital wallets are confirmed as technical services rather than payment services. Where wallet operators verify SCA elements, they must operate under outsourcing agreements with payers’ PSPs. Technical service providers and payment scheme operators bear liability for SCA failures within their remit, capped at the amount of the transaction concerned.

5. Cross-sectoral obligations: telecoms, platforms, and fraud data sharing

The PSR acknowledges that fraud does not begin and end within the banking perimeter. It brings other sectors into the regulatory framework through a combination of cooperation duties, technical obligations, and liability mechanisms.

Electronic communications service providers must take organisational and technical measures to detect and prevent caller ID and email spoofing used for payment fraud. They must establish dedicated communication channels with PSPs, provide educational alerts to their users when new fraud patterns emerge, and cooperate with Member State awareness programmes, free of charge.

Very large online platforms and search engines (within the meaning of the Digital Services Act) face a new advertiser verification obligation for regulated financial services, covering banking, credit, insurance, payment, and investment products including crypto-assets. They must request authorisation or registration information from advertisers and assess its reliability before allowing the advertisement.

Hosting providers that lose their conditional liability exemption under the Digital Services Act (for example, by failing to act on notices of fraudulent content) become liable to compensate PSPs for fraud losses linked to that content. This creates a direct financial consequence for failure to process notifications of fraudulent activity promptly.

Mandatory fraud data sharing. All PSPs must participate in multilateral fraud information sharing arrangements. The regulation requires participation but does not prescribe the infrastructure. The European Parliament’s earlier proposal for an EBA-operated central platform was not retained. Private-sector frameworks, such as the EPC’s FRIDA initiative, represent one possible vehicle. Data sharing must be accompanied by a joint data protection impact assessment, pseudonymisation safeguards, and a prohibition on drawing adverse conclusions about a customer solely on the basis of shared data.

The Commission Platform on Combatting Fraud. The PSR establishes an advisory expert group bringing together public and private sector representatives to advise the Commission, analyse fraud trends, and recommend a voluntary code of conduct under the DSA framework.

6. PSR timeline and compliance preparation for banks

The PSR’s implementation is phased, and each phase creates a distinct preparation window. Publication in the Official Journal is expected in the second half of 2026. Entry into force follows 20 days later (D).

  • D + 9 months brings the first RTS deadline: the EBA must deliver draft standards on dedicated interface performance statistics and optimal recovery time standards. 
  • D + 12 months is the major regulatory milestone: the SCA “super-RTS” covering requirements and exemptions, transaction monitoring mechanism specifications, fraud statistics reporting formats, dedicated interface exemption criteria, PI account refusal notification formats, and the limited network exclusion conditions. The commercial agent exclusion guidelines also fall here.
  • D + 15 months is the deadline for the delegated act specifying the fee information that payment card schemes and processing entities must disclose to acquirers.
  • D + 18 months delivers standards on open banking monitoring data methodology and guidelines on assessing the independence of two biometric SCA elements.
  • D + 21 months is the general application date.
  • D + 27 months is when the VoP provisions take effect.

Although some operational detail will only be confirmed once the EBA’s regulatory technical standards are published, the regulation itself is detailed enough to support concrete preparation. The work should begin in 2026.

Below is a more detailed view of the priority areas.

6.1 API performance and parity

The quarterly reporting obligation requires infrastructure: ASPSPs will need to measure and compare the availability and performance of their dedicated interface against their customer-facing channel, and publish the results. This presupposes that monitoring tooling, data collection pipelines, and publication mechanisms are in place.

Beyond reporting, the substantive parity requirement means that any material gap between the API and the customer interface in terms of response time, uptime, or data coverage must be closed. Banks should begin with a thorough assessment of their current API performance relative to their own online banking platform. Where the API falls short, the remediation will involve development cycles that must be planned well in advance. The quarterly reporting obligation requires infrastructure: ASPSPs will need to measure and compare the availability and performance of their dedicated interface against their customer-facing channel, and publish the results. This presupposes that monitoring tooling, data collection pipelines, and publication mechanisms are in place.

The functional parity requirements (standing orders, future-dated payments, ongoing payment status, pre-initiation data verification, and PISP authentication method selection) may require significant API enhancements for ASPSPs whose current PSD2 interfaces were built to a more limited specification.

6.2 Transaction monitoring

Both sending-side and receiving-side monitoring capabilities should be audited against the PSR’s requirements. The sending-side obligation requires monitoring before execution, drawing on behavioural, transactional, and device data. The receiving-side obligation requires monitoring before making funds available, with the additional complexity of the two-tier intervention mechanism for incoming suspected fraudulent payments.

For instant credit transfers, the receiving PSP’s monitoring must be capable of real-time decisioning within the 10-second notification window. Banks should assess whether their current monitoring infrastructure supports this, and whether the governance framework for escalation and decisioning is documented and auditable.

The explicit liability link means that monitoring coverage gaps are directly relevant to financial provisioning. Internal audit and risk functions should be involved in this assessment.

6.3 The consent dashboard

The consent dashboard is a requirement that did not exist under PSD2. The design and development effort should not be underestimated: the dashboard must be integrated into the ASPSP’s user interface, display accurate and up-to-date information about each TPP consent (including purpose, data categories, validity period, and actual access dates), support withdrawal and re-establishment flows with a 48-hour window, and maintain a two-year historical record.

The regulation’s prohibitions on manipulative or discouraging design impose constraints that should be reflected in the design process from the outset, not retrofitted.

Operationally, the dashboard requires bidirectional data flows with TPPs: ASPSPs must notify TPPs promptly of consent withdrawals, and TPPs must notify ASPSPs of new or re-established consents. These integration points will need to be specified, built, and tested.

6.4 Fraud data sharing

The obligation to participate in a multilateral fraud data sharing arrangement carries preparation requirements that should not be deferred. The joint DPIA must be completed before a PSP can join an arrangement, and the regulation specifies the categories of data that may and may not be shared. Internal data governance processes will need to be reviewed to ensure that shared data is appropriately pseudonymised, that retention limits (five years from the suspected fraudulent transaction) are enforced, and that the prohibition on adverse customer decisions based solely on shared data is respected in practice.

Banks should begin by mapping the available sharing arrangements and evaluating their governance structures and data protection safeguards.

6.5 Internal governance for the refund process

The spoofing refund procedure and the broader unauthorised-transaction refund framework both introduce specific procedural requirements that should be mapped against existing complaints and fraud-handling workflows. These include the obligation to invite consumers to provide evidence before reaching any adverse conclusion; the 15-business-day decision window; the requirement to provide written justifications with references to dispute resolution bodies; and the reporting obligation to national authorities where the PSP concludes that the consumer acted fraudulently.

Banks should ensure that front-line and back-office teams are trained on the new procedural requirements, that case management systems capture the information needed to demonstrate compliance with each step, and that internal policies on gross negligence assessment reflect the regulation’s non-exhaustive factor list.

Fraud and liability the refund process from unauthorised transactions to authorised transactions with a spoofing scenario example

6.6 Fraud awareness and staff training

The PSR requires PSPs to alert customers when new forms of payment fraud emerge, using all appropriate means and media, with particular attention to the most vulnerable customer groups. PSPs must also organise at least annual training programmes on payment fraud risks and trends for employees involved in designing, maintaining, or offering payment services. These obligations are ongoing and should be embedded in the institution’s regular training and communication planning.

6.7 Cross-sectoral coordination

Banks should also consider the operational implications of the new cross-sectoral cooperation requirements. The regulation establishes a framework in which electronic communications providers, hosting service providers, and large online platforms have defined obligations towards PSPs. While banks are not responsible for enforcing those obligations, they will benefit from establishing the communication channels and notification workflows that the regulation envisages, particularly for reporting fraudulent content to hosting service providers.

“The regulation is detailed enough for banks to begin preparing today. Waiting for the RTS to be finalised before acting would mean losing months that cannot be recovered.”

Raoul Mulheims, CEO and co-founder of Finologee

As a Luxembourg-regulated Support PFS and trusted provider of PSD2 compliance and open banking infrastructure, with 35 banks and PSPs on its platform, Finologee has been tracking the PSR throughout the legislative process.

Our existing platform already addresses several core PSR requirements, and we are actively preparing for the obligations that are new or substantially changed.

  • Our PSD2 Access to Account (XS2A) infrastructure is built on a high-availability architecture designed to meet the strict performance parity requirements. We already produce detailed availability and performance statistics, positioning our clients to meet the new quarterly publication obligations from the outset. 
  • The PSR’s consent dashboard requirement aligns with the consent lifecycle management capabilities already at the core of our platform, which provides granular visibility into TPP access, permissions, data categories, and consent validity.
  • Our SCA integration capabilities support authentication orchestration across complex multi-channel environments, a critical capability as the PSR broadens SCA triggers and tightens accessibility requirements.
  • Our product roadmap is aligned with the PSR’s expanded functional requirements for dedicated interfaces, including standing orders, future-dated payments, and ongoing payment status updates for PISPs.

By leveraging third-party solutions like Finologee’s platform, banks can reduce the internal IT and compliance burden associated with implementing these complex technical standards and accelerate their path to compliance.

Frequently asked questions about the PSR

What is the PSR?

The Payment Services Regulation (PSR) is a directly applicable EU Regulation that replaces the conduct-of-business rules currently set out in PSD2. Unlike a Directive, it applies identically across all EU Member States without the need for national transposition. It covers fraud prevention, liability, open banking, SCA, Verification of Payee, and transparency requirements for payment services.

When does the PSR apply?

The PSR applies 21 months after entry into force. Based on an expected publication in the Official Journal in the second half of 2026, general application is estimated around the end of 2027 or early 2028. The Verification of Payee provisions apply six months later, at the 27-month mark.

What is the difference between the PSR and PSD3?

The PSR is a Regulation covering the conduct of business: rights and obligations of PSPs and users, fraud prevention, open banking rules, SCA, and transparency. PSD3 is a Directive covering the authorisation and supervision of payment institutions and electronic money institutions, which Member States must transpose into national law. Together they replace PSD2.

Does the PSR require banks to maintain a fallback interface?

No. The PSR removes the obligation to maintain a permanent fallback interface. The dedicated API is the sole access channel for AIS and PIS providers. In exchange, the API must meet strict performance and data parity requirements equal to those of the bank’s own customer-facing interface.

What is the PSR spoofing refund right?

The PSR introduces a consumer refund right where a fraudster impersonates the consumer’s own PSP using the PSP’s attributed communication channels (phone number, email, website, mobile application) and the consumer makes a payment as a result. The PSP must refund the full amount unless it can demonstrate that the consumer acted fraudulently or with gross negligence. The scope covers PSP impersonation only and does not extend to investment scams, romance fraud, or impersonation of other entities.

What is the PSR consent dashboard?

ASPSPs must provide customers with a dashboard integrated into their own interface to monitor and manage TPP data access consents. The dashboard must display the TPP name, account, purpose, validity, data categories, and access dates. It must allow withdrawal and re-establishment of consents within a 48-hour window. The dashboard must not contain deterring language or be designed in a way that discourages the use of TPP services.

What are the PSR's transaction monitoring requirements?

Both the payer’s and the payee’s PSP must operate transaction monitoring mechanisms. The payer’s PSP monitors before execution; the payee’s PSP monitors before making funds available. Where a PSP fails to apply monitoring and a fraudulent transaction occurs, that PSP bears the financial loss. The EBA will develop detailed technical standards specifying the monitoring requirements.

What must banks do to comply with the PSR open banking requirements?

Banks must operate a dedicated API that meets performance, functional, and data parity with their customer-facing interface. They must publish quarterly availability and performance statistics, implement a consent dashboard, support extended payment initiation functionality (standing orders, future-dated payments, multi-beneficiary payments), and ensure that none of the twelve prohibited obstacles listed in the regulation are present in their open banking implementation.

Is Verification of Payee mandatory under the PSR?

Yes. VoP is mandatory for all credit transfers. For euro credit transfers, the requirement comes from the Instant Payments Regulation. The PSR extends the same framework to non-euro credit transfers. The service must be free of charge and provided before the payer authorises the transaction. PSPs that fail to provide the service or provide it incorrectly are liable for resulting losses.

The Payment Services Regulation (PSR) is a directly applicable EU Regulation that replaces the conduct-of-business rules currently set out in PSD2. Unlike a Directive, it applies identically across all EU Member States without the need for national transposition. It covers fraud prevention, liability, open banking, SCA, Verification of Payee, and transparency requirements for payment services.

The PSR applies 21 months after entry into force. Based on an expected publication in the Official Journal in the second half of 2026, general application is estimated around the end of 2027 or early 2028. The Verification of Payee provisions apply six months later, at the 27-month mark.

The PSR is a Regulation covering the conduct of business: rights and obligations of PSPs and users, fraud prevention, open banking rules, SCA, and transparency. PSD3 is a Directive covering the authorisation and supervision of payment institutions and electronic money institutions, which Member States must transpose into national law. Together they replace PSD2.

No. The PSR removes the obligation to maintain a permanent fallback interface. The dedicated API is the sole access channel for AIS and PIS providers. In exchange, the API must meet strict performance and data parity requirements equal to those of the bank’s own customer-facing interface.

The PSR introduces a consumer refund right where a fraudster impersonates the consumer’s own PSP using the PSP’s attributed communication channels (phone number, email, website, mobile application) and the consumer makes a payment as a result. The PSP must refund the full amount unless it can demonstrate that the consumer acted fraudulently or with gross negligence. The scope covers PSP impersonation only and does not extend to investment scams, romance fraud, or impersonation of other entities.

ASPSPs must provide customers with a dashboard integrated into their own interface to monitor and manage TPP data access consents. The dashboard must display the TPP name, account, purpose, validity, data categories, and access dates. It must allow withdrawal and re-establishment of consents within a 48-hour window. The dashboard must not contain deterring language or be designed in a way that discourages the use of TPP services.

Both the payer’s and the payee’s PSP must operate transaction monitoring mechanisms. The payer’s PSP monitors before execution; the payee’s PSP monitors before making funds available. Where a PSP fails to apply monitoring and a fraudulent transaction occurs, that PSP bears the financial loss. The EBA will develop detailed technical standards specifying the monitoring requirements.

Banks must operate a dedicated API that meets performance, functional, and data parity with their customer-facing interface. They must publish quarterly availability and performance statistics, implement a consent dashboard, support extended payment initiation functionality (standing orders, future-dated payments, multi-beneficiary payments), and ensure that none of the twelve prohibited obstacles listed in the regulation are present in their open banking implementation.

Yes. VoP is mandatory for all credit transfers. For euro credit transfers, the requirement comes from the Instant Payments Regulation. The PSR extends the same framework to non-euro credit transfers. The service must be free of charge and provided before the payer authorises the transaction. PSPs that fail to provide the service or provide it incorrectly are liable for resulting losses.

Share article on social media