PSD3 and the Payment Services Regulation (PSR) stopped being a proposal and became a confirmed timeline this year. The European Parliament, Council, and Commission agreed final compromise texts on 23 April 2026, following provisional political agreement in November 2025. Publication in the Official Journal is expected mid-2026, with the PSR’s conduct-of-business rules applying roughly 18 to 21 months after that, pointing to somewhere in late 2027 as the realistic compliance date for most core obligations.
GPayments has provided 3D Secure authentication technology since 1999, serving issuers and acquirers across 33 countries through ActiveAccess, ActiveServer, ActiveSDK, and TestLabs. This is a practical breakdown of what PSD3/PSR actually changes for SCA and 3DS infrastructure, including a provision that applies directly to technical service providers like GPayments.
The Confirmed Timeline
|
Milestone |
Date / Status |
|
Provisional political agreement |
27 November 2025 |
|
Council publishes final PSD3 and PSR compromise texts |
23 April 2026 |
|
Publication in the Official Journal |
Expected mid-2026 (Q2/Q3 2026, per multiple law firm trackers) |
|
PSR entry into force |
20 days after publication (as a directly applicable regulation) |
|
PSR conduct-of-business rules apply |
Approximately 18-21 months after entry into force; realistically late 2027 |
|
PSD3 national transposition deadline |
21 months after entry into force |
|
Verification of Payee liability provisions |
Up to 24 months after entry into force, to allow system changes |
The practical implication is that firms should prepare for the core PSR SCA and fraud-liability obligations to apply around 18 months after the Regulation enters into force. Assuming publication in 2026, this is expected to fall in late 2027. That said, institutions with EMI licences facing re-authorisation deadlines, and any organisation relying on outsourced SCA, should not wait until the deadline year to start the gap analysis. (nortonrosefulbright.com)
The Provision That Applies Directly to ACS and 3DS Vendors
PSD3/PSR introduces specific governance requirements for technical service providers (TSPs) that deliver SCA on behalf of a payment service provider, a category that includes ACS vendors and 3DS Server providers. Issuers outsourcing SCA will be required to conduct thorough due diligence on the TSP beforehand, and put in place detailed written agreements covering the scope of the delegated function, roles and responsibilities, service level agreements, and exit plans. The agreement must also grant the delegating institution and its regulators unrestricted rights of access and audit. Separately, PSD3 extends liability for enablers: schemes, technical service providers, and wallet providers can be held liable where their systems contribute to SCA failures in the payment chain.
For issuers, this means the ACS vendor relationship itself becomes an area of documented regulatory exposure, not just a procurement decision. Contracts, SLAs, audit rights, and exit planning with any outsourced SCA provider need to be in place well ahead of the late-2027 application date, and demonstrably reviewed, not simply inherited from an older commercial agreement.
What Changes for SCA and Fraud Liability
Verification of Payee (IBAN-name matching) becomes mandatory across credit transfers under PSD3/PSR, extending a requirement already in force for SEPA Instant since October 2025. PSPs must verify that the payee name matches the account identifier before a transfer completes and flag any mismatch to the payer. Authorised push payment (APP) fraud liability is also clarified: where a payer is misled into authorising a payment, the paying PSP can be held liable for reimbursement if it failed to meet expected fraud-detection standards, a liability standard PSD2 never pinned down with this level of clarity.
For SCA specifically, responsibility for correct implementation sits with the payment service provider, who is liable if SCA is implemented incorrectly, while schemes, technical service providers, and wallet providers can separately be liable if their systems cause an SCA failure. PSD3 also pushes toward more accessible SCA, explicitly supporting authentication methods that don’t require a smartphone, and confirms that SCA obligations extend to adding a card to a digital wallet, not just to completing a transaction.
What Issuers Should Do Now
|
Action |
Why It Matters |
|
Review outsourced SCA/ACS contracts against the new TSP governance requirements |
Written agreements, audit rights, and exit plans need to be in place well before late 2027 |
|
Confirm your ACS vendor’s own PSD3/PSR readiness |
Vendor-side SCA failures can create liability exposure for the issuer under the new enabler-liability provisions |
|
Map current Verification of Payee capability against the mandatory IBAN-name check |
This extends beyond SEPA Instant to credit transfers generally under PSD3/PSR |
|
Check EMI/PI authorisation status if applicable |
PSD3 merges the EMI and PI regimes. Existing EMIs can continue operating during the transition but must provide updated information to demonstrate compliance with the new authorisation requirements. |
|
Build a regulatory change register with named owners |
PSD3/PSR spans authorisation, SCA, fraud liability, and outsourcing governance; treat each as a tracked workstream, not one project |
|
Where GPayments Fits As a technical service provider delivering SCA infrastructure to issuers across 33 countries, GPayments’ ActiveAccess and ActiveServer are built on EMVCo-certified, PCI DSS and PCI 3DS-compliant infrastructure. Issuers preparing PSD3/PSR outsourcing documentation should confirm current certification status and audit-support capability directly with GPayments’ technical team. |
Frequently Asked Questions
When does PSD3 and the PSR actually apply?
Final compromise texts were agreed on 23 April 2026, with publication in the Official Journal expected mid-2026. The PSR enters into force 20 days after publication as a directly applicable regulation, but its core conduct-of-business rules, including most SCA and fraud liability provisions, are expected to apply roughly 18 to 21 months later, realistically late 2027. Verification of Payee liability provisions have a longer runway of up to 24 months to allow for system changes.
What is the Payment Services Regulation (PSR), and how does it differ from PSD3?
PSD3 is a directive requiring national transposition, governing the authorisation, licensing, and supervision of payment and e-money institutions. The PSR is a directly applicable regulation that carries the conduct-of-business rules, including SCA, fraud liability, and open banking standards, applying uniformly across the EU without national transposition. Together they replace the existing PSD2 and Electronic Money Directive regimes.
Does PSD3/PSR affect ACS vendors and technical service providers?
Yes. PSD3/PSR introduces specific governance requirements for technical service providers delivering SCA on behalf of a payment service provider, including ACS and 3DS Server vendors. Issuers outsourcing SCA must conduct due diligence beforehand and maintain detailed written agreements covering scope, responsibilities, SLAs, audit rights, and exit plans. Schemes, technical service providers, and wallet providers can also be held liable where their systems contribute to SCA failures.
What is Verification of Payee, and is it mandatory under PSD3/PSR?
Verification of Payee is an IBAN-name matching check that confirms a payee’s name matches the account identifier before a credit transfer completes, flagging any mismatch to the payer. It has already been mandatory for SEPA Instant transfers since 9 October 2025 under the Instant Payments Regulation, and PSD3/PSR extends the requirement across credit transfers more broadly, with associated liability provisions applying up to 24 months after PSR entry into force.
Who is liable if SCA is implemented incorrectly under PSD3/PSR?
Responsibility for correctly implementing SCA sits with the payment service provider, which is liable if SCA is applied incorrectly. Separately, schemes, technical service providers, and wallet providers can be held liable if their own systems cause an SCA failure within the payment chain, creating a more distributed liability model than existed under PSD2.
How is GPayments preparing for PSD3/PSR as an SCA technical service provider?
GPayments’ ActiveAccess and ActiveServer run on EMVCo-certified, PCI DSS and PCI 3DS-compliant infrastructure. Issuers preparing outsourcing documentation and due diligence files under PSD3/PSR’s technical service provider governance requirements should confirm current certification status, audit-support capability, and contractual terms directly with GPayments’ technical team.
|
Reviewing Your SCA Outsourcing Documentation for PSD3/PSR? Talk to GPayments about certification status and audit support for your PSD3/PSR readiness file: gpayments.com/contact |