In Lithuania, PSD2 operates through the Law on Payments, and only authorized banks, payment institutions, and electronic money institutions may offer payment initiation or account information services. If your business relies on account access or payment initiation, verify the provider’s authorization status, confirm strong customer authentication readiness, and assess whether CENTROlink participation applies to your operations before signing any agreement.

TL;DR:

Only licensed banks, payment institutions, and electronic money providers in Lithuania can legally offer PSD2 payment initiation and account information services, verified through the Bank of Lithuania registry.

Strong customer authentication is mandatory for most electronic payments, with exemptions for low-value, recurring, or trusted payee transactions, and must be designed into operations from the start.

Providers must limit data access strictly to what is necessary for the service, and compliance requires thorough documentation, testing, and ongoing monitoring of API integrations and consent procedures.

Participation in CENTROlink for instant euro payments is crucial for high-volume payment processors, but delays often occur due to incomplete governance or AML documentation.

Businesses should plan for future PSD3 and FIDA changes by designing flexible APIs, conducting staged compliance tests, and maintaining continuous governance to avoid costly rework.

How Is PSD2 Implemented Under Lithuanian Law?
PIS vs. AIS: What Each Service Does for Your Business
Who Can Legally Provide PIS or AIS in Lithuania?
What Do SCA and API Requirements Look Like in Practice?
How Do You Get Authorized and Join CENTROlink?
What Should Be on Your PSD2 Readiness Checklist?
What Should Businesses Track for PSD3 and FIDA?
Demivolt’s View: Lessons From Operating a Regulated Payments Platform
How Demivolt Supports PSD2 Compliance in Lithuania
Where to Verify PSD2 Rules and Provider Status
Sources

How Is PSD2 Implemented Under Lithuanian Law?

PSD2 became enforceable in Lithuania through amendments to the Law on Payments, with the Bank of Lithuania confirming that payment initiation and account information services have been regulated this way since 2018. The statute sets out who may offer these services and under what conditions, and it remains the primary legal reference for any business building payment features on top of Lithuanian bank accounts.

Lithuanian coverage of the rollout, including Verslo žinios’s reporting on the transposition timeline, documented the compliance deadlines that existing payment institutions and electronic money institutions had to meet. The Bank of Lithuania supervises the framework and maintains the registries businesses need to confirm a provider’s legal standing.

Three provisions matter most for day-to-day operations:

Only licensed entities may perform PIS or AIS activities.
Strong customer authentication applies to most electronic payments.
Providers must limit data access to what a service strictly requires.

The Law on Payments transposition also defines authorization tiers for payment institutions and electronic money institutions, which determines what a provider can legally do with your funds and data.

PIS vs. AIS: What Each Service Does for Your Business

Payment initiation services (PIS) let a licensed provider trigger a transfer directly from a customer’s bank account, skipping card networks entirely. A retailer using PIS at checkout gets funds moved account to account, often at lower cost than card processing. Account information services (AIS), by contrast, pull read-only account data across multiple banks into one view, which is why accounting platforms and treasury dashboards rely on it for consolidated cash visibility.

Both services depend on explicit customer consent, and Lithuanian rules follow the same discipline as the rest of the EU on this point:

The customer grants consent through the bank’s authentication flow, not through the third-party provider directly.
The provider may only access the data or initiate the payment the consent specifically covers.
Consent can be revoked at any time, and the bank must honor that revocation immediately.
Providers cannot collect extra personal data beyond what the transaction or account view requires.

That last constraint trips up a surprising number of new entrants, who build data models around convenience rather than the minimization principle baked into the law.

Who Can Legally Provide PIS or AIS in Lithuania?

Five categories of entities can legally offer these services: banks, credit unions, payment institutions, electronic money institutions, and firms passported from elsewhere in the EEA. Each carries different capital and governance obligations, but all must appear in an official registry before touching customer accounts.

Checking the Bank of Lithuania’s PIS/AIS registry takes minutes and should happen before any vendor contract gets signed. An entry confirms not just that a firm exists, but which specific service category it holds a license for.

Watch for these warning signs during vendor due diligence:

No matching entry in the Bank of Lithuania registry.
Vague or missing AML/KYC documentation.
No verifiable local contact or Lithuanian regulatory reference number.
Passporting claims that can’t be traced to a home regulator.

Pro Tip: Ask any prospective payment provider for their exact registry entry number, not just a claim of being “licensed in the EU.” A real entry number takes ten seconds to verify against the Bank of Lithuania’s public list.

What Do SCA and API Requirements Look Like in Practice?

Strong customer authentication requires two independent factors, usually a device plus a biometric or PIN, for most electronic payments over the regulatory threshold. Exemptions exist for low-value transactions, recurring payments to trusted payees, and certain corporate payment flows, but businesses should design for SCA as the default rather than the exception.

