PSPs, Push Payments & Liability: How UK/EU APP Scam Rules Will Reshape Gateway Roadmaps in 2026

Authorised Push Payment (APP) scams have become the most disruptive fraud category in the UK and EU, growing in direct correlation with the expansion of real-time execution rails such as Faster Payments, SEPA Instant and Open Banking–powered account-to-account (A2A) payments. By 2023, the UK alone recorded £459.7 million in APP fraud losses, according to UK Finance. This marked a structural shift: fraudsters no longer target payment cards; they target people and real-time push payments that settle instantly with no built-in dispute buffers.

The regulatory response across the UK and EU is now converging on a single principle: firms involved in initiating or enabling a push payment must share responsibility for preventing fraud, rather than pushing liability downstream to the receiving bank. The UK’s Payment Systems Regulator (PSR) has already finalised mandatory reimbursement requirements, coming into force between late 2024 and 2026. In parallel, the European Commission’s 2023–2024 Payments Package, including PSD3 and the new Payment Services Regulation (PSR), mandates payee verification, stronger authentication flows and real-time fraud monitoring across all instant payments.

This creates a profound operational shift for Payment Service Providers (PSPs), A2A payment gateways, Open Banking PISPs, and paytech firms. Historically, these entities acted primarily as technical facilitators, passing authorisation requests, routing transactions, or triggering payment instructions. Under the 2026 liability landscape, they become jointly accountable, meaning they must monitor risk, verify beneficiaries, operationalise shared fraud intelligence and support regulated reimbursement processes. This is no longer optional architecture; it becomes core infrastructure.

From a product and engineering perspective, the regulatory shift fundamentally reshapes gateway roadmaps. Fraud-scoring engines must sit upstream, not downstream. API payloads must expand to include risk attributes, behavioural data fields and liability classification codes. Routing logic must evolve from cost-optimisation to liability-aware orchestration, prioritising safe corridors and dynamic risk-based slowdown mechanisms for high-risk transactions.

For merchants, the implications are equally material. While they may face marginal increases in pre-payment friction, additional verification prompts, risk-based delays or behavioural checks, the long-term gain is significant: lower exposure to APP-related chargebacks, stronger customer confidence in A2A payment acceptance, and safer cross-border transactions across Europe.

2026 marks a regulatory turning point: APP scam rules in the UK and EU transform push payments from “execute first, investigate later” into a structured, risk-assessed model with mandatory liability sharing. PSPs and gateways must now evolve into active fraud-prevention stakeholders, and their product roadmaps must follow.

Why APP Fraud Rules Are Changing in 2026 (UK & EU)

Authorised Push Payment (APP) fraud has escalated into the most urgent risk factor across instant-payment ecosystems. Faster Payments, SEPA Instant and Open Banking rails have made A2A transactions near-instant, irrevocable and increasingly used for both consumer and business flows. Yet these systems were never designed to support the type of identity verification or behavioural analysis needed to prevent modern social-engineering scams.

By 2023, UK Finance recorded £459.7 million in APP fraud losses, a signal that real-time rails had outpaced the regulatory frameworks supporting them. The UK and EU responses now converge on a central principle: firms that enable, route or initiate a push payment must share responsibility for preventing, detecting and reimbursing fraud.

The upcoming 2026 regulatory changes are therefore not just policy updates; they represent a complete redesign of how PSPs, paytechs and gateways must operate.

The UK’s Regulatory Rationale: Closing the Instant Payments Vulnerability

APP fraud grew faster in the UK than in any other mature payments market, primarily because the Faster Payments Service introduced a near-real-time settlement model without mandatory payee-verification controls. Fraudsters exploited the trust consumers place in digital communication, pushing them to send legitimate payments to criminally controlled accounts.

Regulators identified three structural weaknesses:

• Irrevocability: Faster Payments allows no natural window for intervention or reversal.
• Fragmented liability: Sending banks often carried responsibility, while receiving PSPs, fintechs, and A2A providers had minimal obligations.
• Limited data sharing: Fraud indicators were isolated within individual institutions.

To address this, the Payment Systems Regulator (PSR) introduced a mandatory reimbursement framework, coming into full effect between 2024–2026, which requires both sending and receiving PSPs to share liability. This fundamentally alters the operating model for PSPs and gateways, shifting responsibility from “bank-centric” to “ecosystem-wide”.

The EU’s Response: Harmonising Fraud Controls Across SEPA Instant

While fraud losses in the EU have been more fragmented, the rapid expansion of instant SEPA flows created similar vulnerabilities. Some countries implemented IBAN–name matching; others did not. Fraud reporting obligations varied by jurisdiction. And instant settlement provided a target-rich environment for social-engineering scams.

The European Commission’s Payments Package, combining PSD3 with the new Payment Services Regulation, aims to harmonise prevention and reimbursement standards across all 27 member states. Mandatory IBAN–name matching, stronger identity-verification obligations, consistent dispute rules and real-time monitoring are introduced as baseline requirements for all PSPs processing SEPA Instant.

