Payment Services Regulation (PSR) in 2026: The State of Play for Banks

Following the political agreement reached in November 2025, the technical trilogue work on the Payment Services Regulation has been completed, with the Council and the European Parliament's ECON Committee having already endorsed the final compromise text this spring. Publication in the Official Journal is still expected in the second half of 2026, once the Parliament's plenary vote and formal adoption are complete, projecting a mandatory compliance deadline for H1 2028.

PSR Implementation Timeline

• H2 2026 (Day "D"): Entry into force (Publication in the Official Journal + 20 days).
• D + 9 months: EBA RTS on dedicated API performance and recovery times.
• D + 12 months: Major RTS package (SCA, Transaction Monitoring, Fraud statistics, exemption criteria).
• D + 15 months: Delegated act on card scheme fee transparency.
• D + 18 months: RTS on API monitoring & Guidelines on two‑inherence SCA.
• D + 21 months (Est. H1 2028): General PSR Application.
• D + 27 months (Est. H2 2028): Application of the VoP (Verification of Payee) extension.

*Assumption based on current status, and subject to change.

SCOPE

The scope of the PSR is intentionally broad, encompassing both traditional fiat and the next generation of digital assets. Notably, it will apply to:

Digital Euro

Classified as "funds" under Article 3(30) of the PSR, referencing the Proposal for a Regulation on the establishment of the digital euro (COM/2023/369). This inclusion raises significant operational questions, particularly regarding the compliance paradox we explored in our recent analysis: "The Digital Euro and the Compliance Paradox: Greater Liability with Less Visibility".

Electronic Money Tokens (EMTs)

As per Recital 29b, payment services involving EMTs (stablecoins) fall within the scope to ensure consumer protection. However, a key distinction is made: peer‑to‑peer transfers of EMTs conducted without the involvement of a financial intermediary (via self‑hosted wallets) remain excluded from the PSR’s conduct‑of‑business rules.

Furthermore, the PSR acts as the regulatory blueprint for the Financial Data Access (FIDA) framework. While the PSR’s scope is strictly confined to payment accounts and "funds," FIDA will extend this open data paradigm across the broader financial spectrum, unlocking third‑party access to investment portfolios, retirement funds, and savings accounts. Although FIDA negotiations are currently on hold, the PSR’s "Consent Dashboard" architecture is engineered to be the exact foundation upon which this comprehensive Open Finance ecosystem will potentially be built.

Scope Summary per Asset and Account Type

State of Play

Here is the exact state of play regarding obligations, impacts, and the immediate element of reflection you need to focus on.

1. Fraud Prevention: Transaction Monitoring as the Liability Pivot (Art 82,83)

The PSR redesigns the distribution of responsibility across the payment chain. The core premise remains based on a strict liability shift: Payment Service Providers (PSPs) have more means to prevent fraud than consumers, and they must prove they have used them.

Monitoring as a Direct Liability Trigger: Under PSD2, transaction monitoring was a SCA component. Under the PSR, it is a strict standalone legal requirement. The payer’s PSP must monitor prior to execution; the payee’s PSP must monitor before making funds available. If the monitoring fails and fraud is executed, the PSP bears full financial liability.

Incoming Funds Intervention: The PSR introduces a two‑tier mechanism. If the payee's PSP has "objectively justified reasons to suspect" fraud, it may block the funds. If the evidence is "clear and incontrovertible," blocking the funds becomes mandatory.

The Inter‑Bank Recourse: If your client sends funds and the receiving bank ignores obvious fraud signals, you can legally demand that the receiving bank absorbs the financial loss.

2. The "Spoofing" Refund Right & Cross‑Sectoral Offensive (Art 59)

The PSR creates a specific refund right for consumers manipulated by a fraudster impersonating their own bank's communication channels (phone, email, app).

1. The 15‑Day Rule: Once the consumer reports fraud and files a police report, you have exactly 15 business days to either refund the amount in full or provide a written, justified refusal.
2. The Burden of Proof: Successful Strong Customer Authentication (SCA) no longer constitutes proof of customer negligence. The burden of proof rests entirely on the bank.
3. The DSA (Digital Service Act) Recourse: You refund your client, but you now have the right (and the fiduciary duty to your balance sheet) to turn against Big Tech (VLOPs) or telecom operators. The law now forces them to block spoofing and fake financial ads upstream. If they fail, they must compensate your losses.

