MiCA white paper requirements and iXBRL publication for a non-EU token project

MiCA defines a utility token by its sole intended purpose: access to a good or service supplied by its issuer. Establish who supplies the software service, what the holder can demand, and whether the token also carries profit, repayment, redemption or other investment rights. An issuer and a separate group company operating the software cannot be treated as interchangeable without examining the arrangements. (Regulation (EU) 2023/1114, “MiCA”, Article 3(1)(9).)

Financial instruments fall outside MiCA. An asset-referenced token or e-money token follows a different MiCA regime. Examine any mechanism purporting to maintain stable value, including its reference assets or currency. The token’s substance takes priority over its name. Record the analysis against the exclusions and definitions, with the terms and technical design supporting each conclusion. (MiCA, Articles 2(4) and 3(1)(6)–(7); ESMA Guidelines ESMA75453128700-1323, paragraphs 11–15 and 74–76.)

Vietnam’s pilot regime adds a separate launch condition. An issuance within Resolution 05/2025/NQ-CP requires a Vietnamese limited liability or joint-stock company and underlying real assets other than securities or fiat currency. Tokens issued under that route are offered only to foreign investors and traded between foreign investors through a Ministry of Finance-licensed provider. The regime also requires offer, issuance, trading and settlement in Vietnamese dong, and publication of the prescribed prospectus and any related documents on both the provider’s and issuer’s websites at least 15 days before the offer or issuance. Within that pilot, Article 4(4) of the Resolution also reserves crypto-related services and advertising or marketing to organisations licensed by the Ministry of Finance to provide crypto-asset trading market services. (Resolution 05/2025/NQ-CP, Articles 4(4), 4(7), 5 and 6.)

A working software service does not establish that the underlying-asset condition is satisfied. Nor does an EU platform’s MiCA permission establish compliance with Vietnam’s licensed-channel restriction. Before committing to the proposed structure, determine whether and how the pilot rules apply to the issuer, issuance location, investors, payment flows and subsequent EU trading. If the route cannot satisfy the applicable conditions, change the product or distribution structure, or postpone the offer. Incorporating an overseas entity alone does not resolve the Vietnamese operations and cross-border questions.

Exemptions and the planned EU listing

Article 4(3)(c) exempts an offer of a utility token providing access to an existing or operational good or service. However, Article 4(4) removes the Article 4(2) and (3) exemptions when the offeror, or someone acting on its behalf, communicates an intention to seek admission to trading. The Commission’s published answer confirms that this concerns EU trading platforms. A private intention and a communicated intention are distinct, but the planned EU admission itself also requires assessment under Article 5. (MiCA, Articles 4(3)–(4) and 5; ESMA Q&A 2671, updated 21 May 2026.)

The same limitation affects offers not exceeding EUR 1 million over 12 months, offers to fewer than 150 persons per Member State acting on their own account, and offers solely to qualified investors where only such investors can hold the token. Those Article 4(2) exemptions remove specified disclosure duties, not every Title II obligation. Free distributions, consensus rewards and limited-network offers have separate conditions under Article 4(3). They do not provide a shortcut for the proposed marketed offer and EU listing.

If the project instead abandons EU admission and confines its offer to a qualifying operational utility token, the exemption analysis can change. Document that decision and control subsequent communications. Under Article 4(8), voluntarily drawing up a MiCA crypto-asset white paper despite an Article 4(2) or (3) exemption brings Title II back into application. Licentium’s analysis of utility tokens under MiCA provides related classification context.

Distinguish the issuer, the person making the EU public offer, and the person seeking admission. The offeror and admission applicant must be legal persons under Articles 4(1)(a) and 5(1)(a). They can be the same entity, but the contracts and white paper must reflect the actual arrangement.

Title II does not itself impose a general EU-incorporation requirement on a third-country offeror. The home Member State depends on the responsible person’s structure. An EU registered office ordinarily determines it; a third-country person with EU branches chooses among those branch states. Without an EU branch, the rule refers to the first intended EU public offer or, at the person’s choice, the first application for trading admission. Establish the relevant Member State before scheduling notification. (MiCA, Article 3(1)(33)(a)–(c).)

A written agreement can allocate some or all Article 5(1)(b)–(g) admission duties to the trading-platform operator. The applicant must supply the necessary information. That agreement does not automatically transfer separate public-offer obligations. A platform listing on its own initiative has its own duties where a required white paper has not been published. (MiCA, Article 5(2)–(3).)

Check the platform’s permission to operate the relevant service and its admission rules. A compliant white paper does not guarantee acceptance. Custody, placement, exchange or other services supplied by the project require separate analysis under Articles 59–60; the digital asset licensing route addresses that distinct decision. Article 76 governs the platform’s admission controls.