The EU stops short of replicating the UK’s strict reimbursement model but shifts more responsibility to PSPs to detect and block fraudulent push payments before execution.

A Shared Regulatory Goal: Aligning Liability With Capability

The direction of travel is clear: liability must follow the ability to prevent fraud. PSPs, gateways and Open Banking PISPs control critical parts of the customer journey, authentication, data gathering, payee verification and risk scoring. Regulators expect these firms to use this position to prevent criminal redirection of funds, not simply pass payment instructions downstream.

This shift affects:

• Product roadmaps
• Fraud-prevention architecture
• Dispute-handling workflows
• Settlement logic
• Operational accountability between PSPs and gateways

APP fraud rules are changing because instant payments grew faster than the controls needed to secure them. Both the UK and EU now expect PSPs, gateways and paytechs to act as active fraud-prevention layers, not neutral routing providers. From 2026, liability and technical responsibility will be shared across every part of the A2A payment chain,  making proactive controls a regulatory expectation, not a product choice.

Liability Shift: The New Operating Model for PSPs & Gateways

For more than a decade, payment gateways and PSPs positioned themselves as “technical facilitators”, neutral conduits passing messages between merchants, banks and alternative payment methods. APP fraud regulation in the UK and EU now removes that neutrality entirely. From 2026 onwards, PSPs, paytechs, A2A gateways and Open Banking PISPs will share liability for fraudulent push payments, forcing a shift from passive routing to active fraud governance.

This section explains how the liability model is changing, what it means for PSPs and gateways, and why the operational model that dominated 2010–2023 is no longer viable.

The Pre-2026 Model: Routing Without Responsibility

Traditionally, liability for APP fraud sat almost entirely with:

• The sending bank (ASPSP), responsible for executing the payment, and
• In some markets, the receiving bank, where stolen funds are ultimately held.

Gateways, PSPs and fintechs avoided direct exposure because:

• They did not control the underlying settlement layer,
• They did not perform final beneficiary verification.
• They had limited visibility into account-level data, and
• They were not regulated under a liability-sharing framework.

This created a structural gap: firms with the richest behavioural data (PSPs and gateways) were not responsible for fraud outcomes, while banks receiving limited upstream intelligence were expected to prevent and absorb losses.

The Post-2026 Model: Shared Liability Across the A2A Chain

APP fraud rules in the UK and EU dismantle this separation. In the 2026 framework, any entity that initiates, routes or materially influences a push payment is considered part of the liability chain.

Who Becomes Liable?

• PSPs offering A2A payment initiation
• Payment gateways routing A2A or Open Banking transactions
• Open Banking PISPs, including those layering VRPs
• Paytech middleware providers
• A2A orchestration platforms
• Acquirers triggering card-to-A2A payout conversions
• Alternative settlement partners involved in cross-border A2A flows

This is a major shift: liability no longer follows the settlement account; it follows the data and influence path of the payment.

Liability Assessment Will Be Cause-Based and Control-Based

Regulators are moving toward liability models that assess:

1. Cause-Based Liability

Did the fraud occur because a PSP or gateway failed to perform:

• Correct payee verification?
• Fraud scoring?
• Mandated warnings or risk prompts?
• Transaction delays for high-risk scenarios?

2. Knowledge-Based Liability

Could the PSP reasonably have detected the scam based on:

• Behavioural anomalies
• Device intelligence
• Risk-pattern history
• Merchant-level data

Gateways and PSPs often hold more behavioural and device data than banks, making them natural candidates for shared obligation.

3. Prevention-Based Liability

Did the PSP put in place:

• Confirmation-of-payee / IBAN–name checks
• Multi-layer identity verification
• Fraud-data sharing arrangements
• Robust authentication flows
• High-risk cooling-off measures

Controls that were once “best practice” become baseline regulatory expectations.

Why PSPs and Gateways Are Now Considered “Control Points”

The UK PSR and the EU Commission have repeatedly highlighted that gateways and payment tech firms increasingly act as:

• Data collection points (device, behavioural, session analytics)
• Authentication layers (SCA orchestration, biometric prompts)
• Routing engines (optimising A2A corridors)
• UX owners (how users perceive warnings or risk prompts)
• Risk signal distribution hubs (pushing fraud flags upstream or downstream)

Under the 2026 model, this means they:

• Can influence fraud outcomes
• Do hold critical behavioural intelligence
• Should prevent high-risk payments before execution
• Must participate in liability and reimbursement

The core regulatory logic is simple: If you can see the risk, you are accountable for mitigating it.

What This Means for Roadmaps, Teams and Governance

PSPs and gateways will need to redesign:

1. Product Roadmaps

• Upstream fraud scoring
• Liability metadata in API payloads
• Routing rules based on risk bands, not just cost
• Payee verification as default for A2A

2. Technical Architecture

• Real-time data exchange with banks
• Shared fraud-intelligence pipelines
• Dynamic risk-based delays
• Event-driven dispute APIs

3. Governance

