RWA tokens: MiCA or MiFID II?

Read the rights before choosing the regime

A token can represent a share, a debt claim, a pooled investment, a claim on an asset or access to a service. Calling it an RWA token does not determine which rules apply. Obtain the legal terms, issuing entity, redemption arrangements and the rights a holder can enforce if the technology or issuer fails.

MiCA Article 2(4)(a) excludes crypto-assets that qualify as financial instruments. The ESMA classification guidelines apply technology neutrality: tokenizing a financial instrument does not change its legal nature. Their examples support a case-specific analysis rather than issuing definitive classifications for every token with a similar name.

Separate the asset assessment from the service assessment. Issuance, custody, exchange, placement and operating a trading venue can involve different entities and permissions. A service-provider authorization should be checked for the exact entity and activities, not inferred from the brand's public claims.

Follow a classification sequence

1. Identify the enforceable rights. Record ownership, repayment, profit participation, voting, redemption and liquidation rights. Match the token terms to the underlying legal documents.
2. Assess financial-instrument categories. ESMA's guidelines address transferable securities, money-market instruments, units in collective investment undertakings, derivatives and other relevant categories. A negative answer for shares does not finish the analysis.
3. Examine the MiCA perimeter if appropriate. Assess the exclusions in Article 2 and the definitions in Article 3, including ARTs, EMTs and other crypto-assets. A reference to a real asset is insufficient to classify every product as an ART.
4. Map each service and entity. Document the permissions or other legal route that the proposed activity requires. Include the home jurisdiction and intended cross-border service.
5. Translate the result into operating controls. Specify what the legal analysis requires the system and its operators to do, then test those controls.

This sequence is a DeFiSec preparation method. The classification must consider the complete instrument and applicable law. A token standard such as ERC-20 or a transfer-restriction extension is a technical implementation choice, not the outcome of that legal analysis.

Assemble the evidence that changes the answer

The table identifies questions, not predetermined classifications. A token representing an asset through a special-purpose entity may confer rights against that entity rather than direct ownership of the physical asset. Record that distinction before describing the product to users.

Implement controls after the legal decision

Pharos Production's guide to RWA compliance controls discusses how eligibility, transfer restrictions and operating processes translate into software. Its EU discussion is relevant to this implementation step. Its US securities examples have a different jurisdictional basis and should not be imported into an EU requirements matrix.

For each required restriction, record where it operates: contract code, registry, custodian, administrator or user interface. A restriction enforced only by an interface may not control a direct contract call. Conversely, an on-chain restriction can prevent a transfer without proving that the holder register or legal documents are correct.

Test lifecycle changes as well as issuance: loss of eligibility, token migration, a compromised administrator, a correction to the ownership record and an exceptional redemption. Specify who approves the change and what users can verify afterwards. These scenarios are technical review suggestions and do not prescribe a particular token architecture.

Use the Luxembourg guide or Italy guide for the relevant national route. Keep the DAC8 reporting assessment separate: an instrument's treatment under one regime does not answer every reporting question.