AI-Driven Payment Fraud: Real-Time Payments Under Liability Pressure

Introduction

Consumer payments are increasingly moving in real time – and fraud is keeping pace. AI-driven social engineering is making attacks more credible, scalable, and cost-effective, whilst instant payments remove the traditional protective factor of “time” from the system. Decisions on whether to warn, delay, or block must be made before money leaves the institution – retrospective controls lose much of their effectiveness when finalisation occurs within seconds.

PSD3/PSR introduces a second driver: liability.

The European legislator explicitly addresses fraud types such as spoofing and authorised push payment fraud (APP fraud), in which attackers convincingly impersonate banks or payment service providers. This means that formally correct strong customer authentication is no longer sufficient to ward off liability risks: what becomes decisive is the circumstances under which authentication took place – and whether the institution intervened appropriately given the available signals.¹

For banks, payment service providers, and merchants, this means fraud prevention is shifting from a downstream control function to the core of value creation. It is becoming a liability-relevant, real-time decision-making capability that must be available 24/7, can be systematically documented, and operates consistently across different payment channels.

The strategic consequence is clear: real-time payments without real-time risk are not an engine of innovation, but a systemic risk. Institutions that invest now in real-time decision-making, documentable intervention logic, portfolio management, and cross-rail signal orchestration will not only reduce fraud-related losses, but also stabilise trust, customer experience, and future liability positions.

This article addresses three questions:

1. How is AI-driven payment fraud changing the fraud landscape? We show how generative AI scales social engineering attacks, orchestrates fraud scenarios, and particularly impacts real-time channels such as instant payments.
2. Why do real-time payments place payment risk under particular decisional and time pressure? We examine how instant finality, multi-rail setups, and APP fraud devalue classic protective mechanisms and create new requirements for architecture and operating models.
3. How does PSD3/PSR make fraud prevention a liability-relevant core function? We analyse the new liability logic, derive requirements for real-time prevention, and set out the capabilities that banks, PSPs, and acceptance points will need going forward.

AI-Driven Payment Fraud: From the Individual Transaction to the Orchestrated Fraud Journey

Historically, time was an ally of fraud prevention. Payment processes were batch-capable, lead times provided buffers, reversals were possible, and many control mechanisms – from rule sets to manual reviews – implicitly assumed that a meaningful time window existed between authorisation and economic finality.

This paradigm is now obsolete in the modern consumer payment environment: instant payments, wallets, P2P transfers, and push flows are shifting finality into the seconds range – decisions on release, delay, or blocking must be made before the transaction becomes irrevocable.

In parallel, the attacking side has become increasingly professionalised. Generative AI enables social engineering attacks that are highly personalised, multilingual, and context-sensitive: phishing emails, fake bank calls, and messenger chats are tested in variants, optimised, and scaled – not for revenue, but for fraud. AI-based tools generate convincingly realistic voices, manipulated documents, synthetic identities, and realistic-seeming chat dialogues that can be deployed at scale in a short space of time. This increases not only the number of attacks, but above all their quality and conversion rate.

The Europol Spotlight Report “Online fraud schemes: a web of deceit” identifies these scenarios as a central threat, highlighting in particular investment fraud, romance scams, account takeover, and money muling as core patterns of modern, division-of-labour-based process chains.²

The fraud landscape in payments has fundamentally changed in recent years. Whilst classic fraud prevention systems were long trained on patterns such as unusual amounts, geographical deviations, or card misuse, today’s practice reveals significantly greater variety and complexity. Payment fraud is no longer primarily visible in the transaction itself, but manifests in different, often upstream scenarios. Situation reports from the EBA and ECB confirm this trend: the joint “Report on Payment Fraud 2025” shows that fraud losses are increasingly shifting away from classic card fraud towards social engineering and transfer fraud – particularly in the context of instant payments.³

As a result, payment fraud is moving away from the “suspicious individual transaction” towards orchestrated fraudulent process chains. Typical patterns include: social engineering fraud, in which victims are pressured through targeted communication into making payments or disclosing their authentication credentials; impersonation attacks, in which perpetrators pose as a bank, PSP, or authority; account takeover via phishing, credential stuffing, or malware; APP fraud, in which victims authorise the payment themselves; as well as fake investment and romance scams that obscure payment flows via mules and crypto bridges. In many of these scenarios, the actual payment is merely the endpoint of a longer manipulation chain – the critical junctions occur beforehand.

From the institutions’ perspective, this makes one thing clear: classic, transaction-centric fraud systems that primarily look for unusual amounts, geographical deviations, or card misuse are no longer sufficient. Effective prevention must consider the entire process chain – from identity and onboarding through login behaviour, device and channel usage, to payee setup and disbursement logic.