• Clear liability decision trees
• Documented fraud-prevention controls per transaction type
• New compliance roles focused on A2A risk architecture

4. Operational Models

• Faster dispute-handling SLAs
• Proactive investigation of high-risk patterns
• Merchant onboarding linked to liability exposure

From 2026, PSPs and gateways will no longer be “just pipes”. They will be treated as active risk stakeholders, expected to detect, prevent and share liability for APP fraud. For merchants, this means safer A2A acceptance, but also more scrutiny, more verification logic, and a deeper partnership with their payment providers.

The 12 Mandatory Roadmap Changes PSPs Must Make by 2026

The shift to shared liability does not simply require minor adjustments to fraud systems. It forces PSPs, A2A gateways and Open Banking PISPs to rebuild their roadmaps around regulatory-first architecture. Instant-payment fraud controls are no longer optional add-ons; they form the structural core of A2A payment design. Regulators expect PSPs to demonstrate that they have embedded verification, monitoring, risk scoring, liability metadata and dispute-response capabilities across every stage of the payment journey.

Below are the 12 roadmap changes every PSP must complete before the new APP fraud rules fully apply across the UK and EU.

1. Real-Time Payee Verification (IBAN/Name/CoP Integration)

By 2026, all PSPs and gateways involved in initiating or routing push payments must implement real-time beneficiary verification. In the UK, this implies integrating the latest Confirmation of Payee (CoP) standards; across the EU, the new Payment Services Regulation mandates IBAN–name matching for all SEPA Instant transactions.

This requires:

• Name-matching at initiation
• Dynamic warnings if a mismatch occurs
• Data-exchange latency <300 ms
• Fallbacks for cross-border corridors

For gateways, this is a fundamental product shift: verification must sit before routing, not simply at the bank layer.

2. Inbound & Outbound Risk Scoring

APP scams frequently rely on behavioural manipulation, not technical compromise. PSPs must therefore implement two-directional risk assessment:

• Outbound: behavioural, device, velocity and intent analytics.
• Inbound: mule detection, synthetic identity markers, account-risk scoring.

Risk scoring must be real-time, API-driven and capable of influencing routing decisions instantly.

3. Fraud-Data Sharing (Bi-Directional, Real-Time)

The UK’s liability model requires both the sending and receiving PSPs to share reimbursement responsibility. This makes fraud intelligence exchange mandatory, not optional.

PSPs will need:

• Standardised risk metadata fields
• Upstream/downstream fraud flags
• Shared indicators for mule accounts
• Session-based behavioural identifiers

This is one of the largest architectural changes for A2A gateways in 2026.

4. High-Risk Transaction Cooling-Off Logic

Regulators expect PSPs to introduce dynamic delay mechanisms for high-risk push payments. These are not blanket delays but risk-band specific:

• <1 second for low-risk
• 1–30 seconds for moderate-risk
• Several minutes for high-risk scenarios

Cooling-off logic will be enforced in fraud audits and reimbursement decisions.

5. Behavioural & AI-Driven Intelligence

PSPs must adopt behavioural analytics capable of detecting:

• Social-engineering patterns
• Anomalous device behaviour
• Unusual timing/velocity
• Payer hesitation or re-entry behaviour

AI models must be explainable (XAI) and auditable, as regulators will require evidence of how decisions were generated.

6. Liability-Aware Routing & “Safe Path” Orchestration

Routing based solely on cost or uptime will be non-compliant. Providers must route based on:

• Fraud-score thresholds
• Risk corridor maps
• Receiving-PSP reliability
• Liability exposure at the corridor level

This is a significant roadmap shift for gateways that traditionally focused on latency and conversion.

7. Strengthened Authentication UX & SCA Behavioural Prompts

PSPs must redesign authentication screens to:

• Display contextual warnings
• Highlight mismatched identifiers
• Use behavioural biometrics
• Incorporate step-up authentication triggers

The UX itself will have a regulatory impact because clear warnings reduce liability exposure.

8. Standardised Fraud Dispute & Reimbursement APIs

Under the new reimbursement rules, PSPs must:

• Submit structured data for disputes
• Respond to reimbursement requests within fixed SLAs
• Provide logs of risk scores and warnings
• Support API-driven dispute coordination

Gateways must incorporate dispute-handling workflows directly into their platform.

9. Merchant Risk Tiering & Ongoing Monitoring

PSPs face new obligations to categorise merchants by:

• MCC risk levels
• Historical dispute rates
• Exposure to social-engineering scams
• Payout patterns and corridor usage

High-risk categories (crypto, gaming, adult, ticketing, classifieds) will require enhanced controls.

10. Push-Payment Chargeback Framework

PSPs must adopt a new A2A chargeback model aligned with:

• UK PSR liability sharing
• EU PSR dispute guidance
• Cross-PSP reimbursement protocols

This requires entirely new operational teams and internal documentation.

11. Mule-Account Monitoring & Synthetic Identity Detection

Compliance teams must integrate:

