Portefeuilles non hébergés et transferts auto-hébergés

Un transfert vers ou depuis un portefeuille auto-hébergé ne fait intervenir aucun deuxième PSVA pour recevoir des données, effectuer des contrôles ou répondre à des questions. Le propre client de l'entreprise est la seule partie assujettie à des obligations dans la transaction : tout ce que la Travel Rule répartirait normalement entre deux prestataires incombe donc à un seul. Les autorités de surveillance s'attendent de plus en plus à ce que les entreprises démontrent qu'elles appliquent une approche délibérée et étayée pour ces transferts, plutôt que de les ignorer ou de les interdire purement et simplement.

Pourquoi les transferts auto-hébergés sont importants

Un portefeuille non hébergé (portefeuille auto-hébergé) est contrôlé par son utilisateur au moyen de ses propres clés, sans prestataire de services intermédiaire. Les transferts entre ces portefeuilles sont de pair à pair (P2P) et échappent au périmètre de la LBC/FT jusqu'à ce que les fonds touchent un PSVA ou un établissement financier. C'est à ce point d'entrée ou de sortie que les contrôles de l'entreprise s'appliquent.

Le GAFI a régulièrement désigné les transferts P2P effectués au moyen de portefeuilles non hébergés comme un risque prioritaire dans ses rapports ciblés et ses mises à jour annuelles, en notant qu'aucune entité assujettie ne voit ces transferts ni ne les signale.

La plupart des transferts auto-hébergés sont légitimes : les clients transfèrent des actifs vers un stockage à froid, utilisent la DeFi ou reçoivent des paiements de particuliers. Il s'agit de distinguer ces transferts de ceux qui déplacent des fonds pour le compte de tiers ou d'acteurs illicites.

Ce que le GAFI attend

Les personnes qui utilisent leurs propres portefeuilles ne sont pas des entités assujetties : il n'y a donc personne à qui envoyer un message au titre de la Travel Rule. Les recommandations du GAFI sur les actifs virtuels n'interdisent pas ces transferts. Elles attendent plutôt des PSVA qu'ils :

• obtiennent les informations requises sur le donneur d'ordre et le bénéficiaire auprès de leur propre client et les conservent ;
• vérifient les noms par rapport aux listes de sanctions et appliquent les obligations de gel et d'interdiction prévues par la R.16 ;
• utilisent ces informations dans la surveillance des transactions et la déclaration des transactions suspectes ;
• appliquent des contrôles fondés sur les risques et proportionnés au risque, tels qu'une surveillance renforcée, des limites ou la restriction des transferts vers des adresses évaluées par l'entreprise.

Les pays peuvent ajouter des exigences. Certains régimes, par exemple, exigent que les entreprises vérifient que le client est propriétaire d'une adresse auto-hébergée ou la contrôle au-delà d'un montant fixé, tandis que d'autres laissent le choix de la méthode à l'évaluation des risques de l'entreprise. La leçon Comment les régimes nationaux mettent en œuvre la norme montre comment cartographier ces différences.

Une approche fondée sur les risques

Une politique applicable attribue un score à chaque transfert auto-hébergé en fonction de quelques facteurs et détermine les contrôles à appliquer selon le résultat :

Les contrôles sont ensuite renforcés progressivement : consigner et surveiller ; exiger une preuve de propriété ; demander les coordonnées du tiers et l'objet du transfert ; appliquer une limite inférieure ou suspendre le transfert pour examen ; ou le rejeter. La politique doit préciser qui peut approuver des exceptions et quels justificatifs chaque étape exige. L'exposition révélée par l'analyse est abordée en détail dans la leçon Vérification des portefeuilles et des transactions.

Prouver la propriété d'une adresse

Les méthodes les plus fiables prouvent le contrôle de la clé privée, et pas seulement la connaissance de l'adresse :

• Message signé. Le client signe, avec la clé associée à l'adresse, un texte de défi choisi par l'entreprise, comprenant une valeur aléatoire et une date ; l'entreprise vérifie ensuite la signature. Il existe des spécifications ouvertes à cet effet : BIP-322 pour Bitcoin, EIP-191 et EIP-712 pour les comptes de type Ethereum, et EIP-1271 pour les portefeuilles de contrats intelligents, qui valident les signatures au moyen de leur propre code.
• Test du satoshi. Le client envoie depuis l'adresse à l'entreprise un petit montant fixé par celle-ci. Cela prouve le contrôle de l'adresse à ce moment-là, au prix de frais et d'un court délai.
• Micro-transfert inversé. L'entreprise envoie à l'adresse un petit montant inhabituel et demande au client de l'indiquer. Cela prouve uniquement que le client peut voir l'adresse, ce que n'importe qui peut faire sur un explorateur de blocs ; la méthode est donc peu fiable.
• Capture d'écran ou déclaration. Une capture d'écran d'une application de portefeuille ou une déclaration signée est facile à falsifier et ne prouve rien quant au contrôle de la clé. Ne les traitez que comme des informations complémentaires dans les cas à faible risque.

