PSD3/PSR and the Future of SCA: What's Changing for 3DS

The European Parliament and Council of the EU reached provisional political agreement on PSD3 and the accompanying Payment Services Regulation (PSR) in November 2025. The legislative shape is now clear enough to act on, before formal publication and transposition. For payment teams, the SCA-related changes are the most operationally significant part of the package, and some require action before the PSR comes into force.

This article unpacks what actually changes under PSD3/PSR for 3DS and SCA, what stays the same, and what the expected 2026/2027 implementation timeline means for how you should be prioritising your authentication roadmap now.

The legislative context: PSD3 directive plus PSR regulation

Unlike PSD2, which was a directive requiring transposition into each member state's national law, PSD3 is accompanied by the PSR, a regulation that applies directly across the EU without national transposition. This matters in practice: the PSR provisions, which cover most of the SCA and fraud liability rules, will apply uniformly and simultaneously across all EU member states. The patchwork of inconsistent national implementations that complicated PSD2 compliance for cross-border merchants is intended to be substantially reduced.

The provisional political agreement reached in November 2025 still requires formal adoption and publication in the Official Journal. Once published, member states will have an implementation period; most estimates point to a compliance deadline in 2026 or early 2027. The 18-month transition period that applied to the PSD2 RTS is the reference point, though the exact timeline will be confirmed in the final text.

What changes for SCA and 3DS

SCA delegation is now explicitly outsourcing

This is arguably the most significant operational change for payment teams using third-party authentication services. Under PSD2, the rules around SCA delegation, where a PSP delegates the authentication function to a third party such as a digital wallet provider, payment gateway, or 3DS Server, were ambiguous and inconsistently applied across member states.

PSD3/PSR resolves this explicitly: where a PSP delegates SCA functions to a third party, this is classified as outsourcing under the EBA outsourcing guidelines and is subject to DORA (Digital Operational Resilience Act) requirements. In practice, this means:

• PSPs must document the delegation arrangement formally as an outsourcing relationship.
• Third-party authentication providers (including 3DS Server providers) must meet DORA's ICT risk management and resilience requirements.
• If the delegated party fails to apply SCA correctly, the PSP remains liable.

For merchants and payment managers, this changes the due diligence question when selecting or renewing a 3DS Server provider. It is no longer sufficient to verify that the provider is scheme-certified; you now need to verify their DORA compliance posture and confirm the contractual framework meets outsourcing governance requirements.

‍Operational note: If your current 3DS Server arrangement does not have a formal outsourcing agreement in place, with documented controls, sub-outsourcing notifications, and exit provisions, this is a gap to address ahead of the PSR coming into force. Scheme certification alone will not satisfy the outsourcing governance requirement.

MIT treatment clarified and aligned to direct debit rules

PSD2 left merchant-initiated transactions (MITs) in a grey area: the regulation did not explicitly address MITs, and implementation guidance evolved informally through EBA Q&As. PSD3/PSR addresses this directly. The treatment is now codified: SCA is required at the point of mandate set-up, but not for each subsequent MIT in the series. Subsequent MITs are explicitly aligned to direct debit consumer protection rules, including enhanced refund rights.

What this means for recurring billing operations: the initial authenticated CIT that establishes the mandate becomes even more critical. If the initial mandate was not properly set up with full SCA authentication and a network transaction ID reference, subsequent MITs may be treated as new CITs, triggering soft declines. Review your mandate set-up flows against this requirement before the PSR applies.

SCA accessibility becomes a legal right

PSD3/PSR introduces a new accessibility requirement: PSPs must offer at least one SCA method suitable for customers without smartphones, with disabilities, or with limited digital literacy. This is a significant shift. Currently, most 3DS challenge flows are designed around mobile: push notification, biometric via banking app, or SMS OTP to a mobile number. A cardholder without a smartphone can easily find themselves unable to complete authentication.

For merchants, the practical implication is that issuers will need to offer alternative challenge methods (hardware token, telephone-based OTP, or branch-based fallback), and the 3DS infrastructure must support routing to those alternatives. Challenge abandonment rates for specific customer segments (elderly cardholders, low-income markets with lower smartphone penetration) should improve as a result.

Stronger governance of SCA exemptions via new EBA RTS

The existing TRA exemption thresholds and exemption signalling rules remain, but PSD3/PSR mandates new Regulatory Technical Standards from the EBA specifically governing SCA exemptions and TRA. The expectation is tighter rules on how acquirers qualify for and maintain TRA exemption eligibility, and stronger monitoring of fraud rates at the granular level. The existing blunt thresholds (0.13%/0.06%/0.01% by transaction band) may be refined. Payment teams relying heavily on TRA exemptions should monitor the EBA consultation process closely.

What does NOT change

For clarity, here is what PSD3/PSR does not change for 3DS:

• The four existing SCA exemption categories remain. Low-value, TRA, trusted beneficiary, and secure corporate payment exemptions all continue under PSD3/PSR in substantially the same form.
• 3DS 2 remains the primary technical mechanism for satisfying SCA. There is no new authentication protocol mandated.
• The liability shift mechanism is unchanged. Successfully authenticated 3DS transactions shift fraud chargeback liability to the issuer.
• The frictionless flow mechanism is unchanged. Issuers retain the right to approve low-risk transactions without a challenge.

What to do now

Given that the PSR is likely to apply from 2026/2027, the window for preparation is defined. The highest-priority actions for payment and finance teams:

1. Audit your SCA delegation arrangements. Identify every third party that performs or supports SCA on your behalf, including your 3DS Server provider, any wallet providers, and payment gateways with embedded authentication. Confirm whether formal outsourcing agreements and DORA-compliant contractual provisions are in place.
2. Review your mandate set-up flows for MITs. Confirm that initial CITs are completing full SCA authentication and that network transaction IDs are being stored and referenced correctly in subsequent MIT authorisations.
3. Assess your challenge method coverage. Check what percentage of your cardholder base may not be able to complete the currently offered challenge methods. This is a pre-emptive step before issuers are required to offer accessible alternatives.
4. Monitor EBA RTS consultations on exemptions. If TRA exemptions are material to your conversion strategy, the new RTS could affect your acquirer's ability to continue offering them at current thresholds.

The November 2025 agreement is provisional. The final text will confirm the detail. But the direction is clear. Waiting for formal publication before auditing SCA delegation arrangements or mandate set-up flows costs more than acting now.