The Whitepaper Obligations MiCAR Places on CASPs

Regulation · August 2026 · Yamal Kalaf, Co-Founder, MiCAR Whitepapers Europe

Most discussion of MiCAR whitepapers assumes an issuer: a project raising money, drafting a disclosure document, notifying a competent authority. Title II has a second door, and it opens onto crypto-asset service providers. Where a token is admitted to trading on a platform, Article 5 makes a compliant whitepaper a condition of admission, and on several routes the duty to produce that document lands on the operator rather than the project. It is the same whitepaper machinery as a public offer, pointed at a different party.

For platforms with a catalogue inherited from before MiCAR applied, this is not a theoretical problem. It is a dated one, and the date is 31 December 2027.

Three routes to a whitepaper duty on a platform

The starting position is unremarkable: the person seeking admission to trading draws up the whitepaper, notifies it and publishes it, in the same way an offeror does for a public offer. What makes Article 5 interesting for CASPs is what happens when there is no such person, or when the parties agree otherwise.

Own-initiative admission. Where the operator of the trading platform admits a crypto-asset on its own initiative, and no whitepaper has already been published in the cases the regulation requires one, the operator itself must meet the admission requirements. There is no counterparty to carry the obligation, so the platform drafts, notifies and publishes, and stands behind the document afterwards. The qualifier matters in practice: if a compliant whitepaper already exists for the asset, own-initiative admission does not manufacture a second drafting duty.

Transfer by written agreement. Where there is a person seeking admission, that person and the operator may agree in writing that the operator prepares the whitepaper instead. The transfer can cover all or part of the requirements, and the agreement has to state clearly that the person seeking admission will supply the operator with all the information it needs to satisfy them. The drafting moves; the underlying information does not, and neither does all of the liability.

Operating rules. Separately from either route, an operator's rules of operation must provide that a crypto-asset is not admitted where a whitepaper is required and has not been published. This is the mechanism that turns the obligation into a listing gate rather than a filing afterthought.

Who drafts, who is liable

Drafting and liability are not the same allocation, and the difference is where platforms get caught out. Under Article 15, the person seeking admission, or the operator where it drew up the document, is liable for the information in the whitepaper, together with the members of its management body. A disclaimer purporting to exclude that liability has no legal effect. Where drafting was transferred by agreement, the person seeking admission does not walk away: it remains responsible for information it supplied that was incomplete, unfair, unclear or misleading.

Route	Who drafts	Who carries Article 15 liability	Deadline
Own initiative Article 5(2)	The operator	The operator and its management body	Before admission
Transfer by agreement Article 5(3)	The operator, by written agreement	The operator for the document; the person seeking admission where it supplied misleading information, and for matters not delegated to the operator	Before admission
Legacy catalogue Article 143(2)	The operator ensures one exists	Whoever draws the document up, on the ordinary Article 15 allocation	31 December 2027

The practical reading for an operator running the Article 5(3) route: the written agreement is not a liability transfer, it is a drafting arrangement with a liability split attached. What protects the platform is not the contract but the quality of the information package it received, and its own record of what it did with that package.

The 31 December 2027 deadline for legacy catalogues

Article 143(2) is the transitional provision that catches everything listed before the regime began. For crypto-assets other than ARTs and EMTs that were admitted to trading before 30 December 2024, operators of trading platforms must ensure that a whitepaper is drawn up, notified, published and kept up to date by 31 December 2027, in the cases where the regulation requires one.

• 30 December 2024 MiCAR Title II applies in full. Tokens admitted to trading before this date form the legacy catalogue.
• 23 December 2025 The machine-readable format requirement applies: whitepapers are prepared in iXBRL under the ESMA taxonomy.
• 1 July 2026 The Article 143(3) transitional period ends for providers that were operating under national law, or earlier if authorisation is granted or refused first. Member States could shorten it further.
• 31 December 2027 Legacy-catalogue deadline: whitepaper drawn up, notified, published and kept up to date.

Two details in the same provision are easy to miss. Article 143(2)(a) keeps the marketing rules alive for the legacy population: Articles 7 and 9 apply to any marketing communication published after 30 December 2024, whitepaper or no whitepaper. And Article 143(1) disapplies Articles 4 to 15 to offers to the public that ended before 30 December 2024, which is a separate carve-out from the admission one and is often quoted as though it covered both.

ESMA addressed the allocation directly in a Q&A published on 14 October 2025. For tokens in that legacy population, offerors and persons seeking admission carry no whitepaper duty, and the obligation sits with the operator of the trading platform. Read narrowly, that is a sensible answer to a real problem: many pre-2025 listings have no cooperative counterparty, and some have no counterparty at all.

After Q&A 2654, a misreading circulated: that offerors in general were now exempt from Article 4 until 2028. The Q&A says no such thing. The relief in Article 143(2) attaches to one situation only, tokens admitted to trading before 30 December 2024, and the duty it defers lands on operators of trading platforms, not on offerors. An offer to the public that is ongoing, or made today, takes the ordinary Article 4 route in full, whatever the token's listing history. Any launch plan built on the broader reading is built on a provision that does not exist.

Triaging a legacy catalogue

For a platform with hundreds of listed assets, 31 December 2027 is not a filing deadline, it is a programme. The work is triage before it is drafting, and the order of the questions decides how much drafting there turns out to be.

Tokens without an identifiable issuer

