A Lithuanian EMI license allows an authorized Electronic Money Institution to issue electronic money and provide payment services across the EEA after passporting. For a full EMI, the core hard-law entry point remains €350,000 initial capital, with authorization and supervision handled by the Bank of Lithuania (Lietuvos bankas) under the national regime implementing Directive 2009/110/EC (EMD2) and Directive (EU) 2015/2366 (PSD2). In practice, serious applicants should budget for a 6–12 month end-to-end project, not just the formal supervisory review period, and should treat DORA, AML/CTF, safeguarding, outsourcing, and ICT governance as part of the licensing file rather than post-launch cleanup.
This page is informational and does not constitute legal, tax, or regulatory advice. Licensing outcomes depend on the applicant's business model, governance quality, completeness of the file, source of funds, safeguarding design, ICT setup, and supervisory assessment by the Bank of Lithuania. Tax treatment should be confirmed against current official guidance and case-specific advice before implementation.
Core authorization thresholds, timeline reality and the practical review lens in one block.
Define whether the model requires EMI, PI, or another regime; map products, target markets, safeguarding, and outsourcing.
Incorporation, capital planning, governance appointments, policies, financial model, AML framework, and ICT architecture are prepared.
The supervisory clock matters only after the file is considered complete; weak files lose time before substantive review even starts.
Approval does not replace operational onboarding with banks, safeguarding partners, vendors, auditors, or SEPA infrastructure providers.
A Lithuanian EMI license authorizes an institution to issue electronic money and provide relevant payment services within the legal perimeter of the EU electronic money and payments framework. In practical product terms, this is the regime used for customer wallets, stored balances, payment accounts, IBAN-led account products, merchant settlement flows, payroll wallets, and embedded finance models where users hold redeemable value rather than merely sending one-off payments.
The key legal distinction is that electronic money is not a bank deposit. E-money represents a monetary value stored electronically, issued on receipt of funds, and redeemable at par. That redemption feature is not a marketing detail; it is one of the core prudential mechanics that affects safeguarding, reconciliation, customer terms, and balance-sheet treatment. A Lithuanian EMI may also provide payment services listed under the PSD2 framework, but it may not present itself as a bank or take repayable funds from the public as deposits.
For founders, the practical test is simple: if the product requires customer balances that can be held, reused, and redeemed, EMI is usually the relevant route. If the model only moves funds from point A to point B without issuing stored value, a PI license may be enough. If the model requires deposit-taking or broader banking permissions, the EMI regime is the wrong perimeter.
The correct license depends on the product perimeter, not on branding. A Lithuanian EMI is the right fit where the business model requires stored value, customer wallets, or balances that remain available for later use. A PI is usually sufficient where the institution only executes payment flows and does not issue e-money. A specialized bank sits in a different category because it can engage in deposit-taking and broader banking activity, with a materially heavier prudential and governance burden.
Founders often over-license because they want optionality. In practice, over-licensing can slow the project and expand the control burden unnecessarily. Under-licensing is worse: if the model functionally creates redeemable stored value, the regulator will look through product labels and assess the substance. That is why the stored-balance question is usually the first licensing fork.
| Parameter | PI | EMI | Specialized Bank |
|---|---|---|---|
| Core legal function | Provides payment services under PSD2 without issuing electronic money. | Issues electronic money and may also provide payment services. | Provides banking services under a banking regime, including deposit-taking within its licensed scope. |
| Initial capital | €20,000–€125,000 depending on the payment services provided. | €350,000 for a full EMI. | Higher prudential threshold than EMI; separate banking regime applies. |
| Stored balances / wallets | Not suitable where the model requires issuance of reusable stored e-money value. | Yes; this is the core use case. | Yes, but under a banking framework rather than e-money law. |
| Deposit-taking | No. | No. | Yes, within the banking authorization perimeter. |
| Typical use cases | Money remittance, payment processing, payment flow only models, some merchant payment services. | Neobank-style wallets, payroll wallets, marketplace balances, B2B treasury wallets, embedded finance with customer balances. | Deposit products, broader treasury and lending structures, bank-grade balance-sheet models. |
| Passporting | Yes, for authorized institutions after notification. | Yes, for authorized institutions after notification. | Passporting mechanics differ and follow the banking framework. |
| Prudential focus | Payment volume, safeguarding where relevant, governance, AML, outsourcing. | Initial capital, outstanding e-money, safeguarding, redemption, governance, AML, ICT resilience. | Bank capital, liquidity, governance, recovery and broader prudential supervision. |
| Best fit | Payment flow only. | Wallet / IBAN / stored value / reusable balance models. | Deposit-taking and wider banking strategy. |
A Lithuanian EMI operates under a layered framework: EMD2 for electronic money, PSD2 for payment services, national Lithuanian implementing law and supervisory rules, and cross-cutting EU regimes such as DORA, AML/CTF legislation, and GDPR. In 2026, applicants should also understand the reform trajectory toward PSD3 / PSR, even though authorization decisions continue to be made under the current applicable regime until new legislation takes effect.
The practical point is that the Bank of Lithuania does not assess an EMI file as a stack of isolated PDFs. It reviews whether the applicant’s legal perimeter, control model, outsourcing map, safeguarding design, governance, and ICT environment form a coherent operating institution. This is where many weak applications fail: the legal documents say one thing, the financial model assumes another, and the technology or safeguarding setup cannot support the promises made in the program of operations.
A 2026-ready EMI file should distinguish clearly between current applicable law and forward-looking reform planning. Referring to PSD3 or PSR as if already in force would weaken legal accuracy; ignoring them entirely can weaken strategic planning.
| Framework | Why It Matters | Operational Impact |
|---|---|---|
| Directive 2009/110/EC (EMD2) | EMD2 is the core EU legal basis for electronic money issuance, redemption, initial capital, and prudential treatment of EMIs. | Defines whether the product is actually e-money, drives redemption wording in customer terms, and shapes safeguarding and own-funds analysis. |
| Directive (EU) 2015/2366 (PSD2) | PSD2 governs payment services, conduct rules, security obligations, and passporting mechanics for payment activity. | Affects payment execution, SCA-related design where relevant, agent/outsourcing structures, and the range of payment services the EMI may provide. |
| Bank of Lithuania national supervisory regime | Lithuania's national law and supervisory practice determine the application package, local expectations, and ongoing reporting interface. | Applicants must submit a file that is complete, internally consistent, and tailored to the Lithuanian supervisory process rather than copied from another jurisdiction. |
| DORA — Regulation (EU) 2022/2554 | DORA applies to financial entities and makes ICT risk management, incident governance, resilience testing, and third-party oversight a live compliance issue. | Applicants should be ready with ICT asset inventory, incident classification, vendor register, contractual controls, business continuity, and recovery planning. |
| AML/CTF framework | EMIs are high-scrutiny financial institutions for AML, sanctions, fraud, and source-of-funds controls. | The regulator will expect customer risk assessment, onboarding controls, transaction monitoring, sanctions screening, escalation logic, and MLRO ownership. |
| GDPR and local data protection supervision | Fintech onboarding, transaction monitoring, fraud controls, and vendor outsourcing all involve large-scale personal data processing. | Applicants should map lawful basis, retention, processor contracts, access control, and cross-border data flows; weak privacy governance can undermine the licensing narrative. |
| MiCA — Regulation (EU) 2023/1114 | MiCA matters if the group intends to issue an e-money token or build a stablecoin strategy on top of EMI authorization. | EMI status may be necessary for EMT issuance, but additional MiCA obligations such as white paper, reserve, disclosure, and redemption controls still apply. |
A Lithuanian EMI applicant must show more than a legal entity and paid-in capital. The Bank of Lithuania will assess whether the institution has the financial base, governance, fit-and-proper management, AML and safeguarding architecture, and operational substance necessary to run a regulated e-money business. In practice, the quality of management and control design often matters as much as the formal document count.
The usual corporate vehicle is a Lithuanian company such as UAB or AB, but the legal form is only the starting point. The regulator will look through ownership, source of funds, group structure, and decision-making reality. Applications built around nominal local presence but fully externalized control frequently run into questions on substance, outsourcing dependence, and who actually manages risk.
Applicants should also separate three categories of requirements: hard law, supervisory expectations, and market practice. For example, physical presence and credible local decision-making are practical expectations that support supervisory comfort, even where a specific staffing number is not a universal statutory rule for every case.
A common licensing mistake is to present outsourcing as a substitute for governance. Outsourcing may be permitted, but accountability remains with the EMI. The stronger the outsourcing footprint, the stronger the oversight evidence must be.
| Area | Regulatory Expectation | Evidence Pack |
|---|---|---|
| Legal entity and seat | A Lithuanian legal entity is required, commonly a UAB or AB, with a registered office and an operating setup consistent with the proposed business. | Incorporation documents, shareholder register, articles, registered address, and organizational setup. |
| Initial capital | A full EMI requires €350,000 initial capital. This is an entry threshold and does not replace ongoing own-funds maintenance. | Capital contribution evidence, bank confirmation, accounting records, and prudential planning. |
| Own funds | The institution must maintain own funds at least at the required prudential level, generally assessed against the higher of initial capital and the formula-driven ongoing requirement linked to e-money/payment activity. | Financial projections, prudential methodology, capital planning memo, and stress assumptions. |
| Shareholders and UBOs | Qualifying shareholders and beneficial owners must be transparent, reputable, and able to evidence lawful source of funds and source of wealth where relevant. | UBO charts, passports, corporate chain documents, source-of-funds pack, declarations, and adverse-media screening. |
| Management body and senior management | The regulator expects a credible governance structure with real oversight, not nominee appointments. Interviews may be used to test understanding of the business and risk model. | CVs, criminal-record and reputation checks, role descriptions, time-commitment analysis, and governance map. |
| Control functions | Compliance, AML/MLRO, risk, and internal control responsibilities must be clearly assigned, with adequate independence and escalation lines. | Policies, committee terms, reporting lines, outsourcing analysis, and evidence of function-holder competence. |
| Physical office and substance | A physical office and genuine operational presence in Lithuania are typically expected. Substance is assessed case by case against the scale and risk of the model. | Lease, staffing plan, local management availability, board calendar, and operational process ownership. |
| Business model clarity | The product perimeter must be legally coherent: issuance of e-money, payment services, customer segments, geographies, and safeguarding flows must align. | Program of operations, customer journey maps, T&Cs, financial model, and product-control matrix. |
| Safeguarding design | The applicant must show how customer funds are separated, reconciled, protected, and redeemed without contamination by proprietary funds. | Safeguarding policy, account structure, reconciliation procedure, insolvency analysis, and partner-bank documentation. |
| ICT and outsourcing | Core systems, cloud providers, processors, AML vendors, and card/program partners must be governed under a controlled outsourcing and ICT risk framework. | Architecture diagrams, vendor register, outsourcing policy, SLAs, incident process, and DORA control mapping. |
The Bank of Lithuania reviews an EMI application as a structured evidence pack, not as isolated forms. A strong file usually contains five document groups: corporate, financial and prudential, governance, AML/compliance, and ICT/operations. The regulator is not only checking whether each document exists; it is testing whether the documents agree with each other on the same facts.
For example, if the business plan promises instant merchant settlement, the safeguarding model, liquidity assumptions, bank-partner setup, and reconciliation process must support that promise. If the AML policy says high-risk customers are excluded, the commercial deck and onboarding flow cannot quietly target those same segments. Internal consistency is a licensing issue, not just a drafting preference.
| Document | Purpose | Owner |
|---|---|---|
| Program of operations | Defines the licensed activities, product perimeter, customer journeys, target markets, and operating model the regulator is being asked to authorize. | Legal / founders / regulatory lead |
| Three-year business plan and financial projections | Shows commercial rationale, prudential sustainability, revenue assumptions, cost base, break-even logic, and capital adequacy planning. | Finance / founders |
| Initial capital and source-of-funds pack | Evidences paid-in capital, shareholder funding capacity, lawful source of funds, and ownership transparency. | Shareholders / finance / legal |
| Corporate documents | Establishes the Lithuanian legal entity, constitutional documents, shareholding, and governance structure. | Corporate legal |
| UBO and qualifying holding disclosures | Allows fit-and-proper and ownership assessment of controllers and beneficial owners. | Legal / compliance |
| Governance framework | Sets out board oversight, senior management roles, committees, reporting lines, conflicts management, and decision rights. | Legal / compliance / HR |
| CVs and fit-and-proper evidence | Demonstrates the competence, reputation, time commitment, and role suitability of directors and key managers. | HR / legal |
| AML/CTF policy suite | Covers customer due diligence, risk scoring, sanctions screening, transaction monitoring, suspicious activity escalation, and MLRO responsibilities. | Compliance / MLRO |
| Safeguarding policy | Explains segregation or alternative protection method, reconciliation logic, customer-fund classification, and redemption controls. | Finance / operations / compliance |
| Risk management framework | Maps operational, AML, fraud, conduct, liquidity, outsourcing, and ICT risks with ownership and controls. | Risk / compliance |
| ICT architecture and security documentation | Shows core systems, data flows, access control, logging, resilience, incident handling, and vendor dependencies. | CTO / security / operations |
| Outsourcing register and key contracts | Identifies critical providers, control allocation, SLAs, audit rights, exit planning, and DORA-relevant contractual safeguards. | Legal / procurement / CTO |
| Customer terms and redemption terms | Confirms the legal characterization of e-money, fees, redemption rights, complaint handling, and conduct disclosures. | Legal / product |
A Lithuanian EMI project usually starts with regulatory perimeter analysis and ends only when the institution is operationally ready to launch, not when the first draft application is emailed. In practice, the process has five stages: feasibility, incorporation and design, documentation build, supervisory review, and post-approval readiness. The formal review clock matters, but incomplete files usually lose more time before that clock starts than during the clock itself.
The file should read like one operating model, not like disconnected policy appendices.
| Document | Purpose | Owner |
|---|---|---|
| Program of operations | Defines exactly what the Bank of Lithuania is being asked to authorize. | Legal / founders |
| Financial projections and prudential model | Supports capital adequacy, own-funds planning, and business viability. | Finance |
| AML/CTF framework | Shows how the EMI will identify, monitor, and escalate financial crime risk. | Compliance / MLRO |
| Safeguarding framework | Explains client-funds protection mechanics and reconciliation controls. | Finance / operations |
| ICT and outsourcing pack | Demonstrates system resilience, vendor governance, and DORA readiness. | CTO / security / legal |
The cost of a Lithuanian EMI project has two different layers: regulatory capital and implementation spend. The first is the hard-law capital requirement of €350,000 for a full EMI. The second includes legal drafting, compliance design, audit and accounting support, staffing, office, technology, AML tooling, and vendor onboarding. Founders often confuse these two buckets and under-budget the launch by focusing only on the capital number.
For planning purposes, many applicants model a first-year launch envelope in the range of roughly €430,000–€600,000+, depending on how much is built in-house, whether card or cross-border infrastructure is included, and how mature the AML/ICT stack already is. This is not a statutory number; it is a practical market-planning range and should be validated against the actual project scope.
| Cost Bucket | Low Estimate | High Estimate | What Drives Cost |
|---|---|---|---|
| Initial regulatory capital | €350,000 | €350,000 | Hard-law entry capital for a full EMI. This is not a fee and should not be treated as disposable operating spend. |
| State application fee | €1,463 | €1,463 | Application fee commonly referenced for a Lithuanian EMI filing. |
| Legal and regulatory preparation | €20,000 | €50,000+ | Depends on the complexity of the business model, number of jurisdictions, outsourcing footprint, and whether MiCA or card-program elements are in scope. |
| Audit, accounting, and finance setup | €8,000 | €20,000 | Includes external audit planning, accounting design, and reporting setup; recurring cost continues after launch. See also /accounting/lithuania/. |
| AML, sanctions, and fraud tooling | €5,000 | €30,000+ | Varies significantly by customer volume, screening vendors, KYC depth, and transaction-monitoring sophistication. |
| ICT, security, and vendor onboarding | €10,000 | €60,000+ | Cloud, core ledger, access management, logging, BCP/DR, and integration work can materially change the budget. |
| Office and substance build-out | €5,000 | €25,000+ | Physical office, local administration, and staffing create real substance cost even before scale. |
Safeguarding is a core prudential obligation, not a back-office formality. A Lithuanian EMI that receives funds in exchange for e-money must protect those funds so that customer money is separated from the institution’s own assets and remains insulated in an insolvency scenario to the extent required by law and the safeguarding model used. In practice, the regulator will look for a safeguarding design that is legally sound, operationally executable, and supported by daily controls.
The most common model is segregation through dedicated safeguarding accounts with a credit institution, combined with reconciliation procedures that match incoming funds, issued e-money, pending settlements, fees, chargebacks, and redemptions. The difficult part is not writing that sentence in a policy; the difficult part is proving how the institution will classify funds at each stage of the payment lifecycle and who resolves breaks when ledger balances and bank balances diverge.
A strong safeguarding file usually explains at least four things clearly: when funds are deemed received, when e-money is issued, where safeguarded balances are held, and how the institution prevents operational funds from contaminating protected funds. It should also explain treatment of edge cases such as delayed bank postings, failed payouts, chargebacks, and redemption requests arriving around cut-off times.
| Workflow Step | Control | Owner |
|---|---|---|
| Receipt of customer funds | Classify the incoming payment, identify payer and purpose, and determine whether the funds are being received for e-money issuance or another permitted payment flow. | Operations / finance |
| Placement into safeguarding structure | Move or maintain funds within the designated safeguarded account structure in line with the safeguarding policy and timing rules. | Treasury / finance |
| Issuance of e-money | Create the corresponding customer liability on the ledger only when the receipt and classification conditions are met. | Core ledger / operations |
| Ongoing reconciliation | Reconcile bank balances, customer liabilities, pending settlements, fees, and exceptions; investigate mismatches and record root cause. | Finance / reconciliation team |
| Customer redemption or payout | Process redemption at par, update the ledger, and ensure the payout reduces safeguarded liability consistently across systems. | Operations / finance |
| Exception and insolvency protection review | Escalate unresolved breaks, review legal ring-fencing assumptions, and maintain evidence that customer funds remain distinguishable from house funds. | Compliance / finance / legal |
In 2026, an EMI application without a credible ICT control environment is structurally weak. Since 17 January 2025, DORA has made ICT risk management, incident handling, operational resilience, and third-party oversight an explicit compliance layer for financial entities. For a Lithuanian EMI, this means the technology stack is part of the licensing perimeter, not a post-approval implementation detail.
The Bank of Lithuania will not expect every early-stage applicant to run a bank-scale infrastructure, but it will expect the institution to know its critical systems, data flows, dependencies, and failure points. That includes core ledger logic, customer onboarding, sanctions screening, transaction monitoring, access control, logging, backup, recovery, and vendor governance. If cards or acquiring are in scope, additional standards such as PCI DSS, scheme rules, and fraud controls become relevant. If the institution relies on SEPA rails, the operating model should also be consistent with ISO 20022 messaging and payment operations discipline.
A practical supervisory question is not whether the EMI uses vendors; almost all do. The question is whether the EMI can still govern critical risk if a vendor fails, degrades service, or changes subcontractors.
| Area | Control | Owner |
|---|---|---|
| ICT governance | Maintain an ICT governance framework with asset inventory, role ownership, risk taxonomy, and board-level reporting on critical systems. | Board / CTO / risk |
| Access management | Implement role-based access, joiner-mover-leaver controls, privileged access review, MFA where appropriate, and evidenceable approval trails. | CTO / security |
| Logging and monitoring | Retain system and security logs, define alert thresholds, and ensure suspicious operational events can be investigated end to end. | Security / DevOps |
| Incident management | Maintain incident classification, escalation, response, root-cause analysis, and regulatory reporting logic consistent with DORA obligations. | Security / compliance / operations |
| Business continuity and disaster recovery | Define backup, recovery objectives, failover responsibilities, and periodic testing for critical services and data restoration. | CTO / operations |
| AML and sanctions systems | Deploy customer screening, transaction monitoring, alert handling, and case management with documented tuning and ownership. | MLRO / compliance / operations |
| Fraud prevention | Implement fraud rules, velocity controls, device or behavioral signals where relevant, and escalation paths between first line and compliance. | Operations / fraud / compliance |
| Outsourcing and third-party risk | Keep a register of critical providers, perform due diligence, include audit and exit rights, and monitor concentration risk and subcontracting. | Legal / procurement / CTO / compliance |
A Lithuanian EMI can expand across the EEA through passporting, but passporting is a notification-based market access mechanism, not a substitute for operational readiness. The institution must distinguish between freedom to provide services on a cross-border basis and establishment through a branch. The choice affects governance, local presence, customer support, and implementation sequencing.
Lithuania remains strategically relevant because of the Bank of Lithuania’s fintech infrastructure layer, especially CENTROlink, which can support access to SEPA Credit Transfer (SCT) and SEPA Instant Credit Transfer (SCT Inst). That said, access to SEPA infrastructure is not automatic with the license. The EMI still needs onboarding, technical readiness, compliance alignment, and operational capability to use the rails effectively.
Passporting should be planned together with AML segmentation, customer support language, complaints handling, sanctions coverage, and payment operations. Expansion fails more often from weak operating design than from the notification itself.
| Topic | Details | Risk Note |
|---|---|---|
| Freedom to provide services | Allows the Lithuanian EMI to serve customers in another EEA state without establishing a branch, subject to the passporting notification process. | Cross-border service does not eliminate host-state consumer, marketing, or AML overlay considerations. |
| Branch establishment | Used where the expansion model requires a more permanent local presence, local staff, or operational footprint in another EEA state. | A branch can increase governance, reporting, and local compliance complexity. |
| CENTROlink and SEPA access | CENTROlink can reduce dependence on correspondent structures by providing access to SEPA schemes, including SCT and SCT Inst, where the EMI meets onboarding and operational criteria. | License approval alone does not guarantee acceptance into infrastructure or immediate production connectivity. |
| Instant payments competitiveness | In 2026, euro instant payments are increasingly a commercial and operational baseline rather than a premium feature for many fintech models. | Institutions that design only for batch settlement may face both market pressure and additional remediation later. |
| IBAN and account products | A Lithuanian EMI can structure IBAN-led payment account products where its banking, scheme, and infrastructure arrangements support the model. | IBAN capability depends on the actual account and payment architecture, not on marketing language. |
Most EMI files are not delayed because the law is unclear; they are delayed because the application does not prove that the institution can be supervised safely. The Bank of Lithuania typically looks for coherence between product design, governance, safeguarding, financial assumptions, and ICT control. When those elements do not align, the file starts to look like a concept pitch rather than a regulated institution.
The fastest way to weaken an EMI application is to understate operational complexity. A wallet business is not just a user interface plus a partner bank. It is a regulated liability model with redemption rights, safeguarding, AML surveillance, reconciliation discipline, outsourcing control, and incident governance. If the application treats those as outsourced afterthoughts, the regulator will usually ask who is actually in control.
Legal risk: The supervisory review may not progress efficiently because the regulator cannot assess the real business perimeter or control model.
Mitigation: Run a consistency review across the program of operations, financial model, AML policy, safeguarding policy, and ICT architecture before submission.
Legal risk: If customer-funds protection is vague, the regulator may doubt whether the institution can lawfully issue and protect e-money.
Mitigation: Document account structure, reconciliation logic, exception handling, and ownership of daily safeguarding controls in operational detail.
Legal risk: Fit-and-proper and AML concerns can arise at shareholder and UBO level, undermining the entire application.
Mitigation: Prepare a clean ownership map, source-of-funds evidence, and adverse-media screening pack early in the project.
Legal risk: The regulator may conclude that governance is not credible for the scale or risk of the proposed business.
Mitigation: Appoint experienced executives and control-function holders with real time commitment and clear role ownership.
Legal risk: The institution may appear unable to control essential functions, creating governance and DORA-related concerns.
Mitigation: Maintain a critical-outsourcing register, due diligence, contractual controls, KPIs, incident escalation, and exit planning.
Legal risk: Aggressive assumptions can call into question viability, prudential planning, and the credibility of the business plan.
Mitigation: Use conservative ramp-up assumptions, stress scenarios, and a prudential narrative that explains capital resilience.
Legal risk: If Lithuania is used only as a formal seat while control sits elsewhere, the supervisory home-state logic becomes weak.
Mitigation: Evidence local office, local management availability, governance cadence, and real decision-making in Lithuania.
The best route depends on timing, control, and product ambition. Building a Lithuanian EMI gives maximum regulatory control and long-term enterprise value, but it requires capital, governance maturity, and patience. Using a partner EMI or acquiring an existing platform can accelerate market entry, but those options usually limit product flexibility, margin control, or integration independence.
The strategic mistake is to choose only on speed. Founders should decide based on whether the business needs its own balance-sheet perimeter, its own safeguarding model, and its own passporting strategy. If the answer is yes, building or acquiring a regulated perimeter may be justified. If the answer is no, a partner model can be rational while the product proves demand.
| Option | Advantages | Limitations | Best For |
|---|---|---|---|
| Build a new Lithuanian EMI | Full control over product perimeter, safeguarding model, governance, passporting strategy, and long-term regulatory asset creation. | Requires €350,000 initial capital, full licensing project, management build-out, and ongoing compliance overhead. | Groups building wallets, stored-value products, embedded finance, or multi-market account infrastructure with long-term scale plans. |
| Operate under a partner EMI / BaaS model | Faster market entry, lower upfront regulatory burden, and ability to test product-market fit before building a regulated institution. | Lower control over pricing, compliance perimeter, product roadmap, customer terms, and infrastructure dependencies. | Early-stage fintechs validating demand or launching a narrow feature set before committing to own authorization. |
| Acquire or invest in an existing regulated platform | Potentially faster than greenfield licensing if the target is clean, operational, and strategically aligned. | Requires deep legal, regulatory, AML, financial, and technology due diligence; hidden liabilities can outweigh speed benefits. | Well-capitalized groups with M&A capability and a clear post-acquisition integration plan. |
These answers address the questions founders, legal teams, and investors most often ask when assessing a Lithuanian EMI project in 2026.
For a full Lithuanian EMI, the minimum initial capital is €350,000. This is the entry threshold under the electronic money regime and should be distinguished from ongoing own-funds requirements, which may need to be maintained above that level depending on the institution's activity.
A realistic end-to-end project usually takes 6–12 months. The often-cited formal review period of up to 3 months is generally relevant after the application is considered complete, so weak or inconsistent files can take materially longer.
A PI provides payment services but does not issue electronic money. An EMI can issue e-money and also provide payment services. If the product requires customer balances, wallets, or reusable stored value, EMI is usually the relevant regime.
Yes, non-resident founders or groups may structure a Lithuanian EMI project, but the applicant still needs a Lithuanian legal entity, transparent ownership, lawful source-of-funds evidence, credible management, and sufficient local substance to satisfy the Bank of Lithuania.
A physical office and genuine operational presence in Lithuania are typically expected in practice. Substance is assessed case by case, but purely nominal local presence is a common weakness in applications.
Yes. After authorization, a Lithuanian EMI may passport eligible services across the EEA through the applicable notification process, either on a cross-border basis or through a branch model.
Potentially yes, including through the Lithuanian infrastructure ecosystem such as CENTROlink, but access is not automatic with the license. The EMI must still satisfy onboarding, technical, compliance, and operational requirements.
An EMI can support card and IBAN-led products where the operating model, banking arrangements, scheme participation, and infrastructure setup lawfully support those services. The license alone does not create every operational capability automatically.
An EMI may be a necessary type of issuer for an e-money token under MiCA, but EMI authorization alone is not sufficient. The issuer must still comply with the relevant MiCA obligations, including the EMT-specific layer such as disclosure, reserve, and redemption requirements.
A Lithuanian EMI should expect ongoing prudential, AML/CTF, safeguarding, governance, reporting, audit, outsourcing, and ICT resilience obligations. In 2026, DORA-related incident governance and third-party oversight are part of the practical compliance baseline.
Tax treatment should be confirmed against current official guidance from the Lithuanian tax authority and case-specific advice. Corporate income tax, VAT treatment of financial services, withholding tax, payroll taxes, and transfer-pricing issues may all be relevant depending on the structure.
The most common causes are incomplete files, weak safeguarding design, unrealistic financials, opaque source of funds, thin local substance, and over-reliance on outsourced providers without credible oversight.
A workable EMI project starts with perimeter accuracy, not document volume. If your model involves wallets, stored balances, IBAN-led accounts, merchant settlement, or a future MiCA / EMT layer, the next step is to map the license scope, capital path, safeguarding architecture, governance, and rollout sequence before drafting the filing.
