An EMI license in Lithuania allows a company to issue electronic money and provide payment services under the supervision of the Bank of Lithuania (Lietuvos bankas). For a full EMI, the headline entry threshold is €350,000 initial capital; the practical end-to-end timeline is usually 6-12 months, not just the statutory review clock. A licensed Lithuanian EMI can generally passport services across the EEA after notification, but it must also maintain safeguarding, own funds, AML/CTF controls, governance substance, and ICT resilience aligned with EMD2, PSD2, DORA, GDPR, and, where relevant, MiCA.
This page is an informational compliance guide, not legal or tax advice. Regulatory fees, filing mechanics, tax treatment, and supervisory expectations should be verified against current Bank of Lithuania, EUR-Lex, and local counsel sources at the time of application.
Core authorization thresholds, timeline reality and the practical review lens in one block.
Define whether the model requires EMI rather than PI, map target services, governance, safeguarding, and outsourcing perimeter.
Prepare the program of operations, AML package, financial projections, ICT architecture, safeguarding model, and shareholder evidence.
The practical timeline depends on file completeness, response quality, and whether the regulator pauses the clock for clarifications.
Open safeguarding arrangements, finalize vendor contracts, implement reporting, test payment flows, and activate control functions.
An EMI license in Lithuania authorizes a company to issue electronic money, redeem electronic money, and provide the payment services permitted under the applicable legal framework. In practical terms, this can support e-wallets, stored-value accounts, multicurrency payment products, merchant settlement flows, remittance models, payroll and payout solutions, and embedded finance structures where users hold monetary value with the institution.
The critical legal distinction is that an EMI may issue electronic money, while a PI generally may provide payment services without issuing e-money. That distinction matters where client balances are stored as a claim on the institution. It also affects safeguarding design, own funds analysis, customer terms, and product architecture.
An EMI is not a bank. It does not become a credit institution merely because it offers IBAN-linked accounts, cards through partners, or SEPA connectivity. A Lithuanian EMI may support payment accounts and payment execution, but it cannot market itself as taking deposits like a bank unless it holds the relevant banking authorization.
The decision starts with one question: will the customer hold stored monetary value with your institution? If yes, the model often points toward an EMI rather than a PI. If the company only executes payments without issuing e-money, a PI may be sufficient. A specialized bank becomes relevant where the business needs a broader prudential perimeter, including deposit-taking or a more bank-like balance sheet model.
Founders often over-license too early. The better approach is to map the actual product mechanics: where funds sit, whether balances are stored, whether the institution owes redemption of e-money, and whether the business needs passporting, direct scheme connectivity, or broader banking functionality.
| Parameter | PI | EMI | Specialized Bank |
|---|---|---|---|
| Right to issue electronic money | No. A PI provides payment services but does not issue e-money. | Yes. This is the defining feature of an EMI. | Yes, but within a banking prudential framework rather than a pure EMI model. |
| Typical use case | Payment execution, remittance, acquiring, or payment initiation without stored value. | Wallets, stored-value accounts, multicurrency balances, embedded finance with customer balances. | Broader banking products, more balance-sheet intensive models, and deposit-oriented structures. |
| Initial capital baseline | Depends on the payment services provided under the PI regime. | €350,000 for a full EMI is the standard headline threshold. | Higher prudential capital expectations than EMI. |
| Safeguarding relevance | Yes, where client funds are received for payment services. | Yes, and it becomes central because e-money issuance creates a standing redemption claim. | Different prudential framework applies; not the same safeguarding logic as EMI. |
| Customer perception risk | Lower risk of confusion with deposits if no stored balances are offered. | Higher risk if marketing language blurs the line between e-money and deposits. | Banking terminology is native to the license type. |
| When it is usually enough | When the product only moves money and does not store value as e-money. | When users maintain balances, wallets, or account-like stored value. | When the model needs a full banking perimeter rather than a payments-only one. |
A Lithuanian EMI sits inside a layered EU and national framework. The licensing core still comes from EMD2 and PSD2, implemented through Lithuanian law and supervised by the Bank of Lithuania. Around that core, the operational burden has expanded: AML/CFT expectations are deeper, outsourcing governance is more granular, and DORA has made ICT resilience a board-level issue rather than a technical appendix.
For 2026 applicants, the practical point is simple: the regulator does not assess only the legal form and capital. It assesses whether the institution can operate safely. That means the file must connect the business model, safeguarding, governance, AML risk assessment, ICT architecture, outsourcing map, incident management, and financial projections into one coherent operating model.
Where the EMI intends to issue or support crypto-linked products, MiCA becomes relevant. In particular, an e-money token (EMT) is not just a branding exercise around a stablecoin; it is a regulated category with issuer obligations, redemption mechanics, reserve logic, and disclosure requirements. That is why crypto-adjacent founders should map the EMI perimeter and MiCA perimeter together, not sequentially.
A useful 2026 distinction is this: hard law defines the perimeter, while regulator expectation defines the quality threshold. Many weak applications fail not because the law is unclear, but because the operating model is internally inconsistent.
| Framework | Why It Matters | Operational Impact |
|---|---|---|
| Directive 2009/110/EC (EMD2) | EMD2 defines electronic money and the authorization logic for electronic money institutions. | It drives the distinction between e-money issuance and ordinary payment services, including redemption and own funds logic tied to outstanding e-money. |
| Directive (EU) 2015/2366 (PSD2) | PSD2 governs payment services and the broader payments perimeter around an EMI. | It affects service classification, customer information, conduct rules, security, SCA-related flows, and passporting mechanics. |
| Lithuanian Law on Electronic Money and Electronic Money Institutions | This is the national legal basis that operationalizes the EMI regime in Lithuania. | It governs local authorization mechanics, restricted vs full regimes where applicable, and domestic supervisory expectations. |
| Lithuanian AML/CFT law and EBA AML expectations | AML/CFT is one of the main reasons for regulator comments, delay, or refusal. | Applicants need customer risk scoring, sanctions screening, PEP handling, transaction monitoring, STR/SAR escalation, and UBO/source-of-funds clarity. |
| Regulation (EU) 2022/2554 (DORA) | DORA applies to financial entities and raises the standard for ICT risk governance. | The EMI must evidence incident handling, ICT asset governance, testing, business continuity, disaster recovery, and third-party ICT contract controls. |
| Regulation (EU) 2023/1114 (MiCA) | MiCA matters where the EMI intends to issue or support e-money tokens or operate adjacent crypto business lines. | EMT issuance requires additional compliance layers such as disclosures, redemption rights, reserve arrangements, and MiCA-specific governance. |
| Regulation (EU) 2016/679 (GDPR) | EMIs process large volumes of financial and identity data. | The institution needs lawful processing, retention rules, access controls, vendor due diligence, and breach governance aligned with privacy obligations. |
A Lithuanian EMI applicant must show more than a registered company and capital. The regulator expects a real operating institution with coherent governance, identifiable controllers, credible funding, and a control environment proportionate to the risk profile. In practice, the application is tested across three layers: hard law, supervisory expectation, and market practice.
The company is usually structured as a Lithuanian legal entity, with governance and decision-making that are not purely nominal. Substance is not just office rent. The regulator looks at where strategic decisions are made, who controls risk, where key functions sit, how outsourcing is supervised, and whether the institution can operate without being a shell around vendors.
Ownership transparency is another decisive area. The Bank of Lithuania will not treat UBO analysis as a formality. Complex chains, nominee-style opacity, unexplained wealth, or weak source-of-funds evidence can undermine the file even if the business model itself is sound.
A frequent mistake is to present staffing numbers as if one universal headcount rule existed for all EMIs. In practice, the regulator assesses whether the human and governance setup is credible for the specific operating model, risk profile, and outsourcing footprint.
| Area | Regulatory Expectation | Evidence Pack |
|---|---|---|
| Legal entity and corporate setup | The applicant should use an appropriate Lithuanian corporate form and maintain a governance structure suitable for a regulated financial institution. | Incorporation documents, articles, share capital evidence, shareholder register, governance chart, and internal allocation of responsibilities. |
| Initial capital | A full EMI must meet the €350,000 initial capital threshold and document lawful funding sources. | Bank confirmations, capital contribution records, source-of-funds documents, shareholder financial background, and audit trail of incoming funds. |
| Substance in Lithuania | The institution should demonstrate meaningful local presence and decision-making capacity proportionate to its model. | Office arrangements, employment or service structure, management availability, operational map, and evidence that control functions are not purely decorative. |
| Management fit and proper | Senior managers and key function holders must have relevant competence, good repute, and sufficient time commitment. | CVs, criminal record extracts where required, references, role descriptions, conflict disclosures, and track record in payments, risk, AML, or regulated operations. |
| Qualifying holdings and UBO transparency | Ownership must be transparent and compatible with prudent supervision. | Ownership chart up to ultimate beneficial owners, corporate documents across jurisdictions, beneficial ownership declarations, and explanation of control rights. |
| AML/CTF framework | The applicant must show a risk-based AML system calibrated to products, channels, geographies, and customer types. | Business-wide risk assessment, AML policy, onboarding rules, sanctions and PEP controls, monitoring scenarios, escalation workflow, and MLRO arrangements. |
| Risk, compliance, audit and internal controls | Control functions must exist in substance and be proportionate to scale, including independence where needed. | Three-lines-of-defence mapping, compliance monitoring plan, risk register, internal audit approach, reporting lines, and board oversight materials. |
| ICT and outsourcing governance | The EMI must understand its systems, data flows, dependencies, and vendor concentration risk. | System architecture, outsourcing policy, vendor register, SLAs, security controls, incident response plan, BCP/DRP, and DORA-aligned governance. |
An EMI application in Lithuania is not a single form; it is a structured evidence file. The strongest applications treat each document as proof of one licensing proposition: the business model is lawful, the people are suitable, the money is clean, the controls work, and the institution can operate safely on day one. The weakest applications submit generic templates that do not match the actual product flow.
The regulator usually pays particular attention to internal consistency. If the financial model assumes instant onboarding across multiple EEA markets, but the AML policy, staffing model, and outsourcing contracts are built for a local pilot only, the file will attract comments. The same applies where the safeguarding model described in the business plan does not match treasury operations or customer terms.
| Document | Purpose | Owner |
|---|---|---|
| Program of operations | Defines the services, target customers, channels, geography, transaction flows, and operational model. This is the document that anchors service classification. | Founders with legal and compliance input |
| Business plan and financial projections | Shows commercial viability, funding runway, revenue logic, cost base, and prudential sustainability over a multi-year horizon. | Finance lead and founders |
| Corporate and incorporation documents | Proves legal existence, constitutional framework, shareholding, and authority structure of the applicant. | Corporate legal team |
| Ownership and UBO package | Allows the regulator to assess qualifying holdings, control chain transparency, and prudential suitability of owners. | Shareholders and legal team |
| Source-of-funds and source-of-wealth evidence | Demonstrates that capital and funding are lawful, traceable, and consistent with the shareholder profile. | Shareholders with compliance support |
| Governance framework | Explains board and senior management roles, committees, reporting lines, and allocation of responsibilities. | Management and legal |
| Fit-and-proper files for managers | Supports competence, reputation, and time commitment assessment for directors and key function holders. | HR, management, legal |
| AML/CTF policy suite and business-wide risk assessment | Shows how the institution identifies and mitigates ML/TF risk across products, customers, countries, delivery channels, and transaction patterns. | MLRO and compliance |
| Safeguarding policy and funds flow map | Explains when client funds arise, how they are segregated or otherwise protected, how reconciliation works, and how insolvency remoteness is preserved. | Finance, operations, compliance |
| ICT architecture, security and outsourcing package | Demonstrates system design, access controls, vendor governance, resilience, incident response, and DORA readiness. | CTO/CISO, operations, legal |
The practical path to a Lithuanian EMI license starts with business model qualification and ends only after operational go-live. The statutory review period matters, but it is only one segment of the total project. Most delays arise before formal submission or during comment rounds triggered by weak documentation, unclear ownership, or mismatched operating assumptions.
Classify the product correctly: EMI, PI, or another regime. Map whether the institution will issue e-money, hold customer balances, rely on agents or distributors, outsource core functions, or target multiple EEA states from launch. This stage should also test whether MiCA, GDPR, card scheme, or merchant acquiring issues sit adjacent to the EMI perimeter.
Incorporate the Lithuanian vehicle, design governance, identify key function holders, and align ownership disclosures, capital plan, and local substance. A common hidden issue here is overreliance on external providers without a credible internal oversight layer.
Prepare the program of operations, financial projections, AML package, safeguarding model, ICT documentation, outsourcing inventory, and fit-and-proper materials. The file should read as one operating manual rather than disconnected annexes.
Where appropriate, discuss the model with the regulator before filing. A focused pre-application discussion can surface service-classification issues, substance concerns, or safeguarding questions early enough to avoid later rework.
The regulator checks whether the file is complete enough to start substantive review. A formally submitted file is not the same as a review-ready file; missing or inconsistent materials can delay the effective start of the process.
The Bank of Lithuania tests the business model, governance, AML controls, safeguarding, financial assumptions, ownership, and ICT resilience. Comment rounds are normal. The quality and speed of responses materially affect the real timeline.
After authorization, the institution still needs to activate safeguarding arrangements, reporting lines, payment infrastructure access, customer documentation, vendor controls, and live compliance monitoring before scaling.
The file should read like one operating model, not like disconnected policy appendices.
| Document | Purpose | Owner |
|---|---|---|
| Program of operations | Anchors the legal classification of services and target markets. | Founders and legal |
| AML business-wide risk assessment | Shows that the AML framework is tailored to real risks rather than copied from a template. | MLRO |
| Financial model | Tests viability, capital planning, and whether compliance costs are realistically budgeted. | Finance lead |
| ICT and outsourcing package | Allows the regulator to assess resilience, vendor dependency, and DORA alignment. | CTO/CISO and legal |
The cost of an EMI license in Lithuania is not just the regulator fee. Founders should separate regulatory capital from project spend and from first-year operating runway. The most common budgeting mistake is to assume that the €350,000 initial capital covers the real cost of authorization and launch. It does not.
A practical budgeting model is: Total budget = initial capital + setup costs + 12-month operating runway + contingency. Setup costs include legal, compliance drafting, incorporation, translations, governance build-out, and technology implementation. Operating runway includes staff, office, AML tooling, sanctions screening, audit, security, and vendor costs. Contingency matters because comment rounds often require document upgrades, additional hires, or revised vendor arrangements.
Official filing fees and local service costs should always be verified at the time of application. Tax and accounting treatment should also be confirmed with Lithuanian counsel and accountants because rates and interpretations can change.
| Cost Bucket | Low Estimate | High Estimate | What Drives Cost |
|---|---|---|---|
| Initial capital | €350,000 | €350,000+ | This is the regulatory entry threshold for a full EMI, not a substitute for operating budget. |
| Regulatory and filing costs | Subject to current tariff | Subject to current tariff | Official application fees must be checked against the current Bank of Lithuania tariff at filing. |
| Legal and licensing support | Project-specific | Project-specific | Cost depends on whether the scope includes structuring, drafting, regulator responses, and post-approval implementation. |
| Compliance framework build | Project-specific | Project-specific | Includes AML/CTF documents, risk framework, safeguarding policy, governance pack, and internal controls. |
| ICT, AML and security tooling | Project-specific | Project-specific | Can include KYC/KYB vendors, sanctions screening, transaction monitoring, case management, logging, and security controls. |
| Office, staffing and local substance | Project-specific | Project-specific | Depends on whether functions are internalized or outsourced and how much substance is expected for the model. |
| Audit, accounting and reporting | Project-specific | Project-specific | Annual audit, bookkeeping, prudential reporting support, and policy maintenance are recurring costs. |
| Contingency reserve | 10% of project budget | 20%+ of project budget | Useful for extra comment rounds, vendor changes, additional hires, or remediation work before go-live. |
Safeguarding is the mechanism that protects customer funds received in exchange for e-money or for payment transactions. It is not the same as capital adequacy. Capital protects the institution’s solvency buffer; safeguarding protects client money from misuse and, in principle, from being mixed with the institution’s own assets.
In practice, safeguarding requires more than opening a separate account. A credible safeguarding model explains when funds become relevant for safeguarding, how they are segregated, how often reconciliation is performed, who reviews breaks, and how insolvency remoteness is preserved. The regulator will also want comfort that ledger design, treasury operations, customer terms, and accounting treatment all support the same safeguarding logic.
A useful operational nuance is that many safeguarding failures are reconciliation failures, not bank account failures. If the EMI cannot reconcile customer ledger balances, pending transactions, fees, chargebacks, and partner-held funds accurately, the safeguarding model is weak even if segregated accounts exist.
| Workflow Step | Control | Owner |
|---|---|---|
| Receipt of customer funds | Classify whether the incoming amount creates safeguarded client funds and map it to the correct ledger bucket. | Operations and finance |
| Segregation or protection | Move or maintain relevant funds within the safeguarding structure in line with the approved model. | Treasury and finance |
| Ledger reconciliation | Match customer balances, transaction states, fees, reversals, and external account balances. | Finance with operations oversight |
| Exception handling | Investigate breaks, document root cause, remediate shortfalls, and escalate material issues. | Finance, compliance, senior management |
| Management reporting | Provide periodic safeguarding MI, break analysis, and control attestations to management and board. | Finance and compliance |
For a 2026 EMI applicant, ICT governance is part of the licensing case, not a post-license clean-up task. DORA, applicable from 17 January 2025, has raised the standard for ICT risk management, incident handling, resilience testing, and third-party oversight across financial entities. A Lithuanian EMI that relies on cloud infrastructure, KYC vendors, core banking software, card processors, or white-label payment engines must show that it understands and controls those dependencies.
The regulator will look beyond architecture diagrams. It will want to see who owns systems, how access is controlled, how incidents are classified and escalated, how critical providers are monitored, and whether the EMI can continue operating if a major vendor fails. The more outsourced the model, the more important internal governance becomes. Outsourcing does not outsource accountability.
A strong 2026 application links DORA and outsourcing in one narrative: systems, vendors, data, and controls must map to the same operating model described in the program of operations and financial plan.
| Area | Control | Owner |
|---|---|---|
| ICT governance | Maintain board-approved ICT risk governance, asset visibility, role allocation, and reporting lines for critical systems. | Board, CEO, CTO/CISO |
| Incident management | Define incident detection, severity classification, escalation, response, recovery, and recordkeeping procedures. | CTO/CISO with compliance involvement |
| Business continuity and disaster recovery | Document recovery objectives, fallback procedures, testing cadence, and communication plans for operational disruption. | Operations and ICT |
| Access and security controls | Implement least-privilege access, logging, change management, vulnerability management, and segregation of duties. | ICT security |
| Third-party ICT risk | Keep a vendor register, classify critical providers, assess concentration risk, and ensure contractual audit, exit, and security rights. | Procurement, legal, CTO/CISO |
| Outsourcing governance | Map outsourced critical or important functions, retain internal oversight, and define contingency plans for provider failure. | Management, compliance, legal |
| Testing and assurance | Run resilience testing proportionate to the model, including backup restoration, access reviews, and incident simulations. | ICT, risk, internal audit |
A Lithuanian EMI can generally expand across the EEA through passporting after the required notification process. Passporting is not a second license, but it is also not automatic market access. The institution must define which services will be provided cross-border, through which channels, and whether local consumer, marketing, tax, or AML nuances affect the rollout.
Lithuania is also discussed in connection with CENTROlink and broader SEPA access. This matters because payment connectivity can materially improve the operating model of an EMI. However, founders should avoid a common misconception: access to payment infrastructure does not turn an EMI into a bank and does not eliminate the need for safeguarding banks, partners, or scheme relationships where the business model requires them.
A sound expansion strategy sequences markets by compliance complexity, not just revenue potential. Launching in fewer EEA states with stronger controls is often better than a broad passporting plan that the organization cannot supervise.
| Topic | Details | Risk Note |
|---|---|---|
| EEA passporting | A Lithuanian EMI may notify the regulator and passport relevant services into other EEA states, subject to the applicable process and scope of authorization. | Passporting does not remove the need to assess local conduct, consumer, AML, and tax issues in target markets. |
| Cross-border operating model | The institution should define whether it will serve clients cross-border directly, through agents, distributors, or local branches. | An expansion plan that is too broad for the control framework often triggers regulator concern. |
| CENTROlink relevance | CENTROlink can be strategically relevant for SEPA payment connectivity and operational efficiency in eligible setups. | It does not solve every banking dependency and should not be treated as a substitute for all correspondent, safeguarding, or card scheme relationships. |
| SEPA and ISO 20022 | An EMI may structure payment operations around SEPA rails such as SCT and SCT Inst, with ISO 20022 messaging relevance in the broader payments stack. | Technical access still requires operational readiness, testing, sanctions controls, reconciliation, and customer support capability. |
| IBAN-led products | Lithuanian EMIs often use IBAN-based payment products to support account-like user experience and payment execution. | Customer communications must clearly distinguish e-money accounts from bank deposits. |
Most Lithuanian EMI applications do not fail because the founders chose the wrong jurisdiction. They fail because the file does not prove operational credibility. The regulator expects a controlled financial institution, not a pitch deck with annexes. The most common issues are weak AML design, unclear ownership, unrealistic projections, over-outsourcing, and a safeguarding model that exists only at policy level.
A useful way to think about rejection risk is to test whether every core statement in the application can be evidenced. If the company says it will onboard high-volume merchants across the EEA, it must show the AML scenarios, staffing, fraud controls, vendor capacity, safeguarding mechanics, and capital planning that make that statement believable.
Legal risk: The filing describes stored customer value but frames the institution as a PI or uses vague product language.
Mitigation: Map the funds flow and legal claim structure early; align product, terms, and license type before drafting.
Legal risk: AML documents are generic and do not reflect actual products, geographies, customer types, or delivery channels.
Mitigation: Build a real risk taxonomy and link it to onboarding, monitoring, sanctions, and escalation controls.
Legal risk: The regulator cannot get comfortable with UBO transparency or the origin of capital.
Mitigation: Prepare a clean ownership chain, documentary trail, and narrative explanation before filing.
Legal risk: The institution proposes ambitious activity with minimal internal oversight and excessive reliance on consultants or vendors.
Mitigation: Strengthen management, define accountable function owners, and evidence real oversight capacity.
Legal risk: The file mentions segregated accounts but does not explain timing, reconciliation, shortfall handling, or insolvency protection logic.
Mitigation: Document end-to-end safeguarding operations and test them against actual ledger and treasury flows.
Legal risk: Critical functions are outsourced without sufficient contractual rights, monitoring, or exit planning.
Mitigation: Create a vendor register, classify criticality, and strengthen contractual and operational oversight.
Legal risk: Revenue assumptions, onboarding volumes, or margin logic are not supported by staffing, technology, or compliance capacity.
Mitigation: Use conservative assumptions, show downside scenarios, and budget for compliance and resilience costs.
Legal risk: The applicant cannot explain incident response, resilience testing, or third-party ICT governance.
Mitigation: Integrate DORA controls into the application package rather than treating them as post-license remediation.
The two routes are fundamentally different. A fresh application gives the cleanest compliance narrative because governance, ownership, systems, and product perimeter are designed together from the start. Buying an existing licensed company may shorten market entry in some cases, but it introduces acquisition diligence risk, change-of-control scrutiny, legacy compliance issues, and possible remediation costs that are often underestimated.
In regulated payments, a ready-made vehicle is not automatically a shortcut. The real question is whether the target license, systems, safeguarding setup, outsourcing model, and historical compliance record fit the buyer’s intended business. If not, the buyer may inherit a license but still need a quasi-reauthorization-level remediation project.
| Option | Advantages | Limitations | Best For |
|---|---|---|---|
| Fresh EMI application | Clean ownership narrative, tailored governance, product-specific documentation, and no inherited compliance baggage. | Longer time to market and heavier upfront build effort. | Founders building a long-term platform with a defined product architecture and willingness to invest in first-principles compliance. |
| Acquire an existing licensed EMI | May offer a faster route to market if the target is clean, operationally aligned, and acquisition approvals are manageable. | Requires deep legal, regulatory, AML, ICT, safeguarding, accounting, and change-of-control diligence; legacy issues can erase any time advantage. | Buyers with strong M&A discipline, integration capacity, and a target whose existing perimeter closely matches the intended business. |
| Interim partner model before own license | Allows product validation while the company prepares for a later own-license strategy. | Lower control over economics, compliance perimeter, customer experience, and strategic dependencies. | Teams that need market testing first and are not yet ready for full regulated build-out. |
These answers summarize the questions founders, compliance teams, and investors ask most often about a Lithuania EMI license in 2026.
An EMI license in Lithuania authorizes a company to issue electronic money and provide payment services under the supervision of the Bank of Lithuania. It is the appropriate regime where customers hold stored monetary value with the institution, not just one-off payment execution.
For a full or unrestricted EMI, the headline initial capital threshold is typically €350,000. Applicants should distinguish this from ongoing own funds requirements and from the separate safeguarding of client funds.
A realistic end-to-end project usually takes 6-12 months. The statutory review clock is only part of the process; preparation, completeness review, comment rounds, and post-approval operational setup often take longer than founders initially expect.
Yes, non-resident ownership is generally possible, but the ownership chain, UBO disclosures, and source-of-funds evidence must be transparent and acceptable to the regulator. Opaque structures materially increase licensing risk.
A credible local presence is usually expected for a regulated EMI, but substance is assessed functionally rather than by office lease alone. The regulator will focus on where decision-making, oversight, and key control functions actually sit.
The core difference is e-money issuance. A PI can provide payment services but does not issue electronic money. If your product stores customer value as a claim on the institution, the model often points to an EMI.
Yes, a Lithuanian EMI can generally passport authorized services across the EEA after the required notification process. Passporting does not remove the need to assess local conduct, AML, consumer, and tax issues in each target market.
Safeguarding is the protection of client funds received in exchange for e-money or for payment transactions. It usually involves segregation or another legally permitted protection method, plus reconciliation, governance, and controls designed to keep client money separate from the EMI's own assets.
No. Safeguarding protects customer funds. Initial capital is the entry threshold for authorization. Ongoing own funds are prudential resources the EMI must maintain over time. These are separate concepts with different legal purposes.
The €350,000 figure is the initial authorization floor for a full EMI. After licensing, the institution must also maintain ongoing own funds under the applicable prudential methodology, which can include a calculation linked to average outstanding electronic money.
A Lithuanian EMI may be relevant for issuing an e-money token (EMT) under MiCA, but EMI authorization alone is not sufficient for every stablecoin or crypto model. MiCA adds its own issuer obligations, disclosures, redemption, and reserve requirements.
No. CENTROlink can be strategically useful for payment connectivity, but it does not convert an EMI into a bank and does not eliminate every dependency on safeguarding banks, partners, or payment schemes.
The most common reasons are weak AML risk assessment, unclear business model classification, poor source-of-funds evidence, unrealistic financial projections, superficial safeguarding design, and excessive outsourcing without robust oversight.
In practice, EMIs should plan for annual audit and ongoing accounting and regulatory reporting obligations. The exact reporting and assurance perimeter should be confirmed against current Lithuanian law and supervisory requirements.
It may be possible to acquire an existing licensed entity, but this requires careful legal, regulatory, AML, ICT, safeguarding, and accounting due diligence. A ready-made EMI is not automatically faster if the target needs major remediation or change-of-control approval.
Lithuania remains relevant for founders who need an EU-regulated payments base, understand the compliance burden, and value the local payments ecosystem. It is less suitable for applicants seeking a light-touch or low-substance route, because supervisory expectations have become more operationally demanding.
A useful first step is to test whether your model truly requires an EMI, whether the ownership and funding story is regulator-ready, and whether your safeguarding, AML, and ICT architecture can survive comment rounds. That usually saves more time than rushing into drafting.
