Securing the whole payment journey: fraud prevention in the PSD3/PSR era

How PSD3/PSR is rewriting fraud prevention and what banks must build in the next 24 months. An exclusive conversation with Susann Gäbler, Head of Risk Steering Fraud (Abteilungsdirektorin | Prokuristin), Openbank Deutschland.

 

Susann, could you please introduce yourself and share more details about your professional background and your role at Openbank Deutschland?

Of course. I’m a risk executive with more than 20 years of experience in the banking industry, including 17 years in leadership positions. Throughout my career, I have focused on transforming risk and fraud functions into data-driven, scalable organisations that not only ensure effective risk management but also support the business. My professional expertise covers fraud prevention, credit risk steering, governance, and operating model transformation. Over the past three years, I have concentrated on building effective and scalable fraud prevention capabilities across different portfolios and payment channels.

In my role at Openbank Deutschland (formerly Santander Deutschland), I bring together strategic risk management, data-driven decision-making, and organisational transformation. My aim is to strengthen fraud prevention while creating solutions that are pragmatic, sustainable, and effective within a highly regulated banking environment.

How did PSD2 fall short of what Europe's next phase of payments regulation requires?

Regarding fraud prevention, PSD2 did not fall short; it was simply designed for an earlier generation of payment fraud. 

At the time, introducing Strong Customer Authentication as a central fraud-prevention measure proved highly effective in reducing fraud based on stolen credentials and unauthorised access. And it continues to be effective for this type of fraud. But as patterns evolve – and they always do - securing the authentication event alone is no longer sufficient. The focus needs to be extended to the entire payment journey. With the shift towards social engineering and impersonation, the customer may technically authenticate and authorise the payment, while the underlying consent has been manipulated. With this development, the assumption was disproved that if authentication is strong, the payment is broadly secure. Consequently, the binary distinction between authorised and unauthorised gets increasingly difficult and authorisation-based liability models are becoming too narrow.

In a nutshell, PSD2 successfully strengthened the front door through SCA; the next phase must secure the whole payment lifecycle, taking the complexity of advanced social engineering-based fraud patterns into account. This means that aspects like behavioural monitoring, payer- and payee-side controls, cross-sector information exchange, and accountability for failures across the fraud chain need to be tackled.  

What commercial and regulatory gaps are PSD3 and PSR intended to address?

From a commercial perspective, the focus clearly lies on Open Banking and the creation of a more reliable and investable environment. This is an important topic in promoting fair competition and a level playing field.  But as a fraud responsible, my focus quickly moves towards the regulatory aspects the new framework is addressing, which is the fraud topic itself as a major gap.

The separation between PSD3 and the PSR also creates a clearer regulatory framework: PSD3 focuses on authorisation and supervision, while the PSR sets out the relevant conduct-of-business rules, rights and liabilities in a directly applicable regulation, limiting scope for divergent national interpretation.

Against that background, the PSR moves beyond an authentication-centred model towards end-to-end fraud prevention. It adds elements such as verification of the payee, transaction monitoring by both the payer’s and the payee’s PSP, the suspension or return of suspicious payments, targeted reimbursement rights, stronger evidentiary requirements, customer interaction, and wider fraud-information sharing within the banking network.

But it also acknowledges that payment fraud often starts outside the regulated banking perimeter. Modern fraud chains involve payment initiation providers, technical service providers, wallet operators, telco networks, hosting providers and online platforms. The PSR therefore also allocates duties and, in some cases, liability more broadly across that ecosystem, including cooperation and information-sharing requirements involving telecom providers and major online platforms.

In which areas do banks and fintechs remain underprepared? What should institutions prioritise over the next 24 months? 

I think it’s difficult to come up with a uniform assessment of how prepared banks and fintechs are, because the starting point in payment fraud prevention varies significantly across market participants.

That said, I see two areas as particularly challenging over the next 24 months: transaction monitoring and data sharing. Both are not just technology projects; they also require a significant shift in culture, mindset, and skillset.

On transaction monitoring, institutions already have experience in monitoring outgoing payments, although the maturity level varies considerably – for example, in the extent to which device intelligence or behavioural and biometric data is incorporated. The much bigger challenge, however, will be monitoring incoming payments. This is a fundamentally different concept from traditional transaction monitoring to detect money laundering activities. Existing AML infrastructure is unlikely to be sufficient for the requirements of instant payments, where fraud decisions have to be made within seconds. Institutions will need a very different approach, combining real-time data, behavioural signals, and highly automated decision-making.

The second major challenge will be data and information sharing. There is already a long tradition of cooperation and information sharing between banks. The challenge now is to make external fraud intelligence available and actionable in realtime and on a transaction-by-transaction basis, while integrating it into existing infrastructures in a GDPR compliant way. The involvement of telcos and online platforms could add significant value, because they possess data and signals that banks do not have. But this will also make the challenge considerably harder. There is very little established history of sharing fraud intelligence across these sectors, so the issue is not only technological and legal – it also requires a cultural shift towards proactive cooperation in the interests of the wider ecosystem.

