A MiCA értelmezve: A kriptovaluta-fehérkönyved nem lehet csupán egy Gitbook vagy PDF

A MiCA Decoded egy 12 részes heti sorozat a Bitcoin.com News számára, amelynek társszerzői a LegalBison társalapítói és ügyvezető igazgatói: Aaron Glauberman, Viktor Juskin és Sabir Alijev. A LegalBison kriptovaluta- és fintech-vállalatoknak nyújt tanácsadást a MiCA-engedélyezés, a CASP- és VASP-kérelmek, valamint a szabályozási struktúrák terén Európában és azon túl.

A MiCA szerint a fehér könyv kötelező jogi közzétételi eszköz. A hagyományos pénzügyi világban a legközelebbi analógiája az értékpapír-prospektus, nem pedig egy marketingdokumentum. A rendelet előírja, kinek kell elkészítenie, milyen formátumban, milyen azonosítókat kell tartalmaznia, milyen automatizált érvényesítésnek kell alávetni, és hogy a felelősség egy konkrét, megnevezett személyt terhel.

Ha ezek közül bármelyik elem nem megfelelő, az azt jelenti, hogy a dokumentum az európai szabályozó hatóságok szemében nem létezik, függetlenül attól, hogy mennyire jól van megírva.

A MiCA Decoded sorozat hatodik része apránként elmagyarázza, hogy ez valójában mit jelent.

A mítosz: A MiCA fehér könyv csupán egy GitBook vagy egy PDF

A MiCA fehér könyv hivatalos szabályozási bejelentésnek minősül.

A kriptopénz-eszközök fehér könyveinek formáit, formátumait és sablonjait szabályozó (EU) 2024/2984 bizottsági végrehajtási rendelet előírja, hogy a dokumentumot olyan strukturált digitális formátumban kell elkészíteni, amelynek kialakítása lehetővé teszi, hogy az ESMA és az összes EU-tagállam nemzeti illetékes hatósága azonos automatizált elemzést futtasson minden benyújtott dokumentumon, függetlenül attól, hogy ki és hol nyújtotta be.

Ennek a tervezési döntésnek a jogi célja fontosabb, mint a technikai részletek. A MiCA az egységes piacra vonatkozó szabályozás, és a beadványok közötti összehasonlíthatóság a végrehajtás egyik alapvető eszköze.

Az a fehér könyv, amelyet nem tud ugyanaz a gép olvasni, mint az Európában benyújtott összes többi fehér könyvet, nem felel meg a követelményeknek, függetlenül attól, hogy mi áll a tartalmában. Az ESMA 2025. augusztus 5-én tette közzé a szükséges taxonómiát (azt a strukturált keretrendszert, amely meghatározza, mit kell tartalmaznia egy szabályoknak megfelelő fehér könyvnek). A szabályok 2025. december 23-tól lépnek hatályba.

A közzétételi kötelezettségek az érintett kriptopénz-eszköz típusától függően változnak. A MiCA három különálló kategóriát különböztet meg, amelyek mindegyike saját fehér könyv-sablonnal és mezőkövetelményekkel rendelkezik:

A kategória nem csupán a fehér könyv tartalmát határozza meg, hanem a benyújtáshoz vezető teljes jogi útvonalat is. A projekt nem választhatja meg saját preferenciája alapján, hogy melyik kategória vonatkozik rá. Ezt az eszköz jellemzői határozzák meg, és ebből következnek az előkészítési kötelezettségek.

Ki viseli a jogi kötelezettséget – és a felelősséget

A piacon található tokenek túlnyomó többségének esetében (amelyeket „egyéb” kriptopénz-eszközöknek, vagy OTHR-nek minősítenek) a kötelezettség nem automatikusan a tokent létrehozó szervezetre hárul. Ezeknél az eszközöknél a MiCA a kötelezettséget az ajánlattevőre vagy a kereskedésbe való felvételét kérő személyre ruházza, amelyek meghatározott szerepkörök, amelyek egybeeshetnek az eredeti kibocsátóval, de nem feltétlenül.