Use Article 6 and Annex I as the content map. They require information on the responsible entities, project, offer or admission, token, rights and obligations, underlying technology, risks, and principal adverse climate and environmental impacts of the consensus mechanism. Obtain the required environmental evidence and apply the relevant sustainability standards. (MiCA, Article 6(1); Delegated Regulation (EU) 2025/422.)

The project description should reconcile the working service with the roadmap, development resources and use of proceeds. Token disclosures should reconcile the legal rights with deployed code, supply, allocations, vesting, transfer restrictions, administrative powers and any minting or burning arrangements. Explain what happens if the service changes, fails or becomes unavailable. Identify dependencies on affiliates, contractors, custodians and infrastructure providers where material.

Annex I, Part A, point 10 requires information about the financial condition of the offeror or admission applicant for the past three years, or since registration if it is newer. It requires a fair review of development, performance and position, including relevant interim information and material changes. It does not impose a universal requirement to produce three years of audited accounts. Obtain available financial statements and supporting management information, identify the reporting basis and audit status, and explain material funding dependencies accurately.

Use the required non-approval statement, management-body statement, summary warnings and risk statements in the prescribed order. The document must address possible loss of value, transferability and liquidity, utility-service failure, and the absence of deposit-guarantee and investor-compensation protection. It must not assert future token value. Include the notification date and table of contents. (MiCA, Article 6(3)–(8).)

Management must review the evidence underlying its statement. A polished narrative cannot cure missing rights, contradictory supply figures or an unsupported security claim. Where an audit or assurance report is mentioned, state its actual scope, date and limitations.

The entity responsible for a deficient white paper and members of its administrative, management or supervisory body can face liability for loss caused by incomplete, unfair, unclear or misleading information that infringes Article 6. Article 15 also addresses reliance, summary-specific liability and the applicant’s responsibility for defective information supplied to a delegated platform. Contractual exclusions of the statutory liability have no legal effect. (MiCA, Article 15(1)–(6).)

The MiCA white paper template for this route is Table 2 of the Annex to Implementing Regulation (EU) 2024/2984. Its format requirements have applied since 23 December 2025. The white paper must be a single Extensible HyperText Markup Language (XHTML) file using Inline Extensible Business Reporting Language (iXBRL) 1.1 to mark the specified fields. iXBRL embeds machine-readable tags in the document people read. Deliver that regulated file even if a PDF is also supplied. (Implementing Regulation 2024/2984, Articles 1–4 and Annex, Table 2.)

As of 4 November 2026, ESMA’s current publication is the MiCA White Paper Taxonomy 2025, released on 5 August 2025. The downloadable package identifies version 1.0.0; the accompanying Reporting Manual is version 1.0, dated July 2025. Use the Table 2 reporting entry point and record the package version and dependencies used for each release. The taxonomy ZIP supplies software dependencies; the white-paper instance submitted under Article 2 is the XHTML file.

Use a valid legal entity identifier where available, or the identifier required by applicable national law, for the reporting entity. Plan ISO 24165 identifiers for the individual crypto-assets and a type 3 functionally fungible group identifier for the white paper. Where the ISO token identifier is unavailable, the alternative must have ESMA’s Union-level approval. The template’s conditional fields do not establish permission to leave the identification requirement unresolved. (Implementing Regulation 2024/2984, Article 2(1)(c) and Annex, Table 2; Delegated Regulation (EU) 2025/421, Articles 2–3.)

Choose a language permitted by Article 6(9): an official language of the home Member State or a language customary in international finance, with the corresponding rule for host states. Check the actual language plan with the selected authority’s requirements. For multiple languages, ESMA’s manual calls for a separate iXBRL file for each, consistent content and identical tagging concepts. (MiCA, Article 6(9); Reporting Manual, Guidance 1.1.1–1.1.2.)

Legal review should settle the disclosures, rights, warnings, classification explanation and marketing. Management confirms the underlying facts. The tagging provider maps the approved content to the published taxonomy and tests XHTML/iXBRL validity, required facts, identifiers, contexts, dates, units and enumerated values. Review the rendered document and extracted facts together, resolve errors, assess warnings and retain the validation record. Recheck after any legal or translation change. (Reporting Manual, Sections 1–2, especially Guidance 2.5.1.)

ESMA’s Excel showcase is voluntary; its outputs still require validation under the preparer’s responsibility. The Reporting Manual and validation guidance support implementation. They do not replace the binding template or establish that the tagged legal and business statements are true.

Notify the competent authority of the home Member State at least 20 working days before the intended white-paper publication date. Include the Article 8(4) explanation of why the token falls outside the Article 2(4) exclusions and is neither an asset-referenced token nor an e-money token. The joint supervisory guidelines provide the relevant explanation template in Annex A. This is distinct from the legal-opinion template for an asset-referenced token application. (MiCA, Article 8(1), (4)–(5); Joint Guidelines JC 2024 28, paragraphs 12–13 and Annex A.)

