MiCAR Romania Guide for Web3, DeFi and CASPs

The Markets in Crypto-Assets Regulation - commonly referred to as MiCA or MiCAR - has fundamentally changed the regulatory environment for Web3 businesses operating in the European Union. It is no longer sufficient for a project to describe itself as "DeFi" or "non-custodial" and assume that it falls outside financial regulation. In practice, many products marketed as decentralized still involve an identifiable company that controls the user interface, establishes commercial terms, routes transactions, collects fees, manages administrative keys or provides services to customers. These elements may bring the project within the scope of MiCAR.

For founders, the consequences of an incorrect regulatory assessment appear quickly: banking and fiat-ramp partners may refuse onboarding; exchanges may delay or reject a token listing; investors may request formal legal opinions; commercial partners may require proof of regulatory status; product flows may need expensive redesigns; marketing campaigns may create enforcement or liability risks.

This guide provides a practical framework for Web3 and DeFi founders seeking to operate in Romania and across the EU. At Buju, Stanciu & Asociații ("BSA"), our blockchain and crypto practice approaches MiCAR compliance as an integrated product, legal and go-to-market exercise - not as an isolated legal project. The objective is to preserve product functionality and speed while creating a model that can withstand scrutiny from investors, banks, exchanges, commercial partners and regulators.

30 Dec 2024

the CASP regime and broader MiCAR framework became applicable

token classes with different regimes: utility/other, ART, EMT

30/60/90

days - a realistic phased compliance plan (below)

2–3h

product-flow review that surfaces the issues before investors do

MiCAR in Romania: five key points for Web3 founders

"Non-custodial" is determined by the actual product architecture
Not by the wording used in the Terms of Use.
A company may be treated as an intermediary even with smart contracts
Executing transactions through smart contracts does not, by itself, remove intermediary status.
Custody, exchange, execution, transfer or order-routing may trigger CASP authorization
When provided professionally to customers in the EU.
Token classification can completely change the applicable regime
Utility token, ART or EMT - the distinction determines the entire regulatory path.
Compliance should begin during product design
Not immediately before launch, fundraising or exchange listing.

Does MiCAR apply to DeFi projects?

MiCAR primarily regulates two areas: the issuance, public offering and admission to trading of crypto-assets; and the professional provision of crypto-asset services by intermediaries. For DeFi projects, the critical question is therefore not simply whether a smart contract is used. The more important question is:

"Is there an identifiable person or company that provides, controls, manages or commercially operates the service?"

- The central question of every DeFi regulatory assessment

A protocol may use decentralized technology while still having centralized operational elements: a company-controlled interface, upgradeable contracts, administrative permissions, transaction-routing systems, fee-setting powers, customer support, recovery mechanisms or marketing activities. The regulatory assessment must be based on how the service works in practice. Expand each screening question below:

Who controls the user interface and commercial access?

Regulatory exposure may increase when the project operator: controls the main website or application; establishes the Terms of Use; selects available tokens or liquidity routes; charges or modifies transaction fees; operates whitelists or geographic restrictions; controls access to particular functions; can pause, upgrade or modify the protocol; provides customer support as part of a commercial service.

Operating a user interface does not automatically make a company a CASP. However, the greater the operator's control over how users access and use the protocol, the more difficult it may be to argue that the service is fully decentralized.

Who controls or can move customer assets?

A project enters a higher-risk area when it or another operator can directly or indirectly control customer funds. Examples include: custody of private keys or seed phrases; managed MPC wallets; administrator-controlled smart-contract wallets; recovery or account-restoration mechanisms; the ability to freeze, sweep or redirect assets; transaction approval mechanisms controlled by the operator.

These features may bring the project closer to custody and administration of crypto-assets on behalf of clients - a regulated crypto-asset service under MiCAR.

Who executes or routes the transaction?

The distinction between providing software and providing a regulated service can depend on the actual transaction flow. Risk may increase when: the customer interacts primarily with the project rather than directly with a decentralized protocol; the operator selects or changes the execution venue; transactions are routed or executed on behalf of users; the project aggregates liquidity as a professional service; the operator acts as principal, agent or commercial counterparty.

Depending on the structure, these activities may resemble exchange, execution or reception and transmission of orders.

Are additional services offered on top of the protocol?

