MiCA ontrafeld: je crypto-whitepaper mag niet alleen maar een Gitbook of pdf zijn

MiCA Decoded is een wekelijkse serie van 12 artikelen voor Bitcoin.com News, geschreven door de medeoprichters en managing directors van LegalBison: Aaron Glauberman, Viktor Juskin en Sabir Alijev. LegalBison adviseert crypto- en FinTech-bedrijven over MiCA-licenties, CASP- en VASP-aanvragen en regelgevingsstructurering in heel Europa en daarbuiten.

Onder MiCA is een whitepaper een verplicht juridisch openbaarmakingsinstrument. De beste vergelijking in de traditionele financiële wereld is een effectenprospectus, niet een marketingdocument. De regelgeving schrijft voor wie er een moet opstellen, in welk formaat, met welke identificatiegegevens, onderworpen aan welke geautomatiseerde validatie, en met aansprakelijkheid die aan een specifiek genoemde persoon is verbonden.

Als ook maar één van deze elementen niet klopt, bestaat het document in de ogen van de Europese toezichthouders niet, ongeacht hoe goed het is geschreven.

In deze zesde aflevering van MiCA Decoded wordt stuk voor stuk uitgelegd wat dat eigenlijk betekent.

De mythe: een MiCA-whitepaper is slechts een GitBook of een PDF

Een MiCA-whitepaper heeft het gewicht van een formele regelgevingsaanvraag.

Uitvoeringsverordening (EU) 2024/2984 van de Commissie, die de formulieren, formaten en sjablonen voor whitepapers over crypto-activa regelt, vereist dat het document wordt opgesteld in een gestructureerd digitaal formaat dat zo is ontworpen dat de ESMA en de nationale bevoegde autoriteiten in alle EU-lidstaten identieke geautomatiseerde analyses kunnen uitvoeren op elke indiening, ongeacht wie deze heeft ingediend of waar.

Het juridische doel van die ontwerpkeuze is belangrijker dan de technische details. MiCA is een verordening voor de interne markt, en vergelijkbaarheid tussen indieningen is een essentieel handhavingsinstrument.

Een whitepaper dat niet door dezelfde machine kan worden gelezen als alle andere whitepapers die in Europa zijn ingediend, voldoet niet aan de voorschriften, ongeacht de inhoud ervan. ESMA heeft de vereiste taxonomie (het gestructureerde kader dat bepaalt wat een conform whitepaper moet bevatten) op 5 augustus 2025 gepubliceerd. De regels zijn van toepassing vanaf 23 december 2025.

De openbaarmakingsverplichtingen variëren afhankelijk van het type crypto-actief in kwestie. MiCA onderscheidt drie verschillende categorieën, elk met een eigen whitepaper-sjabloon en veldvereisten:

De categorie bepaalt niet alleen de inhoud van de whitepaper, maar ook het volledige juridische traject om er een in te dienen. Een project kan niet op basis van voorkeur kiezen welke categorie van toepassing is. De kenmerken van het activum bepalen dit, en de voorbereidingsverplichtingen vloeien daaruit voort.

Wie draagt de wettelijke verplichting – en de aansprakelijkheid

Voor de overgrote meerderheid van de tokens op de markt (gecategoriseerd als "Overige" crypto-activa, of OTHR) rust de verplichting niet automatisch op de entiteit die de token heeft gecreëerd. Voor deze activa legt MiCA de verplichting bij de aanbieder of de persoon die toelating tot de handel zoekt, wat gedefinieerde rollen zijn die al dan niet samenvallen met de oorspronkelijke uitgever.

Dit onderscheid heeft reële gevolgen. Een project dat onder de OTHR-categorie valt en gelanceerd is vanaf de Britse Maagdeneilanden, de Kaaimaneilanden of een ander offshore-rechtsgebied, kan de aanbieder zijn in het kader van MiCA en de whitepaper-verplichting rechtstreeks dragen, zonder dat het zijn statutaire zetel naar Europa hoeft te verplaatsen.

(Opmerking: deze structurele flexibiliteit geldt strikt voor OTHR-tokens. Voor Asset-Referenced Tokens en E-Money Tokens berusten de wettelijke verplichting en de strikte civiele aansprakelijkheid voor de whitepaper volledig bij de geautoriseerde EU-uitgever en kunnen deze niet worden gedelegeerd).

Zoals we in het tweede deel van deze serie hebben onderzocht, bevestigen de ESMA-registers dat dit al gangbare praktijk is: het merendeel van de onafhankelijke tokenregistraties is afkomstig van entiteiten met hoofdkantoor buiten de EU.