Identify the intended host Member States and the planned offer or admission start date, and communicate changes. The home authority transmits the prescribed information to other authorities and ESMA. Do not plan around submitting the white paper directly to ESMA as the normal notification route. (MiCA, Article 8(6)–(7).)

Check the selected authority’s current submission instructions. If Ireland is properly selected as home Member State, the Central Bank’s process as of 4 November 2026 requires the white paper, explanatory note and Title II submission template through a requested Kiteworks upload link. Its 23 October 2026 announcement describes a forthcoming portal; it does not establish that the new Title II portal is already operating. Build the calendar around the actual filing channel and the authority’s handling of an incomplete package. (Central Bank of Ireland, MiCAR notification instructions and 23 October 2026 communication.)

Publish the notified white paper on the publicly accessible website of each entity responsible for publication a reasonable time before, and in any event before, the offer or admission starts. Keep the published version identical to the notified version, subject to the Article 12 modification process. No prior approval is required, and publication in ESMA’s register does not endorse the token. (MiCA, Articles 8(3) and 9.)

Marketing must be identifiable, fair, clear, consistent with the white paper and accompanied by the required references, contact details and non-approval statement. Where a white paper is required, marketing communications cannot precede its publication. Review the website, social posts, sales materials and platform descriptions together. (MiCA, Article 7.)

Before accepting subscriptions, settle the withdrawal and refund arrangements. Article 13 generally gives retail purchasers buying directly from the offeror or through a placing service provider 14 calendar days to withdraw. Exceptions include purchases after the token has already been admitted and the end of a time-limited subscription period. Publish time-limited offer results within 20 working days of subscription close; publish circulation information at least monthly for an open-ended offer. Implement the safeguarding arrangements required by Article 10(3)–(4), alongside Article 14’s conduct, conflicts and security duties.

Appoint one accountable disclosure owner with access to legal, finance, engineering, marketing and the platform. Require those teams to escalate changes to token rights, supply, service availability, technology, security, funding and material dependencies. Schedule regular review of sustainability information under Article 2(1) of Delegated Regulation 2025/422.

A significant new factor, material mistake or material inaccuracy capable of affecting the token assessment triggers the Article 12 process during the offer and for as long as the token is admitted to trading. Notify the modified white paper, modified marketing where applicable, reasons and intended publication date at least seven working days before publication. Publish the changes and reasons, timestamp the documents and identify the current version. (MiCA, Article 12(1)–(7).)

Keep the white paper and modifications available while the public holds the token. Older versions must remain publicly available for at least ten years after publication, with a prominent warning that they are no longer valid and a link to the latest version. Maintain a release register linking each version to its source evidence, approvals, notification receipt, technical validation and public URL. (MiCA, Articles 9(1) and 12(7), (9).)

Assess inside information separately once admission is requested or obtained. Under Article 88, issuers, offerors and admission applicants must disclose as soon as possible information that meets Article 87’s test and directly concerns them, unless the specific conditions for delay are met. The seven-working-day white-paper process is not permission to withhold inside information. (MiCA, Articles 86–88.)

Request these materials before substantive drafting:

• Corporate records for the issuer, offeror and admission applicant; group relationships; management details; EU branches; and the proposed home and host states.
• Token terms, software-service terms, intellectual-property and operating arrangements, classification analysis, and the Vietnam issuance and distribution assessment.
• Contract addresses, chain and token identifiers, code and audit records, administrative controls, supply and allocation schedules, vesting, transfer restrictions and consensus-mechanism evidence.
• Financial statements, relevant interim accounts, funding commitments, budgets, use-of-proceeds plans and evidence supporting project milestones.
• Offer mechanics, pricing, allocation rules, withdrawal and refund processes, safeguarding arrangements, platform terms and any Article 5 delegation agreement.
• Existing white papers, websites and marketing, translations, identified risk events, and a list of people responsible for maintaining each factual disclosure.

Use a joint release meeting to resolve the following conditions:

1. Management confirms the entities, rights, figures, service status and evidence. Legal review records the classification, exemption analysis, Vietnam position and permissible offer structure.
2. The offeror and admission applicant accept their duties. Any platform delegation is signed, and the platform’s permission and admission requirements have been checked.
3. The statutory content and classification explanation are complete. Marketing and transaction terms agree with the white paper.
4. The tagging provider delivers the required files and validation record. Legal and business owners check the rendered text and tagged facts against the approved content.
5. The home-authority package, working-day calendar, publication URL and version controls are ready. The notified and published files match.
6. Customer safeguards, ongoing disclosure ownership, change escalation and document retention are operating before launch.

An unresolved classification issue, an unsupported Vietnam issuance route or a material discrepancy between token terms and code should stop release. A change to the product, entity arrangement or distribution plan may require the project to revisit earlier stages.