Additional services may create regulatory exposure even when the underlying protocol is decentralized: staking-as-a-service; managed yield products; automated vault management; copy trading; managed portfolio strategies; institutional custody; transaction execution; token-placement services.

The assessment should focus on who provides the service, who controls the relevant assets or decisions and whether the activity is performed professionally for customers.

Business models that frequently enter CASP territory

Custody and administration (hosted wallets, institutional custody, wallet-recovery services, managed MPC infrastructure, operator-controlled contract wallets); exchange and swap services where the operator acts as counterparty, sets the price or executes for customers; operation of an order book, matching system or AMM-based trading service; transfer services initiated or executed on behalf of customers; and broker-like execution or order-transmission models.

Interactive: is your model defensibly non-custodial?

Tick each statement that is true for your project as it actually works - not as the Terms of Use describe it. The score shows how defensible your non-custodial claim really is:

The defensible non-custodial model checklist

The project does not hold private keys, seed phrases or recovery keys
The project cannot unilaterally move, freeze, recover or redirect user funds
Users independently initiate and sign their own transactions
The operator does not execute transactions under a customer mandate
The interface accurately describes itself as software, not an asset-management or execution service
Protocol and smart-contract risks are disclosed clearly
Governance rights and upgrade permissions are transparent
Administrative actions are recorded and subject to defined controls
The fee model does not unintentionally make the project a transaction counterparty
The legal documentation matches the real technical architecture

A disclaimer will not fix the architecture

A statement that a service is "non-custodial" will not correct a product flow that gives the operator effective control over customer assets. Every unticked item above is a question a bank, an exchange or a regulator will eventually ask. Get your product flow reviewed.

When does a Web3 company become a CASP?

A company is likely to require a detailed CASP assessment when it provides at least one regulated crypto-asset service professionally to customers in the European Union. MiCAR's rules for asset-referenced tokens and e-money tokens became applicable on 30 June 2024. The broader framework, including the CASP regime, became applicable on 30 December 2024.

Practical indicators of CASP status

A business may qualify as a CASP where it: provides one or more crypto-asset services on a professional basis; serves EU consumers or businesses under commercial terms; safeguards or administers customer crypto-assets; exchanges crypto-assets for funds or other crypto-assets; operates a crypto-asset trading platform; executes customer orders; receives and transmits orders; places crypto-assets; provides transfer services; advises on crypto-assets; or manages crypto-asset portfolios.

The assessment depends on the real service being delivered. Product labels, disclaimers and corporate descriptions are relevant, but they are not decisive when the technical and commercial reality indicates otherwise.

Typical CASP authorization workstreams

Expand each workstream for what it covers:

1. Regulatory scoping and gap assessment

The first stage identifies: the services provided; the tokens involved; the target customers; the relevant jurisdictions; custody and transaction flows; outsourcing arrangements; licensing gaps; operational dependencies.

2. Corporate structure and governance

The business defines: legal entities and their responsibilities; management roles; reporting lines; internal control functions; decision-making processes; conflicts-management arrangements; responsibility for outsourced functions.

3. Programme of operations

The authorization package generally needs to explain: the business model; the services offered; target markets; projected activity; customer journey; revenue model; technology architecture; material risks and controls.

4. AML, KYC and sanctions controls

MiCAR is not itself the EU's primary anti-money-laundering regime - but AML, KYC and sanctions controls remain critical. Banks, payment institutions, exchanges and investors will conduct detailed due diligence on: customer identification; beneficial ownership; source of funds; transaction monitoring; wallet screening; sanctions exposure; suspicious-activity escalation.

5. IT, security and operational resilience (incl. DORA)

The project should document and test: cybersecurity controls; access management; key-management procedures; incident-response processes; data backups; disaster recovery; business continuity; vendor dependencies; change-management procedures. The relationship with the Digital Operational Resilience Act (DORA) should also be assessed where relevant.

6. Customer disclosures, complaints and marketing review

Customer-facing documentation should accurately explain: the services provided; fees and charges; execution arrangements; custody risks; technological risks; conflicts of interest; complaint-submission procedures. Marketing materials must be consistent with the product's legal status and, where applicable, with the crypto-asset white paper.

7. Application and regulatory interaction

The application process may involve: preparation and submission of the authorization file; responses to regulatory questions; document revisions; operational demonstrations; remediation of identified gaps.

