Exigences de déclaration CARF et différences d'implémentation locale expliquées

Écrit par FinTax

Dans les articles précédents de la série CARF, nous avons discuté et analysé les questions « Qui doit déclarer » et « Où déclarer » dans le cadre CARF. La première porte sur l'identification des fournisseurs de services d'actifs cryptographiques tenus de déclarer (Reporting Crypto-Asset Service Provider, RCASP), tandis que la seconde détermine, à travers les règles du Reporting Nexus, dans quelles juridictions le RCASP est tenu d'accomplir des obligations de diligence raisonnable et de déclaration. Une fois les entités déclarantes et les juridictions déclarantes identifiées, la mise en œuvre des obligations CARF soulève une question plus précise : quelles informations le RCASP doit-il déclarer aux autorités compétentes ?

Le rapport CARF exige que le RCASP, sur la base de la procédure de due diligence, identifie les utilisateurs à déclarer et leurs contrôleurs associés, et classifie et regroupe les transactions liées à leurs actifs cryptographiques selon les méthodes prescrites. Le rapport final comprend trois sections : informations sur le RCASP, informations sur l'utilisateur et informations sur les transactions.

L'OCDE fournit des normes internationales harmonisées, mais chaque juridiction doit les mettre en œuvre à travers ses propres lois et réglementations techniques. Par conséquent, pour comprendre ce que le CARF « déclare », il faut non seulement revenir aux règles de l'OCDE elles-mêmes, mais aussi examiner comment les règles d'implémentation locales modifient le contenu final des déclarations.

Cet article présente le cadre de base des informations à déclarer par le CARF, les principales différences dans la mise en œuvre locale, ainsi que les préparations possibles pour les RCASP au niveau des données et des systèmes, dans le but de fournir une référence pratique.

(1) Qu'est-ce qu'un « actif crypto pertinent » dans le cadre du CARF ?

La classification des actifs constitue la base des rapports de transaction. Selon les définitions du CARF, le terme « actif cryptographique » désigne une valeur numérique qui repose sur un registre distribué ou une technologie similaire pour sa vérification et sa sécurisation. Les « actifs cryptographiques concernés (Relevant Crypto-Asset) » couvrent en principe tous les actifs répondant à la définition d’un actif cryptographique, à l’exception de :

• Monnaie numérique de banque centrale (CBDC) ;
• Produit de monnaie électronique spécifique (SEMP) ;
• Le fournisseur de services d'actifs cryptographiques a déterminé de manière adéquate les actifs cryptographiques non utilisables à des fins de paiement ou d'investissement.

Les jugements sur les actifs principaux tels que le BTC et l'ETH sont généralement plus directs, tandis que les stablecoins, les NFT, les titres tokenisés et certaines jetons utilitaires nécessitent une analyse supplémentaire.

Figure 1 : Schéma illustrant la plage d'ajustement de CARF et CRS

(2) Quelles informations CARF signale-t-il exactement ? Trois catégories d'informations : RCASP, utilisateurs et transactions

Les informations à déclarer sont réparties en trois catégories : les informations sur les fournisseurs de services d'actifs cryptographiques à déclarer (informations RCASP), les utilisateurs à déclarer ou les personnes à déclarer (informations utilisateur) et les informations sur les transactions d'actifs cryptographiques concernées (informations sur les transactions), qui constituent le contenu complet du rapport CARF.

Informations RCASP

Indiquez le nom, l'adresse et le numéro d'identification du fournisseur de services d'actifs cryptographiques *.

L'identifiant est le numéro d'identification fiscale (TIN) ; en l'absence de numéro d'identification fiscale, utilisez le code d'enregistrement de l'entreprise ou le LEI (Global Legal Entity Identifier). Si aucun identifiant n'a été attribué au RCASP, indiquez uniquement son nom et son adresse.

Informations utilisateur

• Nom, adresse, lieu de résidence, numéro d'identification fiscale (TIN) *, date de naissance, lieu de naissance * ;
• Nom, adresse, lieu de résidence et numéro d’identification fiscale (TIN) de l’entité ; pour les contrôleurs d’entités déclarables déterminés dans le cadre des procédures de diligence raisonnable *, inclure également le nom, l’adresse, le lieu de résidence, le numéro d’identification fiscale (TIN), la date et le lieu de naissance du contrôleur, ainsi que son rôle en tant que contrôleur.

