Vlad Kalashnikov is Head of Products at CFOUR Comply, an inline XBRL (iXBRL) conversion software. Through direct involvement in customer onboarding, he works closely with teams navigating these requirements, giving him firsthand insight into the operational realities firms face with tagging and the challenges corporate service providers encounter delivering these services at scale.
Since 23 December 2025, crypto-asset white papers under MiCA must be drawn up in XHTML and tagged in Inline XBRL (iXBRL) against the taxonomy published by the European Securities and Markets Authority (ESMA).
Using MiCA iXBRL software comes down to three practical tests. The tool should apply the current ESMA taxonomy, validate the file against the taxonomy’s automated checks before submission, and fit the way legal and compliance teams draft, review and update white papers.
This guide explains what the format rules require, sets out the criteria for comparing tools, and assess the options available in the market.
What MiCA requires for crypto-asset white papers
The Markets in Crypto-Assets Regulation (EU) 2023/1114 requires a white paper for three categories of crypto-assets. It also sets out who is responsible for drawing one up.
Who must prepare an iXBRL white paper
ESMA’s MiCA White Paper Reporting Manual names the responsible party for each type of crypto-asset.
- Other crypto-assets (OTHR). For crypto-assets other than asset-referenced tokens (ARTs) and e-money tokens (EMTs), the obligation falls to the offeror, the person seeking admission to trading, or the operator of the trading platform.
- ARTs. The obligation falls to authorised issuers and credit institutions.
- EMTs. The obligation falls to credit institutions and electronic money institutions.
Once a white paper is created or modified, it is sent to the competent authority of the home Member State or to the European Banking Authority. CFOUR’s guide to the scope of the Markets in Crypto-Assets regulation covers the wider obligations behind the white paper.
XHTML, Inline XBRL 1.1 and the single-file rule
Article 2 of Commission Implementing Regulation (EU) 2024/2984 sets the format. White papers must be drawn up in XHTML, with the fields listed in the regulation’s Annex marked up using the Inline XBRL 1.1 specification. The Inline XBRL document must be submitted as a single XHTML file, so a PDF alone does not satisfy the rule.
For a reader, the result still looks like an ordinary document. Behind the visible text, iXBRL adds machine-readable tags that identify specific pieces of information. CFOUR’s explanation of how Inline XBRL filing differs from standard XBRL covers the technical background.
The reporting manual adds constraints that software must respect.
- Only one target XBRL document is permitted per filing.
- Embedded resources must not contain executable code.
- Images must be in PNG, GIF, SVG or JPEG format.
- Images may carry branding, layout or photographs, but never information that forms part of the disclosure.
The ESMA MiCA taxonomy and its three templates
ESMA published the MiCA White Paper Taxonomy 2025 on 5 August 2025, and the format requirement entered into application on 23 December 2025.
In simple terms, the taxonomy is the standard set of tags and rules used to turn information in the white paper into structured, machine-readable data.
Entry points. The taxonomy has three entry points for reporting entities, one each for ART, EMT and OTHR white papers. These match the three templates in the Annex to Regulation (EU) 2024/2984. The entry point determines which part of the taxonomy applies to the type of crypto-asset being reported. A fourth entry point covers the full taxonomy and is reserved for software providers. ESMA’s documentation states that reporting entities must not reference it in their submissions.
Closed taxonomy and updates. ESMA’s taxonomy documentation describes the taxonomy as closed. This means preparers must use ESMA’s existing tags and cannot create their own additional tags, or “extensions” ESMA states that it will publish updates on its website if necessary, with each release identified by a date in its namespace. As of September 2026, ESMA’s taxonomy page lists the 2025 version, with its Excel showcase last updated in December 2025.
Labels. Element names do not always match the ITS (Implementing Technical Standard) field names word for word. The reporting manual notes that each reportable element carries a short label following the ITS numbering, which helps preparers find the right element.
Lists and fixed answers. Some fields need more than a simple text or number tag. Lists of people, such as members of the management body, are reported using typed dimensions. The manual places responsibility for structuring those entries on the preparer. Fields with a fixed set of permitted answers use enumerations.
Language versions. Where a white paper is published in more than one language, each language version is a separate iXBRL file. All versions must be tagged with the same elements.
LEI and DTI identifiers
Regulation (EU) 2024/2984 requires the issuer to be identified in the Inline XBRL document by its ISO 17442 Legal Entity Identifier (LEI) where one is available. Where a valid LEI is provided, information retrievable from the LEI record does not need to be repeated in the white paper. This covers details such as legal form and registered address. The MiCA taxonomy imports XBRL International’s LEI taxonomy so that the identifier can be checked automatically.
Delegated Regulation (EU) 2025/421 adds two further requirements. The LEI must be valid and duly renewed. Where an ISO 24165 Digital Token Identifier (DTI) is provided, it must be a valid identifier of type 3.
Sustainability indicators under Delegated Regulation (EU) 2025/422
Delegated Regulation (EU) 2025/422 was published in the Official Journal on 31 March 2025. It sets the content, methodology and presentation of sustainability indicators relating to adverse impacts on the climate and the environment. Persons drawing up white papers under Articles 6, 19 and 51 of MiCA must disclose these indicators. Supplementary indicators on energy use and greenhouse gas emissions apply to crypto-assets issued through consensus mechanisms with higher annual energy consumption.
The MiCA taxonomy already includes the data types these figures require, including energy, greenhouse gas emissions and mass. The reporting manual recommends kilowatt-hours and metric tonnes of CO2 equivalent as units. This means numeric sustainability data therefore needs the same careful handling ofunits and scale, just as the figures in a financial report.
Modifications require a new iXBRL version
A MiCA white paper is not filed on an annual cycle. It is drawn up when a crypto-asset is offered or admitted to trading, and each modification produces a new white paper that must meet the same format rules. Teams responsible for tokens that change often should expect to produce several iXBRL versions over the life of the asset.
What to look for in MiCA iXBRL software
The criteria below follow the specific rules in ESMA’s taxonomy documentation and reporting manual. CFOUR’s article on wider criteria for evaluating iXBRL tagging platforms covers general factors such as usability and support for several regulations.
Current taxonomy and the correct entry points
The software should apply the taxonomy version ESMA currently publishes and select the entry point that matches the token type. ESMA identifies each release by date, so a tool also needs a defined process for adopting a new version if one is published. Before choosing a provider, preparers should confirm both which taxonomy version the software currently supports and how quickly future ESMA releases will be implemented.
Validation against ESMA’s assertions
The MiCA taxonomy defines two main groups of automated checks, known as assertions.
- 257 existence assertions. These check that required ITS fields are reported.
- 223 value assertions. These check conditional fields in specific reporting scenarios.
Six further value assertions come from the LEI taxonomy. Each assertion carries a severity of either error or warning. The reporting manual states that a white paper must be valid against assertions set at error severity and should be valid against those set at warning severity.
ESMA recommends that software vendors build these checks into their tools. A tool that runs the complete assertion set and explains failures clearly makes it easier to identify and fix technical problems before submission.
Technical validation does not, however, determine whether the content of the white paper itself is legally compliant. The assertions test whether the file is correctly structured and tagged. They do not test whether the disclosure meets Article 1 of Regulation (EU) 2024/2984. Article 1 requires information that is fair, clear and not misleading, presented concisely and without omitting material information. That judgement remains with the legal and compliance team.
Handling narrative disclosures
Most of a white paper is text. ESMA adopted iXBRL following an independent study that recommended the format for its handling of qualitative information.
Unlike a financial filing, where much of the tagged information consists of numbers, a MiCA white paper requires software to handle substantial amounts of narrative content. The reporting manual sets specific rules for block tags.
- Text that belongs to a single tag but appears in different sections should be joined using Inline XBRL continuation constructs.
- Extracted text must remain legible, with words, numbers and table content in the same order as the human-readable document.
Software that correctly converts documents to XHTML and preserves text and tables, can reduce the manual correction these rules would otherwise require.
Review across legal, compliance and auditors
White papers pass through several reviewers before notification, and each modification repeats that cycle. Useful features include the following.
- Controlled user permissions.
- Reviewer or auditor access to the tagged file.
- The ability to carry tags from a previous version into an updated one.
Multi-language filings create an additional review requirement because every language version is a separate file but must use the same taxonomy elements.
Multi-client support for law firms and service providers
Crypto law firms and white paper service providers often prepare white papers for several issuers. These firms need to manage separate entities, users and versions within one environment. They also need a licensing model that scales with the number of clients they serve.
MiCA iXBRL software compared
The table below compares tools with a published MiCA iXBRL offering, based on each vendor’s product pages as of September 2026. Vendor claims have not been independently tested. Features that a vendor does not state publicly are marked as not stated.
| Tool | Delivery | Input | Validation | Collaboration | Multi-client | Pricing |
|---|---|---|---|---|---|---|
| CFOUR Comply | Cloud, self-service | PDF, converted to XHTML | Fujitsu Interstage XWand engine, aligned with the MiCA taxonomy | Preparer, reviewer and auditor roles | Multi-entity and multi-client | Per-entity licence, on request |
| DataTracks Rainbow | Cloud platform | Not stated | Over 1,000 checks (vendor-stated) | Tracked changes, comments and approvals | Not stated | Not published |
| CoreFiling | Not stated in detail | Not stated | Validation against MiCA filing rules | Not stated | Not stated | Quote on request |
CFOUR Comply
CFOUR Comply is a cloud-based iXBRL tagging platform that supports MiCA alongside ESEF, UKSEF, CSRD and SBR.
- Workflow. Reports are uploaded as PDF, converted to XHTML and tagged in a shared workspace. AI-based tag suggestions assist with narrative disclosures.
- Validation. Validation runs on the Fujitsu Interstage XWand engine.
- Review. User permissions separate preparers, reviewers and auditors.
- Modifications. Roll-forward carries tags from a previous submission into a new one, which applies directly when a white paper is modified.
- Multi-client. Multi-entity management supports law firms and service providers handling several issuers.
- Onboarding. CFOUR states that onboarding and a first iXBRL filing can be completed within the same day.
DataTracks Rainbow
DataTracks states that Rainbow loads ESMA’s latest MiCA taxonomy automatically, applies tags to the required disclosures and alerts users when mandatory data points are missing. The vendor cites more than 1,000 validation checks. It describes shared working for legal, compliance and product teams, with tracked changes, comments and approvals. Input formats, multi-client features and pricing are not stated on the product page.
CoreFiling
CoreFiling’s MiCA page describes a four-stage process. The finished white paper is converted to iXBRL with specialist software, tagged, validated against the MiCA filing rules, and then submitted. The same page covers the separate supervisory reporting for ART and EMT issuers, which is prepared from EBA templates in XBRL-CSV format. Product details and pricing are available on request.
ESMA’s Excel showcase and open-source validators
ESMA publishes a free Excel-based showcase, with one workbook each for ART, EMT and OTHR white papers, last updated in December 2025. ESMA describes its use as voluntary, accepts no liability for it, and states that its outputs need validation and remain the preparer’s responsibility. The showcase is useful for understanding how an iXBRL white paper is structured.
Open-source XBRL processors such as Arelle can load the MiCA taxonomy and run its assertions. This gives preparers an independent check on a file produced by any method.
Choosing between software and a tagging service
Issuers have two broad routes.
In-house software. The first route is to license software and tag white papers internally. It suits teams that expect several modifications over a token’s life and want control over timing.
A law firm or service provider. The second route is to use a crypto law firm or white paper service provider that prepares the iXBRL file as part of drafting. Service providers handling white papers for several issuers will, in turn, need software that supports multiple clients, separate access and consistent review workflows.
In both routes the preparer remains responsible for the final file. Whoever performs the tagging, the responsible team should therefore be able to review both the tagged document and its validation results before submission.
Errors to check before submitting a MiCA white paper
ESMA’s taxonomy documentation and reporting manual set rules that are easy to overlook, particularly when a white paper is modified some time after its first notification.
Before submission, check the following points.
- Entry point. The file should reference the entry point for its token type. ESMA states that reporting entities must not reference the technical entry point that covers the full taxonomy.
- Identifiers. An LEI used in the white paper must be valid and duly renewed under Delegated Regulation (EU) 2025/421. A DTI, where provided, must be a valid identifier of type 3. It is worth checking the LEI’s renewal status again whenever a white paper is modified.
- Images. Images should carry only branding, layout or photographs. Any information that forms part of the disclosure belongs in tagged text.
- Language versions. Each language version is a separate iXBRL file, and every version must use the same taxonomy elements.
- Validation and legal review. Validation should run against the full assertion set, with every error-severity assertion resolved. A separate legal review then confirms the disclosure meets the Article 1 standard, since the assertions do not test it.
Conclusion
Choosing MiCA iXBRL software is not simply a question of converting a white paper into XHTML. A suitable tool needs to apply the current ESMA taxonomy, use the correct entry point, run the required validation checks and support the way the document is reviewed and updated.
This matters particularly for MiCA because white papers can contain substantial narrative content, may be published in several languages and may need to be reissued when information changes. The software should make those processes easier without obscuring the preparer’s responsibility for the final disclosure.
Book a walkthrough of a MiCA white paper tagged and validated in CFOUR Comply.
Yes. Since 23 December 2025, white papers must be drawn up in XHTML with Inline XBRL 1.1 tagging under Regulation (EU) 2024/2984, using the ESMA MiCA taxonomy. No. The regulation requires a single XHTML file containing the Inline XBRL tagging. A PDF can be used during drafting, but the submitted document must be the iXBRL file. No. Passing the taxonomy’s assertions confirms that the file is correctly structured and tagged. The substantive disclosure standards in MiCA and Article 1 of Regulation (EU) 2024/2984 are assessed separately, and responsibility for them remains with the preparer. ESMA provides a free Excel-based showcase, with a separate workbook for each type of crypto-asset. However, this is primarily intended as a technical solution and requires users to work directly within the provided Excel templates. The resulting iXBRL output still needs to be validated, and ESMA makes clear that responsibility for the accuracy and compliance of the final white paper remains with the preparer. For organisations looking for a more controlled and user-friendly process, a dedicated iXBRL reporting solution can significantly reduce the manual work and technical complexity involved. Yes. ESMA’s reporting manual treats each language version as a separate iXBRL file. All versions must be tagged with the same taxonomy elements. Frequently asked questions - MiCA Reporting
