PSD3European UnionFintech

PSD3 & PSR: Strong Customer Authentication and KYC

PSD3 and the PSR reshape EU payments from 2027: biometric SCA, payee verification, and what they mean for your KYC, fraud controls, and licensing.

PSD3 raises the bar on proving who is behind a payment

On 27 November 2025, EU co-legislators struck a political agreement on the package that replaces PSD2: a third Payment Services Directive (PSD3) and, alongside it, a directly applicable Payment Services Regulation (PSR). The agreed texts were published in April 2026. General application lands roughly 21 months after the rules hit the Official Journal — so the earliest most obligations bite is the second half of 2027, with some slipping into 2028.

"2027" reads as far away. It isn't, for two reasons. The authentication patterns most fintechs built for PSD2 are about to become non-compliant, and re-authorising your licence under PSD3 is a project you start in 2026, not the week before the deadline.

This guide covers what PSD3 and the PSR change for authentication, fraud, and the identity checks underneath — and what you do about it now.

Two instruments, one rulebook

The split matters because it changes how the rules reach you:

  • PSD3 (a directive) governs the licensing of payment institutions. It merges the separate payment-institution and e-money-institution regimes into one, and tightens the authorisation requirements — including the AML and KYC frameworks an applicant must demonstrate.
  • PSR (a regulation) governs conduct: strong customer authentication, fraud, transparency, and access to data. Because it is a regulation, it applies directly in every member state with no national transposition, which removes the gold-plating and divergence that fragmented PSD2.

If you hold or are applying for a payment or e-money licence, both land on you at once. The licence sits in the directive; the day-to-day authentication and fraud duties sit in the regulation.

Strong customer authentication gets stricter — and biometric

PSD2 made SCA mandatory. The PSR rebuilds it around risk and biometrics.

  • Adaptive, risk-based authentication. PSPs must run authentication that reflects user behaviour, transaction patterns, and current fraud typologies — not a fixed two-factor prompt on every action.
  • Biometrics, both kinds, are explicitly on the table. The agreement allows SCA built from physiological biometrics — fingerprint, facial recognition — combined with behavioural biometrics such as typing rhythm and screen-touch patterns. Behavioural signals can serve as an authentication element, not just a fraud score.
  • Accessibility becomes a legal right. PSPs must offer at least one SCA method that works for customers without a smartphone, with disabilities, or with low digital skills. This is the clause that breaks the most existing flows: a smartphone-only push-approval setup no longer satisfies the rule on its own.

For most teams, the inherence factor moves from "selfie at onboarding" to a continuous, accessible, biometric capability. That is an identity problem before it is a payments problem.

Verification of Payee: matching a name to an account

The PSR extends a Verification of Payee (VoP) duty across the EU. Before a transfer is processed, the payer's PSP must check that the payee's name matches the account identifier (the IBAN) and warn the payer of a mismatch. This obligation, and the liability attached to it, applies 24 months after the regulation enters into force — a longer runway because it forces system changes on both sending and receiving sides.

VoP is, at its core, an identity-data matching problem: resolving a claimed name against the verified holder of an account. Get the matching logic wrong and you either wave through fraud or bury customers in false-positive warnings they learn to ignore.

The fraud-liability shift

The PSR keeps the basic rule that a payer who authorises a fraudulent payment carries the loss. But it carves out where the provider pays instead:

  • Failure to flag a payee-name/identifier mismatch can shift liability to the PSP that skipped or botched the VoP check.
  • Impersonation ("spoofing") fraud, where a criminal poses as the bank or a public authority, can move liability to the PSP under the agreed terms.
  • SCA failures can attach liability to scheme operators and technical service providers, not only the customer-facing bank.

Translation: weak authentication and weak payee verification stop being a customer's problem and become a balance-sheet item for you and your vendors.

Where KYC actually fits