Lithuanian banks support both redirect-based flows, where the customer authenticates directly on the bank’s own interface, and dedicated PSD2 APIs that keep more of the experience inside your product. OpenBankingTracker catalogs which Lithuanian banks offer developer sandboxes and API documentation, a useful starting point before committing engineering time to any single integration path.

Before going live, confirm your build covers:

Secure, auditable consent storage separate from analytics systems.
Logging sufficient to reconstruct any transaction dispute.
A documented incident response plan for authentication failures.
3DS integration where card rails run alongside account-to-account payments, detailed further in Demivolt’s guide to SCA and 3D Secure.

How Do You Get Authorized and Join CENTROlink?

Authorization as a payment institution or electronic money institution in Lithuania follows a defined sequence:

Prepare governance documentation, including organizational structure and fit-and-proper assessments for management.
Demonstrate minimum capital requirements tied to your license category.
Submit AML and KYC policies that satisfy the Bank of Lithuania’s supervisory standards.
Await regulatory review, which typically runs several months depending on file completeness.

CENTROlink participation, covered in the Bank of Lithuania’s FAQ, gives direct access to instant euro payments and matters most for PIs and EMIs that process high transaction volumes. The most common delay isn’t capital. It’s incomplete governance documentation and underdeveloped AML policies that get bounced back for revision.

What Should Be on Your PSD2 Readiness Checklist?

A structured internal review beats scrambling after a partner asks for proof of compliance. Break the check into three lanes:

Legal: Confirm your provider’s registry status, update customer terms to reflect PIS/AIS use, and sign formal agreements with account-servicing payment providers.
Technical: Build an API integration plan, run SCA test cases in a sandbox, and separate consent logs from general analytics, echoing the data minimization approach Demivolt outlines for European SMEs.
Operational: Assign clear internal ownership for AML/KYC monitoring, document incident response roles, and schedule periodic third-party audits.

Pro Tip: Run your sandbox tests against real edge cases, expired consent, revoked tokens, partial refunds, not just the happy path. Most integration failures surface exactly there.

What Should Businesses Track for PSD3 and FIDA?

PSD3 and the Financial Data Access Regulation (FIDA) are expected to widen data-sharing obligations well beyond the account information scope PSD2 currently covers. OpenBankingTracker notes that firms building only to today’s PSD2 requirements risk having to rework consent and data-governance models again within a few years.

Three actions reduce that rework:

Design API governance broad enough to absorb new data categories without a full rebuild.
Monitor Bank of Lithuania guidance on CENTROlink migration windows, since instant payment infrastructure keeps evolving alongside the regulation.
Run staged compliance testing on a schedule, not just before a deadline, so gaps surface while there’s still time to fix them.

Treat this as a governance habit, not a one-time project. The businesses that struggle most under PSD3 will be the ones that treated PSD2 compliance as a box checked once and forgotten.

Demivolt’s View: Lessons From Operating a Regulated Payments Platform

Some regulated European fintech platforms offer dedicated IBAN accounts, SEPA and SWIFT processing, and segregated client funds, which means compliance work like this isn’t theoretical. The most common failure pattern isn’t fraud or bad intent. It’s a sandbox environment that behaves differently from production, catching teams off guard during launch week.

Consent user experience causes nearly as much trouble. A confusing authentication flow drives customers to abandon transactions, which shows up as a business problem long before it shows up as a compliance one. AML edge cases, particularly around passported EEA firms with limited local presence, deserve extra scrutiny during vendor selection.

For finance and engineering teams evaluating a payments partner, the practical move is to test the full consent and revocation cycle before committing, not just the initiation flow.

— dd

How Demivolt Supports PSD2 Compliance in Lithuania

Some platforms give businesses a regulated foundation instead of a patchwork of vendors, with dedicated IBAN accounts, SEPA and SWIFT payment rails, and virtual or physical card issuance, built on segregated client funds rather than pooled accounts. That structure matters most for companies juggling cross-border payments who need one compliant setup instead of stitching together multiple banking relationships.

Finance teams handling international payouts benefit most, especially those verifying account details before every SEPA or SWIFT transfer. Before you initiate your next cross-border payment, confirm the receiving account is correctly formatted using Demivolt’s free IBAN validator. If you’re setting up a new business account and want to understand how IBAN structure affects routing, Demivolt’s guide on what an IBAN is and how it works covers the fundamentals. For businesses exploring alternative settlement rails alongside SEPA, CryptoPayr’s coverage of payment options for high-risk industries offers useful industry context. Start by validating your next IBAN before it reaches production.

Where to Verify PSD2 Rules and Provider Status

Confirm any claim in this article against the primary sources. The Bank of Lithuania’s PIS/AIS registry answers whether a provider is legally authorized. Its FAQ section covers CENTROlink participation questions. OpenBankingTracker tracks which banks offer developer sandboxes, and Noda’s overview of Lithuanian open banking adds market adoption context worth cross-checking before any integration decision.

Get PSD2 Ready in Lithuania: 4 Steps to Authorization + Demivolt Tips

Table of Contents