This is precisely where the real lever for AI-driven payment fraud lies: attackers use AI to design and exploit these processes; institutions must use AI to better understand, secure, and make real-time decisions across those same processes.

These scenarios illustrate that modern fraud prevention must go well beyond pure transaction analysis and requires a deep understanding of the entire payment process.

Real-Time and Multi-Rail: When Seconds and Silos Become a Risk

Real-time payments were built to make money and payments faster, more convenient, and available at all times. For customers, this means convenience; for merchants, liquidity advantages and better customer experience. For fraudsters, it creates an environment perfectly suited to their business models: finality within seconds, 24/7 availability, and often still heterogeneous control logic across different rails.

The decisive difference from the “old world” lies in the time window. In a batch setup, institutions could analyse suspicious payments ex post, halt batch bookings, or negotiate reversals. Today, a decision must be made before execution – particularly with instant payments, P2P transfers, and wallet disbursements. Downstream controls still have their place for pattern recognition, model tuning, and recovery, but they lose their protective effect for the individual payment event. When transfers are finalised within seconds, the risk window shifts entirely to upstream controls and those integrated into the moment of authorisation.

Added to this: modern fraud models rarely use only a single payment channel. Cards serve as a point of entry, account takeover opens access to the account, and instant payments or wallet transfers are used as cash-out channels. The transitions between rails are particularly systemically vulnerable. Different risk engines, fragmented responsibilities, and data silos create gaps that attackers deliberately exploit: signals from the card channel do not reach the account engine in time, wallet information is not correlated with account movements, and suspicious patterns in e-commerce checkout do not feed into real-time limits. Fraud optimises itself along the weakest transition – not along the strongest individual control.

For institutions, this presents a dual challenge: on the one hand, they must make real-time decisions that are economically viable and can be defended on regulatory grounds. On the other, they need an architecture that aggregates signals from different rails in real time and evaluates them consistently. Real-time risk is therefore not a feature of individual tools, but a cross-cutting capability of the entire payment architecture – from event capture through data integration and analytics to documented intervention logic.

Real-Time Prevention: From Point Controls to a Liability-Capable Operating Function

When fraud develops along orchestrated process chains and payments are finalised within seconds, point controls are no longer sufficient. Effective real-time prevention is not another module in the payments stack, but an operating function that connects technology, processes, and governance into a coherent system – with one clear objective: to be able to make decisions on intervention or non-intervention at the moment when liability arises.

Background: The PSR bundles several real-time requirements – from updating external reference exchange rates through risk-based transaction monitoring and verification of payee (VoP), to swift intervention decisions – and thereby confronts historically grown core banking systems with their latency limitations. For many institutions, this means that existing interfaces between payments, fraud systems, and front ends are no longer sufficient to maintain regulatory latency requirements in a stable manner. Real-time prevention is therefore not only a question of intelligent models, but also one of architecture modernisation and clearly defined technical pathways for data, decisions, and actions.⁵’ ⁶

Four design principles are central:

1. Process-based rather than transaction-centric Prevention does not begin with the transaction, but considerably earlier. Relevant risk signals arise at onboarding, in login behaviour, in device and channel usage, when setting up new payee relationships, and in refund and service flows. Institutions that take real-time prevention seriously embed controls throughout the entire process chain before and during payment: strong identity and device binding, consistent anomaly detection in logins, plausibility checks for new payees, controlled refund processes, and clear rules for “high-risk journeys” – for example in investments or P2P payments.
2. Real-time decision-making capability rather than batch controls Real-time prevention requires risk decisions to be made within the same time windows in which payments are routed – that is, within seconds, not overnight. Technically, this means: event-driven architecture, low-latency scoring, predefined intervention pathways (warning, delay/hold, step-up authentication, limit adjustment), and a seamless interplay of rule-based and AI-assisted models. Examples include verification of payee as an upstream payee check, dynamic limits for new payees, or real-time warning notices for typical APP fraud patterns.
3. Documentable intervention logic rather than black-box scoring Under PSD3/PSR, it will be liability-relevant to explain why an institution did not intervene. Real-time prevention must therefore be designed so that decisions remain explainable and verifiable – even when AI models and complex rules are operating in the background. In practice, this means: every payment passes through a traceable decision logic comprising data, rules, models, and possible overrides; this logic is recorded in an appropriate form (scores, features used, rules applied, reasons for overrides). This creates the capability to demonstrate in the event of a dispute not only that authentication took place, but also that monitoring and intervention were proportionate given the available signals.
4. Integrated and adaptive rather than fragmented and static Effective prevention is not the sum of isolated systems. It requires a unified fraud engine that connects data from various sources (customer, transaction, channel, and third-party data), manages rules and models across rails, and channels alerts into an integrated case and investigation process. This must be complemented by a governance structure – for example in the form of an AI/Fraud Competence Centre – that manages model life cycles, conducts bias and robustness checks, fulfils regulatory explainability requirements, and ensures that operational insights (true positives, false positives, near misses) feed back into rules and models.

