MiCA pe înțelesul tuturor: Documentul tehnic privind criptomonedele nu poate fi doar un Gitbook sau un PDF

MiCA Decoded este o serie săptămânală de 12 articole pentru Bitcoin.com News, scrisă în colaborare de cofondatorii și directorii generali ai LegalBison: Aaron Glauberman, Viktor Juskin și Sabir Alijev. LegalBison oferă consultanță companiilor din domeniul criptomonedelor și FinTech cu privire la licențierea MiCA, cererile CASP și VASP, precum și structurarea reglementărilor în Europa și nu numai.

În conformitate cu MiCA, un document de referință este un instrument obligatoriu de divulgare legală. Cea mai apropiată analogie a acestuia în finanțele tradiționale este un prospect de valori mobiliare, nu un document de marketing. Regulamentul prescrie cine trebuie să îl pregătească, în ce format, conținând ce identificatori, supus ce validare automată și cu răspunderea atribuită unei persoane specifice numite.

Dacă vreunul dintre aceste elemente este greșit, documentul nu există în ochii autorităților de reglementare europene, indiferent cât de bine este redactat.

Această a șasea parte a seriei MiCA Decoded explică, pas cu pas, ce înseamnă acest lucru.

Mitul: un document de prezentare MiCA este doar un GitBook sau un PDF

Un document de referință MiCA are greutatea unui document oficial de depunere.

Regulamentul de punere în aplicare (UE) 2024/2984 al Comisiei, care reglementează formularele, formatele și șabloanele pentru documentele de referință privind cripto-activele, impune ca documentul să fie întocmit într-un format digital structurat, conceput astfel încât ESMA și autoritățile naționale competente din toate statele membre ale UE să poată efectua analize automate identice asupra fiecărei depuneri, indiferent de cine a depus-o sau unde.

Scopul juridic al acestei alegeri de proiectare contează mai mult decât detaliile tehnice. MiCA este un regulament privind piața unică, iar comparabilitatea între documentele depuse este un instrument esențial de aplicare a legii.

Un document tehnic care nu poate fi citit de același sistem ca orice alt document tehnic depus în Europa nu este conform, indiferent de conținutul său. ESMA a publicat taxonomia necesară (cadrul structurat care definește ce trebuie să conțină un document tehnic conform) la 5 august 2025. Normele se aplică începând cu 23 decembrie 2025.

Obligațiile de divulgare variază în funcție de tipul de criptoactiv implicat. MiCA distinge trei categorii distincte, fiecare cu propriul șablon de document tehnic și cerințe privind câmpurile:

Categoria determină nu doar conținutul cărții albe, ci și întregul parcurs juridic necesar pentru depunerea acesteia. Un proiect nu poate alege categoria care se aplică în funcție de preferințe. Caracteristicile activului o determină, iar obligațiile de pregătire decurg de aici.

Cine poartă obligația legală – și răspunderea

Pentru marea majoritate a token-urilor de pe piață (clasificate ca „alte” cripto-active sau OTHR), obligația nu revine automat entității care a creat token-ul. Pentru aceste active, MiCA impune obligația ofertantului sau persoanei care solicită admiterea la tranzacționare, roluri definite care pot sau nu să coincidă cu emitentul inițial.

Această distincție are consecințe reale. Un proiect care se încadrează în categoria OTHR, lansat din Insulele Virgine Britanice, Insulele Cayman sau orice altă jurisdicție offshore, poate fi ofertantul în temeiul MiCA și poate avea direct obligația de a prezenta cartea albă, fără a fi necesar să-și mute sediul social în Europa.

(Notă: Această flexibilitate structurală se aplică strict token-urilor OTHR. Pentru token-urile referențiate la active și token-urile de monedă electronică, obligația legală și răspunderea civilă strictă pentru cartea albă revin în întregime emitentului autorizat din UE și nu pot fi delegate).

Așa cum am examinat în a doua parte a acestei serii, registrele ESMA confirmă că aceasta este deja o practică standard: majoritatea înregistrărilor independente de token-uri provin de la entități cu sediul în afara UE.

