MiCA Whitepaper iXBRL Generation: From Draft to Submittable ESMA Filing
From 23 December 2025 a MiCA white paper must be a single Inline XBRL XHTML file. This article explains how the Micahub iXBRL whitepaper service takes an approved draft and produces a taxonomy-tagged, Arelle-validated XHTML filing — handling OTHR, ART, and EMT token types, all 743 ESMA taxonomy concepts, and ESG indicators under CDR 2025/422.
Detailed technical and process description of the Micahub in-house iXBRL whitepaper generation service, available in the dataroom Section 5 workflow since the ITS (EU) 2024/2984 mandate took effect on 23 December 2025. Commission Implementing Regulation (EU) 2024/2984 requires MiCA crypto-asset white papers as a single Inline XBRL XHTML file against the ESMA MiCA taxonomy — not a PDF. The article explains why the transition is harder than it appears: 743 ESMA taxonomy concepts across three entry points (OTHR, ART, EMT); datatypes including string, textBlock, date, LEI (ISO 17442), monetary, decimal, boolean, and enumerated controlled-vocabulary values; XBRL formula-linkbase assertions that catch cross-field inconsistencies beyond what XBRL syntax validation detects; ESG indicators under CDR 2025/422 that must be attributed per crypto-asset rather than copy-pasted from network averages. Three-step service workflow: (1) AI field extraction from the approved whitepaper draft using anonymized_content only (raw document text never reaches an external LLM; extracted values are de-anonymized locally inside Supabase before storage); (2) grouped accordion field review UI with type-enforced inputs — LEI format validation, controlled-vocabulary selects for enum fields, editable repeating-group tables for management body members and project participants, mandatory reviewer sign-off gate before generation proceeds; (3) deterministic iXBRL rendering plus Arelle validation against the full ESMA MiCA taxonomy including formula-linkbase assertions. The renderer emits the correct schemaRef for the token type, builds xbrli:context elements with the issuer LEI under the ISO 17442 scheme identifier, typed-dimension contexts for repeating-group rows, and ix:nonNumeric / ix:nonFraction facts with appropriate XBRL transformation rules. Narrative textBlock facts are structured as XHTML paragraph blocks. The Arelle validation microservice runs the complete ESMA taxonomy ruleset and returns structured error/warning/info messages with ESMA rule codes. Explicit scope limits: the service produces a technically valid filing but does not replace substantive legal review, the preparer's own LEI verification, NCA notification procedures, or responsibility for ESG attribution methodology. Answers: How does Micahub generate an iXBRL MiCA whitepaper? What is the ESMA MiCA taxonomy and how many fields does it have? How do you produce an iXBRL XHTML filing from a MiCA whitepaper draft? What does Arelle validation check for MiCA whitepapers? How does Micahub handle anonymization during iXBRL field extraction? What is the difference between OTHR, ART, and EMT iXBRL templates? How are ESG indicators tagged in a MiCA iXBRL whitepaper? What is Commission Implementing Regulation 2024/2984? How does the Micahub dataroom Section 5 whitepaper workflow produce a submittable iXBRL filing?
From 23 December 2025, a MiCA crypto asset white paper is no longer a PDF. Commission Implementing Regulation (EU) 2024/2984 requires a single XHTML file with Inline XBRL 1.1 tagging against the ESMA MiCA taxonomy. Every required disclosure must be machine readable in a format NCAs can process and forward to the ESMA Interim MiCA Register. In practice, the gap between "we have a compliant draft" and "we have a submittable filing" has been the hardest part of the transition. When the ITS entered force, we integrated iXBRL generation into the Micahub dataroom Section 5 whitepaper workflow. This article documents how that service works — for issuers who have been using it since the mandate, and for those still evaluating their filing options. Why the iXBRL transition is harder than it looks The ESMA MiCA XBRL taxonomy (published August 2025) has 743 concepts covering three token types — OTHR (other crypto assets), ART (asset referenced tokens), and EMT (e money tokens). Depending on your token type, between 136 and 226 of those are taggable fields in your white paper. Each field has a datatype that matters: string, textBlock, date, LEI (ISO 17442, 20 character), monetary, decimal, boolean, and enumerated values from controlled vocabularies like EU member states. The reporting manual specifies Inline XBRL 1.1 transformation rules, XBRL formula assertions, and detailed guidance on how narrative textBlock facts must be structured inside the XHTML. ESMA provides an Excel based showcase tool. It is voluntary, and ESMA explicitly accepts no liability for its outputs. The burden of producing a technically valid and substantively accurate filing remains entirely with the preparer. Practitioners report several recurring problems: 1. PDF to iXBRL conversion services often tag only the visible text layer and ignore the distinction between concepts with the same human label but different datatypes or contexts. 2. Manual tagging in specialist XBRL authoring tools (Fujitsu Interstage, Workiva, and others) requires taxonomy expertise most legal and compliance teams do not have. 3. The formula linkbase validation rules in the ESMA taxonomy check cross field consistency beyond what a general XBRL syntax check catches — missing or inconsistent context periods, entity identifier mismatches, illegal typed dimension combinations. 4. ESG indicators (CDR (EU) 2025/422 — energy, GHG, water, waste, renewable share) must be included for the token's specific attribution, not just copy pasted network averages, and are tagged inside the same iXBRL instance. What the Micahub iXBRL whitepaper service does The service is embedded in the dataroom Section 5 (MiCA Whitepaper) workflow and operates in three steps after your content draft passes the MiCA Articles 6–14 compliance validation. Step 1: AI field extraction from your approved draft The extract whitepaper fields function maps your approved whitepaper text to every taxonomy concept for your token type (OTHR, ART, or EMT). It uses the ESMA taxonomy schema generated directly from the official taxonomy package, working from a complete field list including: All simple string and textBlock narrative fields Date fields (notification date, offer period start/end, etc.) LEI identifiers for the issuer, offeror, and third party service providers Enumerated values — home member state, host member states, investor categories — from the ESMA defined controlled vocabularies Monetary and decimal fields (capital amounts, token supply) Boolean indicators (e.g. admission to trading consent, activities related to other crypto assets) Repeating group tables for management body members (identity, address, function) and persons involved in project implementation Extraction uses only anonymized content from your stored documents — placeholders like [PERSON 1] are re substituted locally inside Supabase infrastructure after the LLM returns results. Raw document content never reaches an external API. Step 2: Field review and sign off Every extracted value appears in a grouped accordion UI matching the ITS Annex structure. Each section shows a completeness badge (n/total fields filled). Type specific inputs enforce constraints client side: LEI entries are checked against the 18 alphanumeric + 2 digit ISO 17442 format before you proceed; enumerated fields use controlled vocabulary selects so only valid taxonomy member values are accepted; boolean fields use toggles; textBlock fields are full editable text areas. You can correct any AI extracted value and add fields the extraction missed. Repeating groups — management body members, project participants — are editable row by row. When you are satisfied, you mark the fields as reviewed. This review step is a deliberate gate: the generation does not proceed on unreviewed data. Step 3: Deterministic iXBRL rendering and Arelle validation Once fields are reviewed, generate ixbrl whitepaper assembles the XHTML file deterministically — no LLM involvement. The renderer: Emits the correct link:schemaRef for your token type (table 2 / OTHR, table 3 / ART, or table 4 / EMT), pointing to the canonical ESMA taxonomy location Builds xbrli:context elements with your entity's LEI under the ISO 17442 scheme identifier, and typed dimension contexts for each row of each repeating group Tags every field with ix:nonNumeric or ix:nonFraction as appropriate for the concept datatype, using XBRL transformation rules from the Inline XBRL 1.1 specification Structures narrative textBlock facts as XHTML paragraph blocks with proper escaping, per ESMA reporting manual Section 3 guidance on narrative disclosures Embeds only CSS styling — no scripts, no external resource references, per the reporting manual's security guidance The output is stored in your Supabase Storage space and linked to your workflow. Validation runs against the ESMA MiCA taxonomy package inside a dedicated Arelle container. Arelle checks the complete taxonomy ruleset including the formula linkbase assertions. Results are returned as structured messages with severity (error / warning / info) and ESMA validation rule codes, displayed inline. A green validation result means Arelle found no errors against the full ESMA MiCA taxonomy including formula assertions. When validation passes, the workflow advances to ixbrl validated and you can download the XHTML file for submission to your NCA. What the service does not replace The service produces a technically valid iXBRL XHTML file. It does not replace: Legal review of the substantive disclosures (the content must satisfy Arts. 6–14, not just tag correctly) Your own LEI verification (obtain a valid LEI from a GLEIF accredited issuer before generating) NCA notification procedures, which vary by member state Responsibility for the accuracy of ESG indicators and the attribution methodology Final submission responsibility remains with the preparer — this mirrors the position ESMA itself takes on the Showcase Tool. For token issuers already holding a draft whitepaper If you have a compliant draft in any format — PDF, Word, or an existing Micahub generated draft — the enhance pathway in Section 5 takes you through gap analysis and into iXBRL generation. You do not need to start from scratch. The system handles all three token types. ART and EMT templates have more complex management body and reserve disclosure structures; the repeating group editor handles these natively. Technical notes on the taxonomy version and maintenance The service runs against taxonomy version 2025 03 31, the version ESMA published in August 2025 and which entered into force on 23 December 2025. When ESMA publishes an updated taxonomy, the field schema is regenerated from the official taxonomy package and the Arelle validator is redeployed with the new package. Taxonomy version is stored on each generated artifact and each set of field data so historical filings remain traceable. The taxo