A Definitive Guide to PSD3 and PSR in the Baltics 2027–2028

PSD2 vs. PSD3: Key Regulatory Changes

PSD3 is a structural rebuild. The single biggest change is that most conduct rules move out of the directive and into the PSR, a regulation with direct legal effect across all 27 member states, closing the national transposition gaps that let PSD2 be interpreted inconsistently from one country to the next.

PSD2 achieved a great deal – it opened up account access to third-party providers and introduced strong customer authentication as a baseline. But the European Commission's own review found real limitations: national transposition created room for regulatory arbitrage, API quality varied sharply by country, and payment institutions and e-money institutions were governed by two separate legal instruments with different standards. PSD3 addresses all three by:

• Splitting the framework into a directive (PSD3, covering licensing and prudential supervision) and a regulation (the PSR, covering day-to-day conduct rules) that applies uniformly without national implementing legislation.
• Merging the E-Money Directive into PSD3, so e-money institutions become a licensed subcategory of payment institutions under one supervisory regime.
• Removing interpretive grey areas – the Limited Network Exemption, for example, was applied inconsistently under PSD2; the PSR now defines its conditions directly and applies them identically everywhere.
• Raising the cost of getting it wrong: reported penalty ceilings run up to 4% of annual turnover or 20 million euros, a GDPR-style deterrent that boards will need to take seriously.

For a business operating across the Baltics and the wider EU, the practical upshot is that a single PSR conduct standard now applies from Vilnius to Lisbon – but licensing, supervision, and day-to-day regulatory relationships still run through national authorities, which is why the choice of home regulator still matters under PSD3.

The Payment Services Regulation (PSR) Framework

The PSR is the regulation that carries most of PSD3's real operational weight. Because it applies directly, without needing a national law to activate it, the same rules on strong customer authentication, transparency, open banking access, and fraud liability apply the moment the PSR takes effect – no waiting on national legislatures, no local drafting quirks.

Two changes inside the PSR framework matter most for product and engineering teams:

• How third-party providers keep access to customer accounts over time, without repeatedly interrupting the customer with re-authentication.
• How banks are required to build the interfaces that make that access possible, now that the old fallback option is gone.

The 180-day SCA re-authentication rule

Under PSD2, account information service providers had to trigger a full strong customer authentication flow with the customer at least every 90 days, which frequently interrupted account-aggregation and budgeting apps mid-session. The PSR extends that window: after the first, fully authenticated access, an account information service provider can rely on its own strong customer authentication for up to 180 days before the customer needs to re-authenticate directly with their bank. For any product built on account aggregation – expense trackers, credit-risk scoring tools, open banking dashboards – this materially reduces drop-off from repeated authentication prompts.

New API standards: removing fallback interfaces

Under PSD2, banks could offer third-party providers access through a dedicated API or, if that API failed to meet standards, fall back to a modified version of the bank's own customer interface. In practice, that fallback became an escape hatch: some of the roughly 6,000 account-servicing payment service providers across the EU built dedicated interfaces that underperformed, knowing the fallback covered them. The PSR removes the fallback option entirely.

• Every dedicated interface must now perform as reliably and quickly as the bank's own customer-facing app.
• Screen scraping is banned outright.
• National regulators are required to act without delay against interfaces that fall short on uptime, incident-response timelines, or functionality.

The PSR does not mandate one single technical API standard – standardisation bodies such as the Berlin Group, STET, and PolishAPI continue to shape the detailed specifications – but it does set a much higher enforceable performance floor and bans the artificial obstacles (extra authentication steps, incomplete data fields) banks previously used to slow third-party access.

The Role of Baltic Regulators: How Lithuania, Latvia, and Estonia Implement PSD3

Because PSD3 keeps authorisation and day-to-day supervision at the national level even as conduct rules harmonise under the PSR, the choice of home regulator continues to matter. All three Baltic supervisors have built reputations as approachable, digitally native licensing authorities, which is a large part of why the region already hosts a disproportionate share of the EU's payment institutions and e-money institutions.

• Lithuania – the Bank of Lithuania (Lietuvos bankas) has issued a large share of EU e-money institution licences over the past decade and runs its own SEPA gateway service, CENTROlink, directly for applicants.
• Latvia – Latvijas Banka supervises payment institutions and e-money institutions under clearly defined substance requirements, paired with a 0% corporate tax rate on retained, undistributed profits.
• Estonia – Finantsinspektsioon runs a digital-first, English-language supervisory process and, since March 2026, requires licence applications to be filed through its own online application portal.

For groups already licensed in one Baltic state and passporting services into the other two, or into the Nordics, PSD3's re-authorisation requirement is also a natural point to review which jurisdiction should remain the group's primary regulator.

Integrating Baltic digital IDs (Smart-ID & Mobile-ID) with new SCA standards

