In 2026, Bulgaria is no longer a jurisdiction that can be analysed through an old AML-only “VASP registration” lens. The operative question is whether the business model falls within Regulation (EU) 2023/1114 (MiCA) as a crypto-asset service provider (CASP), whether adjacent regimes such as e-money, payment services or securities law are triggered, and which Bulgarian authority is competent for the relevant perimeter.
In 2026, Bulgaria is no longer a jurisdiction that can be analysed through an old AML-only “VASP registration” lens. The operative question is whether the business model falls within Regulation (EU) 2023/1114 (MiCA) as a crypto-asset service provider (CASP), whether adjacent regimes such as e-money, payment services or securities law are triggered, and which Bulgarian authority is competent for the relevant perimeter.
This page is an informational legal-practical guide, not legal or tax advice. Regulatory treatment depends on the exact service model, token design, client geography, custody structure and fiat/payment flows.
Key regulatory facts, timeline markers, and practical next steps for a fast initial read.
Asset-referenced token perimeter began earlier than the general CASP regime.
From this point, older “unregulated Bulgaria crypto” summaries became materially outdated for in-scope activities.
Founders needed to align governance, disclosures, outsourcing, AML, travel rule and ICT controls with the post-MiCA EU framework.
The practical answer to “crypto license in Bulgaria” is that the market term still exists, but the legal analysis must distinguish between CASP authorisation under MiCA, legacy AML-driven crypto treatment, and separate regimes for electronic money, payment services, financial instruments, tax and reporting. Bulgaria can be attractive for founder-led structures because incorporation is relatively straightforward and the tax baseline is competitive, but that does not reduce the burden of governance, own funds, AML/CFT, travel rule implementation, complaints handling, outsourcing control and cybersecurity. The strongest Bulgaria setups in 2026 are those that start with service mapping, token classification and banking architecture before filing anything.
The key change is that bulgaria crypto regulation can no longer be described accurately through pre-MiCA language such as “light VASP registration” or “mostly unregulated crypto business”. For in-scope crypto-asset services, the controlling EU framework is now MiCA, supported by DORA for digital operational resilience and Regulation (EU) 2023/1113 for travel rule obligations on crypto transfers. Older Bulgaria guides often mix three different concepts: AML registration logic, company incorporation, and full authorisation to provide regulated crypto services. In 2026, that mix-up is one of the fastest ways to misprice timeline, budget and launch risk.
A second change is that token classification matters far more than founders expect. A utility-style token, an electronic money token (EMT), an asset-referenced token (ART) and a token that is actually a financial instrument do not sit in the same legal box. The regulator, disclosure package, prudential burden and go-to-market path may differ sharply. A third change is operational: travel rule data exchange, wallet screening, outsourcing governance and incident management are no longer optional “best practices” if the model falls inside the regulated perimeter.
The practical effect is simple: the phrase crypto license in Bulgaria remains commercially useful, but the legal answer now turns on whether the applicant is a CASP, an EMT-related operator, a payment/e-money business, an investment firm case, or a business outside licensing but still inside tax, AML, accounting and consumer-law obligations.
| Topic | Legacy Approach | Current Approach |
|---|---|---|
| Market language | “Crypto licence” used loosely for almost any crypto business setup. | Use “crypto licence in Bulgaria” as a search term, but analyse the legal route as CASP authorisation, AML obligations and adjacent financial licensing where relevant. |
| Regulatory focus | AML registration logic dominated the conversation. | MiCA drives authorisation, conduct and prudential analysis for in-scope crypto-asset services; AML remains necessary but not sufficient. |
| Operational controls | Policies on paper were often treated as enough. | Regulators and counterparties expect evidence of onboarding controls, transaction monitoring, travel rule tooling, outsourcing oversight and ICT resilience. |
| Banking assumptions | Company incorporation was marketed as a near-automatic path to bank access. | Banks and EMIs review business model risk, wallet flows, counterparties, source of funds, sanctions exposure and governance in depth. |
The applicable framework is a layered EU-and-national stack, not a single Bulgarian “crypto act”. For most founders, the right way to read the market is: MiCA for crypto-asset issuance and crypto-asset services, DORA for ICT risk and resilience, TFR for travel rule data obligations, Bulgarian AML/CFT laws for customer due diligence and suspicious activity reporting, tax legislation for corporate and indirect tax treatment, and company/accounting law for substance, books and reporting. If fiat functionality, e-money issuance, payment execution or investment-type rights are present, additional regimes can displace or supplement the pure crypto analysis.
| Law / Regime | Scope | Applies To | Why It Matters |
|---|---|---|---|
| Regulation (EU) 2023/1114 (MiCA) | Crypto-asset issuance and crypto-asset services, including CASP authorisation, conduct, governance and prudential rules. | Exchange, custody, trading platform operation, transfer services, order handling, advice, portfolio management and certain token issuers. | This is the central answer to the Bulgaria CASP question in 2026. |
| Regulation (EU) 2022/2554 (DORA) | ICT risk management, incident reporting, testing, third-party ICT risk and resilience governance. | In-scope financial entities and their technology operating model. | A credible crypto application now needs more than basic cybersecurity claims; it needs a defensible control framework. |
| Regulation (EU) 2023/1113 (recast TFR) | Transfer-of-funds style information requirements extended to crypto-asset transfers. | Crypto transfer flows involving obliged entities and related data exchange processes. | Travel rule implementation is an operational requirement, not a marketing add-on. |
| Bulgarian Law on Measures Against Money Laundering | CDD, EDD, beneficial owner checks, monitoring, recordkeeping and reporting duties. | Obliged entities carrying on relevant activities in Bulgaria. | AML/CFT remains a live national enforcement layer even where MiCA governs authorisation. |
| Law on Measures Against the Financing of Terrorism | Counter-terrorist financing controls and restrictive measures compliance. | Relevant obliged entities and persons subject to Bulgarian compliance duties. | Sanctions and terrorism-financing exposure are core onboarding and monitoring issues for crypto operators. |
| Payment Services / e-money framework | Payment execution, payment accounts, e-money issuance and related services. | Crypto businesses with fiat rails, stored fiat value, cards, IBANs or payment functionality. | Some models marketed as “crypto exchange” are partly payment or e-money businesses in substance. |
| Tax, VAT, Accounting and GDPR framework | Corporate tax, dividend tax, VAT analysis, bookkeeping, financial reporting and data protection. | Every operating entity, whether regulated or not. | Many founder problems arise after launch from tax misclassification, weak records or poor data governance rather than from licensing alone. |
There is no single Bulgarian authority that handles every crypto issue. In practice, founders need an authority map. The FSC is the regulator most often associated with capital markets and the likely focal point for many MiCA-related service questions. The BNB becomes central where the model touches e-money, payment services or other banking-adjacent functions. SANS / FID matters for AML reporting and financial intelligence obligations. The NRA matters for tax registration, tax filings and the tax treatment of business activity. Treating all of this as “the crypto regulator” is a category error that causes delays and wrong filings.
Primary supervisory touchpoint for many capital-markets and MiCA-related questions, including the CASP perimeter where applicable under Bulgarian implementation and competence allocation.
You provide in-scope crypto-asset services, prepare for CASP authorisation or assess conduct/governance obligations.
Relevant for e-money, payment services and banking-adjacent questions; also important where the token or service model overlaps with monetary or payment regulation.
You issue or handle fiat value, payment accounts, IBANs, cards, stored fiat balances or EMT-related structures.
AML/CFT intelligence and suspicious transaction reporting ecosystem.
You are an obliged entity with AML monitoring, escalation and reporting duties.
Tax registration, corporate tax, VAT, payroll and reporting touchpoints.
You incorporate, invoice, earn crypto-related revenue or need tax treatment analysis for exchange, custody, consulting, mining or proprietary trading.
The right question is not whether “crypto” is regulated in the abstract. The right question is which exact activity you perform. Under MiCA, the main regulated service buckets include custody and administration of crypto-assets on behalf of clients, operation of a trading platform, exchange of crypto-assets for funds, exchange of crypto-assets for other crypto-assets, execution of orders, placing, reception and transmission of orders, advice, portfolio management and transfer services for crypto-assets on behalf of clients. A founder running an OTC desk, custody wallet, broker interface or exchange engine may therefore be inside the CASP perimeter even if the website describes the product only as “software”.
At the same time, not every blockchain business needs a crypto authorisation. Pure software development, certain analytics tools, non-custodial infrastructure, some treasury-only proprietary activity and some mining operations may fall outside CASP authorisation, while still triggering company, tax, AML, consumer, data protection or energy-law issues. The hard cases are mixed models: a platform that offers hosted wallets, fiat settlement, card top-ups, yield features, copy trading or token issuance can move beyond a simple crypto-service analysis very quickly.
A practical nuance often missed in Bulgaria guides is that custody is not only about holding private keys directly. If the operator can unilaterally influence transfer execution, recovery, whitelisting, policy controls or client asset movement through wallet architecture, regulators and counterparties may still treat the model as functionally custodial. That point matters for MPC setups, omnibus wallets and outsourced custody chains.
Custody and administration of crypto-assets on behalf of clients
Usually requires authorisation
Exchange of crypto-assets for fiat funds
Usually requires authorisation
Exchange of crypto-assets for other crypto-assets
Usually requires authorisation
Operation of a crypto-asset trading platform
Usually requires authorisation
Execution of orders on behalf of clients
Usually requires authorisation
Reception and transmission of orders
Usually requires authorisation
Crypto-asset advice or portfolio management
Usually requires authorisation
Pure proprietary trading with no client service element
Needs case-by-case analysis
Pure non-custodial software development
Needs case-by-case analysis
Mining as such
Needs case-by-case analysis
| Business Model | MiCA Relevance | Adjacent Regimes | Practical Answer |
|---|---|---|---|
| Crypto exchange with client onboarding and fiat on/off-ramp | High; typically within CASP exchange scope. | Payment/e-money analysis may also be required depending on fiat handling and settlement design. | Assume authorisation analysis is required from day one. |
| Hosted wallet / custody provider | High; custody and administration is a core CASP service. | AML, cybersecurity, outsourcing and client asset controls become central. | Usually regulated even if marketed as a wallet technology product. |
| OTC broker routing client orders to third-party venues | Potentially high; order reception/transmission, execution or exchange may apply. | AML, best execution-style governance, conflicts and outsourcing review. | Needs detailed service mapping; do not assume it is “just consulting”. |
| Token issuer raising funds through an EMT-like structure | Very high, but not a standard CASP-only case. | BNB / e-money perimeter and issuer-specific rules may be triggered. | This is more complex than a standard crypto licence project. |
| Mining company selling mined assets for own account | Usually low for CASP authorisation. | Tax, accounting, energy contracts, AML touchpoints and corporate reporting still matter. | Not automatically licensed, but not legally frictionless. |
| Non-custodial analytics SaaS for exchanges | Often outside CASP if no client asset service is provided. | GDPR, B2B contracting, cybersecurity and export/sanctions screening may still matter. | Usually outside authorisation, subject to precise functionality review. |
Token classification is the first legal gate because the same launch can move between very different regulatory outcomes depending on the token’s stabilisation mechanism, redemption logic and attached rights. Under MiCA, founders must distinguish at least between electronic money tokens (EMTs), asset-referenced tokens (ARTs) and other crypto-assets. A separate question is whether the token is actually a financial instrument under securities law rather than a MiCA crypto-asset. If the token gives profit participation, governance rights tied to a common enterprise, debt-like claims or other investment-style rights, a financial instruments analysis may override the “crypto token” label used in marketing.
| Category | Core Feature | Typical Trigger |
|---|---|---|
| Electronic money token (EMT) | Purports to maintain stable value by referencing the value of one official currency. | Requires issuer analysis beyond a standard CASP discussion and may engage the e-money perimeter. |
| Asset-referenced token (ART) | Purports to maintain stable value by referencing another value, right or combination, including multiple currencies or assets. | Subject to a distinct MiCA issuer regime with heightened scrutiny. |
| Other crypto-asset | Crypto-asset that is neither EMT nor ART and is not excluded from MiCA. | May still require white paper and service-provider analysis depending on issuance and services. |
| Financial instrument | Tokenised form does not prevent classification as a security or other instrument under financial law. | May fall outside MiCA and into investment services / prospectus / securities regulation. |
| Excluded / out-of-scope item | Some digital assets or closed-loop structures may fall outside MiCA based on legal design. | Requires careful legal qualification; labels alone are not determinative. |
Yes: Assess as potential EMT and review e-money implications.
No: Move to the next classification question.
Yes: Assess as potential ART.
No: Move to the next classification question.
Yes: Run a financial instruments analysis; MiCA may not be the primary regime.
No: Assess as another crypto-asset or out-of-scope structure.
The transition issue in Bulgaria is that many legacy market descriptions were built around AML-driven treatment of virtual currency activity, while 2026 compliance reality is MiCA-centric for in-scope services. Existing operators should not assume that historical operation, company registration or prior AML positioning automatically converts into a MiCA-ready status. The correct question is whether the current business model, client journey, custody design, token offering and cross-border footprint fit the post-MiCA authorisation and conduct framework.
Where a business has been active since the pre-MiCA period, the review should cover service scope, governance, own funds planning, outsourcing chains, complaints handling, marketing disclosures, client asset controls, travel rule implementation and ICT resilience. A practical risk often missed is “scope drift”: a company that began as software or consulting may have added hosted wallets, OTC execution, referral routing or fiat settlement support over time, thereby moving into a regulated perimeter without updating its legal basis.
Because national transition mechanics and supervisory communications can evolve, existing operators should verify the current Bulgarian treatment directly against official guidance and case-specific legal advice rather than relying on generic summaries from older websites.
Useful only as historical context; insufficient for 2026 launch planning.
Stable-value token projects required earlier regime-specific analysis.
In-scope service providers needed to align with the EU authorisation and conduct framework.
Legacy operators needed remediation across governance, AML, TFR, disclosures and ICT controls.
A legacy AML-facing position or historical registration logic should not be treated as proof of full MiCA readiness. Existing crypto companies in Bulgaria should review: service classification, token classification, governance and fit-and-proper evidence, prudential planning, outsourcing register, complaints process, client disclosures, sanctions controls, travel rule tooling, incident response and record retention.
The realistic process starts with legal qualification, not with filing forms. For a crypto license in Bulgaria, the usual sequence is: determine whether the model is a CASP case or an adjacent regime case, incorporate the legal entity, build the governance and compliance package, prepare the application set, manage regulator questions, run banking/EMI onboarding in parallel and only then launch client-facing activity. Promises such as “2 weeks” or “100% remote guaranteed” are not decision-grade planning assumptions. A practical timeline depends on scope complexity, token classification, number of shareholders, whether outsourcing is used for AML or technology, whether the model is custodial, and how quickly banking counterparties complete due diligence. Founders often underestimate the document burden around outsourcing, complaints, conflicts, ICT asset inventories and financial projections. Another common delay driver is mismatch between the website copy and the legal filing: if the public product description implies execution, custody or portfolio management but the application describes a narrower model, remediation requests are likely.
Map services, token type, target clients, custody architecture, fiat flows, referral chains and cross-border strategy. Decide whether the model is a CASP case, an EMT/payment case, a securities case or partly outside licensing.
Incorporate the Bulgarian entity, usually an OOD, obtain address and corporate records, identify UBOs and align shareholder/director documents. Remember that incorporation is not authorisation.
Prepare business plan, compliance manual, AML risk assessment, onboarding rules, sanctions controls, outsourcing framework, incident response logic, complaints handling and financial model.
Submit the application set, answer follow-up questions, remediate gaps, clarify operational design and evidence readiness of key persons and control functions.
Run account opening, safeguarding and payment-rail discussions in parallel. Banking due diligence often outlasts licensing work.
Test onboarding, sanctions screening, wallet screening, travel rule messaging, incident escalation, customer support and recordkeeping before going live.
The file should read like one operating model, not like disconnected policy appendices.
| Document | Purpose | Owner |
|---|---|---|
| Corporate documents | Evidence legal existence, ownership, governance and constitutional structure. | Corporate / legal |
| UBO and management file | Support fit-and-proper, source of wealth/funds and integrity review. | Founders / legal / compliance |
| Business plan and financial forecast | Show service model, revenue logic, cost base, prudential planning and runway. | Founders / finance |
| AML/CFT framework | Set onboarding, monitoring, sanctions, escalation and reporting controls. | Compliance |
| Technology and security pack | Evidence wallet architecture, access control, logging, backups, vendor oversight and incident response. | CTO / security |
| Outsourcing and third-party agreements | Show who performs critical functions and how the company retains oversight. | Legal / operations |
| Complaints, conflicts and disclosure policies | Demonstrate conduct governance and customer-facing control design. | Compliance / legal |
The cost stack is broader than incorporation and legal drafting. A realistic founder model includes entity setup, application preparation, policy drafting, governance build-out, AML tooling, sanctions screening, wallet screening, travel rule connectivity, accounting, tax support, cybersecurity controls, vendor due diligence and ongoing legal updates. The useful formula is: total setup cost = incorporation + legal/compliance drafting + application work + local substance + AML tooling + banking/EMI onboarding + security implementation + annual operating compliance.
Another practical point is that the cheapest setup is rarely the cheapest launch. Underinvesting in onboarding controls, sanctions screening or incident management usually creates higher remediation cost later, especially when a bank, EMI, auditor or regulator asks for evidence that the control works in production rather than in policy text.
| Cost Bucket | Low Estimate | High Estimate | What Drives Cost |
|---|---|---|---|
| Company formation and corporate records | Low | Moderate | Usually not the main budget driver. |
| Legal scoping and application drafting | Moderate | High | Depends heavily on service complexity, token type and cross-border footprint. |
| AML / sanctions / wallet screening tooling | Moderate | High | Recurring vendor cost; often underestimated in early budgets. |
| Security and DORA-readiness controls | Moderate | High | Includes logging, access control, testing, vendor risk and incident response capability. |
| Banking / EMI onboarding and safeguarding setup | Moderate | High | Commercial friction and EDD effort can be material even where no formal fee is large. |
| Annual accounting, tax and compliance operations | Moderate | High | Recurring cost should be budgeted for 12 months, not just launch month. |
The usual misconception is to anchor on the 2 BGN minimum capital for a Bulgarian OOD and assume the regulatory project is therefore cheap. That figure relates to company formation, not to the prudential, operational and tooling burden of a regulated crypto business.
AML in Bulgaria is an operating system, not a PDF policy. A crypto business with relevant obligations must build customer due diligence, beneficial owner checks, sanctions and PEP screening, risk scoring, source-of-funds review, transaction monitoring, escalation, suspicious transaction reporting and record retention into the onboarding and transaction lifecycle. Under the post-MiCA environment, the AML layer sits alongside conduct and prudential rules; it does not replace them.
For practical implementation, founders should design onboarding around both person risk and wallet risk. That means not only collecting identity and corporate data, but also screening wallet exposure to sanctions, darknet, mixers, fraud typologies or high-risk services where the risk-based model requires it. A mature Bulgaria setup also links AML and product governance: if the platform offers instant swaps, OTC settlement, hosted wallets or high-velocity transfers, the monitoring logic must reflect those risk patterns.
The travel rule side is governed at EU level by Regulation (EU) 2023/1113. In operational terms, businesses need a process to collect, verify where required, transmit and reconcile originator and beneficiary data for in-scope crypto transfers. Industry implementations frequently use IVMS101 as a messaging standard. A recurring failure point is treating travel rule as a post-launch integration item. In reality, it affects vendor selection, wallet flow design, exception handling and customer support scripts from the start.
| Workflow Step | Control | Owner |
|---|---|---|
| Customer onboarding | Identity, KYB, UBO, sanctions and PEP screening; risk scoring. | Compliance / onboarding |
| Wallet association | Wallet screening, address attribution checks, source-of-funds review where risk requires. | Compliance / fraud / blockchain analytics |
| Transaction initiation | Travel rule data capture and sanctions controls before or during execution as applicable. | Operations / compliance |
| Ongoing monitoring | Behavioural monitoring, threshold alerts, unusual pattern review and escalation. | Compliance / MLRO function |
| Suspicion handling | Internal case review, decisioning, reporting and evidence retention. | AML responsible person / MLRO |
A properly authorised EU crypto business may in principle use passporting-style mechanisms available under the applicable framework to provide services across the Union, but this is not the same as automatic unrestricted operation everywhere from day one. The business still needs the correct home-state authorisation, the correct service scope, compliant disclosures, AML controls, travel rule capability and any required notification steps. Cross-border strategy should therefore be designed at application stage, not added later as a sales expansion idea.
A practical nuance is that passporting does not cure a wrong perimeter analysis. If the Bulgarian entity is actually carrying on payment services, e-money issuance or investment services in substance, a CASP-only strategy may be insufficient. Another nuance is consumer-facing localisation: marketing, complaints handling, language support and sanctions screening often need adaptation even where the legal right to provide services exists.
Reverse solicitation is a narrow concept and should not be used as a default market-entry strategy for an EU-facing crypto business. Regulators generally look at the real commercial setup, not only at website disclaimers.
The main risk in Bulgaria is not a single dramatic prohibition; it is cumulative failure across perimeter, AML, banking and operational controls. A company can be incorporated, technically live and commercially active while still being exposed because the service model was misclassified, the custody function was understated, travel rule was not implemented, or banking disclosures did not match actual flows. In 2026, enforcement risk also comes indirectly through counterparties: a bank, EMI, liquidity provider or institutional client may freeze onboarding or terminate service before a regulator takes formal action if the control environment looks weak.
Legal risk: Unlicensed regulated activity and misleading perimeter analysis.
Mitigation: Run service mapping against MiCA and adjacent regimes before launch.
Legal risk: Weak monitoring, poor reporting and inability to evidence control effectiveness.
Mitigation: Assign accountable AML responsibility, test workflows and maintain oversight of vendors.
Legal risk: Operational non-compliance for in-scope transfer flows and counterparty friction.
Mitigation: Select travel rule tooling and workflow design during build phase.
Legal risk: Commercial inability to operate, delayed launch and inconsistent disclosures to counterparties.
Mitigation: Prepare EDD pack early and run banking workstream in parallel.
Legal risk: Mis-selling, wrong filing path and disclosure failures.
Mitigation: Complete token classification before fundraising or public marketing.
The tax baseline is straightforward only at the top line: Bulgaria is widely known for a 10% corporate income tax rate and a 5% dividend tax baseline. The difficult part is classification of revenue streams, VAT treatment by service type, accounting recognition and documentation quality. A crypto exchange, custody provider, software developer, mining company and advisory business do not necessarily have the same VAT or bookkeeping profile even if all operate in the digital asset sector.
The most common overstatement in market guides is to say either that “crypto services are VAT exempt” or that “crypto services are subject to 20% VAT” as a universal rule. Both are too broad. The standard Bulgarian VAT rate is 20%, but whether a specific crypto-related service benefits from an exemption or falls within the taxable baseline depends on the exact legal character of the service. Exchange activity may need to be analysed differently from custody, software licensing, consulting, marketing or white-label technology. The CJEU’s reasoning in Hedqvist is relevant background for certain exchange analyses, but it does not solve every crypto VAT question automatically.
Mining and proprietary trading also need separate treatment. Mining is not automatically a licensing case, but it raises tax, accounting and cost-allocation questions, especially around electricity, hardware depreciation and inventory or revenue recognition logic. Proprietary trading on own account may sit outside client-service authorisation in some cases, yet still generate taxable income and require disciplined accounting records. For founders, the practical rule is simple: tax treatment should be mapped by revenue line, not by industry label.
| Topic | Why It Matters | Responsible Team |
|---|---|---|
| Corporate income tax | The headline 10% rate is attractive, but taxable base depends on correct accounting and expense support. | Finance / accounting / tax |
| Dividend tax | The baseline 5% rate matters for founder extraction planning and holding structure design. | Finance / tax / legal |
| VAT by service type | Exchange, custody, software, consulting and marketing may not share the same VAT outcome. | Tax / finance |
| Mining and proprietary trading accounting | Revenue recognition, inventory treatment, cost allocation and asset valuation can become contentious without a defined policy. | Accounting / tax |
| Payroll and contractor reporting | Founders often focus on token flows and miss routine Bulgarian employment and contractor tax obligations. | HR / payroll / accounting |
First 90 days before go-live
Sequence these after the core perimeter, governance, and launch-control decisions are stable.
Open the key issues founders, compliance teams and legal leads usually need to confirm before launch.
Yes as a market term, but legally the analysis is more precise. In 2026, the phrase “crypto license in Bulgaria” usually refers to whether the business needs CASP authorisation under MiCA or falls under another regime such as e-money, payment services or securities law. The correct label depends on the exact activity, token type, custody model and fiat/payment functionality.
Yes. Foreign founders can generally own a Bulgarian company, including an OOD, and non-resident ownership is common. But foreign ownership does not remove the need for governance, beneficial owner transparency, fit-and-proper evidence, AML accountability and a credible operating model. “Non-resident friendly” does not mean “substance-free”.
Company incorporation can be relatively fast, often within several business days to around 2 weeks for clean cases. The full regulatory readiness and authorisation timeline is much longer and depends on service scope, custody, token classification, outsourcing, quality of the application pack and banking/EMI onboarding. Founders should plan in ranges, not fixed promises.
They are different concepts. A Bulgarian OOD can be formed with a very low minimum company capital, commonly cited as 2 BGN. That figure is a company-law formation threshold, not the same as prudential own funds or regulatory capital expectations for a crypto business. Founders who confuse the two usually underbudget the project.
Mining is not automatically the same as providing regulated crypto-asset services. In many cases, mining as such does not trigger CASP authorisation. However, mining businesses still face tax, accounting, corporate, contractual and sometimes AML-related questions, especially when mined assets are sold, pooled, converted or used in broader commercial operations.
Potentially yes, subject to the applicable MiCA framework and required procedures. The key point is that the Bulgarian entity must first hold the correct home-state authorisation for the services actually provided. Passporting is not a substitute for proper perimeter analysis, and it does not automatically cover services that are really payment, e-money or investment services in substance.
Yes. Outsourcing can support execution, but not eliminate accountability. The business still needs a defensible AML/CFT framework, sanctions and PEP screening, monitoring, escalation, reporting capability and, where applicable, travel rule implementation. Regulators and counterparties usually expect the firm to understand and oversee the outsourced control environment.
Not as a universal rule. Bulgaria’s standard VAT rate is 20%, but the VAT outcome for a crypto-related service depends on what the service actually is. Exchange analysis may differ from custody, consulting, software licensing, marketing or white-label infrastructure. Any blanket statement that all crypto services are exempt or all are taxable is too simplistic.
The fastest way to de-risk a Bulgaria launch is to map the business model against MiCA, token classification, AML/travel rule obligations, banking architecture and tax treatment before incorporation or filing. That avoids the two most expensive mistakes: building the wrong entity stack and marketing a broader service than the legal basis supports.