Quick test: CASP territory or not?

Four common Web3 business models. Pick the assessment you think is right:

Model 1: A wallet app where users hold their own keys, sign their own transactions, and the company only ships software updates and publishes documentation.

Likely outside CASP scope - this is the defensible non-custodial pattern: no key custody, no execution mandate, users initiate and sign independently. The claim holds only as long as the architecture matches: add recovery keys or an execution feature and the analysis changes.

Model 2: A "non-custodial" wallet with a managed recovery service - the operator holds recovery keys and can restore (or effectively move) user funds.

Likely CASP territory. The ability to restore or redirect user assets brings the model close to custody and administration of crypto-assets on behalf of clients - a regulated service. The "non-custodial" label in the Terms of Use does not override the recovery architecture.

Model 3: A swap interface where the operator aggregates liquidity, selects the execution route, charges a spread and effectively acts as the commercial counterparty.

Likely CASP territory. Routing, execution-venue selection, pricing power and counterparty positioning resemble exchange and execution services - even if the settlement happens through smart contracts. The transaction flow, not the technology, drives the assessment.

Model 4: A platform offering "staking-as-a-service" and managed yield vaults, marketed to EU retail users, with the operator controlling the strategy and the assets.

Likely CASP territory. Services layered on top of a protocol - managed yield, vault management, portfolio strategies - create exposure even where the underlying protocol is decentralized. Who provides the service, who controls the assets, and whether it is done professionally for customers: all three point the wrong way here.

These are screening calls, not legal conclusions

Each real project needs an assessment of its actual technical and commercial structure - the same model can land differently depending on who controls what. Book a product-flow review.

MiCAR crypto-asset white papers

MiCAR may require a crypto-asset white paper when a token is offered to the public or admission to trading is sought. The precise obligations depend on: the token classification; the type of offering; the number and type of investors; the total value of the offer; whether an exemption applies; whether the token is already admitted to trading. Certain exemptions may be available, including proportionality mechanisms for some offers below specified thresholds - each exemption should be assessed carefully before it is relied upon.

Why prepare a white-paper-lite?

Even when a full MiCAR white paper is not legally required, a shorter disclosure document provides significant commercial value: investor due diligence, exchange-listing discussions, banking and payment partnerships, market-maker negotiations, vendor onboarding, marketing consistency and internal product governance. A strong disclosure document explains the product honestly and makes the risks understandable - it is not just promotional material.

MiCAR marketing rules for crypto projects

Marketing is one of the areas in which Web3 projects create regulatory exposure before the product has even launched. MiCAR generally requires relevant marketing communications to be fair, clear and not misleading. Where a crypto-asset white paper is required, marketing must also be consistent with that document.

High-risk crypto marketing claims

Presenting APY or yield as guaranteed
Or suggesting that returns are risk-free - the fastest way to convert a marketing page into a liability.
Promising future exchange listings
Or implying that token appreciation is certain.
Describing unaudited smart contracts as completely safe
Or omitting bridge, oracle, liquidity or counterparty risks.
Using influencers without appropriate disclosures
Influencer briefs and community announcements are marketing communications too.
Making claims that conflict with the white paper
Or creating artificial urgency or scarcity.
Presenting a utility token primarily as an investment opportunity
The marketing itself can push the token toward a different classification.

What legal review should cover

Websites, landing pages, investor decks, token-sale pages, social-media campaigns, influencer briefs and community announcements - the full surface, not just the homepage.

Token classification under MiCAR: utility, ART, EMT

Token classification is one of the most important steps in any MiCAR analysis. It can affect issuer requirements, authorization, white-paper obligations, reserve and redemption arrangements, marketing, governance, banking relationships, exchange listings and regulatory supervision.

A first-pass classification map

Calling a token a "utility token" does not automatically determine its legal classification. The analysis considers: the rights attached to the token; how it is marketed; whether it provides access to a product or service; whether its value is stabilized; whether holders have redemption rights; whether it resembles a financial instrument; whether it references another asset or currency.

Structuring a Web3 product to reduce regulatory exposure

The objective should not be regulatory avoidance. It should be a defensible structure in which each entity's role is clear and unnecessary regulated functions are eliminated.

Separate software development from customer services