So, over the next 24 months, I would prioritise building truly real-time fraud monitoring capabilities on both sides of the payment, and establishing the technical, legal, and organisational foundations for effective cross-industry fraud intelligence sharing.

Banks typically point to two different types of pain: the cost of operational transformation and the cost of regulatory uncertainty. Which is actually the bigger challenge right now, and why?

From my perspective, the bigger challenge right now is the cost and complexity of the operational transformation itself. The costs associated with online banking fraud – beyond the direct financial losses – have already become so significant that banks have little choice but to transform their fraud functions and processes. The business case for transformation exists independently of the PSD3/PSR regulatory update. In many respects, the industry’s homework is already clear.

That said, I do think the regulatory changes can act as an additional accelerator. The expansion of liability and the broader scope of the regulatory framework can help accelerate the transition in two areas in particular: external fraud-data sharing and the provision of the necessary internal investments in technology, processes, and people.

Currently, it can be observed that reputational and operational costs do not always translate into the same level of investment urgency. A concrete increase in the operational risk budget resulting from reimbursement liabilities – together with the corresponding implications for an institution’s capital requirements – tends to create a much stronger investment case.

The Level 2 measures, the EBA's Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS), have not yet been published and will not be finalised until after the PSD3 and PSR texts are formally adopted and published in the Official Journal. Firms should anticipate the new regime taking effect around late 2027, with the Level 2 measures following to shape detailed compliance requirements.

At this Level 1 stage, what remains unclear? What are you having to make assumptions about rather than simply waiting for regulatory guidance?

Ironically, the good news is that firms already have a lot to do based on the Level 1 text. Many of the core capabilities will be required regardless of the final Level 2 details.

For example, firms need to build real-time transaction monitoring for both outgoing and incoming payments and integrate it with legacy core and payment systems. The same applies to cooling-off and suspension mechanisms across the relevant customer journeys. Given the challenges many banks have already faced with implementing the Instant Payments Regulation, making these additional functions available in real time will require significant technical effort.

Firms also need to build the architecture to orchestrate internal data and transaction-level information from other PSPs and turn that into fraud decisions. These capabilities can already be designed and implemented in a modular and flexible way.

The bigger uncertainty is around cooperation with telcos and platforms. Before technical standards and data protection requirements can even be finalised, there needs to be a common understanding of how this cross-sector information sharing should work.

And finally, customer communication, claims handling and reimbursement processes need to be redesigned end-to-end. For that, firms do not need to wait for detailed Level 2 guidance either – including on how gross negligence will be defined in detail.

Where do you see the gap between what the legislative text requires and what can realistically be built within existing core banking infrastructure? Is there any requirement in the current draft that you believe is technically unrealistic within the proposed timeline? 

This depends to some extent on the starting point of each individual institution. However, banks that start off with a batch process-based AML monitoring, with no data points such as device or behavioural data available in their payment journey, and with legacy systems already reaching their limits when implementing the Instant Payments Regulation will certainly face significant challenges in meeting the timeline.

And I do not see this as a purely technical implementation challenge. Institutions will also need to build the necessary skills and capabilities to develop and operate these real-time monitoring models, calibrate thresholds and rules, and keep false-positive rates at an acceptable level.

Beyond that, it requires a mindset shift: towards scalable, data-driven fraud prevention that is deeply integrated into the customer journey, not considered as a separate control function, but as an integral part of the customer experience and, ultimately, a business enabler.

PSR requires behavioural transaction monitoring to detect and prevent fraud, yet GDPR's purpose limitation and data minimisation principles can work against the creation of persistent behavioural profiles. Where do you draw the line between the behavioural data that can legitimately be retained for fraud prevention and what GDPR might consider excessive collection? 

For me, having spent many years in credit risk management in an IRBA environment, this trade-off between purpose limitation, data minimisation and the need for sufficiently predictive models is very familiar. It is simply part of the homework to be done in model development and governance.

I certainly would not claim that these discussions are always easy. In fraud prevention, the debate can quickly be reduced to the slogan “data protection means fraudster protection”. But I think this is the wrong framing. If fraud and data protection functions engage with each other as equal partners and take each other’s mandates seriously, it is possible to find a good balance in the interests of the customer.

For the fraud function, that also means being able to demonstrate clearly which data fields are actually relevant to the model or ruleset and that they perform to a high standard, including being free from material bias and discrimination. In automatised payment transaction monitoring, the tolerance for false positives is extremely low, which almost automatically raises the standards the model has to meet. This again makes it possible to test and demonstrate quite well that individual characteristics are not driving discriminatory outcomes.