The PSR states explicitly that payment service providers may not make strong customer authentication dependent, directly or indirectly, on possession of a smartphone – they must offer at least one authentication method that does not require one, to serve elderly customers, people with disabilities, and the digitally excluded – the Baltics largely already have that infrastructure in place.

• Smart-ID, the region's dominant mobile identification service, holds the highest eIDAS assurance level and already serves a combined user base in the millions across Lithuania, Latvia, and Estonia.
• The older Mobile-ID and national ID-card infrastructure remain in active use alongside Smart-ID as further non-smartphone-dependent options.
• Under the parallel eIDAS 2.0 framework, every member state must also make an EU Digital Identity Wallet available to citizens by the end of 2026, and banks, payment institutions, and e-money institutions will be required to accept wallet-based credentials for strong customer authentication.

Baltic PSPs that already integrate Smart-ID or Mobile-ID are starting the PSD3 transition with authentication infrastructure most of the EU still has to build.

Where Passkeys, FIDO2, and WebAuthn Fit In

Alongside national eID schemes, PSD3 and the PSR are also expected to give explicit regulatory footing to a broader authentication shift already underway across the industry: the move to FIDO2/WebAuthn-based passkeys. A passkey replaces a password with a device-bound cryptographic key pair – the device itself supplies possession while a PIN, fingerprint, or face scan supplies knowledge or inherence, device-bound passkeys already satisfy SCA's two-factor test and are considered phishing-resistant by design.  

Some of the ways passkeys are used:  