Where commercially justified, the group may separate: IP ownership, software development, interface operation, token issuance, regulated customer services, and marketing. A formal separation is only effective when the entities also operate separately in practice.

Avoid custody unless it is essential

Custody significantly increases regulatory, security and operational requirements. Where it is not essential, design so users retain exclusive control. Where it is essential, treat it as a regulated function with appropriate controls from the beginning.

Match legal documents to the product

Terms and disclosures should explain precisely: what the operator provides and does not provide; who controls customer assets; who initiates transactions; which third-party protocols are used; which risks remain with the user; whether administrative permissions exist. Documentation should reflect the product - not attempt an artificial legal description of it.

Separate marketing claims from uncontrolled outcomes

Never promise outcomes the project cannot control: token appreciation, fixed APY, guaranteed liquidity, exchange listings, uninterrupted protocol operation, complete smart-contract security.

Essential MiCAR documents for Web3 and DeFi projects

A credible compliance package combines public-facing documentation, internal policies and commercial contracts:

White paper or white-paper-lite

Project description, technology architecture, tokenomics, supply and allocation, vesting, governance, upgrade policies, material risks, offering restrictions, regulatory disclosures.

Customer-facing terms and policies

Terms of Use; protocol or interface disclosures; Privacy Notice; Cookie Policy; risk disclosures; Acceptable Use Policy; sanctions provisions; complaints policy; fee disclosures.

Internal compliance policies

Conflicts of interest; outsourcing and vendor management; incident response; business continuity and disaster recovery; cybersecurity and access control; market-abuse controls; AML/KYC procedures; sanctions screening; complaints handling.

Web3 and technology contracts

Infrastructure and node-provider agreements; indexing and analytics; custody technology; SaaS, SDK and API terms; software licensing; open-source policies; audit, exchange and market-maker agreements; NDAs.

A practical 30-, 60- and 90-day MiCAR compliance plan

Compliance should be organized as a sequence of product and operational decisions, not as a last-minute documentation exercise:

First 30 days - regulatory mapping

Activities: map the complete customer journey and all on-chain/off-chain steps; determine who controls each function; identify custody, routing and execution elements; prepare an initial token-classification analysis; identify relevant jurisdictions; review marketing claims; conduct a licensing gap assessment; identify high-risk vendors. Deliverables: regulatory-scoping memorandum, token-classification memorandum, product-flow map, regulatory-risk register, priority remediation list.

Days 31–60 - documentation and product alignment

Activities: revise product flows where necessary; prepare or update Terms of Use and customer risk disclosures; review privacy and cookie documentation; draft the white paper or white-paper-lite; establish complaints procedures; review marketing and investor materials; prepare key internal policies; review material technology contracts. Deliverables: customer-documentation package, disclosure package, white-paper draft, marketing guidelines, policy framework, revised product requirements.

Days 61–90 - implementation and readiness

Activities: implement governance controls; assign policy owners; test incident-response procedures; document outsourcing; establish compliance reporting; train team members; conduct an internal readiness review; prepare the CASP authorization roadmap where required; organize an investor and partner due-diligence data room. Deliverables: implemented governance structure, operational compliance calendar, training records, vendor register, incident-response playbook, authorization-readiness report, due-diligence data room.

Reverse solicitation is not a reliable EU growth strategy

Some non-EU crypto businesses consider relying on reverse solicitation when serving European customers. However, reverse solicitation is interpreted restrictively. It should not be treated as a general market-access strategy where the company: targets EU users; operates EU-focused campaigns; uses local influencers; purchases EU advertising; publishes EU-specific landing pages; actively develops an EU customer base.

For projects with serious European ambitions, a compliant licensing and market-entry strategy is generally more sustainable than attempting to rely on reverse solicitation.

How Buju, Stanciu & Asociații supports Web3 and DeFi projects

Through its dedicated blockchain and cryptocurrency practice, BSA advises Web3 businesses by combining regulatory analysis with product architecture, commercial contracts and operational implementation:

MiCAR scoping and token classification

Whether the project provides regulated crypto-asset services; whether CASP authorization may be required; whether the token qualifies as utility, ART or EMT; financial-instrument classification risks; how MiCAR applies to the customer journey.

Product-first compliance

We map the actual product flows and identify where regulated intermediation may arise: custody, execution, order routing, transfer services, staking, managed yield, protocol fees, administrative permissions. The objective: identify product changes before they become expensive.

