PSD2 and PSD3 Strong Customer Authentication Guide

Strong customer authentication (SCA) is a legal requirement for most electronic payments and online account access in the EU, and getting the detail wrong means failed payments, unrecoverable fraud losses or a supervisory finding. The rules sit in two layers: the Second Payment Services Directive (PSD2, Directive (EU) 2015/2366) sets when SCA applies, and the Regulatory Technical Standards on SCA and common and secure communication (Commission Delegated Regulation (EU) 2018/389) set how it must work and which exemptions are allowed. A new Payment Services Regulation (PSR) and a third directive (PSD3) were agreed politically in November 2025 and will change liability and fraud prevention around SCA. This guide covers requirements, exemptions, third-party machine access, implementation, evidence and the PSR and PSD3 changes, for payment security, fraud, identity and compliance teams.

Key takeaways

Two layers, read both: PSD2 says when SCA is required; the RTS (Delegated Regulation 2018/389) sets the authentication code, dynamic linking, element independence, the exemptions and the third-party access interface.
Two independent elements from different categories: knowledge, possession and inherence. The EBA has said printed card details are neither knowledge nor possession, and an app counts as possession only with device binding.
Exemptions are optional and conditional: low value (EUR 30), contactless (EUR 50), trusted beneficiaries, recurring payments and transaction risk analysis each carry limits, and the transaction risk analysis exemption depends on fraud rates you must calculate and report.
Machine identities are part of SCA: third-party providers identify themselves to banks with qualified eIDAS certificates, and the dedicated interface, its tokens and its fallback are in scope of the RTS.
PSD3 and the PSR raise the stakes: the provisional agreement makes payment service providers refund impersonation fraud in defined cases, adds payee name checks and fraud data sharing, and keeps SCA with risk assessment. Check the final text and application dates before planning.

What it is and who it applies to

PSD2 defines strong customer authentication in Article 4(30) as authentication based on two or more elements from the categories of knowledge (something only the user knows), possession (something only the user has) and inherence (something the user is), which are independent so that a breach of one does not compromise the others, and designed to protect the confidentiality of the authentication data. Article 97 requires a payment service provider to apply SCA when the payer accesses a payment account online, initiates an electronic payment transaction, or carries out any action through a remote channel that may imply a risk of payment fraud or other abuses. For remote electronic payments, SCA must also include elements that dynamically link the transaction to a specific amount and a specific payee.

Who must apply it: the payer's provider (card issuer or account servicing institution). Merchants and acquirers must support it, for example through EMV 3-D Secure. See the Payment Fraud Guide for the 3DS and chargeback side.
Third-party providers: payment initiation (PISP) and account information (AISP) providers may rely on the account holder bank's authentication, through a secure interface.
Dates: the RTS have applied since 14 September 2019.

Liability makes SCA commercially important: payer liability for unauthorised transactions is capped (EUR 50 in recital 71); where the payer's provider does not require SCA, the payer bears no loss unless they acted fraudulently; and a payee or its provider that fails to accept SCA must refund the payer's provider.

Structure and key requirements

The RTS article by article

RTS article	Requirement	What it means in practice
Art. 2	Transaction monitoring	Monitor for unauthorised or fraudulent payments using at least: lists of compromised or stolen authentication elements, the transaction amount, known fraud scenarios, signs of malware in the session, and abnormal use of the access device or software
Art. 3	Review and audit	SCA measures documented, tested and audited by independent auditors with IT security expertise; yearly audit of the transaction risk analysis methodology where Art. 18 is used
Art. 4	Authentication code	Two or more elements generate a one-time code; failure messages must not reveal which element was wrong; at most five consecutive failed attempts before a temporary or permanent block; online session ends after at most 5 minutes of inactivity
Art. 5	Dynamic linking	Payer is shown the amount and payee; the code is specific to that amount and payee; any change invalidates the code; batch payments link to the total and the list of payees
Art. 9	Independence	On a multi-purpose device such as a phone, use separate secure execution environments and mechanisms to detect and mitigate alteration of the device
Arts. 22 to 27	Personalised security credentials	Mask credentials on entry, never store them in plain text, create and deliver them securely, require SCA for remote binding of a credential to a user, and revoke and reset devices securely
Arts. 28 to 36	Common and secure communication	Mutual identification, unique session identifiers and time-stamped logs, access interface for third-party providers, eIDAS certificates, session security and data exchange limits