And finally, I think the benefits of building comprehensive behavioural profiles of individual customers are often overstated. Focusing instead on specific fraudster profiles and fraud patterns can provide an effective basis for preventing fraudulent payments and, at the same time, help to mitigate some of the data protection concerns associated with extensive customer profiling.

PSR's fraud information-sharing arrangements between PSPs require a DPIA and, in some cases, prior consultation with supervisory authorities before data sharing can begin. In practice, does this consultation requirement risk creating a bottleneck that is incompatible with real-time fraud prevention? How do you reconcile real-time payment decisions with compliance processes that were not designed to operate in real time? 

I do not think the current approach is fully compatible with real-time fraud prevention. This is also one of the reasons why, for incoming payment monitoring, we cannot simply rely on the infrastructure, experience and processes used by compliance functions for AML monitoring. While the two areas may appear closely related, AML processes are generally not designed for real-time decision-making, and the compliance function also has a fundamentally different mandate from fraud prevention.

I therefore expect the Level 2 framework to provide further specifications, particularly for recurring scenarios and high-volume processing. Ideally, there should be mechanisms that allow the necessary DPIA and regulatory requirements to be addressed upfront, so that individual real-time fraud decisions do not become dependent on a separate compliance process during day-to-day operations.

If a payment is declined "to protect the customer" based on behavioural anomaly detection, and that customer later argues that an automated decision was made without sufficient human review under GDPR

Article 22, where does liability ultimately sit? Does liability rest with the bank, or does PSR provide any protection or carve-out that would override such a challenge?

I see this as largely a theoretical discussion, at least in the case of instant payments. According to ECB data, instant payments already account for roughly one third of credit transfers in Europe, and the share is likely to continue to increase. Since an instant payment has to be settled within 10 seconds, a meaningful human review before execution is simply not feasible. I also do not think it would make sense for institutions to build fundamentally different fraud decisioning processes for instant and non-instant SEPA payments.

Banks have strong expertise in developing and calibrating fraud models, and false positives are already an important performance metric in fraud prevention. If a model is demonstrably calibrated to an appropriate level of false positives and this is consistently monitored through robust model governance, I believe institutions can make a strong case that automated intervention is proportionate and justified.

Ultimately, I would expect the focus to be on whether the overall decisioning framework is appropriately designed and governed, rather than on whether every individual transaction can be subject to human review. As long as customers are not subject to frequent or inexplicable payment blocks, I would also expect the risk of customer complaints to remain manageable. In my experience, customers generally respond positively when payment controls are transparently communicated and clearly aimed at protecting them.

That said, I would not interpret this as meaning that GDPR Article 22 simply does not apply. The key question is how the automated decisioning process is designed, what legal basis and safeguards apply, and how institutions reconcile those requirements with the operational reality of instant payments.

Regulatory conflicts are often resolved informally long before they are addressed through courts or formal guidance. In practice, when PSR's fraud prevention obligations and GDPR's data minimisation requirements point in opposite directions, who ultimately makes the decision within the bank: compliance, risk, legal, or the Data Protection Officer? Has this internal decision-making process already been tested in practice, or does it remain largely theoretical?

Banks are very familiar with the concept of checks and balances. They have always had to balance business interests with the perspectives and requirements of their control functions to come up with well-balanced decisions. So I would not see this as a completely new or theoretical decision-making process. The key is that the different functions understand and respect each other’s mandates, and that the institution ultimately finds the best balance in the interests of both customer protection and the protection of the institution.

I also would not frame this as a question of compliance versus risk versus legal versus the DPO. The underlying principle should be that the institution takes all applicable requirements seriously and addresses them to the greatest extent possible. Where those requirements genuinely come into tension, it becomes a matter of prioritising the risk remaining. This will most likely be a top management consideration and the outcome may differ between institutions, depending on their fraud landscape, business model, risk appetite and existing infrastructure.

And just to add another layer of complexity, I would even add one more stakeholder to the discussion: the product and sales function. Fraud prevention measures – particularly deliberate friction in the customer journey – can have a direct impact on conversion and customer experience. These commercial considerations also need to be part of the overall balancing exercise as institutions operate in a competitive environment.

About Susann Gäbler

Susann Gäbler is a Risk & Fraud Executive with more than 20 years of experience in banking, including 17 years in leadership roles. She is known for turning risk and fraud functions into effective business enablers. Her expertise spans fraud prevention, credit risk steering, governance and operating model transformation, with a particular focus over the last three years on building data-driven, scalable fraud prevention capabilities across portfolios and payment channels.

 

 

About Openbank

Openbank in Germany is one of the large private banks in Germany and offers customers a comprehensive range of financial services across various channels. Whether online, via video consultation, or in person at a branch, Openbank provides a broad portfolio of services and products, ranging from current accounts and credit cards to securities and investment services. In Germany, the bank is the largest manufacturer-independent provider of mobility financing. The wholly owned subsidiary of Spain’s Banco Santander is headquartered in Mönchengladbach. For more information, please visit www.santander.de.