Een CASP die een handelsplatform exploiteert, kan de whitepaper-verplichting ook op zich nemen, hetzij op eigen initiatief, hetzij via een schriftelijke overeenkomst met het projectteam. Dat is geen maas in de wet of een administratief gemak.
Wanneer een CASP een aanvraag indient, neemt deze de wettelijke verantwoordelijkheid op zich voor de juistheid en volledigheid van de openbaarmaking. Als de whitepaper misleidende informatie bevat of niet voldoet aan de regelgevingsnormen, ligt de aansprakelijkheid bij degene die deze heeft ingediend.

De persoon die de whitepaper ondertekent, kan die aansprakelijkheid niet delegeren aan een softwareleverancier, een technische integrator of een advocatenkantoor. Juridische toetsing van de inhoud en technische validiteit zijn twee afzonderlijke nalevingsverplichtingen, en beide rusten bij de aanbieder. Dit is het punt dat de meeste projecten onderschatten.

Twee codes die moeten bestaan voordat de indiening kan beginnen

Twee verplichte identificatiecodes zijn voorwaarden voor elk compliant whitepaper. Beide zijn afgeleid van internationale normen die dateren van vóór MiCA. De verordening heeft ze niet gecreëerd, maar wel verplicht gesteld.

De eerste is de Legal Entity Identifier (LEI), een ISO 17442-code die wordt toegekend aan rechtspersonen en wordt bijgehouden in de Global LEI-database die wordt beheerd door GLEIF. Het mandaat voor het gebruik ervan strekt zich uit over meerdere regelgevingsnormen: terwijl artikel 14 van de RTS inzake het bijhouden van gegevens (Gedelegeerde Verordening (EU) 2025/1140 van de Commissie) LEI-vereisten oplegt aan CASP's voor hun klanten, schrijft artikel 3 van de RTS inzake de classificatie van whitepapers (Gedelegeerde Verordening (EU) 2025/421 van de Commissie) strikt voor dat alle opstellers van whitepapers hun eigen rechtspersoon moeten identificeren met een geldige LEI-code. Voor elke entiteit die er nog geen heeft, moet de LEI-aanvraagprocedure worden voltooid voordat met de opstelling van het whitepaper wordt begonnen.

De tweede is de Digital Token Identifier (DTI), een ISO 24165-code die het crypto-actief zelf identificeert en wordt bijgehouden in het DTIF-register. Artikel 15 van de RTS inzake het bijhouden van gegevens en artikel 3 van de RTS inzake de classificatie van whitepapers (Gedelegeerde Verordening (EU) 2025/421 van de Commissie) schrijven het gebruik ervan voor. Het cruciale punt voor elk project dat een nieuw token lanceert: als de DTI nog niet in het register bestaat, moet iemand de aanmaak ervan aanvragen voordat de whitepaper kan worden ingediend. Wanneer een CASP een aanvraag indient voor een activum zonder gecentraliseerde uitgever en zonder bestaande whitepaper, is het platform verantwoordelijk voor het opvragen of aanvragen van de DTI rechtstreeks bij de DTIF.

Bron: het DTIF-register voor crypto-activa

Een whitepaper dat geen geldige LEI en DTI bevat, faalt bij de geautomatiseerde validatie voordat een menselijke beoordelaar het te zien krijgt. Projecten die de indieningsfase bereiken zonder beide codes in handen te hebben, staan voor een volledige herstart.

De geautomatiseerde poort en wat dit juridisch betekent

Geen enkele medewerker van een nationale bevoegde autoriteit beoordeelt een whitepaper dat de geautomatiseerde controles niet doorstaat. De ESMA-taxonomie definieert 257 aanwezigheidscontroles (om te verifiëren dat verplichte velden aanwezig zijn) en 223 waardecontroles (om te verifiëren dat de inhoud van de velden geldig is). Een aanvraag die niet door een controle met de ernst "Fout" komt, is technisch ongeldig. Het document gaat niet verder.

De juridische implicatie van die architectuur is duidelijk: technische geldigheid en inhoudelijke nauwkeurigheid vallen beide onder de verantwoordelijkheid van de aanbieder. Een perfect opgestelde juridische openbaarmaking met de verkeerde structuur wordt afgewezen. Een structureel geldig bestand met misleidende inhoud wordt ook afgewezen; het wordt alleen in een andere fase afgewezen en met andere gevolgen.

Projecten die tokens aanbieden in meerdere EU-lidstaten hebben te maken met een extra laag. Elke taalversie van de whitepaper vereist een eigen, afzonderlijk gestructureerd bestand. Alle taalversies moeten intern consistent zijn en niet alleen vertaald, maar ook identiek georganiseerd op veldniveau. Een vertaling die de structuur van het origineel niet weerspiegelt, is technisch niet-conform, ongeacht de taalkundige nauwkeurigheid ervan.

Duurzaamheidsverslagen voegen een extra beperking toe. De taxonomie schrijft specifieke meeteenheden voor energieverbruik en CO2-uitstoot voor: respectievelijk kWh en tCO2. Dit zijn wettelijke openbaarmakingsvereisten, geen optionele milieurapportage. Indienen met andere eenheden of het weglaten van de velden leidt tot een validatiefout.