Which elements count

Examples from the EBA Opinion on the elements of SCA (EBA-Op-2019-06, 21 June 2019):

Category	Compliant examples (EBA opinion)	Not compliant
Knowledge	Password, PIN, passphrase, knowledge-based challenge, memorised swiping path	Username or email address, printed card details, OTP generated by or received on a device (that evidences possession)
Possession	OTP from a hardware or software token or by SMS, device-generated signature, app or browser with device binding, card reader evidence, dynamic card security code	App installed without device binding, printed card details, printed OTP lists or matrix cards
Inherence	Fingerprint, face, voice, iris, vein, keystroke dynamics, heart rate or body movement patterns	Data sent through EMV 3-D Secure as then observed by the EBA

In Q&A 2019_4671 the EBA confirmed that a combination of card details, an SMS OTP and EMV 3DS behavioural data does not meet SCA, because card details are not a valid element and the 3DS data is not inherence. SMS OTP is still possession, but is exposed to SIM swap and real-time phishing. Passkeys and FIDO2 authenticators bound to the device give possession plus a local knowledge or inherence check in one phishing-resistant step; see the Phishing-Resistant MFA Guide and the Passwordless and Passkeys Guide.

Exemptions and thresholds

Exemption (RTS)	Condition	When SCA is still needed
Account information (Art. 10, 10a)	Viewing balance or the last 90 days of transactions, no sensitive payment data shown	First access, and when more than 180 days have passed since the last SCA (since 25 July 2023, under Delegated Regulation 2022/2360); for access through an AISP, Art. 10a makes the exemption mandatory
Contactless at point of sale (Art. 11)	Single payment up to EUR 50	When cumulative contactless spend since the last SCA exceeds EUR 150, or after five consecutive contactless payments (issuer chooses the counter)
Unattended terminals (Art. 12)	Transport fares and parking fees	No amount limit in the RTS
Trusted beneficiaries (Art. 13)	Payee on a list the payer created	Creating or changing the list
Recurring transactions (Art. 14)	Series with the same amount and payee	Creating, amending or first initiating the series
Own accounts (Art. 15)	Transfers between accounts of the same person at the same provider	Not applicable
Low-value remote (Art. 16)	Single remote payment up to EUR 30	When cumulative spend since the last SCA exceeds EUR 100, or after five consecutive remote payments
Secure corporate processes (Art. 17)	Dedicated payment processes and protocols for legal persons	Only where the competent authority is satisfied they give equivalent security
Transaction risk analysis (Art. 18)	Remote payment assessed as low risk in real time, provider fraud rate within the reference rate for the threshold band	Any risk signal (abnormal spending, unknown device, malware, known fraud scenario, abnormal payer location, high-risk payee location)

The transaction risk analysis exemption is tied to the provider's own fraud rate, calculated over a rolling 90 days as the value of unauthorised or fraudulent remote transactions divided by the value of all remote transactions of that type (Art. 19). The Annex reference rates are:

Exemption threshold value	Remote card-based payments	Remote credit transfers
EUR 500	0.01%	0.005%
EUR 250	0.06%	0.01%
EUR 100	0.13%	0.015%

A provider above the reference rate must report immediately and, after two consecutive quarters above it, stop using the exemption for that band until one compliant quarter is evidenced to the authority (Art. 20). The payer's provider decides whether to apply any exemption.

Identity and NHI requirements

Much of the RTS governs machine-to-machine access, which is where non-human identities appear.

