On 2 October 2026, the CSSF published its first FAQ on tokenisation. For Luxembourg fund managers, the useful development is the clarity it brings to the operating model: who maintains the register, how traditional and tokenised units fit together, and which obligations follow the control agent and its technology providers.
This article concerns the issuance and administration of tokenised fund units or shares. A fund investing in crypto-assets raises a separate set of questions. Putting a fund’s ownership record on distributed ledger technology (DLT) does not, by itself, describe what the portfolio holds.
Can Luxembourg funds issue native tokens?
Yes. In Q1, the CSSF confirms that Luxembourg undertakings for collective investment (UCIs) can issue units or shares natively on DLT, subject to compliance with the framework applicable to the fund. Those units may be registered or dematerialised. The technology does not decide their legal form.
For registered units, the UCI administrator performing the registrar function may maintain the register using DLT. For dematerialised units, the requirements of the Law of 6 April 2013 on dematerialised securities also apply. A UCI administrator planning a substantial change to its operating model must seek CSSF authorisation for that change under point 5 of Circular 22/811 (FAQ, Q1).
For a launch committee, the first deliverable should therefore be a description of the legal rights and operating arrangements. A successful demonstration of token issuance is only one part of that file. The FAQ is supervisory guidance on recurring questions, rather than a complete new regime or an approval of individual projects.
A control agent does not replace the registrar function
The distinction matters most for dematerialised units. Q2 confirms that appointing a control agent does not remove the need for a UCI administrator (UCIA) responsible for the registrar function. Registrar duties under points 19 and 20 of Circular 22/811 extend beyond the control agent’s statutory tasks.
The same entity may perform both functions if it holds the appropriate licences and authorisations. Otherwise, the allocation must leave an eligible entity responsible for the remaining registrar duties. A service agreement should make this understandable to someone who was not involved in designing the blockchain architecture.
A useful review question is: for each investor-facing event, who performs the activity, who records it, who checks the result, and who resolves an exception? Record the answers for subscriptions, transfers, redemptions and corrections. This is a practical way to test the division of responsibilities; it is not an additional CSSF-prescribed template.
Traditional and tokenised units need a consolidated view
Q3 allows multiple UCIAs to carry out the registrar function where a fund issues both traditional and tokenised units. The conditions are substantive: the split must remain manageable, investors must receive adequate disclosure of the model and its risks, and the offering documents must identify the UCIAs and their functions.
An entity, the IFM and/or one of the UCIAs, must maintain a consolidated view of the units issued so that other administration tasks can be performed, including NAV-per-share calculations, distributions and capital calls. Additional risks from the division of responsibilities must be managed. Applicable legal register requirements continue to apply, including, where relevant, the register of registered shares at the fund’s registered office (FAQ, Q3).
Consider a fund with one traditional share class and another issued on DLT. Both registers may look correct independently while a transfer, cancellation or cut-off difference creates an inconsistency in the consolidated position. The review should establish who reconciles the records, which discrepancies stop processing and how corrections reach the administrator using the consolidated data.
DORA follows the control agent’s activity
Q5 explains that the eligible entities concerned fall within DORA and must apply their DORA compliance framework to their control agent activity. Q6 permits technical support from third parties, including smart-contract development or administration. The CSSF considers it highly likely that the control agent activity is a critical or important function.
Where ICT third-party arrangements support that activity, Q6 directs applicants to Circular CSSF 25/882 and the relevant notification form and deadlines. An applicant reaching a different conclusion in its self-assessment is asked to present a robust rationale to the CSSF before formal notification.
These statements concern the control agent and its arrangements. They should not be read as automatically assigning every participant in a tokenisation project the same regulatory status. For the IFM, the practical task is to understand the dependencies across its service chain and confirm which entity owns each obligation. Our guide to outsourcing after DORA explains the broader distinction between ICT and other outsourcing arrangements.
Build the timetable around a complete file
The CSSF invites early dialogue supported by the full lifecycle: issuance, trading, settlement and distribution, the legal qualification and rights of the tokens, stakeholder activities, contracts, outsourcing and an initial assessment of licences and procedures.
For control agent activities, Q4 specifies notification at least two months before commencement. Crucially, the statutory period starts only when the CSSF confirms that the notification is complete. An initial submission date is therefore not a reliable launch-date calculation.
Additional outsourcing or ICT notifications may affect the timetable. Q4 refers to applicable notifications at least three months before the outsourcing begins, reduced to one month for a Luxembourg support PFS. Determine the applicable route and scope before treating these as project milestones. EEA applicants also face home-authority and supervisory-cooperation conditions described in Q4.
What belongs in the CRA and CMP?
The FAQ does not prescribe a tokenisation score or a standard monitoring schedule. The following is a proposed translation into the second line’s work for a firm whose activities are affected. Keep operational execution with the responsible teams and use the compliance monitoring plan to test the relevant arrangements.
| Risk to assess in the CRA | Possible CMP review | Evidence to retain |
|---|---|---|
| A gap between registrar and control agent duties | Trace selected lifecycle events across the agreed allocation of responsibilities. | Contracts, responsibility map, sample records and exception follow-up. |
| Inconsistent traditional and DLT records | Review reconciliations and the resolution of differences affecting the consolidated view. | Dated reconciliations, break logs, corrections and approvals. |
| Incomplete investor disclosure | Compare the actual operating model and providers with the offering documents. | Approved disclosures, provider inventory and change history. |
| An unassessed technology dependency or model change | Check the applicable assessment, notification and approval path before implementation. | Risk rationale, due diligence, CSSF correspondence and implementation decision. |
Choose the review scope and frequency according to the firm’s actual exposure. A manager with no tokenised funds may document its applicability assessment and watch for a business-model change. A manager preparing a launch needs a more detailed assessment before relying on the new arrangements. Our CRA-to-CMP guide explains how to connect that reasoning to executable tests.
Five questions for the next project committee
- Have we documented the legal form of the units and the rights attached to the tokens?
- Is every registrar and control agent task allocated to an appropriately authorised entity?
- Who owns the consolidated position, and can we show how differences are resolved?
- Do disclosures, contracts and technology dependencies describe the same operating model?
- Which CSSF procedures apply, and what evidence confirms that their conditions have been met?
These questions give management a concrete basis for a decision. They also provide a useful starting point for the first monitoring cycle after launch.
Where Klavius fits
Klavius helps connect regulatory developments to the compliance risk assessment, monitoring plan and follow-up actions. For a tokenisation project, the useful record is the link between the FAQ, the applicability decision, the risks reviewed, the controls scheduled and the outstanding actions. Klavius does not issue tokens or perform the registrar or control agent function.
If you are assessing the second-line implications of a project, book a working session around your current CRA and CMP.
Sources and scope
CSSF, FAQ – Tokenisation, version 1, 2 October 2026; full document, introduction and Q1–Q6. The FAQ expressly leaves other applicable obligations, including AML, intact. This article reflects that version as reviewed on 12 October 2026. The monitoring examples are Klavius’s practical analysis, not additional rules issued by the CSSF.