Fraud & Liability: The Refund Process

Detailed Steps – Unauthorised Transaction

Unauthorised transaction
A payment made without the customer’s consent or approval.

1. PSU reports the unauthorised transaction to the PSP (no later than 18 months after the debit date).
   PSU = Payment Service User, i.e. the customer.
2. PSP must refund by the end of the next business day, unless it has “objectively justified reasons to suspect fraud or gross negligence” by the PSU.
   PSP = Payment Service Provider, e.g. the bank.
3. If the PSP suspends the refund, it has 15 business days to investigate and must invite the PSU to explain the circumstances.
4. After investigation: Refund or refuse with specific written justification. Crucially, if refused, the bank must directly provide the customer with the contact details of the relevant Alternative Dispute Resolution (ADR) body.
5. If the PSP concludes that the PSU acted fraudulently, it must report the case to the national authority.

Note: The burden of proof remains on the PSP/PISP throughout the procedure. Correct application of SCA remains the responsibility of the payer’s PSP, even when outsourced. Crucially, a successful SCA alone no longer legally proves user authorization. To defend against liability, banks must now cross‑reference SCA with multi‑layered contextual evidence, such as behavioral biometrics or device intelligence, to validate the user's true intent.

Authorised Transaction – Spoofing Scenario

A payment approved by the customer, even if the approval was obtained through manipulation or fraud.

1. Fraudster impersonates the customer’s PSP, for example their bank, through PSP‑attributed communication channels.
2. Customer makes the payment as a result of the manipulation, then reports the fraud to the PSP without undue delay after becoming aware of it AND files a police report.
3. PSP has 15 business days to investigate from receiving both the customer notification and the police report.
4. After investigation: refund the full amount or refuse, with justification and indication of relevant ADR bodies. Refusal is only possible if the PSP has objectively justified reasons to suspect fraud or gross negligence by the customer. If fraud is confirmed, the PSP must report it to the national authority.

Note: Impersonation of authorities, investment scams or romance scams are not in scope; this only covers impersonation of the customer’s PSP.

3. Open Banking: Technical Parity, Frictionless UX and Data Control (Art 35‑42 ; 44)

The PSR structurally redefines the Open Banking framework. It forces institutions to move beyond simple interface availability to simultaneously master three operational pillars: strict performance matching between APIs and native channels, the systematic prohibition of artificial user experience friction, and a robust, GDPR‑aligned architecture for managing consent.

• Dedicated API & Performance Parity: The fallback mechanism is definitively retired. The dedicated API is now the exclusive access route, and its response times strictly cannot exceed those of your customer‑facing native apps. You will be required to publish quarterly statistics proving this technical parity.
• The 12 Prohibited Obstacles: The text explicitly blacklists 12 technical barriers to establish a strict "anti‑friction" doctrine. Any mechanism that degrades the user journey or subtly deters clients from using Open Banking, such as forcing manual IBAN inputs or imposing clunky web redirections, is now illegal.
  Banks are no longer merely required to tolerate third‑party flows; they must actively facilitate them.
• The Consent Dashboard: Long debated during negotiations as a "permission dashboard", the final text definitively locks in the term "Consent" to explicitly echo the GDPR definition. This imposes strict technical obligations: banks must engineer a natively integrated, easily accessible interface providing a real‑time and completely free of “dark patterns,” overview of all active TPP connections, allowing users to manage and revoke these consents instantly.

4. Strong Customer Authentication (SCA): The UX War (Art 85)

The PSR refines SCA to improve conversion rates while patching security holes.

• The Double Inherence Opportunity: This is a major structural shift. It is now legal to use two authentication factors of the inherence category (e.g., Facial biometrics + Behavioral keystroke dynamics), provided you can mathematically prove their independence.
• Total Accessibility: Smartphone‑only SCA is no longer legally sufficient. You must provide at least one non‑mobile strong authentication method free of charge (unless the client has explicitly signed a digital‑only contract).
• Expanded Triggers: SCA is now mandatory for enrolling cards into digital wallets, modifying spending limits, and updating contact information.

