PSD3 and PSR: Why Fraud Protection Must Be an End-to-End Customer Process

Author: acceleraid Redaktion | 20 August 2026

For banks, the discussion about PSD3 and the Payment Services Regulation (PSR) starts with a timing question. The European Commission put forward the two proposals on 28 June 2023. Parliament and Council reached a provisional political agreement on 27 November 2025, and the text agreed in the interinstitutional negotiations was approved by the ECON Committee on 5 May 2026. Formal adoption by Parliament and Council is still required before the deal can enter into force. European Parliament: Legislative Train Schedule

That distinction is operationally important. The new fraud-protection mechanisms described in the agreed text must not be presented as PSR or PSD3 duties that already apply. Programmes, customer communications and control evidence need to keep current law separate from the prospective framework. Some rules do already apply: PSD2 has applied since January 2018, and its strong customer authentication requirement has applied since September 2019. The Commission also records that, from October 2025, payment service providers in the euro area are required to enable clients to send euro instant payments and verify the intended beneficiary. European Commission: Payment services

The provisional agreement is still useful for operating-model design. It points to a chain rather than a single fraud-control event: prevention and warning, transaction checking, informed customer action, hold or block, case hand-off, possible reimbursement, and feedback into prevention and service. Treating those stages as separate systems creates conflicting messages and fragile hand-offs. Designing them as one customer process creates a sound foundation without claiming that a future legal requirement is already in effect.

Start with legal status, then design the target state

The agreed PSR text places payment services and certain supporting technical service providers in a more harmonised framework, while PSD3 addresses matters including authorisation and supervision. On fraud, the political agreement describes checking whether a payee’s name and unique identifier match; refusing the payment order and informing the payer when they do not; strong customer authentication; risk assessment; and spending limits and blocking measures. European Parliament: payment-services deal

These elements belong in an architecture as a potential target state, not as a current PSR checklist. The key distinction is between a requirement that applies today under PSD2 or the Instant Payments Regulation and an additional requirement described in the politically agreed PSR/PSD3 text that has not yet entered into force. Make that distinction visible in policy registers, training, customer messaging, test scenarios and management reporting.

A target state does not replace case-by-case judgement. It specifies what information should be available when: transaction data and warning signals before release, authentication status at consent, an immutable timeline for the case, and traceable criteria for escalation, hold or communication. The bank can then evidence both what happened technically and what the customer saw or confirmed.

Make warning and transaction checking one decision point

In the agreed text, the check of the payee’s name and unique identifier has a clear proposed consequence: where there is a discrepancy, the payment service provider should refuse the payment order and inform the payer. The process lesson is straightforward: checking and explanation should not be separated. A warning that appears only after the journey has stopped is less useful than clear information at the decision point. European Parliament: payment-services deal

This matters particularly in digital journeys. A team should not only store that a rule fired. It should be able to show which version of a warning was delivered in which channel, which transaction it concerned, and whether the journey was abandoned, refused or routed to further review. That is a design principle for accountable customer interaction, not a claimed statutory wording.

Strong customer authentication should not sit in a separate security lane. It is part of the same moment: the customer should understand what they are consenting to, and the system needs an unambiguous connection between the authentication, the transaction and the risk context. The current framework already includes strong customer authentication; the PSR agreement additionally describes risk assessment and further prevention mechanisms. European Commission: Payment services European Parliament: payment-services deal

From consent to hold: explicit states, not silent hand-offs

The politically agreed text refers to spending limits and blocking measures to reduce fraud risk. It also says the receiving payment service provider should freeze a transaction it identifies as suspicious. Those are statements about a text that is not yet formally adopted, not obligations already imposed by an applicable PSR. European Parliament: payment-services deal

Operationally, that supports explicit states rather than a generic “fraud hold”. Useful business states might include warning displayed, authentication pending, order refused, payment on hold, case opened, counterparty informed, and decision pending. These are conceptual labels, not legal classifications. Their value is that the digital interface, contact centre, fraud team and complaints operation see the same status and can explain the next step consistently.

A suspected fraud event should not end the customer experience with an automated block. The process needs a hand-off with context: transaction reference, timestamps, warning and authentication events, contact history, reason for concern and ownership. Staff need a view that does not require them to reconstruct the case across several tools. Equally, the digital journey needs to know that a case is open so it does not send a contradictory confirmation or promotion.

Treat reimbursement as a case decision, not a back-office payment

The agreed text differentiates several scenarios. If a fraudster initiates or changes a transaction, it would be treated as unauthorised and the payment service provider would be liable for the full fraudulent amount. For impersonation fraud, in which a fraudster pretends to be a payment service provider employee and persuades a customer to approve a payment, the text describes a full refund provided that the customer reports the fraud to the police and informs the provider. European Parliament: payment-services deal

For that reason, a possible reimbursement should not be designed as an isolated back-office posting. It needs a case record linking the trigger, customer report, transaction status, communications, any police report and the rationale for the decision. The refund provisions just described are part of the politically agreed package that has not been formally adopted. Current cases remain subject to the rules in force and to assessment of their actual facts.

The agreement also describes possible liability of online platforms towards payment service providers if they have been informed of fraudulent content and fail to remove it after a provider has reimbursed defrauded customers. This illustrates that case handling may involve interfaces beyond the bank. A process architecture should therefore retain evidence, notifications and communication steps in a structured form, without automatically asserting a legal outcome. European Parliament: payment-services deal

Let case closure improve prevention

The political agreement also refers to human customer support and public education on avoiding fraud. Protection therefore does not stop at a rule in the payment flow. After a case closes, a bank should review which signals, warnings, hand-offs and support routes worked, and which did not. European Parliament: payment-services deal

A closed learning loop is a practical B2B operating discipline. First, cases are classified through a controlled scheme. Second, avoidable friction between app, contact centre and case handling is captured. Third, a warning, rule or work instruction is changed deliberately and versioned. Fourth, the team checks whether the change has the intended process effect without unnecessarily blocking customers. These are process-management measures, not a statement about a metric future law would require.

Governance should likewise run on two tracks. A legal and compliance track monitors the formal conclusion of PSR and PSD3 and updates mandatory controls only on that basis. A process track can improve traceability, hand-offs and customer information now where that is consistent with current law and the firm’s own risk framework. The Eurosystem supports structured cooperation among authorities and market participants against payment fraud, referring to PSD3, PSR and the AML package. European Central Bank: payments strategy

The decisive question is therefore not “PSR programme or customer process”. It is whether the bank can explain, from the first warning to case closure, which state applies, who acts, what information the customer receives, and how insights return to prevention. That end-to-end design is a sensible management task today. Being well prepared does not make it law already in force.

Illustration: AI-generated. AI-assisted content: We use AI technologies and automated agents in the creation of our articles, including from Microsoft, Google, OpenAI, Anthropic and other providers. Topics, editorial direction and final approval remain with our team.