PSD3 for Luxembourg Payment Institutions and EMIs: What Changes and What to Prepare Now

Last updated: April 2026

If you run a payment institution or electronic money institution authorised by the CSSF, the next 18 months will reshape the rules you operate under. The European Parliament and Council reached provisional political agreement on PSD3 and the Payment Services Regulation (PSR) on 27 November 2025. Formal adoption and publication in the EU Official Journal are expected by mid-2026. After that, a transition period of roughly 18 months starts ticking. That puts the likely application date somewhere in late 2027 or early 2028.

The stakes are not abstract. PSD3 requires a fresh authorisation process for every existing PI and EMI. The PSR rewires fraud liability in ways that will hit your P&L if your controls are not ready. And the merger of the EMI regime into PSD3 means every e-money institution in Luxembourg will need to re-examine its licence structure. This is not a minor update to PSD2. It is a re-architecture of EU payments regulation, split into two instruments that work very differently from what we have today.

Related reading: PSD2 Reporting Requirements

The Split: Why PSD3 and PSR Are Two Separate Instruments

PSD2 was a single directive. Member states transposed it into national law, and the results varied. Luxembourg transposed PSD2 through the Law of 20 July 2018, amending the Law of 10 November 2009 on payment services (the PSL). That national transposition created local nuances that other EU jurisdictions handled differently.

The Commission’s 2023 review found that this variability undermined the single market for payments. The fix: split the rules into two instruments. PSD3 (COM(2023)366) is a directive covering authorisation, licensing, and prudential supervision of payment institutions. It requires national transposition. The PSR (COM(2023)367) is a regulation covering conduct rules, user rights, fraud liability, strong customer authentication (SCA), open banking access, and transparency. As a regulation, it applies directly in all member states without transposition.

The practical result for Luxembourg: most of the day-to-day operational rules (how you handle fraud claims, SCA, transparency disclosures, open banking interfaces) will come from the PSR and apply identically across the EU. The authorisation and supervision rules in PSD3 will still need to be transposed into the PSL by the Luxembourg legislator, with CSSF implementation. That means two timelines to track and two different types of compliance work.

One common mistake I see in early gap analyses: teams treat PSD3 and PSR as a single deadline. They are not. The PSR applies 18 months after entry into force. PSD3 must be transposed into national law within 18 months of entry into force. Luxembourg has historically been late on transposition. PSD2 should have been transposed by 13 January 2018. The Luxembourg law was passed on 20 July 2018, more than six months late. Teams should plan for the possibility that PSR obligations arrive before the national PSD3 transposition is complete.

EMI Merger into PSD3: The End of a Separate Regime

The second Electronic Money Directive (EMD2, Directive 2009/110/EC) will be repealed. PSD3 absorbs electronic money institutions as a sub-category of payment institutions. This is not cosmetic. It means every EMI authorised by the CSSF will operate under a PI licence framework, with specific e-money provisions built into PSD3 rather than sitting in a separate directive.

The CSSF currently lists PIs and EMIs separately under the PSL. The supervisory approach, the application forms, the reporting expectations, and the governance circulars (Circular IML 95/120 on central administration, Circular CSSF 04/155 on compliance, Circular CSSF 19/713 on security measures) all assume the PI/EMI distinction exists. That distinction disappears under PSD3.

What this does NOT mean: it does not mean PIs and EMIs become identical. E-money concepts like redeemability of electronic money at par value survive. Distributors of e-money will be explicitly recognised and regulated similarly to agents. The own funds calculation for e-money issuance (currently method D under EMD2) remains distinct from the PI methods. But the licensing shell is unified.

For Luxembourg EMIs specifically, the operational question is whether the CSSF will handle re-authorisation as a routine file update or as a full new application. The European Parliament’s position favoured a “simplified process” for currently authorised entities, rather than requiring a brand-new authorisation from scratch. The final agreed text is expected to follow this approach. But “simplified” still means filing a winding-up plan, demonstrating DORA compliance, and updating your security policy documentation. If your last authorisation file is from 2019, you will have material gaps to close.

Re-Authorisation: What the CSSF Will Need from You

PSD3 requires all existing PIs and EMIs to go through a re-authorisation process to continue operating. Even if the process is simplified, the content requirements are heavier than what PSD2 demanded. Here is what changes.