Les informations sur le lieu de naissance des utilisateurs individuels ne doivent pas être signalées, sauf disposition contraire de la loi du pays où se trouve le RCASP.

Le numéro d'identification fiscale (TIN) désigne le numéro d'identification attribué au contribuable ou au contrôleur effectif par la juridiction fiscale de résidence du contribuable, et non par la juridiction où la plateforme est établie, où la transaction a lieu ou où les revenus sont générés.

Si un utilisateur est considéré comme ayant plusieurs juridictions de résidence fiscale, le rapport doit refléter chaque juridiction de résidence fiscale dans laquelle l'utilisateur se trouve ainsi que le TIN correspondant pour chacune, sans sélection possible.

L'enquête de diligence raisonnable et la déclaration d'informations concernant les utilisateurs entités peuvent être étendues jusqu'aux bénéficiaires effectifs. Le CARF exige que les RCASP identifient d'abord les bénéficiaires effectifs des entités, puis déterminent si ces bénéficiaires effectifs constituent des personnes à déclarer. Les bénéficiaires effectifs soumis à déclaration doivent satisfaire à deux critères : être résident fiscal d'une juridiction à déclarer et exercer un contrôle sur l'entité. Le critère fondamental pour déterminer le contrôle est « la propriété de droits de contrôle » ; cela peut être atteint en détenant un pourcentage supérieur à un certain seuil d'actions, en occupant un poste de direction, ou en étant le constituant, le fiduciaire ou le bénéficiaire d'un trust, entre autres.

Informations sur les transactions

Pour chaque type d'actif crypto associé défini par CARF *, il faut déclarer :

1. Nom complet du type d'actif cryptographique concerné ;
2. Achat et disposition d'actifs cryptographiques en monnaie fiduciaire : montant total payé / reçu *, nombre total d'unités et nombre de transactions associées ;
3. Acquisition et disposition d'actifs cryptographiques associés en échange d'autres actifs cryptographiques associés : valeur marchande totale juste *、nombre total d'unités、nombre de transactions associées ;
4. Transactions de paiement de détail à déclarer * : valeur marchande totale juste, nombre total d'unités, nombre de transactions ;
5. Transferts effectués par l'utilisateur déclarant ou effectués au nom de l'utilisateur déclarant d'autres actifs cryptographiques connexes : les transactions de transfert ne relevant pas des types ci-dessus, classées par type de transfert (par exemple, airdrop, revenus de staking, paiements de prêt, échange de biens ou services), avec indication de la valeur marchande totale juste, du nombre total d'unités et du nombre de transactions associées ;
6. Transfer vers un portefeuille externe inconnu : valeur marchande totale juste, nombre total d'unités.

Le montant total payé ou reçu correspond au montant net après déduction des frais de transaction et est rapporté dans la devise fiat utilisée lors de la transaction. En cas de plusieurs devises fiat, un seul montant en devise fiat est rapporté, avec une conversion effectuée de manière cohérente à chaque transaction concernée. Par exemple, le taux de change au comptant au moment de la transaction est systématiquement utilisé pour la conversion.

L'évaluation de la valeur marchande juste totale doit être effectuée au moment de la transaction et doit déduire les frais de transaction ; elle doit être déterminée et déclarée dans une seule devise fiduciaire et évaluée de manière cohérente à chaque transaction. En ce qui concerne les méthodes d'évaluation, RCASP doit privilégier en priorité les paires de trading qu'il maintient lui-même ; en l'absence de prix de paire interne applicable, il peut recourir, dans l'ordre, aux méthodes de substitution suivantes : la valeur comptable interne, la valeur fournie par une entreprise ou un site tiers, la dernière évaluation de RCASP pour cet actif ou une estimation raisonnable.

Le montant de 50 000 dollars américains constitue le seuil pour que les transactions de paiement de détail soient soumises à déclaration ; toutefois, les virements inférieurs à ce montant ne sont pas exemptés de déclaration et doivent être pris en compte dans les catégories « Transferts d'autres actifs cryptographiques associés vers ou depuis des utilisateurs déclarants » et « Transferts vers des portefeuilles externes inconnus ».