Ennek a megkülönböztetésnek valós következményei vannak. Egy OTHR kategóriába tartozó projekt, amelyet a Brit Virgin-szigetekről, a Kajmán-szigetekről vagy bármely más offshore joghatóságból indítottak, a MiCA értelmében ajánlattevő lehet, és közvetlenül viselheti a fehér könyvre vonatkozó kötelezettséget, anélkül, hogy jogi székhelyét Európába kellene áthelyeznie.

(Megjegyzés: Ez a strukturális rugalmasság szigorúan az OTHR tokenekre vonatkozik. Az eszközhivatkozású tokenek és az e-pénz tokenek esetében a fehér könyvre vonatkozó jogi kötelezettség és szigorú polgári jogi felelősség teljes mértékben az engedélyezett uniós kibocsátót terheli, és nem ruházható át).

Ahogyan a sorozat második részében megvizsgáltuk, az ESMA nyilvántartásai megerősítik, hogy ez már bevett gyakorlat: a független token-bejelentések többsége olyan szervezetektől származik, amelyek székhelye az EU-n kívül található.

A kereskedési platformot üzemeltető CASP is vállalhatja a fehér könyvre vonatkozó kötelezettséget, akár saját kezdeményezésére, akár a projektcsapattal kötött írásbeli megállapodás alapján. Ez nem joghézag vagy adminisztratív kényelmi megoldás.
Amikor egy CASP nyújt be bejelentést, jogi felelősséget vállal a közzétett információk pontosságáért és teljességéért. Ha a fehér könyv félrevezető információkat tartalmaz vagy nem felel meg a szabályozási előírásoknak, a felelősség azt terheli, aki benyújtotta.

A fehér könyvet aláíró személy nem ruházhatja át ezt a kockázatot egy szoftvergyártóra, egy technikai integrátorra vagy egy ügyvédi irodára. A tartalom jogi ellenőrzése és a technikai érvényesség két különálló megfelelési kötelezettség, és mindkettő az ajánlattevőt terheli. Ezt a szempontot a legtöbb projekt alábecsüli.

Két kód, amelynek meg kell lennie a benyújtás megkezdése előtt

Két kötelező azonosító előfeltétele minden szabályoknak megfelelő fehér könyvnek. Mindkettő a MiCA-t megelőző nemzetközi szabványokból származik. A rendelet nem hozta létre őket, hanem kötelezővé tette őket.

Az első a jogi személy azonosítója (LEI), egy ISO 17442 kód, amelyet jogi személyeknek rendelnek hozzá, és amelyet a GLEIF által kezelt globális LEI-adatbázisban tárolnak. Használatának kötelezettsége több szabályozási szabványra is kiterjed: míg a nyilvántartási RTS (EU 2025/1140 bizottsági felhatalmazáson alapuló rendelet) 14. cikke a CASP-ekre vonatkozóan írja elő az ügyfeleikre vonatkozó LEI-követelményeket, a fehér könyv osztályozására vonatkozó RTS (EU 2025/421 felhatalmazáson alapuló bizottsági rendelet) 3. cikke szigorúan előírja, hogy minden fehér könyv készítőjének érvényes LEI-kóddal kell azonosítania saját jogi személyét. Azoknál a szervezeteknél, amelyek még nem rendelkeznek ilyennel, a fehér könyv elkészítésének megkezdése előtt le kell zárni az LEI-kérelem benyújtásának folyamatát.

