MiCA spiegata: il tuo white paper sulle criptovalute non può limitarsi a un Gitbook o a un PDF

MiCA Decoded è una serie settimanale di 12 articoli per Bitcoin.com News, scritta a quattro mani dai cofondatori e amministratori delegati di LegalBison: Aaron Glauberman, Viktor Juskin e Sabir Alijev. LegalBison fornisce consulenza alle aziende del settore delle criptovalute e del FinTech in materia di licenze MiCA, richieste CASP e VASP e strutturazione normativa in Europa e oltre.

Ai sensi del MiCA, un white paper è uno strumento di informativa legale obbligatorio. La sua analogia più vicina nella finanza tradizionale è un prospetto informativo sui titoli, non un documento di marketing. Il regolamento prescrive chi deve redigerlo, in quale formato, quali identificatori deve contenere, a quale convalida automatizzata è soggetto e con quale responsabilità attribuita a una persona specifica nominata.

Un errore in uno qualsiasi di questi elementi significa che il documento non esiste agli occhi delle autorità di regolamentazione europee, indipendentemente da quanto sia ben scritto. Questa sesta puntata di MiCA Decoded spiega cosa ciò significhi effettivamente, passo dopo passo.

Il mito: un white paper MiCA è solo un GitBook o un PDF

Un white paper MiCA ha il peso di un documento normativo ufficiale. Il regolamento di esecuzione (UE) 2024/2984 della Commissione, che disciplina i moduli, i formati e i modelli per i white paper sulle cripto-attività, richiede che il documento sia redatto in un formato digitale strutturato, progettato in modo tale che l’ESMA e le autorità nazionali competenti di tutti gli Stati membri dell’UE possano eseguire un’analisi automatizzata identica su ogni presentazione, indipendentemente da chi l’abbia presentata o da dove.

Lo scopo giuridico di tale scelta progettuale è più importante delle specifiche tecniche. Il MiCA è un regolamento sul mercato unico e la comparabilità tra le presentazioni è uno strumento fondamentale per l'applicazione della normativa. Un white paper che non può essere letto dalla stessa macchina utilizzata per tutti gli altri white paper presentati in Europa non è conforme, indipendentemente dal suo contenuto. L'ESMA ha pubblicato la tassonomia richiesta (il quadro strutturato che definisce ciò che un white paper conforme deve contenere) il 5 agosto 2025. Le norme si applicano a partire dal 23 dicembre 2025. Gli obblighi di informativa variano a seconda del tipo di cripto-asset coinvolto. Il MiCA distingue tre categorie distinte, ciascuna con il proprio modello di white paper e i propri requisiti relativi ai campi:

La categoria determina non solo il contenuto del white paper, ma l'intero percorso legale per la sua presentazione. Un progetto non può scegliere quale categoria applicare in base alle proprie preferenze. Sono le caratteristiche dell'asset a determinarla, e da lì derivano gli obblighi di preparazione.

Chi ha l'obbligo legale – e la responsabilità

Per la stragrande maggioranza dei token presenti sul mercato (classificati come cripto-asset "Altri", o OTHR), l'obbligo non ricade automaticamente sull'entità che ha creato il token. Per questi asset, il MiCA attribuisce l'obbligo all'offerente o alla persona che richiede l'ammissione alla negoziazione, ruoli definiti che possono coincidere o meno con l'emittente originario.

Questa distinzione ha conseguenze concrete. Un progetto che rientra nella categoria OTHR, lanciato dalle Isole Vergini Britanniche, dalle Isole Cayman o da qualsiasi altra giurisdizione offshore, può essere l'offerente ai sensi del MiCA e assumersi direttamente l'obbligo relativo al white paper, senza alcun obbligo di trasferire la propria sede legale in Europa.