Winding-Up Plan

This is new. PSD2 did not require a winding-up plan as part of the authorisation dossier. PSD3 requires PIs to submit a plan that defines measures for orderly wind-down in case of failure, including continuity and recovery of critical activities performed by outsourced service providers, agents, or distributors. The plan must be proportionate to the size and business model of the institution.

The confusion point: this is not a recovery plan in the BRRD sense. It is closer to what the CSSF already expects from some larger PIs informally. But formalising it means compliance teams need to document outsourcing dependencies, agent networks, and client fund recovery procedures in a structured format. For Luxembourg PIs with significant agent networks across multiple EU jurisdictions, this will be the most time-consuming new requirement.

DORA Alignment

PSD3 requires business continuity arrangements to comply with Regulation (EU) 2022/2554 (DORA). This is not a new obligation if you are already in scope for DORA. But it makes the link explicit in the authorisation file. PIs must describe their ICT risk management framework, incident reporting procedures, and testing arrangements as part of the application.

The trap for smaller PIs: DORA has been live since January 2025, and some smaller payment institutions treated it as a banking regulation that did not fully apply to them. PSD3 closes that gap. If your DORA compliance is superficial, the re-authorisation process will expose it.

Security Policy and Fraud Data Sharing

PIs that participate in fraud information-sharing arrangements under the PSR must include in their security policy the conclusions of their data protection impact assessment and, where applicable, NCA conclusions on dedicated data access interfaces. This connects the PSD3 authorisation file to PSR conduct obligations.

Passporting Disclosure

PSD3 requires PIs to provide an overview of all EU jurisdictions where they have submitted or intend to submit an authorisation application. The CSSF already collects passporting notifications under the current framework, but this formalises cross-border transparency at the authorisation stage. For Luxembourg PIs that passport into multiple EU markets through agents or branches, this is a documentation exercise rather than a substantive change.

Authorisation Timeline

PSD3 harmonises the authorisation timeline at three months from a complete application. The CSSF currently does not have a hard statutory deadline. In practice, Luxembourg PI authorisations have historically taken considerably longer than three months. Whether the CSSF can operationally meet this timeline across a wave of re-authorisation applications is an open question. Filing early will matter.

Capital and Own Funds: What Moves

Initial capital requirements increase to reflect inflation since PSD2. The Commission’s proposal adjusted the thresholds upward across all PI categories. The exact final figures from the trilogue text are awaited, but the direction is clear: higher minimum capital.

Under PSD2, the initial capital for PIs varies by service category: EUR 20,000 for money remittance services, EUR 50,000 for payment initiation services, and EUR 125,000 for other payment services. EMIs required EUR 350,000 under EMD2. The Commission’s PSD3 proposal increased these. AISPs, which currently need only professional indemnity insurance, gain the option to hold EUR 50,000 of initial capital instead.

Own Funds Calculation Changes

PSD2 offers three methods (A, B, C) for PI own funds calculation. EMD2 uses method D for EMIs. PSD3 does not eliminate any method, but it makes method B (based on payment transaction volumes) the default for PIs providing payment services. Methods A and C become restricted to PIs with business models involving low volume but high value transactions, and their use requires NCA validation.

The EBA will develop RTS specifying the criteria for business models that qualify for methods A and C. Until those RTS are published, it is unclear exactly where the line falls. For Luxembourg PIs currently using method A, this is a real risk. If the RTS criteria are narrow, you may be forced to switch to method B, which could increase your own funds requirement if your transaction volumes are high relative to value.

Teams that have not modelled their own funds under method B should start now. The worst outcome is discovering at re-authorisation that your capital buffer is insufficient under the new default method.

Safeguarding: Central Bank Accounts and Diversification

Safeguarding of client funds remains a core obligation. PSD3 does not fundamentally change the safeguarding framework, but it introduces two important options.

First, PIs will have the option to safeguard funds in an account at a central bank. Under PSD2, safeguarding typically happens through segregated accounts at credit institutions or through insurance/guarantee. The central bank option is significant for risk management, but it is at the discretion of each national central bank. Whether the Banque centrale du Luxembourg (BCL) will offer safeguarding accounts to PIs is not yet confirmed. Do not assume this option will be available in Luxembourg from day one.

