DeFi regulation in Luxembourg

Classify the asset before selecting a CSSF procedure

For Luxembourg, begin with the asset and the activity. The CSSF MiCA overview directs firms to assess whether a crypto-asset is within MiCA, including whether it qualifies as a financial instrument. It separates CASPs, ART issuers, EMT issuers and other crypto-assets.

Tokenization changes how a right is recorded or transferred; it does not settle the right's legal classification. For a proposed token, describe redemption rights, payment claims, transfer restrictions and the relationship with any underlying asset. Record the legal rationale before designing a filing around the label "RWA" or "utility token."

MiCA Article 2 excludes financial instruments from its scope. Such a finding calls for assessment under the relevant financial-services framework. It does not mean that the asset or associated service is unregulated.

Separate the provider and issuer workstreams

The CSSF CASP page describes the provider authorization framework and the notification route for certain services of eligible existing institutions. A token issuance workstream addresses a different object from the provider's service permission.

Build a record for each entity and activity. If the same project issues an asset and provides a client service, identify which team owns each analysis, submission and ongoing control. Reconcile the names and roles in customer contracts, token documentation and infrastructure agreements.

Title II white paper notification through eDesk

Since August 3, 2026, the CSSF white paper instructions route notifications for crypto-assets other than ARTs and EMTs through eDesk when Luxembourg is the home Member State. They specify a ZIP containing the iXBRL white paper and a PDF explanation annex.

MiCA Article 8 distinguishes notification from prior approval for these Title II white papers. Keep proof of submission separate from any provider permission. Before uploading, check that the classification explanation, disclosure, issuer or offeror details and deployed token describe the same arrangement.

The following worksheet is DeFiSec's document-control method. It helps identify inconsistent files; it is not an official CSSF submission form.

Translate the classified rights into technical controls

After the legal analysis, test how the agreed rights work in software. For a token with transfer restrictions, inspect the rule source, who can change it and how an eligible holder recovers access. For redemption, trace the request, authorization, asset movement and completion record.

Pharos Production's engineering discussion of compliance controls for tokenized assets can support this implementation review. Select the controls relevant to the EU legal structure and retain the corresponding test results. A restriction embedded in a contract is evidence of behavior, not a regulatory certification.

Preserve disagreement between the documents and the deployed behavior as a finding. If a contract permits an administrator to alter transfer rights more broadly than the disclosure suggests, resolve that mismatch before relying on the document package.

Maintain the evidence when the product changes

For a MiCA-authorized CASP within DORA's scope, connect ICT risk and supplier records to the relevant services. Track who can change the contracts, interfaces and customer operations. A new token version or supplier can affect several evidence records at once.

Use the MiCA security obligations guide for the wider security context. Revisit the classification and filing analysis when the asset's rights or service model changes, and check the current CSSF instructions at the time of submission.