A második a digitális token azonosító (DTI), egy ISO 24165 kód, amely magát a kriptopénzt azonosítja, és amelyet a DTIF-nyilvántartásban tartanak karban. A nyilvántartási RTS 15. cikke és a fehér könyv osztályozási RTS (Európai Bizottság 2025/421 felhatalmazáson alapuló rendelete) 3. cikke előírja annak használatát. Bármely új tokent indító projekt esetében a lényeg: ha a DTI még nem szerepel a nyilvántartásban, valakinek kérnie kell annak létrehozását, mielőtt a fehér könyv benyújtható lenne. Ha egy CASP olyan eszközt nyújt be, amelynek nincs központi kibocsátója és nincs meglévő fehér könyve, a platform felelős a DTI közvetlen lekéréséért vagy igényléséért a DTIF-től.

Forrás: a kriptopénzeszközök DTIF-nyilvántartása

Az a fehér könyv, amely nem tartalmaz érvényes LEI-t és DTI-t, már az automatikus érvényesítés során elbukik, mielőtt bármely emberi ellenőr megvizsgálná. Azok a projektek, amelyek a benyújtási szakaszba jutnak anélkül, hogy mindkét kód a rendelkezésükre állna, teljes újrakezdéssel szembesülnek.

Az automatizált kapu és jogi jelentősége

Az automatizált ellenőrzésen megbukó fehér könyvet egyetlen nemzeti illetékes hatóság munkatársa sem vizsgálja át. Az ESMA taxonómiája 257 létezés-ellenőrzést (a kötelező mezők jelenlétének ellenőrzése) és 223 érték-ellenőrzést (a mezők tartalmának érvényességének ellenőrzése) határoz meg. Az a bejelentés, amely „Hiba” súlyosságú ellenőrzésen bukik meg, technikailag érvénytelen. A dokumentum nem jut tovább.

Ennek az architektúrának a jogi következménye egyértelmű: a technikai érvényesség és a tartalom pontossága egyaránt az ajánlattevő felelőssége. A tökéletesen megfogalmazott jogi közzététel is elbukik, ha a szerkezete hibás. A szerkezetileg érvényes, de félrevezető tartalmú fájl szintén elbukik; egyszerűen csak egy másik szakaszban bukik el, és más következményekkel jár.

A több EU-tagállamban tokeneket kínáló projekteknek további kihívással kell szembenézniük. A fehér könyv minden nyelvi változatához külön, saját szerkezetű fájl szükséges. Minden nyelvi változatnak belsőleg konzisztensnek kell lennie, és nem csupán lefordítottnak, hanem a mezők szintjén is azonosan szervezettnek. Az eredeti szerkezetét nem tükröző fordítás technikailag nem felel meg a követelményeknek, függetlenül a nyelvi pontosságtól.

A fenntarthatósági közzétételek további korlátozást jelentenek. A taxonómia előírja az energiafogyasztás és a CO2-kibocsátás konkrét mértékegységeit: kWh, illetve tCO2. Ezek jogi közzétételi követelmények, nem pedig opcionális környezeti jelentések. Ha eltérő mértékegységekkel nyújtják be a dokumentumot, vagy kihagyják a mezőket, az érvényesítési hibát eredményez.

Mindezen követelmények esetében a minta ugyanaz: a fehér könyv egy jogi bejelentés, amelyre gépi ellenőrzés vonatkozik. Azok a projektek, amelyek ezt dokumentumírási feladatként kezelik, ahelyett, hogy strukturált előfeltételekkel és automatizált ellenőrzéssel járó megfelelési folyamatként tekintenének rá, már az emberi szabályozó hatósághoz való eljutás előtt szembesülnek majd ezzel az ellenőrzéssel.

Mit jelent ez a gyakorlatban

A kriptovaluta fehér könyvről kialakult általános felfogás, miszerint az egy narratív bemutató (valami, amit meggyőzésre írnak, nem pedig közzétételre), egy olyan dokumentumtípust ír le, amelyet a MiCA kategorikusan eltérővel váltott fel.

