PSD3 and PSR: What Payments Firms Must Know About KYC

PSD3 and PSR shift fraud liability to PSPs who miss identity checks. Here is what payment firms need before late-2026 enforcement kicks in.

Emily Carter
By Emily CarterAI Strategy Consultant at Joinble
·8 min read
Share
PSD3 and PSR: What Payments Firms Must Know About KYC
imageUse this imagedownloadDownload

The European Parliament, the Council, and the European Commission struck a final agreement on April 23, 2026 covering the Payment Services Directive 3 (PSD3) and its accompanying Payment Services Regulation (PSR). Strong customer authentication, fraud liability, and open banking form the first enforcement wave, which is expected to land in late 2026.

Shorter than it sounds, that remaining window leaves little slack. Identity verification sits at the centre of PSR compliance. Payment firms that still treat onboarding as a one-time event will soon bear the legal and financial cost of that assumption.

How PSD3 and the PSR Diverge From PSD2

Strong customer authentication (SCA) arrived with PSD2 in 2018. The authentication layer was hardened, yet a critical gap stayed open: almost nothing was said about the quality of identity checks that should precede the opening of a payment account in the first place.

That gap is what PSD3 and the PSR close.

Three changes that PSD2 never made now sit inside the PSR:

Fraud liability is now symmetric. PSR splits liability between the payer's PSP and the payee's PSP. A receiving institution that fails to screen inbound transactions, or that missed a fraudulent counterparty at onboarding, can be held liable for the resulting loss.

High-fraud PSPs lose SCA exemptions automatically. If a PSP's remote electronic transaction fraud rate exceeds 0.13%, the low-friction authentication exemption suspends automatically and stays suspended until the rate returns below threshold. No grace period exists.

Authorised push payment (APP) fraud reimbursement is normalised. Banks and PSPs must refund consumers who were manipulated into authorising fraudulent transfers where the PSP failed to detect social engineering patterns or did not apply required fraud warnings. Liability attaches specifically to the monitoring failure.

Direct implications follow for the identity verification stack, not merely for the authentication layer.

Liability for everything that happens afterward is shaped, under PSR, by what you know about your customer at the moment of account opening.

Run a weak onboarding check — a document scan without liveness detection, skipped sanctions screening, or clearance of a synthetic identity — and the PSP cannot later claim it acted in good faith when that account is used for APP fraud. Retrospective evidence of inadequate controls is exactly what that onboarding failure becomes.

Compliance talk therefore moves away from "what did the customer authorise" and toward "what did the PSP know before approving the account."

Three onboarding failures become particularly expensive under PSR:

Onboarding Failure PSR Liability Exposure
No name-to-IBAN check at account opening Liability for outbound fraud enabled by the account
No real-time sanctions screening Liability for transactions linked to sanctioned parties
No biometric liveness check Inability to defend against synthetic identity claims

At the scale now reached by deepfake threats targeting bank onboarding, the PSR liability framework is unavoidable. Tied to $347 million in verified losses, 8,065 deepfake attempts were logged by one institution across eight months. Those losses carry institutional liability under PSR unless the onboarding controls can demonstrate they were fit for purpose.

Three categories of operational control are mandated by PSR: name-to-IBAN verification, real-time behavioural and device monitoring, and inbound transaction screening by receiving PSPs. Best practices they are not. They are baseline obligations, and their absence triggers direct liability.

Monitoring becomes even more consequential because of the 0.13% SCA threshold. Overnight risk-score updates, instead of real-time scoring, will likely push a PSP over the threshold before systems even notice the accumulation. The low-friction SCA exemption then vanishes across every transaction, not only those already flagged.

Never has the operational case for perpetual KYC been sharper. Continuous, event-driven monitoring removes the lag between a risk trigger and a control response. That lag now carries a direct financial cost under PSR.

EUDI Wallet: A Compliant SCA Instrument

The EU Digital Identity Wallet is explicitly recognised by the PSR as a valid SCA instrument. Acting early creates a significant compliance opportunity for PSPs.

Under eIDAS 2.0, cryptographically signed identity attributes — name, date of birth, nationality, tax ID — sit inside the EUDI Wallet, issued by government authorities. A PSP that accepts a EUDI Wallet credential during onboarding acquires a legally equivalent substitute for traditional identity document verification. The credential also cannot be replicated or forged without breaking the national trust chain.

SCA requirements are satisfied at the same moment. The same EUDI Wallet presentation that confirms identity can serve as the SCA factor, collapsing two compliance obligations into a single interaction.

Almost exactly the same moment brings the December 2026 EUDI Wallet deployment deadline and the late 2026 PSR enforcement window. For PSPs that integrate EUDI Wallet acceptance before enforcement begins, PSD3/PSR compliance and eIDAS 2.0 compliance become the same project.

The AI Fraud Problem That PSR Targets

A specific threat pattern prompted the PSR fraud liability regime: authorised fraud powered by AI-generated social engineering, synthetic counterparties, and real-time identity manipulation.

Where synthetic video streams bypass the biometric API entirely rather than the camera, digital injection attacks have become the dominant fraud vector targeting remote identity verification. Synthetic identity fraud now costs the financial industry an estimated $3.1 billion annually, and AI-driven account takeovers are up 250% year over year.