Un CASP care operează o platformă de tranzacționare poate, de asemenea, să își asume obligația privind cartea albă, fie din proprie inițiativă, fie printr-un acord scris cu echipa de proiect. Aceasta nu este o lacună sau o facilitate administrativă.
Când un CASP depune o cerere, acesta își asumă responsabilitatea legală pentru acuratețea și exhaustivitatea informațiilor divulgate. Dacă cartea albă conține informații înșelătoare sau nu respectă standardele de reglementare, răspunderea revine celui care a depus-o.

Persoana care semnează cartea albă nu poate delega această responsabilitate unui furnizor de software, unui integrator tehnic sau unei firme de avocatură. Revizuirea juridică a conținutului și validitatea tehnică sunt două obligații de conformitate separate, iar ambele revin ofertantului. Acesta este aspectul pe care majoritatea proiectelor îl subestimează.

Două coduri care trebuie să existe înainte de începerea depunerii

Două identificatori obligatorii sunt condiții prealabile pentru orice carte albă conformă. Ambii sunt preluați din standarde internaționale anterioare MiCA. Regulamentul nu le-a creat, ci le-a făcut obligatorii.

Primul este Identificatorul Entității Juridice (LEI), un cod ISO 17442 atribuit entităților juridice și menținut în baza de date globală LEI administrată de GLEIF. Obligația de utilizare a acestuia se întinde pe mai multe standarde de reglementare: în timp ce articolul 14 din RTS privind păstrarea evidențelor (Regulamentul delegat al Comisiei UE 2025/1140) impune cerințele LEI asupra CASP-urilor pentru clienții lor, articolul 3 din RTS privind clasificarea cărților albe (Regulamentul delegat al Comisiei UE 2025/421) impune strict ca toți întocmitorii de cărți albe să își identifice propria entitate juridică cu un cod LEI valabil. Pentru orice entitate care nu deține încă unul, procesul de solicitare a LEI trebuie finalizat înainte de începerea întocmirii cărții albe.

Al doilea este Identificatorul digital al tokenului (DTI), un cod ISO 24165 care identifică cripto-activul în sine, menținut în registrul DTIF. Articolul 15 din RTS privind păstrarea evidențelor și articolul 3 din RTS privind clasificarea cărților albe (Regulamentul delegat al Comisiei UE 2025/421) impun utilizarea acestuia. Punctul esențial pentru orice proiect care lansează un nou token: dacă DTI nu există încă în registru, cineva trebuie să solicite crearea acestuia înainte ca documentul tehnic să poată fi depus. În cazul în care un CASP depune o cerere pentru un activ fără emitent centralizat și fără document tehnic existent, platforma este responsabilă pentru recuperarea sau solicitarea DTI direct de la DTIF.

Sursă: Registrul DTIF pentru cripto-active

Un document tehnic care nu conține un LEI și un DTI valabile nu trece de validarea automată înainte ca vreun evaluator uman să îl vadă. Proiectele care ajung în etapa de depunere fără ambele coduri la îndemână se confruntă cu o reluare completă.

Poarta automată și semnificația sa din punct de vedere juridic

Niciun angajat al unei autorități naționale competente nu examinează un document tehnic care nu trece verificările automate. Taxonomia ESMA definește 257 de verificări de existență (verificarea prezenței câmpurilor obligatorii) și 223 de verificări de valoare (verificarea validității conținutului câmpurilor). O depunere care nu trece o verificare cu gradul de severitate „Eroare” este tehnic invalidă. Documentul nu este procesat.

Implicația juridică a acestei arhitecturi este directă: validitatea tehnică și acuratețea conținutului sunt în egală măsură responsabilitatea ofertantului. O dezvăluire juridică redactată perfect, dar cu o structură greșită, eșuează. Un fișier valid din punct de vedere structural, dar cu conținut înșelător, eșuează de asemenea; pur și simplu eșuează într-o etapă diferită și cu consecințe diferite.

Proiectele care oferă tokenuri în mai multe state membre ale UE se confruntă cu un nivel suplimentar de complexitate. Fiecare versiune lingvistică a cărții albe necesită un fișier structurat separat. Toate versiunile lingvistice trebuie să fie consecvente intern și nu doar traduse, ci organizate identic la nivel de câmp. O traducere care nu reflectă structura originalului este, din punct de vedere tehnic, neconformă, indiferent de acuratețea sa lingvistică.