Web3 documentation packages

Terms of Use, customer disclosures, privacy documentation, marketing review, crypto-asset white papers and white-paper-lite documents, SaaS and technology contracts, SDK/API terms, software licences, open-source policies, NDAs, exchange and market-maker agreements.

CASP authorization preparation

Programme of operations, governance arrangements, internal policies, outsourcing documentation, complaints procedures, risk controls, IT and security documentation, authorization roadmap.

Crypto investigations and incident response

Legal and technical support following wallet compromises, fraud, unauthorized transfers, protocol exploits, internal misconduct or cross-border asset movements - in collaboration with specialists in crypto tracing and blockchain investigations.

Why product-first matters

Large multidisciplinary firms suit complex institutional mandates. BSA focuses on founders and product teams that need direct involvement from experienced lawyers, practical product-flow analysis, rapid risk identification and a clear path from MVP to regulatory readiness.

"The relevant question for a Web3 founder is not which firm produces the longest legal memorandum. It is which adviser can translate MiCAR into product decisions, operational controls and documents that the team can actually implement."

- Marius Stanciu, Partner, Buju, Stanciu & Asociații

Key takeaways

Non-custodial status depends on product design, not labels
If the operator controls assets, execution or customer transactions, CASP requirements may apply.
MiCAR compliance should begin during product development
Early analysis prevents costly redesigns, delayed partnerships and failed listings.
Token classification is critical
The distinction between utility tokens, ARTs and EMTs can determine the entire regulatory path.
A white-paper-lite is commercially valuable even when not mandatory
For investors, exchanges, banks and market makers alike.
The best compliance strategy preserves speed
By identifying and isolating regulated functions early - and keeping marketing claims aligned with the product's real risks and legal status.

Frequently asked questions about MiCAR in Romania

Does MiCAR apply to fully decentralized DeFi projects in Romania?

Services provided in a genuinely decentralized manner without an identifiable intermediary may fall outside certain MiCAR obligations. However, the existence of a company that controls, operates, upgrades, commercializes or provides access to the service can materially change the analysis. Each project must be assessed based on its actual technical and commercial structure.

Is operating a DeFi interface enough to become a CASP?

Not necessarily. The assessment depends on the operator's overall role: control over access, transaction routing, fees, token selection, administrative keys, customer relationships and the execution of transactions.

What are the main steps in a CASP authorization project?

Regulatory scoping; corporate and governance structuring; preparation of internal policies; IT and operational-resilience documentation; AML, KYC and sanctions arrangements; customer documents and complaints procedures; marketing review; application preparation and regulatory interaction.

Does every token require a MiCAR white paper?

No. The requirement depends on the token classification, the type of offering, admission to trading and the availability of an exemption. The analysis should be completed before the token is publicly marketed or offered.

What is the difference between an ART and an EMT?

An EMT generally references a single official currency. An ART generally references another value, asset, right or combination of assets. Both categories are subject to specific regulatory requirements.

Can a project avoid MiCAR by calling its token a utility token?

No. Classification depends on the token's characteristics, economic function, attached rights and marketing - not only on the name selected by the issuer.

Can a non-EU crypto company rely on reverse solicitation?

Only in limited circumstances. Reverse solicitation is interpreted restrictively and should not be treated as a general strategy for actively targeting or developing an EU customer base.

How can BSA help a project launch quickly while remaining compliant?

BSA can provide a product-focused MiCAR playbook covering regulatory scoping, token classification, customer-flow analysis, Terms of Use, risk disclosures, marketing review, white-paper preparation, commercial and technology contracts, and CASP authorization readiness. Get in touch.

Preparing an MVP, token launch or EU expansion?

Start with a focused regulatory-scoping workshop: map whether the project touches custody, executes or routes transactions, facilitates exchange, provides staking or managed yield - and which marketing claims create risk. A two- to three-hour product-flow review can identify issues that would otherwise surface during fundraising, bank onboarding, exchange listing or regulatory review.

Disclaimer: This article is provided for general informational purposes only and does not constitute legal advice. The application of MiCAR depends on the specific facts, documents, technical architecture and commercial flows of each project. A dedicated legal assessment is required before making regulatory, product or market-entry decisions.