(Nota: questa flessibilità strutturale si applica rigorosamente ai token OTHR. Per i token riferiti ad attività e i token di moneta elettronica, l'obbligo legale e la responsabilità civile rigorosa per il white paper ricadono interamente sull'emittente autorizzato dell'UE e non possono essere delegati). Come abbiamo esaminato nella seconda puntata di questa serie, i registri dell'ESMA confermano che questa è già una pratica standard: la maggior parte delle registrazioni di token indipendenti proviene da entità con sede al di fuori dell'UE.

Un CASP che gestisce una piattaforma di trading può anche assumersi l'obbligo relativo al white paper, sia di propria iniziativa che tramite accordo scritto con il team di progetto. Non si tratta di una scappatoia o di una convenienza amministrativa. Quando un CASP effettua una registrazione, si assume la responsabilità legale dell'accuratezza e della completezza dell'informativa. Se il white paper contiene informazioni fuorvianti o non soddisfa gli standard normativi, la responsabilità ricade su chi lo ha presentato.

La persona che approva il white paper non può delegare tale responsabilità a un fornitore di software, a un integratore tecnico o a uno studio legale. La revisione legale dei contenuti e la validità tecnica sono due obblighi di conformità distinti, ed entrambi ricadono sull'offerente. Questo è il punto che la maggior parte dei progetti sottovaluta.

Due codici che devono essere presenti prima dell'inizio della presentazione

Due identificatori obbligatori sono prerequisiti per qualsiasi white paper conforme. Entrambi derivano da standard internazionali precedenti al MiCA. Il regolamento non li ha creati, ma li ha resi obbligatori.

Il primo è il Legal Entity Identifier (LEI), un codice ISO 17442 assegnato alle persone giuridiche e conservato nella banca dati globale LEI gestita dalla GLEIF. L'obbligo del suo utilizzo si estende a molteplici standard normativi: mentre l'articolo 14 delle RTS sulla tenuta dei registri (Regolamento delegato UE 2025/1140) impone i requisiti LEI ai CASP per i loro clienti, l'articolo 3 dell'RTS sulla classificazione dei white paper (Regolamento delegato UE 2025/421) impone rigorosamente che tutti i redattori di white paper identifichino la propria persona giuridica con un codice LEI valido. Per qualsiasi entità che non ne possieda già uno, il processo di richiesta del LEI deve essere completato prima dell'inizio della redazione del white paper.

Il secondo è il Digital Token Identifier (DTI), un codice ISO 24165 che identifica la cripto-attività stessa, conservato nel registro DTIF. L'articolo 15 dell'RTS sulla tenuta dei registri e l'articolo 3 dell'RTS sulla classificazione dei white paper (Regolamento delegato UE 2025/421 della Commissione) ne richiedono l'uso. Il punto cruciale per qualsiasi progetto che lanci un nuovo token: se il DTI non esiste ancora nel registro, qualcuno deve richiederne la creazione prima che il white paper possa essere presentato. Quando un CASP presenta una richiesta per un asset senza emittente centralizzato e senza un white paper esistente, la piattaforma è responsabile di recuperare o richiedere il DTI direttamente dal DTIF.

Fonte: il Registro DTIF per le cripto-attività Un white paper che non contiene un LEI e un DTI validi non supera la convalida automatica prima ancora che venga esaminato da un revisore umano. I progetti che raggiungono la fase di presentazione senza entrambi i codici a disposizione devono ricominciare da capo.

Il filtro automatico e cosa significa dal punto di vista legale

Nessun operatore umano presso un'autorità nazionale competente esamina un white paper che non supera i controlli automatici. La tassonomia ESMA definisce 257 controlli di esistenza (che verificano la presenza dei campi obbligatori) e 223 controlli di valore (che verificano la validità del contenuto dei campi). Una presentazione che non supera un controllo classificato con gravità "Errore" è tecnicamente non valida. Il documento non procede.

L'implicazione legale di tale architettura è diretta: la validità tecnica e l'accuratezza dei contenuti sono entrambe responsabilità dell'offerente. Una divulgazione legale redatta perfettamente ma con una struttura errata viene respinta. Anche un file strutturalmente valido con contenuti fuorvianti viene respinto; semplicemente fallisce in una fase diversa e con conseguenze diverse.

I progetti che offrono token in più Stati membri dell'UE devono affrontare un ulteriore livello di complessità. Ogni versione linguistica del white paper richiede un proprio file strutturato separatamente. Tutte le versioni linguistiche devono essere internamente coerenti e non solo tradotte, ma organizzate in modo identico a livello di campo. Una traduzione che non rispecchia la struttura dell'originale è tecnicamente non conforme, indipendentemente dalla sua accuratezza linguistica.

Le informazioni sulla sostenibilità aggiungono un ulteriore vincolo. La tassonomia impone unità di misura specifiche per il consumo energetico e le emissioni di CO2: rispettivamente kWh e tCO2. Si tratta di requisiti di divulgazione legali, non di rendicontazione ambientale facoltativa. La presentazione con unità diverse o l'omissione dei campi fa scattare un errore di convalida.

Il modello comune a tutti questi requisiti è lo stesso: il white paper è un documento legale soggetto a standard applicati automaticamente. I progetti che lo affrontano come un esercizio di scrittura di documenti, piuttosto che come un processo di conformità con prerequisiti strutturati e controlli automatizzati, si scontreranno con tale applicazione prima di arrivare a un regolatore umano.

Cosa significa questo nella pratica

La concezione popolare del white paper sulle criptovalute come presentazione narrativa (qualcosa scritto per persuadere piuttosto che per divulgare) descrive un tipo di documento che il MiCA ha sostituito con qualcosa di categoricamente diverso.

Il white paper MiCA è uno strumento legale con contenuti prescritti, identificatori obbligatori, un formato strutturato progettato per la comparabilità transfrontaliera automatizzata e una responsabilità personale nominativa attribuita a chiunque lo approvi. La porta d'ingresso al mercato europeo delle criptovalute passa attraverso di esso. I progetti che comprendono il deposito per quello che è legalmente, piuttosto che per ciò che il termine suggeriva storicamente, sono quelli che non vengono respinti al controllo automatizzato.

Punti chiave:

• Il white paper non è un documento di marketing. Il MiCA ha ridefinito il termine. L'equivalente più vicino nella finanza tradizionale è un prospetto informativo sui titoli, e dovrebbe essere trattato con lo stesso peso giuridico.
• Tre categorie di asset, tre percorsi diversi. OTHR, ART ed EMT comportano ciascuna requisiti distinti per il white paper e diversi prerequisiti di autorizzazione. Sono le caratteristiche dell'asset a determinare quale categoria si applica, non il progetto.
• La responsabilità ricade su chi presenta la domanda, ma le regole dipendono dall'asset. Per la stragrande maggioranza dei token (OTHR), l'obbligo legale spetta all'offerente o alla persona che richiede l'ammissione alla negoziazione, non necessariamente al creatore originale del token. Quando un CASP (come un operatore di piattaforma di trading) accetta di preparare e pubblicare un white paper per conto di un progetto OTHR, si assume importanti obblighi normativi, ma non si assume pienamente la responsabilità. Ai sensi dell'articolo 14, paragrafo 3, del MiCA, la persona originaria che richiede l'ammissione alla negoziazione rimane legalmente responsabile se fornisce informazioni incomplete, inique, poco chiare o fuorvianti al CASP. È possibile esternalizzare le pratiche burocratiche, ma non è possibile esternalizzare interamente la responsabilità.
• Per gli Asset-Referenced Tokens (ART) e gli E-Money Tokens (EMT), la responsabilità civile per il white paper non ricade esclusivamente sull'emittente autorizzato in quanto entità societaria; essa si estende esplicitamente ai membri del suo organo amministrativo, di gestione o di vigilanza. Qualsiasi tentativo contrattuale di limitare o escludere tale responsabilità è giuridicamente nullo.
• LEI e DTI sono prerequisiti. Entrambi gli identificatori devono essere disponibili prima che inizi la preparazione del white paper. Se non esiste un DTI per l'asset, deve essere richiesto al registro DTIF prima di procedere con qualsiasi altra cosa.
• La convalida automatizzata è il primo filtro. Vengono eseguiti 257 controlli di esistenza e 223 controlli di valore prima che qualsiasi persona esamini il file. Un documento che non supera un'asserzione a livello di errore non raggiunge l'autorità di regolamentazione.
• I depositi multilingue comportano un obbligo tecnico nascosto. Ogni versione linguistica richiede un proprio file strutturato separatamente, organizzato in modo identico all'originale. Una traduzione che non corrisponde alla struttura di origine a livello di campo non è conforme.
• L'accuratezza dei contenuti e la validità tecnica sono due obblighi distinti. La revisione legale copre il primo. La strutturazione tecnica copre il secondo. Entrambi ricadono sull'offerente e nessuno dei due sostituisce l'altro.

Questo articolo si basa su uno studio condotto da LegalBison nell'aprile 2026. Il contenuto è solo a scopo informativo e non costituisce una consulenza legale.