A MiCA fehér könyv egy jogi eszköz, előírt tartalommal, kötelező azonosítókkal, automatizált, határokon átnyúló összehasonlíthatóságra tervezett strukturált formátummal, valamint a dokumentumot aláíró személy nevéhez fűződő személyes felelősséggel. Az európai kriptopiacra való belépés kapuja ezen keresztül vezet. Azok a projektek, amelyek a beadványt jogi szempontból értelmezik, ahelyett, hogy a kifejezés történelmi jelentésére támaszkodnának, azok, amelyek nem buknak el az automatizált ellenőrzésen.

Főbb tanulságok:

• A fehér könyv nem marketingdokumentum. A MiCA újradefiniálta a kifejezést. A hagyományos pénzügyekben a legközelebbi megfelelője az értékpapír-prospektus, és ugyanolyan jogi súllyal kell kezelni.
• Három eszközkategória, három különböző út. Az OTHR, az ART és az EMT mindegyike eltérő fehér könyv követelményekkel és különböző engedélyezési előfeltételekkel jár. Az eszköz jellemzői határozzák meg, melyik kategória vonatkozik rá, a projekt nem választhat.
• A felelősség a bejelentőt terheli, de a szabályok az eszköztől függenek. A tokenek (OTHR-ek) túlnyomó többségénél a jogi kötelezettség az ajánlattevőt vagy a kereskedésbe való felvételét kérő személyt terheli, nem feltétlenül a token eredeti alkotóját. Amikor egy CASP (például egy kereskedési platform üzemeltetője) vállalja, hogy egy OTHR-projekt nevében fehér könyvet készít és tesz közzé, jelentős szabályozási feladatokat vállal magára, de a felelősséget nem vállalja teljes mértékben. A MiCA 14. cikkének (3) bekezdése értelmében az eredeti, kereskedésbe való felvételét kérő személy marad jogilag felelős, ha hiányos, tisztességtelen, nem egyértelmű vagy félrevezető információkat szolgáltat a CASP-nak. A papírmunkát kiszervezheti, de a felelősséget nem adhatja át teljes mértékben.
• Az eszközhivatkozású tokenek (ART-k) és az e-pénz tokenek (EMT-k) esetében a fehér könyvvel kapcsolatos szigorú polgári jogi felelősség nem kizárólag a felhatalmazott kibocsátót, mint jogi személyt terheli; kifejezetten kiterjed az adminisztratív, irányító vagy felügyeleti testület tagjaira is. Bármely szerződéses kísérlet e felelősség korlátozására vagy kizárására jogilag érvénytelen.
• A LEI és a DTI előfeltételek. Mindkét azonosítónak rendelkezésre kell állnia, mielőtt megkezdődne a fehér könyv elkészítése. Ha az eszközhöz nem létezik DTI, azt a DTIF-nyilvántartásból kell igényelni, mielőtt bármi más továbbhaladna.
• Az automatizált érvényesítés az első kapuőr. 257 létezés-ellenőrzés és 223 érték-ellenőrzés fut le, mielőtt bárki is átnézné a fájlt. Az a dokumentum, amelyik nem felel meg a hiba-szintű érvényesítésnek, nem jut el a szabályozóhoz.
• A többnyelvű bejelentések rejtett technikai kötelezettséget hordoznak magukban. Minden nyelvi változatnak saját, külön strukturált fájlra van szüksége, amelynek felépítése megegyezik az eredetivel. Az a fordítás, amely mezőszinten nem egyezik meg a forrás szerkezetével, nem felel meg a követelményeknek.
• A tartalom pontossága és a technikai érvényesség két különálló kötelezettség. Az elsőt a jogi ellenőrzés fedi le. A másodikat a technikai felépítés. Mindkettő az ajánlattevő felelőssége, és egyik sem helyettesíti a másikat.

Ez a cikk a LegalBison által 2026 áprilisában végzett tanulmányon alapul. A tartalom kizárólag tájékoztató jellegű, és nem minősül jogi tanácsadásnak.