Si l'utilisateur transfère des actifs cryptographiques vers son portefeuille privé ou vers un compte géré par une autre plateforme, empêchant ainsi le RCASP de connaître l'intégralité de ses transactions, le RCASP doit également le déclarer comme un virement vers un portefeuille externe inconnu.

Les règles exigent un regroupement de toutes les transactions. Si les actifs cryptographiques concernés sont non fongibles et que leurs différentes variantes ont des valeurs différentes par unité fixe, chaque unité doit être considérée comme un type distinct d'actif cryptographique concerné.

Les règles CARF publiées par l'OCDE et leurs commentaires fournissent une norme internationale harmonisée, mais leur mise en œuvre finale est effectuée par chaque juridiction sous forme de législation locale. Les règles centrales, telles que la définition des actifs cryptographiques, la classification des transactions et les champs de déclaration, sont très proches des normes de l'OCDE, bien que des différences significatives puissent exister dans certains détails de mise en œuvre selon les politiques locales.

(1) Le périmètre du rapport couvre-t-il les utilisateurs nationaux ?

Le cadre original du CARF de l'OCDE sert principalement à l'échange automatique d'informations fiscales transfrontalières. « La juridiction reportable » désigne une juridiction qui a mis en place un accord d'échange d'informations CARF et qui figure sur la liste publique publiée par la juridiction mise en œuvre. Les déclarations portent sur les résidents fiscaux d'autres juridictions reportables. Certaines juridictions ont ajouté des exigences de déclaration locale, selon lesquelles les RCASP doivent également déclarer aux autorités fiscales locales les informations concernant les utilisateurs résidents fiscaux du pays.

Par exemple, le Royaume-Uni a établi les obligations de déclaration des RCASP britanniques pour les utilisateurs résidents fiscaux britanniques et leurs contrôleurs associés via le Finance Act 2026, et exige explicitement dans ses lignes directrices actuelles que les RCASP collectent toutes les informations des utilisateurs et déclarent les données des résidents fiscaux britanniques ainsi que des résidents des juridictions participant au CARF. La liste des juridictions à déclarer selon le CARF publiée par l’Office des impôts de la Nouvelle-Zélande inclut son propre pays ; par conséquent, les résidents fiscaux néo-zélandais entrent également dans le champ de déclaration local. Les lignes directrices officielles précisent en outre que lorsqu’un RCASP détient à la fois des utilisateurs résidents et non-résidents néo-zélandais, les informations d’identité et les données de transaction de ces deux catégories doivent être soumises à l’administration fiscale : les données des résidents sont utilisées pour la gestion fiscale nationale, tandis que les données des non-résidents sont échangées, conformément aux dispositions du CARF, avec les autorités fiscales des pays de résidence de ces utilisateurs.

Dans le même temps, des juridictions telles que le Japon et Singapour n'incluent pas leurs résidents fiscaux nationaux dans le périmètre de déclaration CARF, adoptant une approche similaire au cadre initial de l'OCDE. Même ainsi, RCASP doit appliquer des procédures de diligence raisonnable à tous les utilisateurs, y compris les utilisateurs locaux, afin d'identifier les utilisateurs soumis à déclaration ; l'absence d'obligation de déclaration locale n'exonère pas cette obligation.

Ainsi, le périmètre de la diligence raisonnable ne correspond pas nécessairement au périmètre du rapport final, et le périmètre de l'échange international ne correspond pas forcément au périmètre requis par les autorités fiscales locales.

(2) Conversion et évaluation des monnaies fiduciaires uniques

Les montants des transactions et la valeur marchande juste doivent tous deux être convertis en monnaie légale conformément aux règles CARF pour déclaration. La désignation éventuelle d'une monnaie de déclaration spécifique par chaque juridiction influence directement la conversion des données et le système de déclaration du RCASP.

