Reporting crypto CARF

CARF è la risposta globale dell'OCSE alla trasparenza fiscale in ambito crypto — uno standard mondiale per la segnalazione e lo scambio automatico di dati crypto tra le autorità fiscali. Questa pagina spiega cos'è, chi deve segnalare, la tempistica e come CryptaCount produce i report.

Informazioni generali, non consulenza legale o fiscale. Verifica i tuoi obblighi specifici con il framework e un consulente qualificato.

Cos'è CARF

Il Crypto-Asset Reporting Framework (CARF), pubblicato dall'OCSE nel 2023, è uno standard globale che obbliga i Reporting Crypto-Asset Service Providers (RCASP) a identificare i propri utenti, determinarne la residenza fiscale e segnalare le loro transazioni crypto — che le autorità fiscali poi scambiano automaticamente tra loro. È modellato sul Common Reporting Standard (CRS) utilizzato per i conti finanziari tradizionali, esteso alle cripto-attività. Nell'UE, CARF è implementato come DAC8. DAC8 →

La tempistica

CARF viene adottato in tutto il mondo: un gran numero di giurisdizioni — la maggioranza dei membri del Global Forum dell'OCSE — si è impegnata a iniziare gli scambi, la maggior parte a partire dal 2027 (alcune nel 2028). In pratica, i fornitori raccolgono dati dall'inizio del relativo anno di segnalazione e presentano l'anno successivo, con i primi scambi internazionali che iniziano intorno al 2027.

Chi rientra nell'ambito

Gli RCASP sono definiti in modo ampio — exchange, broker, alcuni fornitori di wallet e altri intermediari che facilitano transazioni crypto per i clienti. CARF richiede anche la segnalazione di certi trasferimenti tra wallet (inclusi i wallet self-hosted), ampliando i dati catturati oltre i semplici scambi. Se gestisci una piattaforma, un fondo o un servizio che gestisce crypto per altri, valuta se sei un RCASP.

Cosa richiede

Due diligence e autocertificazione per stabilire l'identità e la residenza fiscale di ciascun utente, e segnalazione annuale dei dati sulle transazioni secondo lo schema XML prescritto dall'OCSE — che viene poi scambiato tra le giurisdizioni partecipanti.

Come CryptaCount aiuta con CARF

• Conserva le registrazioni a livello di transazione e i dati degli utenti richiesti dalla segnalazione
• Genera i report CARF nel formato richiesto per la presentazione
• Gestisce CARF e DAC8 insieme dove entrambi si applicano, da un unico processo integrato
• Mantiene una pista di controllo completa e verificabile dietro ogni cifra segnalata

Compliance e reporting → · Scopri il partitario →

Informazioni generali, non consulenza legale o fiscale. Verifica con il framework e un consulente qualificato.

Cosa CARF chiede a un'azienda soggetta all'obbligo di segnalazione, in termini semplici

Depurato degli acronimi, CARF è un regime di segnalazione delle informazioni: le aziende che rientrano nel suo ambito devono sapere chi sono i loro clienti, dove risiedono fiscalmente e quali attività crypto hanno transitato dalla loro piattaforma, per poi trasmettere all'autorità fiscale un riepilogo strutturato che questa condivide con le altre. Per un fornitore soggetto all'obbligo, l'obbligazione riguarda meno il proprio conto economico e più la capacità di rendere un resoconto accurato e attribuibile delle transazioni altrui transitate dalla piattaforma. Questa distinzione ha rilevanza operativa, perché le registrazioni che soddisfano il bilancio ai sensi di IFRS → o US GAAP → non sono automaticamente le registrazioni che soddisfano un framework di reporting — i due sistemi pongono domande diverse agli stessi dati sottostanti.

Chi porta effettivamente l'obbligo è una questione di sostanza, non di autodefinizione. Un'azienda che detiene semplicemente crypto nella propria tesoreria si trova in una posizione molto diversa da chi facilita transazioni per i clienti, e il framework è deliberatamente costruito per cogliere intermediari di molte forme. Se la tua organizzazione gestisce un exchange, un servizio di brokeraggio, una custodia o un wallet, o qualsiasi piattaforma attraverso cui i clienti effettuano transazioni, il punto di partenza prudente è considerarsi potenzialmente in ambito e verificare la propria posizione precisa rispetto al testo ufficiale e al proprio consulente, piuttosto che presumere che le norme siano rivolte ad altri.

Come il reporting CARF raggiunge i tuoi libri contabili

Sebbene CARF sia un framework di reporting e non uno standard contabile, la sua preparazione fa leva sui libri contabili. I saldi e i movimenti dei clienti che si segnalano devono riconciliarsi con le stesse registrazioni che producono il bilancio; se i due divergono, occorre spiegare perché le cifre segnalate e quelle contabili raccontano storie diverse degli stessi wallet. In pratica, il partitario crypto → che registra ogni movimento del cliente diventa l'unica fonte da cui il report viene costruito, in modo che un numero su una dichiarazione regolamentare possa essere ricondotto alla stessa scrittura che ha alimentato la bilancia di verifica.

