PSR: Plenty of time on paper – little time in practice
The Payment Services Directive 3 (PSD3) and the Payment Services Regulation (PSR) are nearing finalisation, even though the timetable has recently been pushed back by a few months once again: We expect the legislation to be adopted in December 2026 – with publication in the Official Journal of the EU in January 2027. There will then be a 21-month period before the vast majority of PSR requirements come into force. One might think that is sufficient time for a „update“ to PSD2.
However, it would be disastrous to wait any longer – for instance, until the new EBA RTS are published (by January 2028 at the latest) and all the details that are still outstanding have been clarified. The PSR introduces a number of requirements that are fundamentally new – and anything but trivial. Three examples:
Example 1: Transaction monitoring – from the RTS standard to a liability-backed obligation
Current setup under PSD2: To date, the fundamentals of transaction monitoring have largely stemmed not from PSD2 itself, but from the Regulatory Technical Standards on Strong Customer Authentication (SCA-RTS). Monitoring serves primarily to support SCA and to enable risk-based exemptions (TRA). It is essentially designed with the payer in mind; there is no explicit obligation for the payee’s PSP (Payment Service Provider). There is also no explicit provision regarding liability for failure to monitor transactions, nor is there a clearly defined, exhaustive list of permissible data categories to serve as the basis under data protection law.
What the PSR changes: The PSR establishes the monitoring obligation at the level of the basic legal act and extends it in several respects:
- Obligation on the part of the payee (Art. 83(1a)): The payee’s PSP must monitor incoming payments before crediting them – a completely new obligation, designed in particular to combat ‘mule accounts’.
- Explicit liability: If monitoring is not carried out and the payer suffers loss as a result, the PSP concerned is directly liable – a liability provision that did not exist in this form under PSD2.
- Distribution of the burden of proof: In the event of a dispute, the payer’s PSP must prove that monitoring took place on both sides – i.e. also at the payee’s PSP. If this evidence is lacking, the amount must be refunded.
- Mandatory exchange of fraud data (Art. 83a): In future, PSPs must exchange fraud data with other PSPs in a structured manner, including an obligation to carry out a data protection impact assessment and, where necessary, to consult the supervisory authority in advance.
- Closed list of data categories: For the first time, the PSR explicitly lists which data categories may be processed for monitoring purposes – this creates legal certainty, but also requires an audit of existing monitoring engines against this list.
The gap: Banks whose monitoring is currently focused primarily on the payer side and on SCA support require additional monitoring logic on the payee side, robust verification processes vis-à-vis correspondent PSPs, and a data infrastructure for the exchange of fraud data – including the associated data protection governance.
Example 2: Liability – from a single framework to three parallel regimes
Current setup under PSD2: Liability for payment transactions currently follows, in essence, a single track: the unauthorised transaction (PSD2 Articles 73/74). In cases of suspected fraud or gross negligence, the PSP must demonstrate ‘reasonable grounds’ and report these to the competent authority.
What the PSR changes: In addition to the modified framework for unauthorised transactions, two entirely new, parallel liability regimes are introduced:
- Liability for errors in payee verification (Art. 57): If payee verification fails and this leads to an erroneous execution, the payer’s PSP must reimburse the payer without delay – and subsequently seek compensation from the PSP responsible for the error.
- Identity fraud/spoofing (Art. 59/60): If a fraudster impersonates a consumer’s PSP (using a fake domain, telephone number or email address) and the customer is thereby induced to make an authorised but fraudulently induced payment, the PSP must refund the full amount – provided that the customer has reported the incident immediately to both the PSP and the police.
Each of these frameworks has its own trigger conditions, its own time limits (often, but not consistently, 15 business days), its own rules on the burden of proof and its own dispute resolution pathway. In future, the framework agreement must set out all three liability regimes separately – previously, a reference to a single standard was sufficient.
The gap: What is currently a single dispute resolution process with a single decision-making logic will become three parallel processes, each with different burdens of proof, different time limits and different escalation procedures. This affects fraud teams, the legal department, customer service and contract drafting in equal measure – it is not merely a matter of adapting existing forms.
Example 3: Open Banking – from an optional to a mandatory interface
Current setup under PSD2: Under the SCA RTS, account-holding payment service providers could choose between two options: a dedicated interface or a customised customer interface. In addition, there was an automatic fallback mechanism: if the dedicated interface failed repeatedly (typically defined by thresholds such as multiple failed access attempts within a short period), AISPs and PISPs were permitted to fall back to the customer interface. At the same time, technical standards in the market define how many details of the RTS are to be interpreted, relating, for example, to availability, security standards, the provision of data and the rights of PSPs.
What the PSR changes: The PSR makes the dedicated interface mandatory at the level of the basic legal act; the alternative of the adapted customer interface is no longer available as a general option. At the same time, the automatic RTS fallback is significantly restricted: the automatic switch to the customer interface in the event of technical faults is no longer provided for in its previous form; access via ‘another secure and efficient interface’ is now only permitted in exceptional cases. In addition, stricter and new obligations apply: logging with a three-year retention period, specification of the payment initiation options offered (standing orders, scheduled payments, payments to multiple recipients) or stricter restrictions on maintenance windows and the documentation of usage statistics. Perhaps the most far-reaching change is the Consent Dashboard, which allows customers to manage TPPs’ active access permissions at any time.
The gap: Banks that currently rely on the adapted customer interface or the traditional RTS fallback must rethink their strategic approach: either to develop a fully-fledged, dedicated interface with the extended PIS capabilities, or to submit a robust application for the more narrowly defined exemption – including the additional logging and dashboard obligations. Both options involve significant technical and organisational lead times, rather than a short-term configuration change. The main drivers of this effort are the numerous detailed adjustments required across the interface, processes and the customer interface, the costs of which can quickly mount up.
A colourful bouquet of topics, not a single measure
The three examples – transaction monitoring, liability and open banking – do not stand alone. Rather, they are excerpts from a whole range of topics that the PSR brings together: new data flows for the exchange of fraud data, new burdens of proof and documentation requirements, new interface requirements, new deadlines for customer communication, and new guidelines for training and governance. Every single element in this range affects different systems, different processes and different organisational units – from fraud and risk management, through legal and IT, to customer service and product management. This is precisely where the real complexity lies: not in a single demanding requirement, but in the number of departments within the bank that must make changes simultaneously, without there already being a well-rehearsed plan in place.
The phased timetable tends to exacerbate this effect rather than mitigate it: whilst the first EBA requirements will be finalised after just twelve months, system development, process design and organisational coordination will continue in parallel – and the additional six months for VoP show that even the regulator considers the lead time for setting up new infrastructure to be tight.
Why now is the right time
This is precisely why it is worth viewing this perceived breather not as such, but as an opportunity to carry out gap analyses against the current PSD2 setup, to identify and quantify the most important sets of measures, and to plan the implementation project(s) with the involvement of all affected departments. The detailed design phase should also begin before the RTS are published – even if this means working with a ‘moving target’ in some areas.
Furthermore, the PSR should not be viewed in isolation. The interplay with eIDAS 2.0 and the EUDI wallet is particularly evident, but there are also points of contact with the new EU Anti-Money Laundering Regulation. In addition, the PSR offers the opportunity to combine obligation with opportunity and, when upgrading systems and processes, to incorporate strategic objectives that go beyond regulatory requirements.
How we can help
We have already supported banks through precisely this kind of assessment – from a structured gap analysis against their existing PSD2 setup, through cross-functional impact workshops, to a prioritised, actionable roadmap. The complexity of the PSR is very real, but it can be managed effectively with the right structure and the right starting point.
The most valuable step this quarter: gaining a clear picture of just how extensive the range of issues within your own organisation actually is – and where the biggest gaps lie. It’s worth having this discussion now, whilst there is still time to act on the findings.