Third-party provider identity: under Art. 34, PISPs and AISPs identify themselves to the bank with qualified certificates for electronic seals or qualified website authentication certificates under eIDAS (Regulation (EU) No 910/2014). The certificate states the provider's role and competent authority. Treat these certificates and keys as high-value machine credentials: inventory them, keep keys in an HSM, and track expiry and revocation. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Dedicated interface: banks must give third-party providers at least one access interface (Art. 30), either a dedicated API or adapted access to the customer interface (Art. 31). A dedicated interface must perform as well as the customer channel and publish quarterly availability statistics (Art. 32). Unplanned unavailability is presumed when five consecutive requests get no reply within 30 seconds, and a fallback must exist unless the authority has granted an exemption (Art. 33).
Tokens and sessions: after the customer authenticates, the third party typically holds an OAuth access token or consent identifier. Art. 35 requires strong encryption, short sessions, prompt termination and parallel sessions linked to the user session. Art. 36 caps unattended account information requests at four per 24 hours. Bind tokens to the client, log their use and revoke them when consent ends. See the OAuth 2.1, GNAP and FAPI Guide.
Traceability: Art. 29 requires unique session identifiers, logs of each transaction and session, and timestamps synchronised to an official time reference.
Agents and automated payments: AI agents and scripts that pay on a user's behalf do not change the rule that SCA belongs to the payer. Design agent payments around a mandate the payer authenticates with SCA (for example a recurring series or a trusted beneficiary), never by storing the payer's credentials in the agent. See the Agent Payments Protocols Guide.

What PSD3 and the Payment Services Regulation change

The Commission proposed PSD3 and the PSR on 28 June 2023, and the Council and Parliament reached a provisional agreement in November 2025 (Council press release of 27 November 2025). At 24 October 2026 the Commission's payment services page still lists the revision as ongoing, and formal adoption and Official Journal publication could not be confirmed from an official source. Treat the points below as the agreed direction and check EUR-Lex for the final text and application dates.

Area	PSD2 today	Provisional PSR and PSD3 agreement
Legal form	Directive transposed nationally, plus RTS	Directly applicable regulation (PSR) for conduct, SCA, open banking and fraud; PSD3 directive for authorisation and supervision
SCA	Art. 97 and the RTS	SCA retained; providers must ensure SCA and carry out a risk assessment (European Parliament press release)
Impersonation fraud	No specific refund rule for payments the payer authorised under deception	Where a fraudster poses as the provider's employee and the payer approves a payment, the provider refunds the full amount if the payer reports it to the police and the provider
Altered or fraudster-initiated payments	Unauthorised transaction rules of Arts. 73 and 74	Treated as unauthorised, with the provider liable for the full amount
Payee checks	Verification of payee only for euro instant payments	IBAN checked against the payee name before transfers more widely
Fraud prevention	Transaction monitoring under RTS Art. 2	Fraud information sharing between providers; spending limits and blocking tools; provider liable if preventive tools are missing
Online platforms	Out of scope	Platforms liable to providers that refunded victims if notified of fraudulent content and they failed to remove it

Until new technical standards under the PSR apply, Delegated Regulation 2018/389 remains the operative SCA text.

Implementation steps

Map the triggers. List every channel and action: online banking login, mobile app, card-not-present payments, contactless, payee and limit changes, credential reset, device enrolment, third-party consents. Mark the Art. 97 trigger and any exemption used.
Choose elements per journey. Prefer device-bound app authentication or passkeys with a local biometric or PIN. Keep SMS OTP only as a fallback with SIM-swap checks.
Build dynamic linking. Show amount and payee inside the authenticator, sign over both, and reject the code if either changes.
Secure the credential lifecycle. Enrolment, device binding, replacement and recovery are the weakest points: require SCA or an equivalent in-branch or identity-verified process to bind a new device (Art. 24), and send activation through a separate channel (Art. 25).
Implement exemptions in a rules engine. Counters for EUR 30, 100 and 150 limits, five-transaction counters, 180-day account information timers, beneficiary and recurring flags, and a transaction risk score with the Art. 18 signals. Log a reason code for each exemption.
Pilot and measure. Run new flows for a small customer segment, compare abandonment and fraud, then widen. Keep the old authenticator available as a rollback path.
Open the interface. Publish dedicated interface documentation and a testing facility, issue and validate eIDAS certificates, implement the 30-second availability rule and the fallback or an exemption.
Plan for the PSR. Add payee name verification, fraud data sharing, spending limits and impersonation fraud handling to the roadmap, and budget for refunds in the fraud model.

Small institutions often outsource SCA and the interface to a processor, but the obligation stays with the licensed provider: contract for audit rights, logs and statistics. Larger groups usually centralise the authenticator and risk engine, which simplifies the Art. 19 calculation.

