FinCEN et les rançongiciels, le tournant mondial des stablecoins : ce que les entreprises doivent savoir
Quatre évolutions réglementaires sont survenues coup sur coup : le Financial Crimes Enforcement Network du Trésor américain a convoqué un sommet multi-agences sur les rançongiciels, assorti d'orientations formelles sur le dépôt de déclarations d'activités suspectes (SAR) ; le Trésor britannique a désigné les stablecoins comme un pilier de l'innovation en services financiers ; la banque centrale néerlandaise a confirmé avoir reçu plus de trois douzaines de demandes d'enregistrement au titre de la 5AMLD de la part d'entreprises crypto ; et le New Jersey a déposé un projet de loi sur les licences qui calquerait le régime du BitLicense de New York. Pris ensemble, ces mouvements signalent un durcissement matériel de l'environnement de conformité pour les entreprises crypto à l'échelle mondiale, avec des implications directes pour la comptabilisation des stablecoins, les flux de travail SAR et les logiciels de comptabilité d'actifs numériques qui soutiennent les deux.
Le sommet de FinCEN sur les rançongiciels et ce qu'il exige des entreprises crypto
Le Financial Crimes Enforcement Network du Trésor américain a convoqué un sommet dédié aux rançongiciels, réunissant des agences fédérales, des entreprises crypto, des fournisseurs d'analyse blockchain et des banques pour examiner les typologies de menaces actuelles et les stratégies de réponse coordonnées. Cette réunion ne s'est pas tenue isolément. L'OFAC avait déjà publié des orientations sur les risques de sanctions associés aux paiements de rançongiciels, et FinCEN avait séparément publié une notice à l'intention du secteur privé soulignant l'obligation légale de déposer une déclaration d'activités suspectes chaque fois qu'une entreprise rencontre une transaction liée à un rançongiciel.
L'obligation de déclaration SAR en termes clairs
Pour les entreprises crypto opérant sous le Bank Secrecy Act, la notice de FinCEN n'est pas consultative : elle réaffirme une obligation légale existante. Toute transaction dont une entreprise sait, soupçonne ou a des raisons de soupçonner qu'elle implique des produits de rançongiciel doit déclencher le dépôt d'une SAR dans le délai requis. La notice relève le niveau attendu de détection, car elle indique que les régulateurs s'attendent à ce que les entreprises disposent de contrôles de détection spécifiquement calibrés sur les typologies de rançongiciels, et non d'un simple filtrage AML générique.
Cela a une implication directe sur les flux de travail. Une entreprise qui s'appuie sur un logiciel de comptabilité crypto traitant la catégorisation des transactions sans alimenter un système de surveillance des transactions risque de ne pas détecter les schémas on-chain spécifiques que FinCEN signale désormais. L'exigence pratique est une intégration plus étroite entre la couche grand livre et la couche conformité, afin qu'un portefeuille ou une contrepartie signalé sur la base de données de campagnes de rançongiciels déclenche un dossier plutôt que de simplement passer dans les comptes.
L'exposition aux sanctions OFAC ajoute une seconde couche de risque
De nombreux opérateurs de rançongiciels sont des entités sanctionnées ou basées dans des juridictions sanctionnées. Les orientations de l'OFAC précisent que faciliter un paiement à un acteur sanctionné, même indirectement par le biais d'une demande de rançon réglée en crypto, peut constituer une violation des sanctions, que la partie payante ait su ou non que le destinataire ultime était sanctionné. Pour les équipes comptables, cela signifie que toute sortie de stablecoins ou de cryptomonnaies identifiée ultérieurement comme un paiement de rançongiciel peut devoir être annulée, déclarée et potentiellement passée en perte, créant à la fois un événement comptable et une obligation de divulgation réglementaire que le logiciel de comptabilité d'actifs numériques de l'entreprise doit pouvoir enregistrer proprement.
Réglementation britannique des stablecoins : un signal politique aux conséquences comptables
La déclaration publique du chancelier britannique selon laquelle les stablecoins occuperont une place de premier plan dans la stratégie d'innovation en services financiers du pays est le signal politique le plus clair à ce jour que le Royaume-Uni entend bâtir un régime supervisé des stablecoins. Le cadrage est notable : le gouvernement reconnaît explicitement que les stablecoins pourraient rendre les paiements moins chers et plus rapides, tout en insistant sur le fait que toute approche réglementaire doit soumettre les émetteurs de stablecoins et les services de paiement aux mêmes normes minimales que les autres méthodes de paiement.
Ce qu'un cadre britannique des stablecoins pourrait signifier pour les classifications comptables
Dès qu'un stablecoin sera réglementé comme instrument de paiement au Royaume-Uni, son traitement comptable selon les IFRS deviendra une question vive. Un stablecoin qualifié d'instrument financier selon l'IFRS 9, plutôt que d'actif incorporel selon l'IAS 38, serait évalué à la juste valeur par le biais du résultat net ou au coût amorti selon ses caractéristiques contractuelles de flux de trésorerie. La différence pratique n'est pas anodine : les gains et pertes transiteraient différemment par le compte de résultat, et les obligations de divulgation changeraient. Les entreprises détenant des USDC ou d'autres stablecoins en dollars dans des comptes britanniques devraient se préparer dès maintenant à la possibilité que leur classification comptable actuelle doive être revue une fois la consultation close et une catégorie réglementaire confirmée.
Pour les entreprises qui gèrent déjà la comptabilité des stablecoins dans plusieurs juridictions, le signal britannique ajoute une variable supplémentaire à la matrice de classification. Le régime MiCA de l'UE a déjà défini les jetons de monnaie électronique et les jetons référencés à des actifs comme des catégories distinctes avec des obligations d'émetteur différentes. Un cadre britannique qui divergerait de MiCA, même modestement, pourrait signifier qu'un même stablecoin nécessite un traitement comptable différent dans un bilan britannique et dans un bilan européen continental. C'est un problème de fragmentation que les logiciels de comptabilité crypto devront gérer au niveau de l'entité et de la juridiction, et non simplement au niveau du jeton. Pour un contexte sur la façon dont les événements de gel de stablecoins peuvent cristalliser ces questions de classification du jour au lendemain, voir notre analyse des obligations AML et comptables des stablecoins après un événement de gel majeur.
Les privacy coins comme signal parallèle
Dans le même cycle réglementaire, une grande plateforme d'échange a annoncé le retrait de la cote des privacy coins, invoquant la réduction du risque réglementaire comme motif déclaré. La décision reflète un calcul industriel plus large : à mesure que les attentes AML se resserrent, les actifs dont les graphes de transactions ne peuvent pas être surveillés créent une charge de conformité asymétrique. Les entreprises qui continuent de détenir ou de faciliter des transactions en privacy coins ont besoin d'une justification documentée et de preuves que leur surveillance des transactions couvre la transparence que le protocole sous-jacent permet. Zcash, par exemple, autorise des transactions transparentes qui peuvent être tracées de manière similaire à Bitcoin, ce qui constitue un profil de risque sensiblement différent d'un protocole qui anonymise toute activité par défaut. Cette distinction devrait se refléter dans la déclaration d'appétit pour le risque de l'entreprise et dans la façon dont son logiciel de comptabilité crypto catégorise ces actifs.
Pays-Bas : la 5AMLD en pratique
La banque centrale néerlandaise a confirmé avoir reçu plus de trois douzaines de demandes d'enregistrement d'entreprises crypto cherchant une autorisation au titre de la transposition de la cinquième directive européenne anti-blanchiment. Les Pays-Bas ont manqué la date limite initiale de mise en œuvre de janvier 2020 et n'ont mis en service leur régime d'enregistrement AML crypto qu'en mai de cette année-là, ce qui signifie que les entreprises qui opéraient avant le lancement du régime pouvaient continuer à le faire pendant le traitement de leurs demandes.
Ce que les équipes de conformité doivent retenir de l'expérience néerlandaise
La situation néerlandaise est instructive pour deux raisons. Premièrement, elle montre que même une transposition nationale retardée ne crée pas une fenêtre sans conformité à perpétuité : les entreprises opérant sous autorisation temporaire doivent toujours démontrer leur préparation AML au moment de l'examen de l'enregistrement. Deuxièmement, le volume des demandes suggère que les entreprises crypto à travers l'UE s'engagent désormais sérieusement dans les régimes d'enregistrement nationaux plutôt que de les traiter comme un problème futur.
Pour les équipes comptables et de conformité servant des clients ayant des opérations aux Pays-Bas, l'implication pratique est que la documentation AML et les preuves de surveillance des transactions doivent être disponibles sur demande, et non assemblées rétrospectivement. Le processus d'enregistrement demande aux entreprises de montrer que leurs contrôles fonctionnent, pas seulement qu'elles ont une politique sur papier. Cela nécessite une pile logicielle de comptabilité d'actifs numériques qui génère des enregistrements de transactions prêts pour l'audit, des journaux de filtrage des contreparties et une documentation des flux de travail SAR dans un format que le régulateur peut réellement examiner.
Le cadre de licence crypto proposé par le New Jersey
Le New Jersey a déposé le Digital Asset and Blockchain Technology Act, qui obligerait les entreprises crypto opérant dans l'État ou servant des résidents du New Jersey à obtenir une licence du Department of Banking and Insurance. La pénalité pour exploitation sans licence serait une amende pouvant aller jusqu'à 500 dollars par jour, et le cadre est étroitement calqué sur le régime BitLicense existant de New York.
Implications pratiques pour les entreprises multi-États
Si le projet de loi passe, toute entreprise détenant déjà un BitLicense de New York devra évaluer si sa clientèle du New Jersey déclenche une obligation de licence distincte. La proximité géographique des deux États signifie que de nombreuses entreprises servent des clients dans les deux sans nécessairement les traiter comme des juridictions réglementaires séparées. Une demande de licence dans le New Jersey exigera le même type de programme AML documenté, d'états financiers et de contrôles opérationnels que New York attend, ce qui signifie que l'infrastructure de conformité construite pour le BitLicense devrait raisonnablement bien se transférer, mais la charge administrative d'un second dépôt étatique n'est pas anodine.
Pour les directeurs financiers gérant des entreprises crypto multi-entités, la proposition du New Jersey incite à cartographier l'exposition aux licences au niveau des États dans toutes les juridictions où les clients sont situés, et pas seulement là où l'entreprise est constituée. À mesure que les cadres étatiques se multiplient, le coût de la conformité évolue avec le nombre de licences détenues, et ce coût doit être reflété dans la planification budgétaire et dans l'évaluation par l'entreprise des marchés qu'il est commercialement viable de servir.
Sur la dimension de la classification des stablecoins, le cadre du GENIUS Act opérant au niveau fédéral ajoute une couche supplémentaire à cette analyse. Dans ce cadre, les banques doivent déterminer si chaque stablecoin qu'elles détiennent ou facilitent est un stablecoin « autorisé » en vertu du droit fédéral, et traiter un stablecoin non autorisé comme autorisé constituerait en soi une défaillance de conformité. Pour une analyse détaillée de la façon dont ce cadre fédéral recoupe les obligations bancaires, voir notre article sur la façon dont le cadre des stablecoins du GENIUS Act remodèle les obligations de conformité bancaire.
Implications comptables et de reporting pour les quatre évolutions
Pris individuellement, chacune de ces quatre évolutions est une question de conformité. Pris ensemble, elles décrivent un changement structurel de l'environnement opérationnel pour les entreprises crypto et les cabinets comptables qui les servent.
Pour les cabinets comptables et les directeurs financiers
L'obligation de dépôt de SAR que FinCEN a réaffirmée est une exigence légale, et non une recommandation de bonne pratique. Les entreprises dont le logiciel de comptabilité crypto ne relie pas l'activité du grand livre à un flux de travail de conformité risquent de manquer entièrement la fenêtre de détection. La bonne architecture intègre la catégorisation des transactions, le filtrage des contreparties et la gestion des dossiers, afin qu'un schéma suspect identifié au niveau de la comptabilité puisse s'escalader automatiquement plutôt que de dépendre d'un cycle d'examen manuel qui pourrait être trop lent.
Sur la comptabilité des stablecoins spécifiquement, la convergence des signaux réglementaires britanniques, du cadre fédéral du GENIUS Act aux États-Unis et de la catégorisation déjà en vigueur de MiCA dans l'UE signifie qu'un même jeton peut nécessiter un traitement différent dans différents bilans au niveau des entités. Les entreprises ont besoin d'une politique de classification sensible à la juridiction, documentée au niveau de la politique comptable et révisable à mesure que les réglementations sont finalisées. La comptabilité des USDC, en particulier, passe d'une question réglée à un choix politique actif dans les juridictions où la catégorie réglementaire de l'instrument n'a pas encore été confirmée.
Pour les praticiens individuels conseillant les entreprises crypto
L'expérience néerlandaise de la 5AMLD rappelle que l'enregistrement n'est pas la fin du parcours de conformité : c'est le moment où le régulateur commence à examiner si les contrôles documentés dans la demande fonctionnent réellement. Les praticiens conseillant des entreprises nouvellement enregistrées devraient tester la résistance des sorties de surveillance des transactions, des flux de travail SAR et des pratiques de tenue de registres par rapport à la norme que le régulateur appliquera lors du prochain examen, et non à la norme qui a permis l'enregistrement de l'entreprise.
Pour les entreprises proches du New Jersey, le projet de loi sur les licences est à un stade précoce mais mérite une surveillance. Une entreprise qui attend que le projet de loi soit adopté pour commencer à préparer sa demande sera en retard. Rassembler les états financiers, la documentation AML et les informations opérationnelles requises pour une demande de type BitLicense prend du temps, et les entreprises qui agissent tôt ont tendance à obtenir leurs licences avant que la file d'attente du régulateur ne s'allonge.
Questions fréquentes
La notice de FinCEN sur les rançongiciels crée-t-elle de nouvelles obligations légales pour les entreprises crypto ?
La notice réaffirme et clarifie les obligations existantes en vertu du Bank Secrecy Act plutôt que de créer une nouvelle loi. Cependant, elle relève le niveau attendu de détection en signalant que les entreprises devraient disposer de contrôles spécifiquement calibrés sur les typologies de rançongiciels, et non d'un simple filtrage AML générique. Ne pas déposer de SAR sur une transaction liée à un rançongiciel parce que l'entreprise manquait de contrôles de détection adéquats resterait une violation du BSA.
Comment une entreprise doit-elle comptabiliser un paiement crypto identifié ultérieurement comme lié à un rançongiciel ?
Si un paiement effectué en cryptomonnaie ou en stablecoins est ultérieurement identifié comme provenant d'un rançongiciel, l'entreprise fait face à la fois à un événement comptable et à une obligation de divulgation réglementaire. Le paiement peut devoir être annulé ou passé en perte irrécouvrable, et si la contrepartie est une entité sanctionnée, les exigences de déclaration à l'OFAC s'appliquent en plus du dépôt de SAR. L'écriture au grand livre doit être étayée par une documentation contemporaine de l'événement de détection et de la réponse de l'entreprise.
Que signifie la consultation britannique sur les stablecoins pour les entreprises utilisant des USDC ou des USDT à leur bilan ?
Tant que le gouvernement britannique n'a pas publié sa consultation et qu'un cadre réglementaire final n'est pas confirmé, la classification comptable des stablecoins selon les IFRS reste en suspens au Royaume-Uni. Les entreprises devraient documenter leur politique de classification actuelle, le raisonnement qui la sous-tend et un plan pour la réviser une fois la catégorie réglementaire confirmée. La question clé est de savoir si un stablecoin réglementé serait traité comme un instrument financier selon l'IFRS 9 ou resterait un actif incorporel selon l'IAS 38, car la réponse détermine les exigences d'évaluation, de dépréciation et de divulgation.
Si une entreprise détient déjà un BitLicense de New York, a-t-elle besoin d'une licence distincte pour le New Jersey ?
En vertu du projet de Digital Asset and Blockchain Technology Act du New Jersey, une licence distincte au niveau de l'État serait requise pour opérer dans le New Jersey ou servir des clients du New Jersey. Un BitLicense de New York ne confère pas de droits de passeport vers d'autres États. Les entreprises ayant une clientèle dans le New Jersey devraient surveiller l'avancement du projet de loi et commencer à rassembler la documentation qu'exigerait une demande de licence.
Comment le régime néerlandais de la 5AMLD interagit-il avec MiCA pour les entreprises opérant dans les deux cadres ?
Les Pays-Bas ont mis en œuvre la 5AMLD par un régime d'enregistrement national administré par la banque centrale néerlandaise. MiCA, désormais en vigueur dans toute l'UE, introduit un cadre d'autorisation harmonisé pour les prestataires de services sur actifs crypto. Les entreprises enregistrées sous le régime néerlandais de la 5AMLD devront transitionner vers une autorisation MiCA CASP à mesure que le calendrier MiCA avance. Les deux régimes se chevauchent mais ne sont pas identiques, et les entreprises ne doivent pas présumer que l'enregistrement 5AMLD satisfait automatiquement aux exigences d'autorisation MiCA.
Source : Elliptic Insights