Par exemple, les règlements CARF publiés par l’Autorité fiscale sud-africaine (Avis 6887) stipulent explicitement que les montants des transactions et la valeur marchande juste doivent être déterminés et déclarés en rand sud-africain (South African Rand). Les réponses de l’administration fiscale aux FAQ abordent les charges de conformité et les défis pratiques auxquels les plateformes à fort volume de transactions peuvent être confrontées, en précisant davantage les exigences relatives à une conversion et une évaluation continues et cohérentes. Elles indiquent que le CARF n’exige pas de conversion monétaire en temps réel par les RCASP, ne restreint pas l’usage de sources de taux de change spécifiques ni la méthode de fixation des prix pour chaque transaction, mais autorise l’adoption de méthodes raisonnables telles que le traitement par lots, l’application du taux de change à la fin de la journée ou l’utilisation d’une moyenne appropriée. La grande volumétrie des transactions, la volatilité des prix des actifs et les différences dans les sources de données de marché peuvent être équilibrées grâce à la flexibilité opérationnelle des RCASP.

(3) Le seuil de montant est-il converti en devise locale ?

Selon les règles de l'OCDE, les transactions de paiement de détail atteignant le seuil de 50 000 dollars américains sont regroupées dans la catégorie des transactions de paiement de détail à déclarer ; sinon, elles sont classées parmi les autres types de transactions.

Les différentes juridictions peuvent convertir les seuils en monnaie locale lors de la mise en œuvre de la législation locale. Par exemple, le Japon fixe le seuil de déclaration des transactions de paiement de détail à 5 millions de yens (environ 31 273 USD), le Brésil adopte un équivalent en réals de 50 000 USD, l'UE dans le cadre de DAC8 utilise 50 000 USD ou un équivalent dans une autre devise, tandis que certaines autres juridictions conservent le seuil original en dollars américains.

Il existe plusieurs formes de localisation des seuils de déclaration pour les montants des transactions de paiement de détail, notamment la fixation d’un montant fixe en monnaie locale ou le calcul du montant équivalent en monnaie locale à partir du seuil en dollars américains. Cette distinction influencera la classification et la synthèse des transactions d’actifs cryptographiques par les RCASP dans la pratique. Une même transaction peut être classée dans des catégories de transactions CARF différentes selon le territoire applicable : elle constitue une transaction de paiement de détail dans le territoire A, mais est classée comme un autre type de transfert dans le territoire B.

(4) Différences détaillées entre les champs de rapport spécifiques

Les règles de l'OCDE établissent uniformément les champs de rapport essentiels pour les utilisateurs individuels, les utilisateurs entités et leurs contrôleurs, tout en laissant une marge pour les lois locales.

La nationalité de l'utilisateur individuel n'est généralement pas à déclarer, sauf si la législation de la juridiction où se trouve le RCASP l'exige autrement. Pour le numéro d'identification fiscale (TIN), s'il n'est pas délivré par la juridiction de résidence fiscale de l'utilisateur à déclarer ou du contrôleur pertinent, ou si la législation locale n'exige pas sa collecte, le TIN n'est pas à déclarer. À cet égard, l'IRAS de Singapour autorise explicitement, dans le cadre de ses règles CARF XML, la fourniture d'un code de raison correspondant dans ces cas.

De plus, même si tous exigent la soumission d'un TIN, les formats de numéro varient selon les juridictions. Au Royaume-Uni, le numéro de sécurité sociale (NINO) pour les utilisateurs individuels ou les contrôleurs concernés, le numéro d'enregistrement (CRN) pour les sociétés britanniques, ainsi que le UTR pour les partenariats et les fiducies, constituent leurs numéros d'identification fiscale respectifs.

(Cinq) La déclaration est-elle encore requise en l'absence d'informations à déclarer ?

Si aucune information concernant des utilisateurs ou des transactions à déclarer n’a été enregistrée au cours de l’exercice, la nécessité pour le RCASP de déclarer auprès des autorités fiscales dépend également des dispositions de la juridiction dans laquelle il est établi.

Le Royaume-Uni adopte clairement un modèle sans données ni déclaration. Singapour exige en principe la soumission d'une déclaration nulle (nil return), c'est-à-dire que seules les informations RCASP doivent être renseignées, sans avoir à fournir de données utilisateurs ni transactionnelles. De plus, les FAQ du Service des impôts du Japon sur le CARF précisent la relation entre le montant des transactions et les informations à déclarer : même si, pour une année donnée, aucune transaction liée à un contrat reportable n'a été réalisée, une déclaration annuelle RCASP est toujours requise tant que le contrat reportable n'est pas terminé.

