MiFID II and tokenization: classification, services and limits

Tokenization allows financial instruments to be represented through a digital record. Shares, bonds and other products retain rights and obligations that determine how they can be issued and marketed. In the European Union, that legal nature is the starting point for understanding which rules apply to each token.

MiFID II forms part of the framework governing financial instruments and related services. MiCA, in turn, excludes crypto-assets that qualify as financial instruments. Understanding the relationship between these frameworks helps define the issuance and platform services before translating their requirements into technical development.

What determines a token’s legal classification

Tokenizing a right changes its technical representation, but does not remove its legal nature. Article 2 of Spain's Law 6/2023 includes financial instruments issued, recorded, transferred or stored using DLT. Shares, debt, investment vehicle interests and derivatives require assessment of specific rights.

Calling an asset a utility token does not determine classification. Nor does every expectation of price appreciation automatically make a token a transferable security. Document characteristics, transferability, rights and offering structure under the applicable framework.

How MiFID II and MiCA relate

Article 2 of MiCA excludes crypto-assets that qualify as financial instruments. A project cannot freely choose between MiCA and MiFID II for the same instrument. Exclusion from MiCA does not exempt it from other legislation.

MiFID II addresses investment services and activities and aspects of markets. Prospectus rules, company law and other obligations have their own scope. Saying that an issuance complies with MiFID II therefore does not describe all its requirements.

Separate instrument, services and distribution

• Instrument: which right the holder receives and against whom it is enforceable.
• Services: who places, advises, executes orders, safeguards or administers.
• Offering: intended recipients, countries and documentation.
• Trading: where positions may be transferred and under which permissions.

This separation assigns responsibilities and identifies activities that may need authorisation. The assessment changes when an application moves from displaying information to receiving orders, recommending products or controlling client assets.

Translating requirements into software

Transfer restrictions, identity checks and transaction records should follow the legal model. Choosing a library described as compliant is insufficient. Define what happens when investor eligibility changes, a check expires or recovery is requested.

Test both permitted and rejected operations. Retain evidence of configuration, version and permissions, together with error correction procedures. A code audit reviews its technical scope; it does not authorise a service or validate an offering.

Documenting the classification

Start with documents that establish the relationship between issuer and holder: issuance terms, constitutional documents where relevant, payment or voting rights, maturity, transfer rules, and commercial commitments. Code helps explain operations, but a contract description does not capture the product's entire legal substance.

Annex I of MiFID II distinguishes categories of instruments and services. A review should identify the particular category being assessed rather than treating “security” as a complete answer. If the asset is not a financial instrument, its position under MiCA, an exclusion, or another regime still needs examination.

A useful working method records which characteristic supports each conclusion and which changes would require reassessment. Adding economic rights, changing redemption arrangements, or permitting new transfer mechanisms can affect the analysis. That review should not be hidden inside a software update.

Example of a platform with different functions

Consider a project that displays information about an issuance, accepts subscription requests, and provides a space where holders express interest in selling. This is an example of scope analysis, not a definitive legal classification.

The information page, reception of requests, and interaction between buyers and sellers must be examined separately. Establish what each component actually does, who makes decisions, how transactions are executed, and which entity provides the service. Calling the product a technology platform does not answer those questions.

For developers, the outcome should become a specification: which actions the interface permits, which require an authorized entity's intervention, and which are outside scope. Specifying that the system forwards an instruction to an identified participant is more verifiable than claiming an application is MiFID compliant without explaining its operation.

Evidence the project should retain

Useful documentation connects requirements to behavior: the version of accepted terms, when a check occurred, which entity authorized an operation, and the recorded result. When a restriction rejects a transfer, the system should support investigation of the applicable rule without unnecessarily exposing personal data.

Define how complaints, corrections, and material changes are handled. Test evidence establishes what happened under a particular configuration; it cannot establish that every future configuration has the same legal treatment. Legal review, change management, and regression testing therefore need explicit points of coordination.

What the DLT pilot regime adds

The pilot regime provides a specific framework for certain trading and settlement infrastructures, with permissions and conditions. It does not turn any dApp into an authorised venue and should not be confused with issuing a token.

Before development, assemble an activity map, rights documentation and responsible parties. Check its framework against CNMV guidance and advice appropriate to the transaction. Technology can then implement defined, verifiable requirements.

To develop the design, see ERIR in Spain: roles and requirements for tokenized securities and how a tokenization project is implemented.