Chaque méthode prouve le contrôle à un instant donné. Les clés peuvent être partagées, vendues ou compromises ; les vérifications de propriété complètent donc la surveillance au lieu de la remplacer. Les portefeuilles à signatures multiples exigent une attention particulière : une signature peut montrer que le client détient une clé, mais pas qu'il contrôle le portefeuille.

Une adresse vérifiée doit laisser une trace justificative qu'un auditeur peut contrôler à nouveau :

{
  "customer_id": "C-20418",
  "address": "bc1q…4h8s",
  "chain": "bitcoin",
  "method": "signed_message_bip322",
  "challenge": "Alpha Exchange ownership check C-20418 2026-10-14 nonce 7f3e91",
  "signature": "AkcwRAIg…Qe1",
  "verified_at": "2026-10-14T09:42:17Z",
  "verified_by": "system",
  "result": "pass",
  "analytics_check": { "risk_category": "none_detected", "checked_at": "2026-10-14T09:42:20Z" },
  "review_due": "2027-10-14"
}

La trace conserve le défi exact et la signature, afin que la vérification puisse être répétée, ainsi que le résultat de l'analyse effectué à ce moment-là et une date de réexamen. Le nonce et la date figurant dans le défi empêchent le client de réutiliser une signature créée pour une autre entreprise ou lors d'une vérification antérieure.

Quand recueillir les données sur le donneur d'ordre et le bénéficiaire

Les données proviennent du propre client de l'entreprise ; les informations à demander dépendent du sens du transfert et de l'identité de la personne qui contrôle l'autre portefeuille :

Les transferts entrants provenant de tiers méritent une attention particulière, car un client qui reçoit des fonds de nombreux portefeuilles auto-hébergés sans lien entre eux peut agir comme mule financière ou comme entreprise non enregistrée. La qualité des données recueillies par l'entreprise dépend des réponses du client ; elles doivent donc être comparées à ce que révèle la chaîne : une « adresse personnelle » qui reçoit des fonds de dizaines d'inconnus ne se comporte pas comme telle.

Défaillances courantes

Les examens des contrôles relatifs aux portefeuilles auto-hébergés révèlent souvent les mêmes faiblesses :

• Des captures d'écran acceptées comme preuve pour des transferts de montant élevé ou à haut risque, parce que les méthodes plus fiables semblaient peu pratiques.
• Vérifier une fois et faire confiance pour toujours. Une adresse vérifiée il y a des années est toujours considérée comme vérifiée, alors que son comportement a complètement changé.
• Aucune donnée sur les tiers. Le formulaire de retrait ne demande qu'une adresse ; l'entreprise ne peut donc pas indiquer qui a reçu les fonds.
• Des contrôles déconnectés de la surveillance. Les résultats des vérifications de propriété et les liens déclarés sont stockés dans un système et ne sont jamais transmis aux règles de surveillance qui pourraient les exploiter.
• Un traitement incohérent. Différentes équipes appliquent des seuils ou des méthodes différents à des transferts similaires, sans que personne ne puisse expliquer pourquoi.

Chaque défaillance est facile à détecter : prélevez un échantillon d'adresses vérifiées, refaites la vérification à partir des justificatifs et comparez le lien déclaré avec le schéma observé sur la chaîne.

Cas pratique

Un client ayant deux ans d'ancienneté et un score de risque standard reçoit des ETH d'une valeur de 9 500 USD depuis une adresse auto-hébergée jamais vue auparavant. L'analyse ne révèle aucune exposition illicite. Le client déclare qu'il s'agit de son propre portefeuille.

1. Selon la politique, un premier transfert provenant d'une nouvelle adresse auto-hébergée dont le montant dépasse le seuil d'examen interne déclenche une vérification de propriété.
2. L'entreprise envoie un défi et le client renvoie une signature EIP-191 valide. L'adresse est vérifiée et consignée.
3. Les fonds sont crédités et l'adresse est ajoutée à la liste des adresses vérifiées du client, avec une date de réexamen.

Un mois plus tard, la même adresse effectue cinq transferts en une semaine, et l'analyse révèle qu'elle reçoit des fonds de plusieurs portefeuilles récemment créés et financés par une grappe d'adresses associée à une escroquerie connue. La preuve de propriété obtenue précédemment ne règle pas la question : l'analyste ouvre une alerte, interroge le client sur l'origine des fonds et envisage de déposer une déclaration de transaction suspecte.

Points clés pour l'examen : pourquoi les portefeuilles non hébergés ne peuvent pas recevoir de messages au titre de la Travel Rule et ce que le GAFI attend à la place (recueillir les informations auprès de son propre client, les conserver, effectuer un filtrage, surveiller les transactions et appliquer des contrôles fondés sur les risques) ; le fait que le GAFI n'interdit pas ces transferts ; les facteurs de risque et les contrôles gradués pour les transferts auto-hébergés ; les quatre méthodes de vérification de propriété et celles qui prouvent le contrôle de la clé (message signé, test du satoshi), par opposition à la simple visibilité (micro-transfert inversé) ou à l'absence de preuve (capture d'écran) ; les réserves concernant EIP-1271 et les signatures multiples ; la collecte de données sur les premières parties par opposition aux tiers ; le fait qu'une preuve de propriété ne vérifie la situation qu'à un instant donné et ne remplace pas la surveillance.