5. The Extension of Verification of Payee (VoP) (Art 50)

• The Instant Payments Regulation (IPR) mandated VoP for euro credit transfers. The PSR closes the remaining gap by extending this obligation to all credit transfers not covered by the IPR (non‑euro denominated transactions whether intra‑SEPA in another currency, or "one leg out" transactions).
• The Liability: The service must be provided free of charge before authorization. If the verification is absent or defective, the payer's PSP is liable and must refund the resulting losses without delay.
• The Opt‑Out: Flexibility is granted to non‑consumer users (B2B/Corporate), who can opt out of VoP for bulk payment flows where manual pre‑authorization verification would break automated treasury supply chains.

Conclusion: Securing the Bank's Intermediary Role

The Payment Services Regulation introduces a dense array of strict technical obligations. Rather than viewing this merely as a constraint hiding a theoretical "opportunity," banks must treat the PSR as a forced architectural reckoning. To preserve their access to customer data and maintain their core position as financial intermediaries and trust partners, institutions must rethink both their infrastructure and their client engagement models.

To secure this position, banking executives must immediately initiate critical reflections across a spectrum ranging from risk mitigation to new service paradigms:

• API Performance Benchmarking: Open banking interfaces will face extreme scrutiny. Banks must objectively measure and adjust current API latencies against native channels before public reporting mandates expose technical gaps.
• Real‑Time Intervention Capabilities: Driven by severe liability shifts, banks must upgrade their transaction monitoring engines to process, analyze, and block suspicious incoming instant payments within a strict 10‑second window.
• Vendor Liability Audits: Institutions must re‑evaluate outsourcing agreements with Technical Service Providers (e.g., digital wallets). Ensuring these contracts align with the new regulatory allocation of responsibility for authentication failures is critical for both legal protection and user experience consistency.
• The "Zero‑Click" Paradigm: As double inherence becomes legalized, banks must question their role in new authentication flows. Institutions must design fully compliant, frictionless payment journeys to systematically reclaim the user experience from third‑party digital wallets.

The Next Frontier: The Agentic Payment Conundrum

As we look beyond the immediate compliance horizon, a critical question emerges: Does the PSR actually accommodate the rise of "Agentic Payments"? What does Strong Customer Authentication (SCA) mean when there is no longer a "human in the loop" at the exact moment of purchase?

The primary friction point is dynamic linking. By regulatory design, an SCA must be strictly linked to a specific, known amount and payee. Yet, when delegating purchasing authorization to an AI agent, these variables are often undetermined at the time of human delegation. Performing a strict PSR‑compliant SCA at the moment of execution becomes structurally impossible.

How will the industry navigate this gray area? The viable pathways will likely depend on how banks and AI developers leverage out‑of‑scope mechanisms and specific SCA exemptions. While entirely non‑exhaustive, the primary avenues of reflection include:

• Merchant‑Initiated Transactions (MIT) to shift the execution out of the immediate SCA scope.
• Transaction Risk Analysis (TRA) to enable frictionless flows based on algorithmic fraud scoring.
• Trusted Beneficiaries (Whitelisting) to pre‑approve AI‑driven platforms.

Beyond these execution mechanisms, Agentic AI fundamentally relies on frictionless access to real‑time financial data to make autonomous decisions. The Open Banking interfaces mandated by the PSR are therefore not just a compliance exercise; they are the indispensable data pipelines required to power tomorrow's Machine‑to‑Machine (M2M) ecosystems.

How will banks architect this new M2M payment logic to actively secure their role as the central intermediary, guaranteeing uncompromising fraud prevention while delivering a frictionless customer experience? We will explore the mechanics and strategic architecture of Agentic Commerce in our next dedicated article.

Sopra Steria supports financial institutions in navigating this transition. Our experts are ready to accompany you in conducting a comprehensive PSR Readiness Check, auditing your current IT infrastructure, fraud monitoring capabilities, and customer journeys against the latest draft agreement, to design the exact engineering roadmap needed to turn this regulatory shift into a lasting competitive advantage.