• Device-bound passkeys stored on a phone, laptop, or hardware security key are the form most readily treated as SCA-compliant, since possession and the biometric or PIN check both stay tied to one physical device.
• Cloud-synced passkeys (for example, Apple's iCloud Keychain or Google Password Manager) remain in more of a regulatory grey area: convenient and device-agnostic, but not yet explicitly confirmed as compliant, since the underlying key can in principle exist outside a single possessed device.
• Where a merchant, wallet, or payment gateway performs SCA on a bank's behalf using passkeys, that arrangement is treated as delegated authentication, a form of regulated outsourcing that pulls in EBA Guidelines and Digital Operational Resilience Act obligations: due diligence, written contracts, and audit rights.

For Baltic PSPs, passkeys are best treated as an additional authentication rail rather than a replacement for Smart-ID or Mobile-ID. National eID schemes already meet the non-smartphone-dependent requirement on their own, while device-bound passkeys give apps and websites a fast, phishing-resistant option for the large share of customers who are authenticating from a smartphone or laptop.

Consumer Permission Dashboards: A Major Change from PSD2

PSD3 and the PSR strengthen customer control over open-banking data sharing alongside the updated authentication rules. Under PSD2, banks had to grant access to authorised third-party providers, but customers often couldn't see which organisations still held access to their account data after giving consent. PSD3 fixes this with consumer permission dashboards, letting users view, manage, and revoke data-sharing permissions directly. The goal: better transparency, more control over financial data, and open-banking services people can actually trust.

For Baltic PSPs, banks, and EMIs, consent management now sits at the front end of the customer experience, not just in the compliance function. Permission dashboards need to connect with authentication systems, consent records, and open-banking APIs, so customers can see exactly which account information service providers (AISPs) and payment initiation service providers (PISPs) have access to their data. Combined with PSD3's expanded authentication requirements and the removal of fallback interfaces, these dashboards push open banking towards something more secure and user-centric than what PSD2 delivered.

Harmonising the Baltic-Nordic Payment Corridor

Lithuania, Latvia, and Estonia were among the first eight EU countries to go live with pan-European instant payments back in 2017, alongside several Nordic and Western European markets, and that early alignment has made the Baltic-Nordic corridor one of the more mature instant-payment routes in Europe. PSD3 and the PSR extend that harmonisation further by requiring:

• Uniform processing standards across every corridor a licensed institution operates in.
• Uniform fraud checks, including Verification of Payee, applied the same way domestically and cross-border.
• Uniform API performance expectations, removing the last pockets of divergence between how a transfer behaves at home and how it behaves across the corridor.

Bank of Lithuania's CENTROlink: direct access to payment systems for non-banks

CENTROlink, launched by the Bank of Lithuania in 2015, already does at national level something the PSR is only now making an EU-wide right: it lets payment institutions and e-money institutions connect directly to SEPA rails – with their own BIC and their own IBAN ranges – instead of relying on a commercial bank as a sponsor. It has grown into the largest such gateway in Europe by usage, reportedly handling the majority of SEPA indirect participation by payment and e-money institutions on the continent, and is now moving participants from an addressable-BIC model towards full direct participation.

The PSR's new right for non-bank payment service providers to access designated EU payment systems, including T2 (previously known as TARGET2), directly rather than through a sponsor bank effectively extends the CENTROlink model across the whole Union. That means Baltic institutions already built around direct settlement access have a multi-year operational head start over PSPs elsewhere that are only now planning for it.

2026 Fraud Rules: Mandatory IBAN & Name Matching

The PSR's fraud provisions are where PSD3 will be felt most immediately by customers, and they represent the sharpest departure from PSD2. For every credit transfer not already covered by separate instant-payments rules, payment service providers must check that the payee's name matches the IBAN or other unique identifier before the payment goes through and warn the payer in real time if there's a mismatch – a mechanism generally referred to as Verification of Payee.

Liability rules tighten alongside it:

• Where a fraudster impersonates a bank employee and manipulates a customer into authorising a payment, the bank must refund the full amount, with no cap, provided the customer reported the fraud to the police and informed the provider.
• The burden of proof shifts to the bank: to refuse a refund, it must show the customer colluded with the fraudster or acted with gross negligence.
• Payment service providers must also run risk- and behaviour-based transaction monitoring, and the PSR creates an explicit exception to GDPR restrictions so PSPs can share fraud intelligence with each other.
• Where a scam originated on a social media platform that knowingly hosted fraudulent content, the bank can, after refunding the customer, seek reimbursement from that platform – extending the liability chain well beyond the banking sector itself.

FiDA vs. PSD3: Open Banking to Open Finance

FiDA – the Financial Data Access Regulation – is a separate but closely related framework running in parallel with PSD3 and the PSR. Where PSD3/PSR governs access to payment accounts (the 'open banking' layer), FiDA extends the same access-and-consent logic to a much broader set of financial data: savings, mortgages, pensions, investments, and insurance. PSD3 covers moving money and reading current-account data; FiDA covers the rest of a customer's financial life.

Scope

PSD3/PSR cover payment accounts only; FiDA covers investment, pension, mortgage, and insurance data held by a much wider range of financial institutions.

Compensation

Account information under PSD3/PSR is generally accessed free of charge; FiDA explicitly permits data holders to charge for access under commercial data-sharing schemes.

Architecture

FiDA assumes a bank can share different data types with different authorised recipients under fine-grained permissions – something a single-block, monolithic core banking system generally cannot do without a move towards modular, microservices-based architecture.

For Baltic fintechs already building against PSD3-era dedicated APIs, FiDA is best treated as the next phase of the same infrastructure investment rather than a separate project. The consent of management and permission-dashboard work required for PSD3 compliance is largely reusable for FiDA readiness.

Unified Licensing for PI and EMI Institutions

PSD3 repeals the Electronic Money Directive (EMD2) as a separate act, so EMIs become payment institutions authorised to provide e-money services. The rules become simpler, but the transition remains complex: every existing EMI must demonstrate that it meets the new requirements. For details on changes to EMI licensing and capital requirements, and whether institutions are already late with re-authorisation, see our interview with legal experts on PSD3 and PSR in Lithuania. H3: Streamlining compliance: merging the E-Money directive into PSD3

Existing non-bank payment service providers, including e-money institutions, are reported to have a transitional window of around 27 months from the PSD3 entry into force to transition to new authorisation regime, During this period e-money institutions will be required to provide proof of their compliance with PSD3 to continue be authorised as payment institutions. For firms with a lean compliance function, this is not a formality: it means resubmitting governance, capital, safeguarding, and ICT risk-management documentation against PSD3's more explicit standards, which are now more closely aligned with the Digital Operational Resilience Act's expectations on incident handling and third-party risk.

Practical next steps for e-money institutions:

• Map current authorisation documentation against the new PSD3 requirements now.
• Flag any outsourcing or delegated-authentication arrangements that will need updated written agreements with audit rights.
• Engage the home regulator early rather than waiting for final technical standards from the European Banking Authority.

PSD3 and PSR timelines: what they mean for Baltic payment businesses

PSD3 and PSR are not routine updates. They reset how PIs and EMIs authenticate customers, share data, prove they are not liable for fraud losses, and connect to settlement systems.

Lithuania, Latvia and Estonia are better prepared for these changes than most EU countries. All three have mature instant payment practices, and their digital identity tools include smartphone-independent options (Mobile-ID and national ID cards), which PSR requires. Their supervisors also have experience licensing large numbers of EMIs.

This head start does not remove the remaining compliance work, and the new rules will not apply immediately. Under the final agreed text:

• both acts will enter into force 20 days after publication in the Official Journal;
• Member States will have 21 months from entry into force to transpose PSD3 into national law. On the same date, PSD2 and the Electronic Money Directive will be repealed and the general PSR provisions will start to apply;
• existing PIs and EMIs will have a transition period of up to 27 months to adapt to the new regime. Within the same period, Verification of Payee will be extended to all credit transfers.

Specific dates should be calculated from the actual entry into force, not from forecast publication dates. The key deadlines are likely to fall in 2028–2029. Verification of Payee, permission dashboards, dedicated APIs and EMIs’ transition to the new authorisation regime are mandatory regardless of jurisdiction, but Baltic-licensed firms have a shorter path to the finish line than most EU firms.