PSD3 and PSR: Why fraud protection must be thought of as an end-to-end customer process

Author: acceleraid Editorial Team | August 20, 2026

The debate about PSD3 and the Payment Services Regulation (PSR) is primarily a question of correct timing for banks. The European Commission presented both proposals on June 28, 2023. Parliament and Council reached a provisional political agreement on November 27, 2025; the text agreed in the interinstitutional negotiations was approved in the ECON Committee on May 5, 2026. However, the agreement still needs to be formally adopted by Parliament and Council before it can enter into force. European Parliament: Legislative Train Schedule

This is not a conceptual subtlety. The new protective mechanisms described in the agreement text are not to be treated as already applicable PSR or PSD3 obligations. Current law and the future legal framework must remain separated in program planning, customer communication, and control records. At the same time, rules are already applicable: PSD2 has been in force since January 2018; the requirement for strong customer authentication has applied since September 2019. For payment service providers in the Eurozone, the Commission has also specified since October 2025 the obligation for customers to be able to send instant Euro transfers and for the intended payee to be verified. European Commission: Payment services

Nevertheless, the content of the political agreement is valuable for operational design. It does not describe an isolated fraud protection step, but rather a chain: prevention and warning, transaction verification, conscious action by the customer, security or block, case handling, possible refund, and feedback of insights into prevention and service. Those who operate these stations as separate systems risk contradictory information and unclear handovers. Those who design them as a customer process create a resilient foundation – without anticipating what will legally apply in the future.

First the Legal Situation, then the Target Image

The agreed PSR text integrates payment services and certain supporting technical service providers into a more harmonized framework; PSD3 concerns, among other things, licensing and supervision. For fraud protection, the political agreement describes, among other things, matching the name and unique identifier of the payee, rejection and information in the event of discrepancies, strong customer authentication, risk assessment, as well as spending limits and blocking measures. European Parliament: Agreement on payment services

These points should be maintained in the architecture as a potential target image, not as a current PSR checklist. Particularly important is the separation of two statements: A requirement may apply today under PSD2 or the Instant Payments Regulation; another requirement may be in the politically agreed PSR/PSD3 text but not yet in force. This separation belongs in policy registers, training, customer notices, test cases, and management reporting.

A good target image also does not replace a case-by-case decision. Rather, it determines what information must be available at what time: transaction data and warning signals before approval, authentication status at the consent step, an unalterable timeline for the case, and comprehensible criteria for escalation, blocking, or communication. This ensures that it remains demonstrable later what happened technically and what the customer saw or confirmed.

Warning and Transaction Verification as a Cohesive Moment

The matching of the name and unique identifier of the recipient is linked to a clear consequence in the agreed text: in the event of a discrepancy, the payment service provider should reject the payment order and inform the payer. For process design, a simple principle follows from this: verification and explanation must not fall apart. A warning that only appears after the process has been aborted is less helpful for the customer process than comprehensible information at the decision point. European Parliament: Agreement on payment services

This is especially true for digital journeys. A team should not only save whether a rule was triggered. It should also be able to document which version of a warning was displayed in which channel, to which transaction it referred, and whether the process was aborted, rejected, or guided into further verification. This is not a claimed legal wording, but a design principle for comprehensible customer interaction.

Strong customer authentication does not belong in a separate security channel. It is part of the same moment: the customer should be able to understand what the consent refers to; the system needs a clear link between approval, transaction, and risk context. The current legal framework already includes strong customer authentication. The PSR agreement text additionally mentions risk assessment and other prevention mechanisms. European Commission: Payment services European Parliament: Agreement on payment services

From Consent to Block: Clear States Instead of Silent Handovers

The politically agreed text provides for spending limits and blocking measures to reduce fraud risks. It also describes that the receiving payment service provider should freeze a transaction it identifies as suspicious. These are also statements about the text that has not yet been formally adopted, not about an already applicable PSR obligation. European Parliament: Agreement on payment services

Operationally, this speaks for clearly named states instead of a generic "Fraud Hold". Examples of functional states are: warning displayed, approval still pending, order rejected, payment stopped, case opened, counterparty informed, and decision pending. The terms are conceptual; they are not intended to replace legal categories. Their benefit lies in the fact that the digital interface, contact center, fraud team, and complaint management all see the same status and can consistently explain the next step.

In case of suspicion, the customer experience must not end with an automatic block. The process needs a handover with context: transaction reference, timestamp, warning and authentication events, contact history, risk reason, and responsibility. Employees need a view that does not require merging multiple systems first. Conversely, the digital path must know that a case is open so that it does not display contradictory confirmations or advertising.

Refund as a Case Decision, Not as a Downstream Payment Process

The agreement text differentiates several scenarios. If a transaction is initiated or modified by a fraudster, it should be considered unauthorized; the payment service provider would be liable for the entire fraudulent amount. In the case of identity fraud, where a perpetrator poses as an employee of a payment service provider and has a payment approved, the text describes a full refund, provided the customer reports the fraud to the police and the payment service provider. European Parliament: Agreement on payment services

For this very reason, a potential refund should not be planned as an isolated back-office booking. It needs a case file that brings together the incident, customer report, transaction status, communication, police report if applicable, and reason for decision. The refund rules mentioned are part of the politically agreed, not yet formally adopted package. For current cases, the respective applicable requirements and the concrete assessment of facts remain decisive.

The agreement text also provides for a possible liability of online platforms towards payment service providers if they were informed about fraudulent content and do not remove it after a payment service provider has refunded damaged customers. This highlights that case handling can have interfaces beyond the bank. A process architecture should therefore keep evidence, reports, and communication steps structured without automatically claiming a legal consequence. European Parliament: Agreement on payment services

Case Closure Provides the Material for Better Prevention

The political agreement also mentions human customer support and public education on fraud prevention. This makes it clear: protection does not end with a rule in the payment flow. After a case is closed, the bank should review which signals, warning texts, handovers, and support paths worked – and which did not. European Parliament: Agreement on payment services

For a B2B operating model, a closed learning loop is recommended. First, cases are classified according to a controlled schema. Second, avoidable friction between the app, call center, and case handling is captured. Third, the warning, rule, or work instruction is targetedly modified and versioned. Fourth, it is verified whether the change has the intended effect in the process without unnecessarily blocking customers. These are process management measures, not a statement on what metric future law might require.

Governance should also run in two tracks. A legal and compliance track monitors the formal completion of PSR and PSD3 and only updates catalogs of duties on this basis. A process track already improves comprehensibility, handovers, and customer information today where that is compatible with applicable law and the bank's own risk framework. The Eurosystem approach supports structured cooperation between authorities and market participants against payment fraud, referencing PSD3, PSR, and the AML package. European Central Bank: Payments strategy

The central decision is therefore not "PSR project or customer process". It is: Can the bank explain from the first warning notice to the closure of the case what status applies, who is acting, what information the customer receives, and how insights flow back into prevention? This end-to-end design is a sensible management task today. It does not become applicable law just because it is well prepared.

Illustration: AI-generated. AI-supported content: In creating our articles, we use AI technologies and automated agents, including those from Microsoft, Google, OpenAI, Anthropic, and other providers. Topics, professional direction, and final approval remain with our team.