PSD3/PSR is a payments rulebook, but it leans on identity at three points:

  • Licensing. A PSD3 authorisation (or re-authorisation) requires you to evidence robust AML and KYC procedures. The same onboarding due diligence that satisfies MiCA for crypto and the EU AML package is what a payment-institution applicant must show. If you need the fundamentals first, start with what KYC is.
  • Authentication. Biometric and behavioural SCA is identity verification running continuously, not once at sign-up.
  • Fraud and mule accounts. Strong onboarding identity checks are the cheapest place to stop the synthetic and mule accounts that downstream fraud rules then have to chase.

PSD3 and eIDAS 2 also intersect: a high-assurance EU Digital Identity Wallet credential can underpin both onboarding and the inherence factor in SCA.

The reality check: your PSD2 setup is already behind

Here is the contrarian read most payments vendors won't lead with: the long timeline is a trap. Three pieces of work cannot wait for 2027.

  • Smartphone-only SCA is already non-compliant in spirit. The accessibility mandate means you need a non-smartphone authentication path. Building that touches your core auth flow, not a side feature.
  • Behavioural biometrics take data and time to train. You cannot switch on behaviour-based authentication the month the rule applies; the models need history.
  • VoP changes both sides of every transfer. Twenty-four months is the runway precisely because the plumbing is deep.

Teams that treat PSD3 as a 2027 problem will spend 2027 firefighting. The ones that win start the authentication and identity rebuild against the 2026 texts.

How Joinble fits

Joinble's AI-powered identity platform covers the identity layer the PSR now demands:

  • Physiological biometric verification with certified liveness for the inherence factor in SCA, plus an accessible fallback for customers who can't use a smartphone flow.
  • Adaptive, risk-based authentication where Joinble's identity agents weigh behaviour and transaction context to decide when to step up a challenge — rather than prompting on every action.
  • Identity verification and AML screening for payment- and e-money-institution onboarding, the evidence a PSD3 licence application requires.
  • Name-to-identity matching to support Verification of Payee logic without drowning customers in false positives.

For fintech teams already running KYC on Joinble, the SCA and VoP work extends the same identity stack instead of bolting on a separate authentication vendor.

How to prepare before the deadline

  • Map every SCA touchpoint and find the ones that assume a smartphone — those need an accessible alternative first.
  • Start collecting the behavioural data your future authentication models will need; you cannot backfill it.
  • Treat Verification of Payee as a data-matching project on both inbound and outbound transfers, and budget for false-positive tuning.
  • Fold the PSD3 licence re-authorisation, with its AML/KYC evidence, into your 2026 roadmap rather than your 2027 one.

FAQ

What is the difference between PSD3 and the PSR?

PSD3 is a directive that governs the licensing of payment and e-money institutions and must be transposed into national law. The PSR is a regulation that governs conduct — strong customer authentication, fraud, and transparency — and applies directly across the EU without national transposition. Most fintechs are affected by both at once.

When do PSD3 and the PSR apply?

EU co-legislators reached political agreement in November 2025, with texts published in April 2026. Most obligations apply roughly 21 months after publication in the Official Journal, so the earliest is the second half of 2027, and some duties extend into 2028. The Verification of Payee obligation applies 24 months after the regulation enters into force.

Does the PSR require biometric authentication?

The PSR does not force biometrics, but it explicitly permits strong customer authentication built from physiological biometrics (fingerprint, facial recognition) and behavioural biometrics (typing and touch patterns). It also requires at least one authentication method that works for customers without a smartphone, with disabilities, or with low digital skills.

What is Verification of Payee under the PSR?

Verification of Payee requires the payer's payment service provider to check that the payee's name matches the account identifier (IBAN) before a transfer and warn the payer of any mismatch. Failing to perform this check correctly can shift fraud liability to the provider. The obligation applies 24 months after the regulation enters into force.

How does PSD3 affect KYC obligations?

PSD3 requires payment and e-money institutions to evidence robust AML and KYC frameworks to obtain or renew authorisation. Beyond licensing, the PSR's biometric and behavioural SCA is identity verification performed continuously, and strong onboarding identity checks remain the most effective control against the mule and synthetic accounts that drive payment fraud.

Automate your compliance with AI Agents

Joinble's Agentic Identity platform reduces manual KYC reviews by up to 80%. Book a demo to see it in action.

Book a demo