Within this logic, real-time prevention becomes a core capability that must be regarded in a similar way to credit risk management or liquidity management: with clear accountability, defined KPIs, investment-grade architecture, and an operating model that is sustainable on a 24/7 basis. Institutions that complete this transformation in time will face AI-driven payment fraud not only with better models, but with a structure that addresses speed, complexity, and liability pressure alike.

PSD3/PSR as a Game Changer: Liability in the Real-Time Setting

From SCA Protection to Context-Dependent Liability

Until now, much of the liability logic in payments rested on a simple principle: if a payment was correctly authenticated – ideally using strong customer authentication (SCA) – the payment service provider was, in many constellations, largely absolved of liability. The risk of authorised but fraudulently induced payments lay predominantly with the customer, particularly in social engineering and APP fraud scenarios.

PSD3/PSR subjects this logic to scrutiny. Political agreements and drafts provide that payment service providers may in future also be liable for authorised payments where these are based on spoofing or impersonation scenarios in which perpetrators convincingly imitate the identity of banks or authorities. What becomes decisive is therefore no longer solely whether a payment was formally correctly authenticated, but the circumstances under which authorisation came about – and whether the payment service provider warned, delayed, or blocked appropriately given the available information.

How concrete this shift is can be seen in the blog post: “PSD3 and PSR on the home straight: Now is the time to prepare.“⁵

Three pillars of PSR fraud prevention are outlined there, which make the regulatory expectations of banks and payment service providers tangible:

Firstly, a significantly expanded internal prevention regime, including risk-based real-time transaction monitoring, extended verification of payee for transfers in all EU currencies, and an obligation to actively reject suspicious payments where there are objectively justified grounds for suspecting fraud – failing which the payment service provider is directly liable for the loss.

Secondly, collaborative fraud prevention, in which institutions exchange fraud-related data via dedicated platforms, flanked by data protection impact assessments and strict retention periods.

Thirdly, a strengthening of the customer interface, for example through extended possibilities for limit management and immediate blocking of payment instruments, combined with explicit intervention rights for institutions to proactively stop payments under certain conditions.

These three pillars translate directly into requirements for real-time prevention: real-time monitoring and VoP as upstream controls, a robust data and signal network between institutions, and a customer interface that treats deliberately designed friction and intervention rights as part of the protective logic.

Burden of Proof and Documentability of Non-Intervention

With this shift, the evidentiary and documentation position also changes. Payment service providers will in future need to demonstrate not only that authentication processes were technically executed correctly, but also that monitoring and intervention were “appropriate” – a term that is increasingly being interpreted by reference to real-time capabilities.

This places at centre stage an aspect that has until now been largely implicit in many institutions: the documentability of non-intervention. Under PSD3/PSR, it is no longer sufficient to operate a scoring system and an SCA pathway. Institutions must be able to explain, in the event of a dispute, why no warning, delay, or block was triggered for a specific payment, even though certain patterns were present – such as new payees, unusual amount/frequency combinations, or known social engineering schemes.

For the operating model, this means: real-time decisioning, logging of scores and rules, traceability of overrides, and clear criteria for “gross negligence” become liability-relevant capabilities, not compliance nice-to-haves.

Collaborative Fraud Prevention as a Regulatory Expectation

PSD3/PSR does not stop at individual liability, but also strengthens the collaborative dimension of fraud prevention. Alongside measures such as verification of payee and stronger information obligations towards customers, regimes are taking shape that expect a more systematic exchange of fraud data, warnings, and patterns between payment service providers, infrastructure providers, and potentially central bodies – naturally within the bounds of data protection and competition law.

For institutions, this means two things: on the one hand, requirements for their own real-time prevention are increasing; on the other, the ability to embed external signals – for example regarding money mule accounts, current social engineering patterns, or compromised payees – into their own decision logic becomes important.

A real-time prevention framework that aspires to be PSD3/PSR-ready must therefore be not only technically robust and well-documented, but also interoperable: capable of ingesting external data, sharing internal findings in an appropriate form, and thereby contributing to collective risk reduction.

Consequences for Banks, PSPs, and Acceptance Points

Three Roles, One Shared Liability Problem