• Network-graph analysis
• Behavioural clustering
• Device linking
• Inbound payment velocity monitoring

This marks a shift from reactive investigations to proactive mule-risk surveillance.

12. Reporting, Transparency & External PSR Dashboards

PSPs operating in the UK will be required to publish and submit:

• Fraud rates
• Reimbursement decisions
• Complaint resolutions
• Risk-prevention performance metrics

These outputs will influence regulatory scrutiny and commercial reputation.

These 12 roadmap changes mark the largest structural upgrade in the history of A2A and Open Banking payments. PSPs and gateways can no longer operate as routing engines; they must act as risk-intelligence platforms, with verification, scoring, routing and reimbursement capabilities deeply embedded into their core architecture. Merchants will ultimately benefit from safer payouts, but must prepare for increased verification, stronger onboarding checks and more controlled payout corridors.

How These Rules Will Reshape Gateway Product Roadmaps in 2026

APP scam regulation not only impacts banks and PSPs, but it also fundamentally alters the role of gateways within the A2A payment stack. Gateways are no longer viewed as “neutral routing pipes”. Regulators now treat them as data-rich control points that influence both the initiation and security of instant payments. This means gateway product teams must redesign their 2026 roadmaps around fraud intelligence, liability-sharing and real-time verification.

Below are the structural shifts payment gateways will need to implement to remain compliant and competitive.

Gateways Will Become Identity and Verification Layers, Not Just Routing Engines

The first major shift is that gateways must bring identity verification upstream. Historically, gateways passed the payer’s request to the PSP without performing deep beneficiary checks. Under the 2026 framework, this will no longer be acceptable.

Gateways must support:

• IBAN–name matching
• Real-time payee verification
• Risk-based prompts and warnings
• Cross-PSP validation fields
• Fraud metadata injection before routing

This transforms the gateway from a neutral conduit into a risk-aware initiation layer. All verification processes must be completed before the gateway selects the execution path.

Smart Routing Moves From Cost Optimisation → Liability Minimisation

Routing in A2A payments traditionally followed two priorities:

1. Latency/uptime
2. Transaction cost

Under the APP framework, these priorities invert. Gateways must route based on risk, not just economics.

2026 routing will consider:

• Real-time fraud scores
• Receiving PSP risk reliability
• Corridor-level fraud density
• Expected reimbursement exposure
• Whether the receiving PSP has strong mule monitoring
• Regulatory risk classification by corridor

This creates a new requirement for liability-aware routing engines, capable of adjusting paths dynamically depending on risk signals and fraud history.

Deeper API Contracts Become Mandatory (Fraud Flags, Identity Attributes, Liability Codes)

Gateways traditionally exchanged limited information: transaction amount, payer details, merchant details and standard metadata.

Under the 2026 model, gateways must support expanded API payloads, including:

• Liability codes (sender/receiver fault markers)
• Risk scoring values
• Outcome classification fields
• Identity attributes (verification match, partial match, mismatch)
• Device data
• Session-level behavioural tags
• Escalated warnings delivered to the PSP

These data points will influence liability calculations and dispute outcomes. If gateways cannot provide these signals, they will default to a higher liability burden.

Real-Time Risk Engines Become Core Infrastructure

Gateways must embed real-time risk engines capable of:

• Session tracking
• Behavioural analytics
• Payer-device fingerprinting
• Pattern detection
• Social-engineering indicators
• Velocity controls
• Contextual user warnings

This requires gateways to shift from a “single logic layer” (static rules) to a multi-layer orchestration model, incorporating:

1. Rule-based logic
2. Machine-learning scoring
3. Contextual risk warnings
4. Hard blocks for high-risk patterns

The objective is not to flag fraud after execution, but to prevent it before the payment instruction is sent downstream.

Settlement and Reconciliation Models Must Support Reimbursement Flows

Gateways were previously not involved in reimbursement logic for A2A scams. Under shared liability, they must integrate:

• Hold/escrow mechanisms for disputed funds
• Settlement delay options for high-risk corridors
• Reimbursement notification APIs
• Structured dispute workflows
• Reporting fields required by PSPs for regulator audits

This is one of the largest structural shifts, as gateways must now maintain reversible and auditable flows within systems designed for irreversible payments.

Gateways Must Support Time-Bound Dispute and Case Management APIs

Under the UK’s mandatory reimbursement rules, PSPs and receiving institutions must respond to fraud cases within strict regulatory timelines. Gateways will now serve as coordination nodes, ensuring:

• Dispute events are synchronised
• Liability information is shared
• Fraud logs are retrievable
• Risk prompts are time-stamped
• Evidence trails can be exported

Gateways that lack dispute APIs will expose PSP clients to regulatory penalties, directly affecting their commercial viability.

Compliance and Legal Must Influence Product Development

Previously, gateway roadmaps were driven by engineering and commercial priorities. Under the new model, compliance and legal teams become core stakeholders in:

• Product design
• API schema development
• Routing logic configuration
• Messaging structures
• Data retention and audit frameworks