PSR recasts the question from "was this transaction authorised" into "did the PSP have the controls to detect that this authorisation was fraudulent." Authorisation looks legitimate in AI-generated fraud, so the control question lands squarely at identity verification quality.

What PSPs Need in Place Before Late 2026

Four workstreams make up practical compliance preparation:

1. Identity verification quality at onboarding

  • Forensic metadata analysis as part of document verification
  • PAD-certified biometric liveness detection that resists injection attacks
  • Sanctions and PEP screening in real time at account opening
  • Infrastructure for name-to-IBAN cross-checks

2. Ongoing monitoring for fraud-rate management

  • Behavioural and device risk scoring in real time
  • Re-verification driven by high-risk events
  • Dashboards that map fraud rates against the PSR 0.13% SCA threshold
  • Escalation that fires automatically as the fraud rate nears the suspension boundary

3. EUDI Wallet integration

  • Register as a relying party with the national eIDAS 2.0 authority (start Q3 2026)
  • Credential verification infrastructure that is ARF-compliant
  • Mapping of attributes from wallet credentials onto existing KYC data fields

4. APP fraud and social engineering controls

  • Warnings in real time when payee name or identifier mismatches, issued before the transaction executes
  • Injection of friction on high-risk payment patterns
  • Transaction monitoring tied to behavioural anomaly scoring

How AI Agents Fit PSR Compliance

A monitoring layer that operates at machine speed is required to meet PSR's fraud rate threshold. Real-time fraud rate awareness across thousands of daily transactions cannot be maintained by manual review processes. Behavioural anomalies will cross the SCA suspension threshold before human analysts reviewing flagged transactions can respond.

Joinble's AI Agents are built to solve this operational problem. Identity signals are monitored continuously by the agentic compliance layer, which triggers re-verification on defined risk events, keeps a live fraud rate against the PSR threshold, and escalates autonomously when the buffer narrows. Batch cycles are gone. Overnight lag is gone. End-of-quarter surprises are gone.

Machine-speed monitoring is what the PSR's compliance architecture assumes. Static, periodic KYC systems will fail to maintain the operational posture the regulation demands.

Timeline for PSR Compliance

Date Obligation
April 23, 2026 Formal agreement on PSD3 and PSR
Late 2026 – Q1 2027 First enforcement wave covering SCA, fraud liability, and open banking
Q4 2026 EUDI Wallet deployment across all EU member states
December 2027 EUDI Wallet acceptance becomes mandatory for SCA use cases
2027–2028 PSD3 transposition into national law completed by member states

FAQ

Does PSD3/PSR replace PSD2's SCA requirements?

Under the PSR, PSD2's SCA requirements carry forward and tighten. An automatic suspension mechanism for PSPs with fraud rates above 0.13% is added by the PSR, and APP fraud reimbursement is normalised — neither of which appeared in PSD2.

Does PSR apply to non-EU payment service providers?

PSPs operating in the EU, including passporting firms, fall under PSR when they process transactions involving EU customers or EU-connected payment accounts. Service-by-service assessment of PSR exposure is needed for non-EU PSPs that serve EU customers.

What is APP fraud and why does PSR address it specifically?

A legitimate account holder manipulated into authorising a payment to a fraudulent counterparty is the definition of authorised push payment fraud. Reimbursement for APP fraud victims is mandated by PSR, which splits liability between the payer's and payee's PSP according to which institution's controls failed to detect the fraud.

How does the EUDI Wallet help with SCA compliance?

Under the PSR, the EUDI Wallet is recognised as a valid SCA instrument. Government-issued identity attributes plus a device-bound possession factor are included in a wallet presentation, so the two-factor SCA requirement is satisfied in a single interaction.

Is real-time fraud monitoring a PSR requirement or just a best practice?

It is a requirement. Real-time behavioural and device monitoring for fraud prevention is mandated by PSR. Batch-cycle monitoring does not satisfy this obligation. Breach the 0.13% fraud rate threshold and the low-risk SCA exemption is lost automatically.

What happens if a PSP exceeds the 0.13% SCA fraud rate threshold?

With no grace period, the low-risk transaction authentication exemption suspends automatically. Full SCA must then be applied to all remote electronic transactions until the fraud rate returns below threshold, which increases friction across the entire customer base.

Emily CarterEmily Carter
Share

Related Articles

DORA and KYC: Identity Vendors Are Now ICT Third Parties
Compliance31 Aug, 2026

DORA and KYC: Identity Vendors Are Now ICT Third Parties

DORA's ICT third-party rules apply to KYC vendors from 2025. Here's what financial firms must audit, contract, and monitor to stay compliant in 2026.

SR 26-2: The Governance Gap in AI-Powered KYC
Compliance17 Aug, 2026

SR 26-2: The Governance Gap in AI-Powered KYC

The Fed's new model risk guidance explicitly excludes generative and agentic AI. For banks using AI in KYC, that gap is now a compliance liability.

KYB Under AMLR: The UBO Threshold Trap of 2027
Compliance13 Aug, 2026

KYB Under AMLR: The UBO Threshold Trap of 2027

44% of KYB processes will fail the EU AMLR's new UBO threshold rules from July 2027. Here's how to audit your beneficial ownership verification now.