Questo cambia anche ciò che si acquisisce nel momento in cui una transazione ha luogo. Una voce contabile necessita solo di dati sufficienti per valorizzare e classificare il movimento; un registro segnalabile richiede in aggiunta l'attribuzione alla controparte — quale cliente, in quale giurisdizione, che tipo di attività — conservata accanto ad essa. Costruire tale attribuzione al momento dell'acquisizione, piuttosto che ricostruirla al momento della presentazione, è ciò che rende il report finale difendibile. Le scritture contabili → dietro ogni movimento sono il luogo naturale dove vivono questi dati contestuali, quindi un partitario che memorizza già metadati ricchi per transazione fornisce la maggior parte di ciò che il framework richiede senza un sistema parallelo separato.

I dati e la pista di controllo da cui dipende il reporting CARF

Un report CARF credibile si basa su una catena di evidenze che va dall'evento grezzo on-chain o sull'exchange fino alla cifra trasmessa. Come minimo, quella catena necessita del dettaglio a livello di transazione — data, asset, quantità e valore — unito ai dati di identità e residenza del cliente e alla classificazione dell'attività, tutto conservato in una forma riproducibile su richiesta. Poiché i framework di reporting si basano sul presupposto che le autorità possano effettuare verifiche incrociate su quanto inviano i fornitori, la credibilità della trasmissione dipende dalla possibilità di scomporre ogni totale segnalato nei singoli movimenti che lo compongono.

• Registrazioni delle transazioni immutabili — gli eventi sottostanti acquisiti una sola volta e mai sovrascritti silenziosamente, in modo che una cifra possa sempre essere ricavata nuovamente dalla fonte.
• Attribuzione al cliente e alla residenza — ogni movimento segnalabile collegato alla parte verificata che lo ha generato, poiché il framework segnala le attività per persona, non solo in forma aggregata.
• Provenienza della valorizzazione — da dove proviene ciascun valore e la data in cui è stato determinato, in modo che un revisore o un'autorità possa vedere come è stata raggiunta una cifra convertita.
• Storico delle modifiche — un registro delle correzioni e delle rettifiche, perché un report presentato l'anno scorso potrebbe richiedere una modifica spiegabile quest'anno.
• Collegamento di riconciliazione — un filo visibile dal report allo stesso partitario che ha prodotto i conti statutari.

La sfida della riconciliazione dietro una dichiarazione CARF

La parte più difficile del reporting è raramente il formato — è assicurarsi che la popolazione sia completa e coerente. L'attività crypto arriva da molte fonti contemporaneamente: più blockchain, diversi exchange, sistemi di custodia e trasferimenti interni, ognuno con i propri identificativi e peculiarità. Prima che qualsiasi dato possa essere segnalato, lo stesso evento economico deve essere riconosciuto una sola volta, i duplicati provenienti da feed di dati sovrapposti devono essere eliminati e i movimenti interni tra i propri wallet devono essere distinti dalla genuina attività dei clienti. Sbagliare questo significa che un report è sovrastimato per doppio conteggio o sottostimato per lacune silenziose — entrambi esattamente il tipo di discrepanza che uno scambio di informazioni transfrontaliero è progettato per rilevare.

È qui che la disciplina che già sorregge una buona contabilità crypto paga doppiamente. La deduplicazione, l'abbinamento dei trasferimenti e l'ordinamento cronologico necessari per libri puliti sono gli stessi controlli che rendono affidabile una popolazione di segnalazione. Piuttosto che eseguire un'esportazione separata e impoverita di informazioni solo per la dichiarazione regolamentare, si riconcilia una volta a livello di partitario e si lascia che sia i conti che il report attingano al risultato riconciliato, in modo che i due non possano mai divergere silenziosamente.

Come un partitario crypto supporta la conformità CARF

Un partitario crypto dedicato è la spina dorsale naturale per CARF perché svolge già il lavoro ingrato che il framework presuppone: acquisisce le attività da ogni wallet e piattaforma, le normalizza in registrazioni coerenti, valorizza ogni movimento e mantiene una pista ininterrotta dietro ogni cifra. Quando i dati segnalabili e i dati contabili provengono da un unico archivio riconciliato, produrre un report diventa una questione di selezione e formattazione di registrazioni esistenti piuttosto che di ricostruzione della verità sottostante da zero. Questa è tutta la logica del livello di compliance e reporting → collocato sopra il partitario piuttosto che accanto ad esso come strumento disconnesso.

Protegge anche il futuro rispetto al fatto che CARF raramente viaggia da solo. Nell'UE gli stessi obblighi arrivano come DAC8 →, e un fornitore che opera oltre confine può trovarsi di fronte a richieste allineate ma distinte in più luoghi contemporaneamente. Un partitario che contiene un unico dataset riconciliato, ricchemente attribuito, consente di generare l'output di ciascun framework dalla stessa base invece di mantenere un foglio di calcolo fragile per regime.

Ambito e tempistica, a livello generale