This will require gateways to build multi-disciplinary roadmap committees where compliance influences functional requirements from day one.

2026 forces gateways to evolve from routing providers into risk-intelligence infrastructure partners. Smart routing, identity verification, liability metadata, dispute-management APIs and real-time risk engines become mandatory components, not premium features. For merchants, this means safer A2A and Open Banking payments, more predictable reimbursement outcomes and a significant reduction in APP-related exposure. But it also means stricter verification and more structured risk orchestration in the checkout and payout experience.

Impacts for Merchants: Strategic & Operational

The transition to shared APP liability will have a direct impact on merchants across the UK and EU. While the regulatory framework is designed primarily for PSPs, PISPs and payment gateways, merchants will experience significant operational, UX and settlement changes throughout 2026. These adjustments are not punitive; they are a natural consequence of the broader shift towards safer, more resilient A2A payment ecosystems.

Below are the core merchant impacts and how each will influence checkout experiences, payout reliability and cross-border operations.

Short-Term Impact: Increased Friction at Checkout

In the first phase of implementation, merchants will see additional steps introduced into the customer payment flow. These changes are a required response to identity-verification standards, liability apportionment rules and the fraud-detection mandates introduced under UK PSR and the EU Payments Package.

Key short-term operational changes include:

• Enhanced payee-verification prompts (IBAN–name matching, CoP warnings)
• Occasional payment delays for high-risk transactions (cooling-off logic)
• Stronger behavioural prompts to alert customers during suspected scams
• Additional authentication layers for unusual or high-value A2A transactions

While friction is unavoidable during the transition, the purpose is to reduce exposure to social-engineering attacks, impersonation scams and unauthorised redirection of funds.

Impact on Conversion: For most merchants, conversion rates may dip slightly until customers become familiar with new verification logic. However, the long-term effect is positive; safer A2A acceptance builds trust and reduces fraud-driven attrition.

Medium-Term Impact: Reduced Fraud Exposure and More Predictable Losses

Once PSPs and gateways fully implement identity-verification layers, real-time risk scoring and liability-aware routing, merchants benefit from a more controlled risk environment.

Mid-term improvements include:

• Fewer payout reversals due to upstream fraud detection
• Lower operational disruption from mule-account investigations
• Fewer disputes linked to redirected funds
• Predictable reimbursement exposure, especially for UK merchants operating under PSR rules
• Reduced need for internal fraud reviews, as liability shifts back to PSPs and gateways

This marks a major strategic change. Merchants move from being reactive victims of APP fraud to participants in a system where fraud prevention is embedded earlier in the payment flow.

Impact on Financial Planning: Fraud losses become more stable and forecastable, which materially improves financial modelling for high-risk verticals such as gaming, crypto services, ticketing, digital goods and cross-border ecommerce.

Long-Term Impact: Safe A2A Acceptance Enables Growth and Market Expansion

As PSPs and gateways deploy better risk controls, merchants gain access to more scalable, lower-cost A2A payment options. This is especially relevant because:

• A2A payments will become a larger part of e-commerce checkout flows
• Open Banking PISPs will expand VRP and recurring-authorisation models
• SEPA Instant becomes the default standard across EU payment corridors
• Cross-border A2A flows will operate with consistent verification rules

The biggest long-term merchant advantage is customer trust. When consumers know A2A payments are protected by reimbursement frameworks and fraud-prevention layers, adoption increases significantly.

Impact on Growth: Merchants operating in travel, subscriptions, FX, iGaming, investment platforms and marketplaces will be able to push more volume through A2A rails, reducing dependency on higher-cost card acquiring.

Operational Adjustments Merchants Should Prepare For

To align with PSP and gateway changes, merchants should prepare for:

1. Updated Checkout UX

• Space for warnings
• Additional validation prompts
• Clearer payee descriptions
• Stronger handling of payer identity fields

2. New Payout Rules

• Delays for high-risk corridors
• Reversible flows for flagged transactions
• Stronger verification of beneficiary details
• Deeper KYC requirements for high-payout merchants

3. Revised Onboarding & Monitoring

• PSPs will implement enhanced MCC-based risk tiering
• High-risk sectors will face stricter onboarding
• Transaction-monitoring thresholds will tighten
• Payout throttling will apply to risk-heavy patterns

4. Regulatory Audits via PSPs and Gateways

PSPs may request merchants to provide:

• Additional verification documents
• Flow and UX screenshots (for warning compliance)
• Dispute-handling documentation
• Settlement logs

This is not a new regulation for merchants; it is indirect compliance driven by PSP obligations.

Strategic Advantage for Merchants Who Adapt Early

Merchants who prepare for the new framework early stand to gain advantages such as:

• Lower fraud liability
• Stronger payment acceptance rates
• Prioritised risk scores from PSPs
• Smoother onboarding for new corridors
• Improved customer perception of payment security

Early adopters often become preferred clients in PSP routing, as strong compliance reduces shared liability exposure.