Second, PSD3 introduces a diversification requirement for safeguarding methods. PIs will need to avoid concentration risk by not relying entirely on a single credit institution or a single method. For Luxembourg PIs that currently hold all client funds in one segregated account at one bank, this means restructuring safeguarding arrangements. That takes time, especially if you need to open accounts with additional credit institutions.

The EBA will develop RTS on safeguarding requirements, adding specificity. But waiting for those RTS before starting the conversation with your safeguarding bank is a mistake. The restructuring itself takes months.

Fraud Liability and Reimbursement: The PSR Shift

This is where the PSR hits hardest. The liability framework for fraud moves decisively toward PSPs bearing more responsibility. Several changes matter for daily operations.

Verification of Payee (VoP)

The PSR makes verification of payee mandatory for all credit transfers, not just instant payments. PSPs must check that a payee’s name and unique identifier (IBAN) match before executing the transfer. If there is a discrepancy, the PSP must refuse the payment order and inform the payer. If the VoP mechanism fails and the customer is defrauded, the PSP is liable for the losses.

This is a direct extension of what the SEPA Instant Payments Regulation already requires for instant credit transfers. But expanding it to all credit transfers means PSPs need VoP infrastructure for batch and standard transfers too. For Luxembourg PIs that handle mainly SEPA credit transfers rather than instant payments, this is new build work.

Impersonation Fraud Liability

Where a fraudster impersonates a PSP employee and tricks a customer into authorising a payment, the PSR treats this as an unauthorised transaction. The PSP must refund the full amount if the customer reports it to both the PSP and the police. This is a significant departure from PSD2, where authorised push payment (APP) fraud generally left the customer bearing the loss because they technically authorised the transaction.

The distinction between “authorised” and “unauthorised” transactions blurs under the PSR for impersonation scenarios. Compliance teams should review their fraud typology classifications. If your current process classifies all customer-authorised payments as inherently outside the refund framework, that classification no longer holds for impersonation fraud.

Platform Liability

Online platforms become liable to PSPs who have reimbursed defrauded customers, if the platform was notified of fraudulent content and failed to remove it. This creates a recovery channel for PSPs, but only if you have processes to notify platforms formally and track their response. Building that notification workflow is new operational territory for most PIs.

Spending Limits and Blocking

PSPs must enable customers to set their own spending limits and must block payment instruments where fraud is suspected. This requires product-level changes: user interfaces for limit-setting, real-time monitoring to trigger blocks, and customer communication workflows for when a block is applied. Smaller PIs that currently handle fraud detection manually will need to invest in automation.

Open Banking: Removing the Remaining Friction

PSD2 introduced open banking through access-to-account (XS2A) rules. The PSR tightens these rules and removes obstacles that limited adoption.

Dedicated Interfaces Become Mandatory

Account servicing payment service providers (ASPSPs, typically banks) must provide dedicated data interfaces (APIs) for third-party providers. The PSR sets requirements for functionality, performance, and availability of these interfaces. For Luxembourg PIs that operate as account information service providers (AISPs) or payment initiation service providers (PISPs), this should improve the reliability of bank APIs they depend on.

The flip side: if you are a PI that also holds payment accounts (some Luxembourg PIs do), you become an ASPSP yourself and must provide compliant APIs to third parties. That is an infrastructure cost many smaller PIs have not budgeted for.

Permission Dashboards

PSPs must offer customers a dashboard to manage third-party access to their payment data. Customers must be able to see who has access and revoke permissions. This is a front-end development requirement. If your current consent management is handled through one-time SCA screens without a persistent dashboard, you will need to build one.

Non-Discrimination

The PSR prohibits banks from imposing obstacles on firms providing open banking services. It also requires manufacturers of mobile devices and electronic service providers to allow payment apps to access necessary hardware features (NFC, biometrics) on fair, reasonable, and non-discriminatory terms. This is good news for Luxembourg fintechs that have struggled with bank API reliability or mobile device access restrictions. But enforcing these provisions will depend on NCA willingness to act.

The Luxembourg Angle: What CSSF Needs to Do