The first triage question got a firmer answer in February 2026, when the Commission's answer to Q&A 2552 was published. Article 5(2) does not reach crypto-assets that have no identifiable issuer: recital 22 places them outside Title II, so no whitepaper is required for them under MiCAR, and the operator's own-initiative drafting duty does not arise. The same qualifier, "in the cases required by this Regulation", runs through Articles 76(1) and 143(2)(b), so the legacy-catalogue deadline inherits the carve-out too.

The carve-out is narrower in practice than in summary. The platform is not relieved of its suitability assessment, and determining whether an identifiable issuer exists is part of that assessment, a documented conclusion rather than a default setting. Our expectation is that competent authorities will read "no identifiable issuer" strictly: most tokens have one, even where it has not yet been identified at admission, and a triage file that stamps half a catalogue "no issuer" without analysis will read as avoidance, not classification. Treat the no-issuer conclusion as an exception that must earn its place in the file.

Reuse, consent and the Article 66(3) hyperlink

A token listed on one EU platform does not need a fresh whitepaper for the next one. Article 5(4) switches off the drafting, notification and publication requirements where the crypto-asset is already admitted to trading on another trading platform in the Union and the existing whitepaper was drawn up under Article 6, updated under Article 12, and the person responsible for drawing it up consents in writing to its use. All three conditions have to hold; the consent is the one that gets forgotten.

Article 66(3) is a transparency duty attached to the service, not to the document, and it is narrower than "every CASP": it bites when operating a trading platform, exchanging crypto-assets for funds or other crypto-assets, advising on crypto-assets, or providing portfolio management. A CASP doing only custody or transfer services is not caught by the hyperlink duty. For those that are, it is cheap to comply with and easy to forget at scale, because it applies across the catalogue rather than at the moment of listing.

The format requirement: everything arrives as iXBRL

Since 23 December 2025, a MiCAR whitepaper is filed as an iXBRL filing, tagged against the ESMA taxonomy, under the technical standards in Implementing Regulation (EU) 2024/2984. For a platform planning a legacy programme this is a production constraint, not a footnote: several hundred documents cannot be tagged by hand in the last quarter of 2027.

The format requirement has a timing question of its own: what about whitepapers notified before 23 December 2025, when the ITS began to apply? Our position is that the prudent course, and in our reading the intended one, is conversion. The ITS applies "as of" that date, language that attaches to the population of whitepapers from that date forward rather than only to new filings, and the stated purpose of the standard, comparability and machine-readable supervision across the market, is defeated if the earliest filings remain permanently outside it. There is also a mechanical forcing point: any Article 12 modification notified after the application date has to be filed to the standard in any event, so a maintained whitepaper converges on iXBRL at its first update. Converting on your own schedule is cheaper than converting on a deadline set by a material change. ESMA's implementation statement is the reference point for how supervisors expect the transition to be handled.

When the CASP is the offeror

One scenario runs in the opposite direction from everything above: instead of the whitepaper duty reaching the platform through Article 5, it reaches the CASP through Article 4, because the CASP's own service amounts to an offer. ESMA's statement on non-compliant ARTs and EMTs made the mechanism explicit for stablecoins: services such as reception and transmission of orders, execution of orders, and exchange of crypto-assets for funds or other crypto-assets can themselves constitute an offer to the public. The logic is not confined to stablecoins. The Article 3(1), point (12) definition is deliberately broad, a communication presenting the terms and enough information to decide, and whether a given exchange or brokerage service crosses it is a case-by-case assessment, not a licensing category.

The practical consequence for CASPs: the whitepaper analysis is not finished when the Article 5 admission questions are answered. A service that presents specific tokens to clients on terms they can act on may be making an offer to the public in its own right, with the Article 4 machinery, legal-person offeror, whitepaper, notification, marketing standard, conduct duties, attaching to the CASP as offeror.

Supervisory context

None of this is happening in a settled framework. Title II is one of the areas under assessment in the 2026 MiCA review consultation, open until 30 September 2026, and the Commission's report is due by 30 June 2027, six months before the legacy deadline falls. Platforms should plan on the rules as they stand: a review that reports in mid-2027 cannot realistically move a deadline at the end of it.

The population subject to these duties keeps growing. The ESMA register listed 322 authorised crypto-asset service providers across 26 Member States when we consulted it in August 2026, up from around 170 at the time of the Commission's consultation document in May, with the transitional period for providers operating under national regimes having ended on 1 July 2026. Every one of those authorisations that includes operating a trading platform brings a catalogue with it.

What platforms and projects should do

For operators, the sequence is inventory, triage, then production. Inventory means a definitive list of admitted assets with their admission dates, because 30 December 2024 divides the catalogue into two different legal populations. Triage means running the four questions above per asset and writing down the answer, including for the assets you conclude need nothing. Production means deciding, per asset, whether the project drafts, you draft, or you contract it out, and building an iXBRL pipeline that can carry the volume.

For projects listed on EU platforms, the point to take is that Article 143(2) is relief from a duty, not from an interest. If your token is in a platform's legacy catalogue, someone is going to draft a disclosure document about your project before the end of 2027, and if it is not you, it will be written from the outside on whatever information the platform can assemble. Volunteering the information package, and the consent, is usually the better outcome.

The deadline looks distant. It is two triage cycles and one drafting programme away, and the first of those is the one nobody schedules.

Yamal Kalaf, Co-Founder, MiCAR Whitepapers Europe