APP fraud rules reshape the merchant landscape across the UK and EU. Short-term friction is unavoidable, but long-term benefits are substantial: reduced fraud exposure, safer A2A acceptance, predictable financial risk and better customer trust. Merchants who adapt early, by aligning their checkout UX, payout processes and verification flows, will gain both operational resilience and competitive advantage as A2A volumes grow across 2026.

Technical Architecture Example: A 2026-Ready A2A Fraud-Resilient Payment Flow

To understand how APP liability reshapes product and engineering priorities, it helps to visualise a 2026-compliant technical architecture. The following model illustrates how a typical A2A transaction flows through PSP, gateway and bank layers under the new regulatory standards.

This is not a schematic of a single provider; it is a composite blueprint reflecting the minimum requirements PSPs and gateways will need to satisfy by 2026.

1. Customer Initiation Layer (Front-End + Pre-Validation)

The customer begins the payment journey through a merchant checkout, mobile app or embedded payment link. Before the transaction can progress:

• The PSP or gateway collects device fingerprinting,
• Captures behavioural session data,
• Applies risk pre-scores (based on user patterns), and
• Performs early identity checks (where supported).
  

Key components include:

• Behavioural biometrics (typing cadence, navigation patterns)
• Device classification (new, trusted, compromised)
• Session scoring (velocity, time-of-day anomalies)

This layer forms the bulk of the “knowledge-based liability” test regulators will use in disputes.

2. Real-Time Payee Verification Layer (CoP / IBAN-Name Matching)

Before routing begins, the gateway or PSP must verify the beneficiary details through:

• Confirmation of Payee (CoP) for UK Faster Payments
• Mandatory IBAN–name matching for SEPA Instant
• Risk-based mismatch prompts are shown to the payer

Verification outcomes are classified as:

• Full Match: Proceed with standard risk scoring
• Partial Match: Trigger warnings + step-up verification
• Mismatch: Block, delay or escalate

This layer directly affects downstream liability sharing.

3. Gateway Risk Engine & Liability-Aware Routing Layer

This is the 2026 architectural centrepiece. Gateways must incorporate:

Core Capabilities

• Real-time risk scoring (rules + ML)
• Anomaly detection (session + account + device)
• Corridor-level “safe-path” routing
• PSP reliability scoring (fraud rate, dispute accuracy, mule detection strength)
• Dynamic throttling for high-risk transactions

Liability Metadata Injection

The gateway adds structured metadata to the transaction request:

• Risk score
• Match status
• Escalation level
• Liability code
• Device hash
• Behavioural identifiers

This metadata travels with the payment instruction to influence PSP and bank decisions.

4. Payment Submission & Bank Execution Layer

Once all upstream checks are satisfied, the transaction is sent for execution:

• Payer ASPSP (Sending Bank) receives the enriched request
• Executes final SCA
• Applies its own fraud checks
• Submits the payment to the instant-payment rail (FPS/SEPA Instant)

The receiving bank conducts:

• Inbound fraud screening
• Mule-account checks
• Account validation
• Posting logic or hold/flag logic

The gateway may receive asynchronous callbacks from either side in case of escalations.

5. Post-Transaction Monitoring, Alerts & Dispute Flows

After execution, the PSP and gateway must continue monitoring for:

• Mule-account behaviour
• Unusual refund activity
• Behavioural anomalies in linked accounts
• Late-stage scam indicators

Dispute APIs are triggered automatically when:

• A customer flags a transaction
• A PSP detects post-execution fraud
• Regulatory reversal obligations apply

Gateways must maintain a retrievable audit trail with:

• Timestamped warnings
• Verification logs
• Risk-score history
• Routing decisions
• Fraud-trigger metadata

These records determine liability in reimbursement cases.

A 2026-ready A2A architecture is no longer about routing speed or conversion. It is about verification, intelligence and liability governance. PSPs and gateways will need multi-layer identity checks, fraud engines, liability metadata, route orchestration and dispute-ready audit logs. Merchants should expect safer, more resilient A2A acceptance, but also deeper upstream risk analysis and structured verification flows that protect both customers and the business.

Regulatory & Scheme Requirements (2024–2026)

The regulatory landscape for instant payments is evolving rapidly across the UK and the EU. Between 2024 and 2026, PSPs, gateways and Open Banking PISPs will move from fragmented, bank-led fraud controls to a structured, liability-sharing model enforced by regulators and payment schemes.

This summarises the requirements introduced by the UK Payment Systems Regulator (PSR), the EU Payments Package, PSD3, + the new Payment Services Regulation, and instant-payment schemes such as Faster Payments and SEPA Instant. It also highlights the operational expectations for PSPs and gateways across verification, identity, fraud monitoring and dispute handling.

UK Regulatory Requirements (2024–2026)

Mandatory APP Reimbursement (PSR)

The most significant regulatory change is the introduction of mandatory reimbursement rules for Authorised Push Payment scams. These rules apply to all payments executed over Faster Payments and require both sending and receiving PSPs to share liability.

PSPs must demonstrate that:

• Payee-verification checks were performed,
• Risk-based warnings were shown,
• Behavioural anomalies were assessed, and
• Transaction data was shared promptly.

A failure in any of the above can result in increased liability for the PSP or gateway involved.

Reference: UK Payment Systems Regulator – APP Fraud Reimbursement Policy

Faster Payments Scheme Requirements (Technical & Operational)

The Faster Payments Scheme (FPS) supports the regulatory rollout by enhancing scheme-level expectations:

• Standardised Confirmation of Payee (CoP) integration
• Enhanced fraud-data interoperability
• Support for structured dispute notifications
• Event-driven callbacks for PSPs and gateways
• Enforcement of real-time fraud checks

Gateways must adapt their routing engines and API payloads to incorporate these new FPS fields and callbacks.

EU Legislative Requirements (2024-2026)

The EU Payments Package reshapes the fraud-prevention landscape across 27 member states. The most impactful requirements include:

Mandatory IBAN–Name Matching (SEPA Instant)

All PSPs offering instant payments must implement real-time IBAN/name verification before processing a SEPA Instant transaction.

Real-Time Fraud Monitoring

PSPs must:

• Conduct continuous behavioural analysis,
• Assess payer and payee risk profiles,
• Block or delay suspicious transactions, and
• Maintain a real-time monitoring engine.

Stronger Customer Authentication (SCA) Enhancements

PISPs and PSPs must strengthen authentication flows by including:

• Dynamic risk warnings,
• Contextual prompts, and
• Higher friction for suspected scams.

Harmonised Dispute Rules

The new Payment Services Regulation (PSR) introduces standardised dispute procedures, supporting clearer PSP-to-PSP coordination during reimbursement claims.

SEPA Instant Scheme Requirements

SEPA Instant requires participating PSPs to:

• Meet strict <10-second processing targets
• Support 24/7 risk assessment
• Adopt AML/CTF enhancements
• Integrate name-matching capabilities natively

The increasing adoption of SEPA Instant across Europe means PSPs must scale their fraud operations to near-real-time, 24/7/365.

2024–2026 Regulatory Comparison Table

Requirement Area	UK (PSR + FPS)	EU (PSD3 + PSR + SEPA Instant)
Payee Verification	CoP mandatory	IBAN–name matching mandatory
Liability	Shared (50:50 PSP/PSP)	Member-state variation: shifting towards shared responsibility
Real-Time Fraud Monitoring	Required for FPS	Required for SEPA Instant
SCA Enhancements	Warning standards regulated	Contextual prompts mandated
Dispute Handling Timelines	Fixed regulatory timelines	Harmonised timelines under the Payments Package
Data Sharing	Mandatory across the PSP chain	Mandatory cross-border fraud reporting
Scheme Integration	FPS-specific controls	SEPA Instant mandatory controls

Between 2024 and 2026, both the UK and the EU will enforce the most extensive upgrades to instant-payment regulation since the launch of Faster Payments and SEPA. For merchants, these rules create a safer, more consistent environment for A2A payments, with stronger verification, fewer APP scams and clearer reimbursement rules. For PSPs and gateways, these requirements demand deeper integration with scheme rules, enhanced API architectures and real-time fraud intelligence at every step of the payment journey.

Roadmap for PSPs: What to Build in Q1–Q4 2026

The transition to shared APP liability requires PSPs and gateways to operate on a fixed regulatory timeline. While some obligations are already in force, the bulk of technical and operational controls must be implemented during 2026. To support compliant delivery, PSPs need a structured quarterly roadmap: beginning with foundational architecture in Q1, expanding into orchestration and routing intelligence by Q2, integrating reimbursement and dispute layers in Q3, and completing readiness audits and scheme certification in Q4.

The following roadmap outlines the minimum deliverables PSPs should achieve each quarter to remain compliant and commercially competitive.

Q1 2026: Build the Foundations (Verification, Data & Core Controls)

The first quarter focuses on building the core technical foundation required for APP liability-sharing. PSPs should prioritise:

1. Identity & Payee Verification

• Integrate Confirmation of Payee (UK)
• Implement IBAN–name matching (EU)
• Configure mismatch and partial-match handling logic
• Embed actor identity checks for high-risk merchants

2. Real-Time Data Infrastructure

• Build low-latency fraud-data pipelines
• Create unified identity and session profiles
• Implement event-driven data capture for risk signals

3. Base Fraud Controls

• Device fingerprinting
• Behavioural biometrics
• Anomaly detection for velocity and pattern shifts

4. API Schema Redesign

Roadmaps must include:

• Liability metadata fields
• Fraud flags
• Partner PSP payload extensions
• Match/mismatch verification fields

Outcome of Q1

By the end of March 2026, PSPs must have a repeatable verification and data foundation. Without these foundations, downstream routing, reimbursement logic and dispute APIs cannot operate correctly.

Q2 2026: Risk Engines, Smart Routing & Operational Readiness