PSD3 requires Luxembourg to amend the PSL. The current PSL structure, which distinguishes between PI authorisation (Articles 6 onwards) and EMI authorisation (Articles 24-2 onwards), will need to be rewritten to reflect the unified framework. The CSSF’s circulars on governance (Circular IML 95/120), internal control (Circular IML 98/143), compliance (Circular CSSF 04/155), outsourcing (Circular CSSF 22/806), and payment security (Circular CSSF 19/713) will all need updates.

The CSSF has not published specific guidance on PSD3 preparation yet. That is expected behaviour at this stage. The final texts are still being polished after the November 2025 political agreement, and the CSSF typically waits for publication in the Official Journal before issuing national implementation guidance. But this creates a planning gap for PIs and EMIs that want to start preparation now.

I have seen Luxembourg follow one of two patterns on payments transposition. Either the Ministry of Finance drives a clean new bill that restructures the PSL (as happened with the 2018 PSD2 transposition), or amendments layer onto the existing law in ways that make the PSL increasingly difficult to read. Given the scale of PSD3 changes, including the EMI merger, a structured rewrite would be more practical. But that takes more legislative time.

The CSSF’s supervisory capacity is another factor. Luxembourg has a relatively small number of authorised PIs and EMIs compared to larger EU jurisdictions. But re-authorising every single one within a compressed timeline, while also processing new applications, will strain resources. PIs and EMIs that submit clean, complete files early will have an advantage. Those that wait until the transposition deadline will face queues.

Reporting and Control Implications

Neither PSD3 nor the PSR create a new standalone reporting regime comparable to COREP or FINREP. But the operational changes ripple into existing reporting and controls.

Incident Reporting

The explicit DORA alignment means ICT incident reporting obligations apply clearly to all PIs. Under DORA, major ICT-related incidents must be reported to the CSSF. PSD3 reinforces this by making DORA compliance a condition of authorisation. If your incident reporting process is currently informal, it needs to be formalised before re-authorisation.

Fraud Reporting and Data Sharing

The PSR’s fraud data-sharing framework requires PSPs to exchange fraud-related information through a dedicated platform, with data protection impact assessments and time-bounded data retention (up to five years). This is not traditional regulatory reporting to the CSSF. It is inter-PSP data sharing. But maintaining the infrastructure, the DPIA documentation, and the retention schedules adds a compliance layer that your data protection officer needs to be involved in.

Supervisory Reporting

PSD3 gives NCAs enhanced enforcement tools, including expanded investigatory powers and obligations to publish enforcement actions. The CSSF already has broad supervisory powers under the PSL, but the directive harmonises these across the EU and introduces product intervention powers. For reporting officers, this means the CSSF may request information on a wider range of topics than currently expected. Building flexibility into your internal reporting infrastructure matters.

AML Interaction

PSD3/PSR do not replace AML obligations, but the fraud data-sharing requirements and the new liability framework interact with AML controls. A payment flagged as potentially fraudulent may also trigger suspicious transaction reporting (STR) obligations under Luxembourg’s AML framework. Teams should map the intersection between fraud detection workflows under the PSR and existing STR processes to avoid duplication or gaps.

MiCA Interaction: Crypto-Licensed Firms

PSD3 includes a simplified authorisation application process for providers already licensed under the Markets in Crypto-Assets Regulation (MiCA). The PSR’s conduct rules will apply to some payment transactions involving certain types of crypto-assets, specifically asset-referenced tokens and e-money tokens used for payment purposes.

For Luxembourg firms holding both a MiCA authorisation and a PI/EMI licence, the interaction creates both simplification (one authorisation process covers more ground) and complexity (determining which transactions fall under PSR versus MiCA conduct rules). The EBA’s no-action letter on the overlap between crypto-asset services under MiCA and PSD2 provides interim guidance, but the final PSD3/PSR texts will need to clarify the permanent boundary.

Settlement Finality: Direct Access to Payment Systems

PSD3 amends the Settlement Finality Directive to enable direct participation of payment institutions and EMIs in designated payment systems. Under PSD2, PIs could only access payment systems indirectly, through a bank. This created dependency and cost.

Direct access to systems like TARGET or national settlement systems changes the competitive position of PIs relative to banks. But it also brings operational requirements: settlement risk management, liquidity management, and compliance with the system’s rules. For Luxembourg PIs that currently rely on a single banking partner for payment system access, this opens a strategic choice. Whether to pursue direct access depends on volume, cost structure, and risk appetite. Not every PI will benefit from going direct.

