Does a token fall under MiCA or financial instrument rules?

Date: 8 November 2026. Author: Redazione LX20 Law Firm. Publisher: LX20 Law Firm.

The technology used to issue a token does not determine its legal regime by itself. Before applying MiCA, examine the rights represented and whether the token qualifies as a financial instrument. MiCA excludes crypto-assets qualifying as financial instruments: calling a project “utility” or using a blockchain does not resolve that assessment.

Analysis requires documents and actual characteristics rather than just a commercial presentation. This guide outlines questions to organise for preliminary assessment. It does not classify a specific token, propose structures to avoid obligations or constitute personalised advice or a promise of authorisation.

Start with rights rather than the name

Collect issuance terms and describe what the holder can obtain. Is there a right to payments? Are governance or economic rights involved? Does the token provide access to a service or represent a different relationship? Answers should reflect documents and project operation. A marketing label does not automatically override substance.

Compare presentations with actual terms. If a page promises participation in results while the document denies any right, record the discrepancy. Do not remove it to make the file fit a predetermined conclusion. Classification should consider relevant project elements, including information presented to recipients.

Understand MiCA's exclusion

Article 2(4)(a) of Regulation (EU) 2023/1114 of 31 May 2023 excludes crypto-assets qualifying as financial instruments. Source: MiCA, Article 2. Being outside MiCA for this reason does not mean being outside financial regulation. Identify the framework relevant to the object and activities performed.

The ESMA guidelines on qualification conditions and criteria provide an analytical reference. Categories require assessment of actual characteristics; examples do not replace case-by-case examination. Do not treat one similarity to an example as definitive confirmation of the entire project.

Prepare a functional description of the token

Identify the issuer, recipients and distribution method. Describe transferability, restrictions and redemption or extinguishment conditions. Clarify who can change rights and which events alter their content. If answers depend on a future decision, make uncertainty explicit rather than presenting the project as already settled.

Distinguish the token from surrounding services. Issuance, custody and organising trading raise different questions. Classifying the object does not automatically settle the authorisation needed by each activity's operator. A useful description retains this distinction and connects each function to its operator rather than assigning everything generically to the “platform”.

Assess what the code implements too

Compare documents with technical architecture. If terms promise transfer restrictions, check implementation and who may change them. Code may demonstrate relevant capabilities or limits but does not replace legal analysis of rights by itself. Documented dialogue is needed between those understanding legal structure and technical implementation.

Also distinguish a configurable feature from an operational capability. A function planned for a future version does not establish present operation. Record what exists and what is merely planned. The assessment should identify its configuration so relevant technical changes can be re-examined.

Understand the DLT Pilot Regime's role

Regulation (EU) 2022/858 of 30 May 2022 establishes a pilot regime for market infrastructures based on distributed ledger technology. Source: Regulation 2022/858. It does not provide general authorisation to issue or trade any token. Its relevance requires examining the infrastructure, activities and applicable conditions.

Before discussing eligibility or thresholds, therefore clarify what the token represents and the intended transaction. This article does not list numerical limits or possible reforms: their assessment requires the text applicable on the project's date. A proposed legislative amendment should not be treated as already operational without verification.

A fictional example

A company presents a token as platform access, but promotional material also describes payments linked to an activity's results. The assessment team collects terms, presentations and technical specifications. Before selecting a category, it asks about the payments' nature and the holder's rights. It does not treat “utility” as decisive.

Discussion reveals a difference between the technical version and that described in the terms. The assessment is tied to an identified configuration while unresolved questions remain open. This example does not classify the token and describes no client or engagement of the Firm. It demonstrates why consistent sources are needed before a conclusion.

Keep the assessment connected to the project

Retain examined documents and relevant assumptions. If rights, transferability or offered activities change, check whether the conclusion remains pertinent. A preliminary document should not become a permanent guarantee used for different configurations. External communications should also respect assessment limitations, avoiding absolute statements unsupported by the file.

When handing the project to another team, preserve those boundaries alongside the documents. A concise conclusion is useful only if readers understand the factual version it addresses. Where an assumption has not been confirmed, identify the information still needed rather than presenting the classification as final. This helps keep subsequent decisions aligned with the assessment actually performed.

For the Firm's relevant practice overview, see Fintech, Digital Assets & Web3.