Q2 is where PSPs shift from structural foundations to intelligent risk orchestration. This quarter has the heaviest engineering load and establishes the core differentiators between providers.

1. Real-Time Risk Engine Deployment

PSPs must deploy risk engines capable of:

• ML-based fraud scoring
• Multi-signal anomaly detection
• Contextual risk warnings
• Smart blocking and fallback logic

2. Liability-Aware Routing

PSPs and gateways must build routing logic that considers:

• Fraud risk
• Corridor-level risk density
• PSP reliability scores
• Expected reimbursement costs
• Mule detection strength of receiving banks

3. Merchant Segmentation & Onboarding

• MCC-based risk tiering
• Enhanced verification for high-risk verticals
• Revised onboarding questionnaires
• Improved merchant fraud controls

4. Internal Fraud & Compliance Training

Operational teams must be trained on:

• Dispute timelines
• Reimbursement obligations
• Escalation processes
• Liability attribution tests

Outcome of Q2

By June 2026, PSPs should have live risk engines and liability-aware routing feeding production traffic, at least for a subset of merchants.

Q3 2026: Reimbursement, Disputes & Full Fraud Operations

Q3 consolidates the previous engineering work and adds the dispute-response capability needed to satisfy UK PSR and EU regulatory standards.

1. Dispute & Reimbursement APIs

PSPs must build:

• Case creation APIs
• Structured claim formats
• Callback notifications
• Evidence-sharing endpoints
• Customer-notification templates
  

2. Fraud Operations Teams

PSPs must establish:

• 24/7 dispute triage
• Layered investigation teams
• High-risk incident workflows
• Fraud-pattern escalation processes

3. Enhanced Monitoring

Deploy:

• Mule-account network analysis
• Graph-based risk clustering
• Inbound/outbound anomaly linking
• Synthetic identity detection

4. Regulatory Reporting

Prepare for monthly or quarterly reporting on:

• Fraud volumes
• Reimbursement outcomes
• Dispute times
• Verification accuracy

Outcome of Q3

By September 2026, PSPs must be able to receive, process and resolve reimbursement cases within required timelines using API-driven workflows.

Q4 2026: Audit, Certification & Go-Live Hardening

The final quarter of 2026 is dedicated to finalising compliance, validating controls and preparing for full regulatory enforcement.

1. Internal & External Audits

• Conduct risk-control audits
• Validate transaction logs and evidence trails
• Review payee-verification coverage
• Perform scheme-driven compliance checks

2. Scheme Certification

FPS, SEPA Instant, and Open Banking certification may be required for:

• New verification logic
• Enhanced risk controls
• Dispute workflows
• Liability-tagged transaction flows

3. Production Hardening

• Latency tuning
• High-risk corridor throttling
• Redundancy for risk engines
• Validation of routing logic under peak load

4. Merchant Communication

PSPs must provide merchants with:

• Updated compliance guidance
• Payout-rule changes
• Verification UX templates
• API upgrade deadlines

Outcome of Q4

By the end of 2026, PSPs will operate fully compliant APP frameworks, with liability-aware routing, real-time verification, automated reimbursement flows and structured fraud operations.

2026 will be a defining year for A2A payments. PSPs that follow a structured quarterly roadmap will not only meet regulatory requirements but also gain commercial advantage by delivering safer, smarter and more predictable A2A experiences. Merchants benefit directly through reduced fraud losses, clearer payout processes and more stable instant-payment flows across the UK and EU.

Conclusion

APP fraud rules represent the most significant shift in A2A payment governance since the launch of Faster Payments and SEPA Instant. What began as a consumer-protection initiative has evolved into a complete restructuring of the liability, verification and monitoring expectations placed on PSPs, PISPs and gateways. The UK and EU now expect these firms to operate as active fraud-prevention layers, not passive technical processors.

For PSPs and gateways, the implications are strategic and long-lasting.

The next two years require:

• A realignment of product roadmaps
• Deep upgrades to verification and routing architecture
• Expanded API schemas
• Real-time fraud-intelligence capabilities
• Structured reimbursement and dispute workflows.

Gateways, in particular, must adjust their identity, routing and risk-scoring engines to reflect their new status as control points within the A2A ecosystem. Meanwhile, merchants will benefit from safer, more predictable payment flows, but should prepare for stronger verification, revised payout logic and tighter onboarding for high-risk corridors.

The regulatory direction is clear across both regions: liability follows capability.
If a PSP or gateway can see the risk, influence the routing decision, verify the payee or adjust the customer journey, regulators expect them to use that capability to prevent APP scams. Firms that do so effectively will not only meet regulatory requirements but also gain a commercial advantage by offering safer A2A acceptance and lower overall fraud exposure.

As the 2026 implementation deadlines approach, payment providers that invest early in data infrastructure, liability-aware routing, risk scoring, verification, and auditability will be the ones positioned to thrive in a market where instant payments become the default.

APP fraud reform not only change compliance. It reshapes how payments are built, how risks are shared, and how trust is established across the entire digital economy.

---

FAQs