With the combination of real-time payments, AI-driven fraud, and the new liability logic under PSD3, the role of all participants in the payments ecosystem is fundamentally changing. Fraud prevention is no longer an isolated task for individual actors, but a pervasive systemic risk that operates across the entire payment chain. The German Banking Industry Committee (GBIC) explicitly notes, in the context of the PSR agreement, that the EU measures primarily address fraud types in which customers are enticed via social media and digital communication channels into making payments or disclosing their identification credentials – precisely the social engineering and APP fraud scenarios examined here.⁴

What differs are the levers available to individual actors – and the points at which responsibility, costs, and risk take effect.

Banks: Decision-Making Authority in Real Time

For banks, fraud prevention is finally moving out of the “operations corner” and into the core of value creation. Whereas institutions previously primarily processed payments, they must in future take responsibility for decisions – including justified non-intervention – and be able to defend those decisions under PSD3/PSR.

In concrete terms, this means:

• Real-time decisioning rather than alerts: Banks require an architecture that enables decisions on warning, delay/hold, step-up, or blocking to be made within seconds – with consistent rules, models, and escalation pathways that function 24/7.
• Documentable decision logic: Every relevant payment must pass through a traceable chain of data, scores, rules, and possible overrides. The ability to explain retrospectively why there was no intervention becomes liability-relevant.
• Customer dialogue as part of the control: Targeted friction – for example, warning notices for typical APP patterns, step-up checks for new payees – shifts from a UX “nuisance” to a regulatorily legitimised protective measure. Banks must define when they actively involve customers in fraud prevention.

PSPs and Acquirers: Risk Intelligence as a Product Core

PSPs and acquirers sit at the intersection of volume, performance, and merchant interests. Under PSD3/PSR, payment processing without integrated risk intelligence is no longer a neutral infrastructure business, but a potential liability driver – for themselves and their clients.

In concrete terms, this means:

• Architecture as a lever. Fraud controls must be integrated into the same latency windows as routing, authorisation, and settlement. Low-latency scoring, real-time signals, and deterministic degradation pathways belong in the platform – not in downstream batch processes.
• Portfolio management rather than cross-subsidisation. PSPs must actively manage merchant risk; inadequately secured process chains (login, checkout, refund) increase overall risk. Without active management, low-risk merchants pay for the failures of high-risk ones. Differentiated limits, pricing, and minimum standards become a necessity.
• Multi-rail orchestration with fraud coverage. Anyone offering multiple rails (card, account, wallet, BNPL, crypto) needs cross-rail fraud and risk monitoring. Signals must not become stranded at rail boundaries – otherwise precisely the gaps that fraudsters exploit are created.

The consequence is a new market proposition: not “payments as fast as possible”, but “payments with accountable risk” becomes the differentiating factor.

Practical implication: PSPs and acquirers must think of risk controls as a product component: SLA-capable checks, clearly defined intervention points, and transparent merchant governance (including minimum standards). The PSR discussion around risk-based transaction monitoring and fraud data sharing underlines exactly this direction.

Acceptance Points: The Customer Journey as a Risk Surface

Merchants and other acceptance points often appear at the margins of regulatory texts, yet they substantially shape the risk profile: many fraud models are initiated well before the actual payment – at registration, login, shopping basket, communication, and refund processes.

In concrete terms, this means:

• Prevention before payment: Weak login flows, absent device binding, unclear payee information, or easily exploitable promotional/refund mechanisms increase the fraud risk across the entire chain. Those who check only at checkout usually detect fraud too late.
• Refund and service flows as part of the attack surface for fraud: Generous, poorly secured refunds or service processes can facilitate secondary fraud and money mule structures – with consequences for limits, pricing, and controls imposed by banks and PSPs.
• Targeted friction as a business consideration: Step-ups for risky payments, well-designed warning notices, and clear payee information are not merely “compliance obligations”, but help reduce chargebacks, disputes, and loss of trust. Fraud prevention thereby becomes part of revenue management and customer retention.

The consequence is uncomfortable – but strategically important: fraud prevention becomes for merchants an element of revenue management and customer retention, not merely a cost factor.

Conclusion: Three Forces, One Paradigm Shift

Generative AI makes fraud not only more frequent, but above all more sophisticated: social engineering attacks are becoming more personalised, more credible, and more scalable – and are targeting payment systems in which seconds determine finality.

Real-time payments devalue classic protective mechanisms, because downstream controls have barely any time to intervene and fraud develops along orchestrated process chains across multiple rails.

PSD3/PSR simultaneously shifts liability to where these decisions are made: to banks, payment service providers, and – indirectly – acceptance points, which must be able to explain why they warned, delayed, blocked, or indeed chose not to intervene in a specific case.

In this constellation, fraud prevention shifts from being a downstream control function to a liability-relevant core function of the payments architecture. Or, put differently: those who offer real-time payments without mastering real-time risk as an operational discipline are not scaling innovation – they are scaling systemic risk.