Sulla tempistica, l'unica generalizzazione sicura riguarda la forma piuttosto che i dettagli: i framework di reporting di questo tipo prevedono tipicamente che i fornitori raccolgano i dati durante un periodo di segnalazione e presentino nel periodo successivo, con lo scambio internazionale delle informazioni che inizia una volta che un numero sufficiente di giurisdizioni è attivo. La sezione precedente illustra il quadro generale dell'adozione; al di là di ciò, le date precise, le modalità di registrazione e la tempistica del primo scambio per la tua giurisdizione sono questioni da confermare con il testo ufficiale e il proprio consulente, poiché variano per paese e continuano a essere implementate per fasi.

Sull'ambito, la domanda pratica per un team contabile è meno «qual è la definizione legale» e più «quali delle nostre attività e clienti rientrano nella popolazione che dobbiamo segnalare». Tale valutazione riguarda i tipi di cripto-attività gestite, la natura dei servizi forniti e il luogo di residenza dei clienti. Poiché il confine può essere genuinamente sottile, vale la pena documentare il ragionamento sull'ambito con la stessa cura delle cifre stesse — una posizione difendibile sul perché qualcosa è stato o meno segnalato fa parte della pista di controllo.

Errori comuni nella preparazione per CARF

• Trattare il reporting come un'esportazione di fine anno. I dati di attribuzione acquisiti mesi dopo il fatto sono molto più deboli dei dati acquisiti al momento della transazione; le esportazioni aggiunte in seguito tendono a perdere esattamente il contesto relativo al cliente e alla residenza di cui il framework ha bisogno.
• Lasciare che il report diverga dai conti. Se i totali normativi non possono essere riconciliati con il partitario, si hanno due versioni della verità e nessun modo di difendere l'una o l'altra.
• Doppio conteggio su feed sovrapposti. Lo stesso movimento che arriva sia dall'API di un exchange che da una lettura on-chain gonfia la popolazione a meno che non venga deduplicato una sola volta nel partitario.
• Etichettare erroneamente i trasferimenti interni come attività dei clienti. Lo spostamento di crypto tra i propri wallet non è un'attività segnalabile dei clienti, ma contamina il report se non viene distinto.
• Presumere che l'approccio di una giurisdizione si adatti a tutte. I framework allineati non sono identici; un processo costruito solo per un regime può tranquillamente mancare i requisiti di un altro.
• Nessuna cronologia delle modifiche. Senza un registro delle correzioni, un report modificato appare come un'incoerenza piuttosto che come una rettifica tracciata.

Come CryptaCount aiuta con CARF

CryptaCount affronta CARF come un prodotto a valle di un partitario ben curato, piuttosto che come un silos di conformità separato. Acquisisce le attività dei tuoi wallet, delle blockchain e delle piattaforme collegate in un unico partitario crypto riconciliato, porta il contesto per transazione di cui il framework si preoccupa e mantiene una pista di controllo ininterrotta e verificabile dietro ogni cifra — così un numero su un report può sempre essere ricondotto alla scrittura da cui proviene. Poiché lo stesso dataset riconciliato alimenta i conti statutari e il reporting, esiste un'unica versione della verità piuttosto che due da tenere sincronizzate manualmente. Dove gli obblighi CARF e DAC8 si sovrappongono, entrambi vengono prodotti da quella singola base, e le specifiche dell'ambito e del formato sono questioni da definire con il proprio consulente rispetto al testo ufficiale.

CARF sostituisce la nostra normale contabilità crypto?

No — si aggiunge ad essa. La tua contabilità ai sensi di IFRS → o US GAAP → misura e presenta la tua posizione; CARF è un obbligo di segnalazione separato e attribuito al cliente. Il punto di connessione sono i dati: entrambi devono attingere allo stesso partitario → riconciliato in modo che le cifre non divergano mai.

Operiamo in diversi paesi — questo complica CARF?

Può farlo, perché i framework allineati come CARF e le sue implementazioni regionali sono simili ma non identici, e le residenze dei clienti si estendono su più giurisdizioni. La soluzione pratica è mantenere un unico dataset ricchemente attribuito e generare da esso ogni output richiesto, piuttosto che mantenere un processo separato per paese. Gli obblighi precisi in più giurisdizioni sono questioni da confermare con il proprio consulente.

Quali registrazioni si aspetterà un revisore o un'autorità dietro una cifra CARF?

In linea generale, un percorso dal totale segnalato fino alle singole transazioni che lo compongono, con la provenienza del valore di ogni movimento, la sua attribuzione al cliente e alla residenza, e tutte le correzioni conservate. È esattamente il tipo di pista che un partitario a livello di transazione mantiene nel corso normale dell'attività, motivo per cui costruire il report partendo dal partitario è più difendibile che costruirlo partendo da un'esportazione piatta.

Quanto prima dovremmo iniziare a prepararci per CARF?

Prima della data del primo deposito, perché la qualità di un report dipende dai dati acquisiti contestualmente — in particolare l'attribuzione al cliente e alla residenza, difficile da ricostruire in seguito. Stabilire un partitario riconciliato con i metadati corretti prima del primo periodo di segnalazione significa che il report finale è un esercizio di selezione piuttosto che di ricostruzione. Le scadenze specifiche per la propria giurisdizione devono essere confermate con il testo ufficiale e il proprio consulente.