PSD3 and PSR: How Does the Directive Differ from the Regulation?
PSD3 and PSR are separate but closely linked pieces of legislation. The key difference between them is their legal form.
Ieva Bakutienė, Partner at Noewe responsible for licensing and regulatory compliance services, explains: 'PSR is a regulation, so it will apply directly in all Member States, and its provisions will not need to be transposed into national law. PSD3 is a directive, so Member States will have to transpose its provisions into their national legislation.'
With this choice, the EU has split the rules by nature. The regulation will cover the rules needed to protect fundamental rights:
- transparency,
- customer rights,
- fraud prevention.
The directive will mainly cover the licensing and supervision of payment institutions. These are more technical rules, which each country can handle through its own legislation within the framework set by the directive.
The PSD2 legacy: same product, different licences
In practice, PSR means more uniform rules across the EU. 'There were cases where supervisory authorities in different countries disagreed on whether a particular activity counted as issuing electronic money or simply as a payment service,' Bakutienė recalls. 'As a result, a payment institution licence was enough for what was essentially the same product in one country, while another country required a broader electronic money institution licence with stricter capital and other operational requirements.'
The intra-group exemption is another example. It allows companies within the same group to make payments to each other without a payment service provider licence, provided no payment service company from outside the group is involved. However, this exemption was also interpreted inconsistently.
According to Bakutienė, for a long time there was no common EU-wide view on how far the exemption extended. This created an uneven playing field within the EU: 'essentially the same intra-group payment processing activity required a licence in some Member States but not in others.'
PSR changes this, because the matters it covers will be governed by a single, directly applicable EU law. For companies operating in several EU countries, this should mean less fragmentation between national rules, greater legal certainty, a smoother customer experience and more consistent implementation across Member States.
PSD3 and PSR timelines: 20 days, 21 and 27 months
The new rules will not take effect immediately after publication. The regulation’s entry into force differs from the date its individual provisions start to apply, and transition periods separate them.
Bakutienė advises against relying only on the expected publication date of PSR or PSD3: 'The specific deadlines must be calculated from the actual entry into force of the legislation and the date it starts to apply.'
Under the final agreed text:
- both laws will enter into force 20 days after publication,
- Member States will have 21 months from entry into force to transpose PSD3 into national law,
- PSD2 and the Electronic Money Directive will be repealed on that same date, and the general PSR provisions will start to apply,
- existing payment and electronic money institutions will have a transition period of up to 27 months to adapt to the new regime and meet the requirements set by the competent authority.
That is why companies need to do more than track the final dates. They should also 'assess now how much time they will need for changes to IT systems, processes, contracts, internal controls, and licensing.'
Electronic Money Institutions Become Payment Institutions
What changes for EMI licences and capital requirements?
PSD3 merges the current regimes for payment institutions and electronic money institutions. An electronic money institution (EMI) will no longer be a separate category as it is today. Instead, it will become a payment institution (PI) authorised to issue electronic money.
As Kristina Jungevičienė, Managing Associate at Noewe, explains, 'the authorisation model itself will change: instead of two separate categories of institution, there will be a single payment institution framework with different scopes of permitted services.'
This does not mean an EMI will automatically become a 'lighter' PI. Specific capital and own funds requirements will continue to apply to electronic money activities. Each institution’s capital needs will therefore be assessed based on the specific services it provides and its business model.
Are EMIs already late with re-registration?
Some in the market believe EMIs that have not started re-registering by mid-2026 are already behind. Jungevičienė disagrees.
'Mid-2026 should not be treated as a formal deadline,' she says. Neither PSD3 nor PSR sets such a date, and Lithuania currently has no national law under which re-registration could take place.
What's more, PSD3 and PSR have not yet been formally adopted. The 21- and 27-month transition periods will begin only once the European Parliament and the Council approve them and they are published in the Official Journal. A formal re-registration process therefore cannot be started yet, at either EU or national level, so it is inaccurate to talk about anyone being 'late'.
From a business perspective, though, now is the right time to start preparing. Jungevičienė recommends carrying out a gap analysis now rather than waiting for national legislation. That way, preparation will take as little time as possible once the laws take effect.
It is also worth reassessing DORA compliance. DORA has applied to payment and electronic money institutions since 17 January 2025, regardless of the PSD3 timeline.
Jungevičienė suggests checking that the ICT risk management framework actually works, that the register of providers and contracts is up to date, and that incident management, business continuity and resilience testing processes have been tried out in practice. 'An institution must be able to demonstrate that these requirements are actually being implemented with concrete evidence, not just internal documents,' she stresses.
Linardas Saldukas, Head of Strategy Consulting at Baltic Amadeus, adds: 'There's no need to build separate architectures for DORA and PSD3. Many technical controls can be shared, so it makes sense to build one common architecture and add extra measures only where the requirements differ. This saves both time and money.'
Real presence: the end of letterbox structures
PSD3 tightens substance requirements. A licence must not serve as the formal basis for activities essentially carried out in another country.
Under PSD3, Jungevičienė explains, 'an institution will need to have its registered office and head office in the same Member State where it is authorised, and actually carry out at least part of its payment services business in that country.'
This does not mean that all of a company's operations or employees must be in Lithuania. However, the company must show the supervisory authority that Lithuania is not just a formal licence 'address'. In other words, the company must have a real central administration in Lithuania, make its decisions there and carry out an essential part of its business in the country.
For companies registered in Lithuania but actually operating in other jurisdictions, this may mean reviewing how management, staff and critical functions are distributed. In some cases, they may need to expand their actual operations in Lithuania or justify their current model to the Bank of Lithuania again.
Verification of Payee (VoP) and Fraud: More Responsibility for Providers
PSR shifts more of the burden of fraud prevention onto payment service providers. Therefore, it's important to understand who is liable for Verification of Payee errors, when a customer is entitled to compensation, and what happens when a customer ignores a warning.
Who is liable when VoP goes wrong?
Verification of Payee (VoP) has been mandatory for instant SEPA payments since October 2025 under the Instant Payments Regulation. PSR extends this obligation to all types of credit transfers.
According to Agata Tomaševičiūtė, Senior Compliance Consultant at Noewe, liability will depend on where in the payment chain the error occurred and which specific VoP requirements were breached.
If the VoP service was provided incorrectly or not at all, and the payment was executed incorrectly as a result, the payer's payment service provider (PSP) is directly liable to the payer. It must refund the full amount transferred without delay.
However, final financial liability lies with the institution at fault. If the payee's PSP (or a payment initiation service provider) failed to meet the requirements, for example by giving the payer's bank incorrect information, it must compensate the payer's PSP for all losses incurred in refunding the consumer.
Tomaševičiūtė sums it up: 'There is no rule that, in such cases, only the payer's PSP or only the payee's PSP is automatically liable. For the customer, what matters is their contractual relationship with their own PSP, while liability between payment service providers can be reallocated depending on where the breach occurred.'
How VoP works technically
Baltic Amadeus expert Saldukas stresses that Verification of Payee does not require a centralised database. It requires a real-time API service built into the payment process, so the payer's and payee's banks can check the payee's name instantly.
The common VoP rules are set by the scheme owner, the European Payments Council (EPC). These rules allow separate Routing and Verification Mechanisms (RVMs) to operate. RVMs connect banks and payment service providers and route requests between them. The payee's bank checks whether the IBAN and the payee's name match and sends back a response.
According to Saldukas, two layers are essential: an API integration layer and a VoP Orchestration Service, which determines which RVM should be used to send the request to the payee's bank. On top of these, you need:
- a connection to the relevant VoP infrastructure,
- monitoring, timeouts, and retry and fallback mechanisms,
- security measures to ensure that only authorised payment service providers exchange information.
In practice, customers should not notice any extra waiting time. 'The key principle is to perform VoP as close as possible to the moment the payment is initiated, and to design the process so that VoP service disruptions don't block the payment,' Saldukas explains. This requires clear logic for what to do if the VoP service is unavailable, along with monitoring and strict timeouts. In his view, an acceptable SLA target is a response within milliseconds, not seconds.
APP fraud: when does a customer get compensated?
Under PSD2, liability for authorised push payment (APP) fraud fell mostly on the customer. PSR significantly changes this approach.
Rita Tamulytė, Partner at Noewe responsible for compliance services, cautions: 'It would be inaccurate to say that, from now on, every fraudulent payment approved by a customer will be automatically refunded.' According to her, the essence of the new rules is that payment service providers will bear greater responsibility for preventing fraud.
A customer's approval of a payment using strong customer authentication (SCA) will not, on its own, be enough to shift liability onto them. The assessment will look at whether the PSP properly verified the payee, assessed the fraud risk, monitored the transaction, and gave the customer clear and specific warnings in time.
At the same time, PSR does not provide for automatic refunds in all cases of authorised fraud. A special procedure applies to impersonation (spoofing) fraud, where the fraudster poses as the consumer's PSP and uses its associated communication channels.
If the PSR conditions are met, the consumer can claim compensation for the full loss. To do so, they will need to:
- report the fraud to their PSP without delay,
- contact the police,
- provide their PSP with the police report confirming this.
Once the PSP receives the required information, it will have 15 business days to refund the money or provide a reasoned refusal.
Compensation may not apply if the customer acted fraudulently or if their behaviour amounts to gross negligence as defined by law.
When a customer ignores a warning
In some cases, a PSP warns a customer that the payee's details do not match, but the customer approves the payment anyway. According to Tomaševičiūtė, this fact alone should not be assessed in isolation or automatically treated as gross negligence. A court or dispute resolution body will assess all the circumstances individually, including:
- whether the PSP carried out VoP properly and, before authorisation, gave a clear and specific warning about the mismatch and its possible consequences,
- whether the customer had a real opportunity to cancel the payment,
- whether the customer checked the payee's details and the amount, why they decided to proceed, and whether fraudsters manipulated them into that decision,
- how sophisticated the fraud scheme was, whether the fraudster impersonated a bank or another trusted entity, how clear the warnings were, and whether the customer had characteristics that could have made them more vulnerable.
'If the payment service provider properly fulfilled its VoP obligations, clearly and specifically warned the customer of the possible consequences, and the customer knowingly chose to proceed with the payment despite that warning, this may be relevant when deciding whether the customer should bear the losses themselves,' says Tomaševičiūtė.
On the other hand, the payment service provider may be held liable if:
- the VoP check was not carried out properly,
- the warning was unclear, too generic or given at the wrong moment,
- the customer approved the payment under the influence of a sophisticated impersonation scam.
Biometrics and device signals: the technology side of prevention
PSR allows two biometric elements to be used in strong customer authentication (SCA). According to Saldukas, this makes authentication simpler for customers but more complex from an architecture standpoint. SCA relies on three categories of elements:
- something you know (e.g. a PIN),
- something you have (e.g. a phone or card),
- something you are (biometric data).
When two biometric elements are used, it must be very clear that each one meets the SCA requirements independently.
PSR also requires device intelligence signals to be assessed, such as an unfamiliar device, remote access software like AnyDesk or TeamViewer, or a phone call during the session. 'It would be a mistake to treat every signal as grounds for blocking. They should be treated as risk indicators,' says Saldukas. He suggests grouping signals by risk level and applying a different action to each:
- low-risk signals – trust,
- medium-risk signals – verify further,
- high-risk signals – block.
To keep false positives from rising, it is important to analyse which signals actually indicate fraud and to recalibrate the model regularly.
Crypto-Asset Service Providers: When Do You Need Both a MiCA and a PSD3 Licence?
The European Banking Authority (EBA) has reduced the number of cases requiring dual licensing. However, some crypto-asset service provider (CASP) business models still require both a MiCA and a PSD3 licence.
According to Jungevičienė, 'what matters is not only whether the activity involves e-money tokens (EMTs), but also the specific service being provided and on whose behalf the CASP is acting.'
Dual authorisation is needed in two main cases:
- when a CASP provides an EMT-related crypto-asset transfer service on behalf of a client, for example by carrying out EMT transfers on behalf of clients,
- when it provides custody and administration of crypto-assets on behalf of clients, and the CASP-managed wallet allows EMT transfers to be sent to or received from third parties – such a wallet is treated as a payment account.
When a CASP exchanges crypto-assets for fiat currency or other crypto-assets in its own name and using its own funds, this activity is usually covered by MiCA alone. In that case, it is not considered a payment service, so payment services regulation does not apply.
Jungevičienė suggests a three-question test:
- Does the activity involve EMTs?
- Is the service by nature a payment service, i.e. a transfer, or custody and administration on behalf of clients with the ability to transfer to third parties?
- Is the CASP acting on behalf of the client or in its own name?
Each business model must be assessed individually. Holding a MiCA licence does not in itself mean that all the services a CASP provides automatically fall under MiCA alone.
For more on the financial requirements of MiCA licensing, read our article 'Navigating MiCA Compliance'.
Open Banking APIs: Parity Must Be Proven
PSR introduces mandatory performance indicators for Open Banking APIs and requires performance parity, meaning the APIs must perform no worse than the bank's own channels. Saldukas stresses: 'The key here is to measure, not simply claim that the system works well.' This means collecting objective data on speed, availability, error rates and other indicators, and being able to present it to the regulator.
He gives an example: if a customer completes an action in the bank’s app in 0.5 seconds, but the same action takes 5 seconds for a third party using the Open Banking API, the question is why the third-party provider receives a much worse service.
Three Tips for Executives on How to Prepare for PSD3
Asked what she would advise the head of a payment or electronic money institution operating in Lithuania today, Bakutienė highlights three steps:
- Don't wait for the final deadlines – carry out a gap analysis. Assess whether your current business model fits the new regulatory framework, which authorisations you will need, and how capital, governance and internal control requirements may change.
- Strengthen fraud prevention and VoP readiness now. Look beyond the technical implementation of VoP to the whole process: customer communication, warning management, audit trail, transaction monitoring and fraud response. It is important to prove not only that controls exist, but that they work.
- Review your governance and business structure in advance. Check where your central administration is, where decisions are made, where key executives work, and how much of your business is actually carried out in Lithuania. If you also provide crypto-asset services, assess how MiCA and PSD3 interact and whether you need dual authorisation.
In Bakutienė’s view, all of this shows that PSD3 preparation should be seen 'not just as a licence change, but as a broader review of the company's business model, governance, capital, technology and customer protection processes.'
Preparation for PSD3 and PSR Starts Now
The PSD3 and PSR timelines will only start after formal publication, but changes to licences, capital, governance, and IT systems take time. The experts agree on what to do: carry out a gap analysis, strengthen VoP and fraud prevention, and review your real presence in Lithuania. Since many requirements will need to be implemented in payment systems, it pays to have lawyers, compliance specialists, and IT teams work together from the start.
