PSD3 and PSR: What Payments Firms Must Know About KYC

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

That window is shorter than it sounds. Identity verification sits at the centre of PSR compliance, and the firms that treat onboarding as a one-time event are about to bear the legal and financial cost of that assumption.

What Changed Between PSD2 and PSD3

PSD2 introduced strong customer authentication (SCA) in 2018. It hardened the authentication layer but left a critical gap: it said little about the quality of identity checks that should precede the opening of a payment account in the first place.

PSD3 and the PSR close that gap.

The PSR makes three changes PSD2 did not:

First, fraud liability becomes symmetric. Under PSR, liability is split between the payer's PSP and the payee's PSP. If a receiving institution fails to screen inbound transactions or missed a fraudulent counterparty at onboarding, it can be held liable for the resulting loss.

Second, automatic SCA suspension for high-fraud PSPs. If a PSP's remote electronic transaction fraud rate exceeds 0.13%, the low-friction authentication exemption suspends automatically until the rate returns below threshold. There is no grace period.

Third, authorised push payment (APP) fraud reimbursement is normalised. Banks and PSPs must refund consumers 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.

Each of these changes has a direct implication for the identity verification stack — not just the authentication layer.

KYC at Onboarding Is Now the First Legal Line of Defence

Under PSR, what you know about your customer at the moment of account opening shapes your liability for everything that happens afterward.

A PSP that runs a weak onboarding check — accepting a document scan without liveness detection, skipping sanctions screening, or clearing a synthetic identity — cannot later claim it acted in good faith when that account is used for APP fraud. The onboarding failure becomes retrospective evidence of inadequate controls.

This shifts the compliance conversation from "what did the customer authorise" to "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

The deepfake threats targeting bank onboarding have reached a scale that makes the PSR liability framework unavoidable. One institution logged 8,065 deepfake attempts in eight months tied to $347 million in verified losses. Under PSR, those losses carry institutional liability unless the onboarding controls can demonstrate they were fit for purpose.

Mandatory Real-Time Monitoring Is a Legal Obligation

PSR mandates three categories of operational control: name-to-IBAN verification, real-time behavioural and device monitoring, and inbound transaction screening by receiving PSPs. These are not best practices. They are baseline obligations that trigger direct liability if absent.

The 0.13% SCA threshold makes the monitoring question even more consequential. A PSP that updates risk scores overnight rather than in real time will likely exceed the threshold before its systems detect the accumulation. At that point, the low-friction SCA exemption disappears across all transactions — not just the flagged ones.

The operational case for perpetual KYC has never been sharper: continuous, event-driven monitoring eliminates the lag between a risk trigger and a control response. Under PSR, that lag has a direct financial cost attached to it.

The EUDI Wallet as a Compliant SCA Instrument

The PSR explicitly recognises the EU Digital Identity Wallet as a valid SCA instrument. This creates a significant compliance opportunity for PSPs that act early.

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

This also satisfies SCA requirements simultaneously. The same EUDI Wallet presentation that confirms identity can serve as the SCA factor — collapsing two compliance obligations into a single interaction.

The December 2026 EUDI Wallet deployment deadline and the late 2026 PSR enforcement window arrive at almost exactly the same time. 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 PSR Was Designed to Address

PSR's fraud liability regime arrived in response to a specific threat pattern: authorised fraud powered by AI-generated social engineering, synthetic counterparties, and real-time identity manipulation.

Digital injection attacks — where synthetic video streams bypass the biometric API entirely rather than the camera — 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 shifts the question from "was this transaction authorised" to "did the PSP have the controls to detect that this authorisation was fraudulent." For AI-generated fraud, where the authorisation looks legitimate, the control question lands squarely at identity verification quality.

What PSPs Must Have Before Late 2026

Practical compliance preparation breaks into four workstreams:

1. Identity verification quality at onboarding

• Document verification with forensic metadata analysis
• Biometric liveness detection that is PAD-certified and injection-attack resistant
• Real-time sanctions and PEP screening at account opening
• Name-to-IBAN cross-check infrastructure

2. Ongoing monitoring for fraud-rate management

• Real-time behavioural and device risk scoring
• Event-driven re-verification for high-risk triggers
• Fraud-rate dashboards mapped against the PSR 0.13% SCA threshold
• Automated escalation when fraud rate approaches the suspension boundary

3. EUDI Wallet integration

• Relying party registration with national eIDAS 2.0 authority (start Q3 2026)
• ARF-compliant credential verification infrastructure
• Attribute mapping between wallet credentials and existing KYC data fields

4. APP fraud and social engineering controls

• Real-time payee-name/identifier mismatch warnings before transaction execution
• Friction injection for high-risk payment patterns
• Transaction monitoring linked to behavioural anomaly scoring

The Role of AI Agents in PSR Compliance

Meeting PSR's fraud rate threshold requires a monitoring layer that operates at machine speed. Manual review processes cannot maintain real-time fraud rate awareness across thousands of daily transactions. Human analysts reviewing flagged transactions cannot respond to behavioural anomalies before they cross the SCA suspension threshold.

This is the operational problem Joinble's AI Agents are built to solve. The agentic compliance layer monitors identity signals continuously, triggers re-verification on defined risk events, maintains a live fraud rate against the PSR threshold, and escalates autonomously when the buffer narrows. No batch cycles. No overnight lag. No end-of-quarter surprises.

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

PSR Compliance Timeline

Date	Obligation
April 23, 2026	PSD3 and PSR formally agreed
Late 2026 – Q1 2027	First enforcement wave: SCA, fraud liability, open banking
Q4 2026	EUDI Wallets deployed across all EU member states
December 2027	Mandatory EUDI Wallet acceptance for SCA use cases
2027–2028	Member states complete PSD3 transposition into national law

FAQ

Does PSD3/PSR replace PSD2's SCA requirements?

PSD2's SCA requirements carry forward and tighten under the PSR. The PSR adds the automatic suspension mechanism for PSPs with fraud rates above 0.13% and normalises APP fraud reimbursement, neither of which appeared in PSD2.

Does PSR apply to non-EU payment service providers?

PSR applies to PSPs operating in the EU — including passporting firms — when they process transactions involving EU customers or EU-connected payment accounts. Non-EU PSPs serving EU customers need to assess their PSR exposure on a service-by-service basis.

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

Authorised push payment fraud occurs when a legitimate account holder is manipulated into authorising a payment to a fraudulent counterparty. PSR mandates reimbursement for APP fraud victims and splits liability between the payer's and payee's PSP based on which institution's controls failed to detect the fraud.

How does the EUDI Wallet help with SCA compliance?

The EUDI Wallet is recognised as a valid SCA instrument under the PSR. A wallet presentation includes a government-issued identity attribute and a device-bound possession factor, satisfying the two-factor SCA requirement in a single interaction.

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

It is a requirement. PSR mandates real-time behavioural and device monitoring for fraud prevention. Batch-cycle monitoring does not satisfy this obligation, and PSPs that breach the 0.13% fraud rate threshold lose the low-risk SCA exemption automatically.

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

The low-risk transaction authentication exemption suspends automatically with no grace period. The PSP must apply full SCA to all remote electronic transactions until the fraud rate returns below threshold, increasing friction across the entire customer base.