(1) Intégration de l'enquête fiscale CARF dans le processus KYC des utilisateurs

Les informations AML/KYC du client remplissent la fonction de vérification de la légitimité de l'autocertification fiscale dans le cadre du CARF, constituant ainsi une base essentielle pour l'accomplissement de la diligence raisonnable par le RCASP. Lors de l'exécution de ses obligations AML/KYC, le RCASP obtient généralement déjà les nom, adresse et pièce d'identité des personnes physiques, ainsi que les informations d'enregistrement, la structure de propriété et les bénéficiaires effectifs des entités ; ces données n'ont pas besoin d'être collectées à nouveau. Aux fins de déclaration, le CARF examine également les juridictions de résidence fiscale, les TIN, ainsi que la qualité des contrôleurs d'entités concernées en tant que personnes à déclarer et la validité de l'autocertification fiscale. À partir des informations sur la structure de propriété et les bénéficiaires déjà collectées dans le cadre du KYC, le RCASP doit en outre déterminer si ces personnes répondent aux définitions de « contrôleur d'entité » et de « personne à déclarer ». Étant donné le chevauchement partiel entre les données KYC et les données CARF, ces deux ensembles doivent être considérés comme partagés, avec des évaluations distinctes ; sur le plan pratique, les entreprises doivent ajouter une couche de exigences CARF à leur cadre KYC existant, plutôt que de créer un système client entièrement séparé.

(2) Mettre en place un mécanisme unifié de conversion et d'évaluation des devises fiat

Dans la phase d'intégration et de rapport des informations de transaction, l'unité monétaire utilisée influence les processus de conversion du montant de la transaction, d'évaluation de la valeur marchande juste, de classification des types de transactions, etc. Les exigences de localisation associées ont un impact significatif sur la conception des systèmes des RCASP mondiaux. Le RCASP doit conserver au minimum la devise d'origine de la transaction, le montant de la transaction, le taux de change au moment de la transaction, ainsi que le montant rapporté converti, la devise et les horaires et méthodes d'évaluation, et non uniquement les résultats convertis. Même si une juridiction met à jour ses exigences politiques concernant le rapport en devise locale, le RCASP doit être en mesure de générer des rapports conformes à partir des données de transaction sous-jacentes.

(3) Améliorer le système de règles de localisation CARF

Bien que le CARF de l'OCDE puisse servir de norme de données de base unifiée, les différences d'implémentation locales mentionnées dans cet article révèlent que la logique finale de déclaration repose toujours sur des juridictions spécifiques. Les RCASP doivent identifier dans quelle juridiction ils génèrent et remplissent leurs obligations de conformité au CARF, et confirmer si la portée de la déclaration inclut les résidents fiscaux locaux, quels territoires déclarables sont publiés dans cette juridiction, si des champs facultatifs tels que le lieu de naissance des utilisateurs individuels doivent être soumis, et s'il est nécessaire de déposer une déclaration nulle en l'absence d'informations à déclarer. Les différences de politiques locales se manifestent également dans la forme des numéros d'identification fiscale. Les champs de déclaration finaux doivent être déterminés en combinant les exigences des RCASP et la législation locale ainsi que les spécifications techniques de la juridiction où se trouve l'utilisateur ; ces différences ne peuvent pas être gérées uniquement par un ensemble de règles unifiées.

Le contenu d'un rapport annuel CARF repose sur une série d'hypothèses préalables, ce qui signifie que le RCASP ne peut pas attendre la date limite de déclaration pour commencer sa préparation, mais doit intégrer la conformité CARF dans les chaînes opérationnelles telles que la gestion des clients, les processus KYC et les systèmes de transaction. La mise en œuvre locale de CARF progresse progressivement à l'échelle mondiale, et les normes unifiées établies par l'OCDE risquent de continuer à se fragmenter. Pour les fournisseurs de services de cryptomonnaie opérant à l'international, les mêmes données d'utilisateurs et de transactions doivent être configurées séparément selon les règles nationales des juridictions concernées lors de la déclaration. La capacité à effectuer à l'avance un tri et une adaptation des règles locales et des données système influencera directement la précision et la stabilité des déclarations CARF ultérieures.