What Teams Should Prepare Now

The final texts are not yet published. But the political agreement is settled, and the direction is clear. Waiting for the Official Journal publication before starting preparation is a tactical error given the 18-month timeline.

Gap Analysis Against the Commission Proposal

Start with the Commission’s published proposals (COM(2023)366 for PSD3, COM(2023)367 for PSR) and the European Parliament’s April 2024 amendments. The final text will adjust details, but the structural changes (EMI merger, re-authorisation, fraud liability, VoP, open banking upgrades) are settled. Run a gap analysis against your current authorisation file, governance framework, safeguarding arrangements, and fraud controls.

Winding-Up Plan Drafting

This is a new deliverable. Start drafting now. Map your outsourcing relationships, agent networks, and critical dependencies. Identify what happens to client funds if you cease operations. The CSSF will want to see this in your re-authorisation application.

Own Funds Modelling Under Method B

If you currently use method A or C for own funds, model the impact of switching to method B. Identify whether your capital buffer survives the change. If not, start capital planning.

Safeguarding Diversification

If all your client funds sit in one safeguarding account at one credit institution, start conversations with additional banks. Opening new segregated accounts takes time, especially in Luxembourg where the banking sector’s appetite for PI safeguarding accounts varies.

VoP Infrastructure

If you process credit transfers and do not yet have verification of payee capability for all transfer types (not just instant payments), start the technical build. This is PSR, not PSD3, so it applies directly without waiting for national transposition.

DORA Compliance Review

PSD3 makes DORA compliance an authorisation condition. If your DORA implementation is incomplete, the re-authorisation process will surface that gap. Fix it now while there is still time.

Fraud Workflow Review

Review your fraud typology classifications, refund policies, and customer communication processes against the PSR’s new liability framework. Impersonation fraud refund obligations and platform notification procedures are new workflows that need to be designed, tested, and documented.

Timeline Summary

June 2023: European Commission publishes PSD3 (COM(2023)366) and PSR (COM(2023)367) proposals.

April 2024: European Parliament adopts first reading amendments.

June 2025: Council of the EU adopts negotiating mandate.

27 November 2025: European Parliament and Council reach provisional political agreement on PSD3 and PSR.

Expected mid-2026: Formal adoption and publication in EU Official Journal.

Expected late 2027 to early 2028: PSR applies directly across the EU; PSD3 national transposition deadline.

Related Articles

PSD2 Reporting Requirements – The current framework that PSD3 and PSR will replace. Understand what exists today before mapping the changes.

SEPA Instant Payments Regulation – Verification of payee requirements for instant credit transfers, now being extended to all transfers under the PSR.

CESOP Reporting Explained – Cross-border payment reporting obligations that interact with the broader payments regulatory framework.

MiCAR Reporting Obligations – For firms at the intersection of crypto-asset services and payment services under the new regime.

AML Reporting in Luxembourg – Fraud data sharing under the PSR interacts with existing STR obligations.

DORA ICT Incident Reporting – PSD3 makes DORA compliance an explicit authorisation condition for all payment institutions.

Sources and References

European Commission, Proposal for a Directive on payment services and electronic money services in the internal market (PSD3), COM(2023)366: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52023PC0366

European Commission, Proposal for a Regulation on payment services in the internal market (PSR), COM(2023)367: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52023PC0367

European Parliament, Press release on provisional agreement, 27 November 2025: https://www.europarl.europa.eu/news/en/press-room/20251121IPR31540/payment-services-deal-more-protection-from-online-fraud-and-hidden-fees

Directive (EU) 2015/2366 (PSD2): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L2366

Directive 2009/110/EC (EMD2): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0110

Regulation (EU) 2022/2554 (DORA): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554

CSSF, Payment institutions/electronic money institutions/AISPs: https://www.cssf.lu/en/payment-institutions-electronic-money-institutions-aisp/

CSSF, Authorisation procedure of a PI or EMI: https://www.cssf.lu/en/authorisation-procedure-payment-institution-or-electronic-money-institution-registration-aisp/

Luxembourg Law of 10 November 2009 on payment services (PSL), as amended by the Law of 20 July 2018 transposing PSD2.

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.