Evidence and assessment

Independent audit (Art. 3): documented, tested and audited SCA measures; where Art. 18 is used, a yearly audit of methodology, model and fraud rates, by an external auditor the first year and at least every three years.
Fraud records (Art. 21): quarterly, per payment type and remote or non-remote: total fraud value, observed fraud rate, average transaction value and the number and share of transactions executed under each exemption.
Interface evidence: quarterly availability and performance statistics for the dedicated interface compared with the customer channel, and documented contingency measures.
Logs: session identifiers, authentication outcomes, exemption reason codes and credential lifecycle events.

Metrics: SCA completion rate by channel; share of volume per exemption; fraud rate per Art. 18 band against the reference; account takeover after device enrolment or reset; dedicated interface uptime against the customer channel.

Mapping to other frameworks

SCA area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ATT&CK threat addressed
Two independent elements, authentication code	PR.AA-03	IA-2, IA-2(1), IA-2(8), IA-5	T1078 Valid Accounts, T1111 Multi-Factor Authentication Interception
Dynamic linking, payee checks	PR.AA-03	IA-2(8)	T1657 Financial Theft, T1566 Phishing
Transaction monitoring and risk analysis	DE.CM-03, ID.RA-05	SI-4, RA-3, AU-6	T1539 Steal Web Session Cookie, T1621 Multi-Factor Authentication Request Generation
Credential lifecycle (RTS Arts. 22 to 27)	PR.AA-01	IA-5, AC-2	T1078 Valid Accounts
Third-party access and certificates	PR.AA-01, GV.SC-07	IA-5, SR-6	T1078 Valid Accounts

For ISO/IEC 27001:2022, the closest Annex A controls are 5.17 Authentication information, 8.5 Secure authentication and 8.16 Monitoring activities. Banks in scope of DORA (Regulation (EU) 2022/2554) must also meet its ICT risk rules, including strong authentication for remote and privileged access under Delegated Regulation 2024/1774; see the DORA Guide and the EBA ICT and Security Risk Guidelines Guide.

Common pitfalls

Counting card details as a factor: PAN, expiry and printed CVV are not an SCA element. A flow of card details plus SMS OTP is single-factor.
Weak device binding: an unbound app is not possession; bind keys to the platform keystore and detect tampering (Art. 9).
Recovery that bypasses SCA: resetting a PIN or enrolling a new phone with only knowledge-based questions or an SMS sent to a ported number hands account takeover to fraudsters. See the Account Takeover Prevention Guide.
Broken exemption counters: counters not shared across channels let exempted payments exceed the EUR 100 or five-payment limits.
Under-reported fraud: it flatters the Art. 18 fraud rate until the Art. 3 audit finds it.
Ignoring impersonation fraud because SCA was passed: customers persuaded to approve a payment still complete SCA. Under the PSR agreement, providers will carry that loss in defined cases, so payee checks and in-app warnings matter as much as the authenticator.

Practitioner checklist

Inventory every Art. 97 trigger across channels and record the element combination and any exemption used.
Confirm no flow counts card details, usernames or unbound apps as an element.
Enforce the five-attempt limit, non-revealing error messages and the 5-minute inactivity timeout.
Secure device enrolment, credential delivery and recovery with SCA or an equivalent verified process.
Log exemption reason codes and reconcile the Art. 21 quarterly fraud figures against the Annex reference rates.
Manage eIDAS certificates and keys used for third-party access as privileged machine credentials, with expiry monitoring.
Measure dedicated interface availability against the customer channel and publish quarterly statistics.
Track the PSR and PSD3 final texts on EUR-Lex and plan payee name checks, fraud data sharing and refund handling.

Standards and references

Related NHI Mgmt Group resources: Financial Services Identity Security Guide · Payment Fraud Guide · Passkey Rollout Guide · DORA and NIS2 Overlap Mapping Guide · Fraud Prevention Guide for Digital Businesses. This guide summarises PSD2, the RTS on strong customer authentication and the provisional PSD3 and PSR agreement and is not legal advice.

PSD2/PSD3 Strong Customer Authentication Guide: Requirements, Exemptions and Changes