Dezvăluirile privind sustenabilitatea adaugă o constrângere suplimentară. Taxonomia impune unități de măsură specifice pentru consumul de energie și emisiile de CO2: kWh și, respectiv, tCO2. Acestea sunt cerințe legale de dezvăluire, nu raportări de mediu opționale. Depunerea cu unități diferite sau omiterea câmpurilor declanșează o eroare de validare.

Modelul pentru toate aceste cerințe este același: cartea albă este o depunere legală cu standarde aplicate automat. Proiectele care o abordează ca pe un exercițiu de redactare a documentelor, mai degrabă decât ca pe un proces de conformitate cu cerințe preliminare structurate și control automat, se vor confrunta cu această aplicare înainte de a ajunge la un regulator uman.

Ce înseamnă acest lucru în practică

Înțelegerea populară a unui document tehnic privind criptomonedele ca prezentare narativă (ceva scris pentru a convinge, mai degrabă decât pentru a dezvălui) descrie un tip de document pe care MiCA l-a înlocuit cu ceva categoric diferit.

Cartea albă MiCA este un instrument juridic cu conținut prescris, identificatori obligatorii, un format structurat conceput pentru comparabilitate transfrontalieră automatizată și răspundere personală numită, atribuită oricui o semnează. Poarta de intrare pe piața europeană a criptomonedelor trece prin ea. Proiectele care înțeleg depunerea pentru ceea ce este din punct de vedere juridic, mai degrabă decât pentru ceea ce sugera termenul din punct de vedere istoric, sunt cele care nu sunt respinse la verificarea automatizată.

Concluzii cheie:

• Cartea albă nu este un document de marketing. MiCA a redefinit termenul. Cel mai apropiat echivalent în finanțele tradiționale este un prospect de valori mobiliare și ar trebui tratat cu aceeași pondere juridică.
• Trei categorii de active, trei căi diferite. OTHR, ART și EMT au fiecare cerințe distincte privind cartea albă și condiții preliminare de autorizare diferite. Caracteristicile activului determină categoria care se aplică, proiectul nu o alege.
• Răspunderea revine celui care depune documentul, dar regulile depind de activ. Pentru marea majoritate a token-urilor (OTHR), obligația legală revine ofertantului sau persoanei care solicită admiterea la tranzacționare, nu neapărat creatorului original al token-ului. Atunci când un CASP (cum ar fi un operator de platformă de tranzacționare) acceptă să pregătească și să publice un document tehnic în numele unui proiect OTHR, acesta își asumă obligații de reglementare semnificative, dar nu își asumă în totalitate răspunderea. În conformitate cu articolul 14 alineatul (3) din MiCA, persoana inițială care solicită admiterea la tranzacționare rămâne responsabilă din punct de vedere legal dacă furnizează informații incomplete, incorecte, neclare sau înșelătoare către CASP. Puteți externaliza documentația, dar nu puteți externaliza în totalitate răspunderea.
• În cazul token-urilor referențiate la active (ART) și al token-urilor de monedă electronică (EMT), răspunderea civilă strictă pentru cartea albă nu revine exclusiv emitentului autorizat ca entitate corporativă; aceasta se extinde în mod explicit la membrii organismului său administrativ, de conducere sau de supraveghere. Orice încercare contractuală de a limita sau exclude această răspundere este nulă din punct de vedere juridic.
• LEI și DTI sunt condiții prealabile. Ambele identificatori trebuie să fie în vigoare înainte de începerea pregătirii cărții albe. Dacă nu există un DTI pentru activ, acesta trebuie solicitat de la registrul DTIF înainte de a se trece la orice alt pas.
• Validarea automată este primul filtru. Se efectuează 257 de verificări de existență și 223 de verificări de valoare înainte ca fișierul să fie revizuit de către o persoană. Un document care nu trece de o verificare la nivel de eroare nu ajunge la autoritatea de reglementare.
• Depunerile multilingve implică o obligație tehnică ascunsă. Fiecare versiune lingvistică necesită un fișier structurat separat, organizat identic cu originalul. O traducere care nu corespunde structurii sursei la nivel de câmp este neconformă.
• Acuratețea conținutului și validitatea tehnică sunt două obligații separate. Revizuirea juridică acoperă prima. Structurarea tehnică acoperă a doua. Ambele revin ofertantului și niciuna nu o înlocuiește pe cealaltă.

Acest articol se bazează pe un studiu realizat de LegalBison în aprilie 2026. Conținutul are doar scop informativ și nu constituie consultanță juridică.