Het patroon in al deze vereisten is hetzelfde: de whitepaper is een wettelijke indiening met door machines afgedwongen normen. Projecten die dit benaderen als een oefening in het schrijven van documenten, in plaats van een nalevingsproces met gestructureerde voorwaarden en geautomatiseerde controle, zullen met die handhaving te maken krijgen voordat ze bij een menselijke toezichthouder terechtkomen.

Wat dit in de praktijk betekent

Het gangbare begrip van een crypto-whitepaper als een verhalende pitch (iets dat is geschreven om te overtuigen in plaats van om informatie te verstrekken) beschrijft een documenttype dat MiCA heeft vervangen door iets dat categorisch anders is.

De MiCA-whitepaper is een juridisch instrument met voorgeschreven inhoud, verplichte identificatiegegevens, een gestructureerd formaat dat is ontworpen voor geautomatiseerde grensoverschrijdende vergelijkbaarheid, en met naam genoemde persoonlijke aansprakelijkheid voor degene die het ondertekent. De toegangspoort tot de Europese cryptomarkt loopt hierdoorheen. Projecten die de indiening begrijpen voor wat het juridisch gezien is, in plaats van wat de term historisch suggereerde, zijn de projecten die niet worden teruggestuurd bij de geautomatiseerde controle.

Belangrijkste punten:

• De whitepaper is geen marketingdocument. MiCA heeft de term opnieuw gedefinieerd. Het dichtstbijzijnde equivalent in de traditionele financiële wereld is een effectenprospectus, en het moet met hetzelfde juridische gewicht worden behandeld.
• Drie activacategorieën, drie verschillende trajecten. OTHR, ART en EMT hebben elk verschillende vereisten voor het whitepaper en verschillende voorwaarden voor autorisatie. De kenmerken van het activum bepalen welke categorie van toepassing is; het project kiest dit niet zelf.
• De aansprakelijkheid ligt bij de indiener, maar de regels zijn afhankelijk van het activum. Voor de overgrote meerderheid van de tokens (OTHR's) ligt de wettelijke verplichting bij de aanbieder of de persoon die toelating tot de handel aanvraagt, niet noodzakelijkerwijs bij de oorspronkelijke maker van het token. Wanneer een CASP (zoals een exploitant van een handelsplatform) ermee instemt om namens een OTHR-project een whitepaper op te stellen en te publiceren, neemt deze aanzienlijke regelgevende taken op zich, maar neemt deze niet de volledige aansprakelijkheid op zich. Krachtens artikel 14, lid 3, van de MiCA blijft de oorspronkelijke persoon die toelating tot de handel aanvraagt wettelijk verantwoordelijk indien deze onvolledige, oneerlijke, onduidelijke of misleidende informatie aan de CASP verstrekt. U kunt het papierwerk uitbesteden, maar u kunt de aansprakelijkheid niet volledig uitbesteden.
• Voor Asset-Referenced Tokens (ART's) en E-Money Tokens (EMT's) rust de strikte civiele aansprakelijkheid voor de whitepaper niet uitsluitend bij de geautoriseerde emittent als rechtspersoon; deze strekt zich expliciet uit tot de leden van het bestuurs-, leidinggevend of toezichthoudend orgaan. Elke contractuele poging om deze aansprakelijkheid te beperken of uit te sluiten is juridisch nietig.
• LEI en DTI zijn vereisten. Beide identificatiecodes moeten aanwezig zijn voordat met de voorbereiding van de whitepaper wordt begonnen. Als er geen DTI voor het activum bestaat, moet deze bij het DTIF-register worden aangevraagd voordat er verder kan worden gegaan.
• Geautomatiseerde validatie is de eerste poortwachter. Er worden 257 bestaancontroles en 223 waardecontroles uitgevoerd voordat een mens het bestand beoordeelt. Een document dat niet voldoet aan een bewering op foutniveau, bereikt de toezichthouder niet.
• Meertalige indieningen brengen een verborgen technische verplichting met zich mee. Elke taalversie vereist een eigen, afzonderlijk gestructureerd bestand, dat identiek is georganiseerd als het origineel. Een vertaling die op veldniveau niet overeenkomt met de bronstructuur, voldoet niet aan de voorschriften.
• De nauwkeurigheid van de inhoud en de technische geldigheid zijn twee afzonderlijke verplichtingen. Juridische controle dekt de eerste. Technische structurering dekt de tweede. Beide zijn de verantwoordelijkheid van de aanbieder, en geen van beide vervangt de andere.

Dit artikel is gebaseerd op een onderzoek dat in april 2026 door LegalBison is uitgevoerd. De inhoud is uitsluitend bedoeld ter informatie en vormt geen juridisch advies.