Surveillance des transactions pour les entreprises de cryptoactifs

La vigilance à l’égard de la clientèle indique à une entreprise qui est son client ; la surveillance des transactions lui permet de savoir si l’activité du client correspond toujours à ce profil. Pour une entreprise de cryptoactifs, c’est lors de la surveillance que la plupart des activités suspectes sont détectées. C’est aussi là que les autorités de contrôle constatent le plus souvent que des programmes, complets sur le papier, détectent peu de choses. Cette leçon explique le fonctionnement de la surveillance à partir des données en monnaie fiduciaire et des données de la chaîne de blocs, ce que recouvre réellement le « KYT » et comment construire un scénario simple.

À quoi sert la surveillance

La recommandation 10 du GAFI impose une vigilance continue, notamment l’examen des transactions tout au long de la relation afin de vérifier qu’elles correspondent aux informations dont l’entreprise dispose sur le client, son activité, son profil de risque et, le cas échéant, l’origine des fonds. La recommandation 20 exige de signaler à la cellule de renseignement financier les cas où l’entreprise soupçonne, ou a des motifs raisonnables de soupçonner, que des fonds proviennent d’une activité criminelle ou sont liés au financement du terrorisme. La surveillance est le mécanisme qui relie ces deux obligations : elle transforme des millions d’événements en un nombre gérable de questions auxquelles une personne peut répondre.

Trois contrôles liés sont souvent confondus :

Le filtrage est binaire et fondé sur des listes (voir la leçon Filtrage des portefeuilles et des transactions). La surveillance est comparative : elle examine les comportements dans le temps, par rapport au profil du client, à ses pairs et aux typologies. Les résultats des trois contrôles devraient être consignés dans le même système de gestion des dossiers, car un client peut déclencher les trois à la fois.

Deux univers de données : monnaie fiduciaire et chaîne de blocs

Une entreprise de cryptoactifs qui utilise de la monnaie fiduciaire doit surveiller deux flux très différents.

Le flux sur la chaîne de blocs est plus riche que tout ce dont disposent les banques : une équipe de conformité peut examiner l’origine des fonds déposés plusieurs transactions avant leur arrivée, ainsi que leur destination après un retrait. Son point faible est l’identité. Une adresse n’est pas une personne, et l’attribution est probabiliste (voir la leçon Analyse de la chaîne de blocs à des fins de conformité). Le flux en monnaie fiduciaire présente le profil inverse : l’identité est bien établie, mais la visibilité s’arrête à la banque de la contrepartie. Les détections les plus efficaces combinent les deux, par exemple un dépôt en cryptoactifs présentant une exposition indirecte à un groupe lié à une fraude, suivi quelques heures plus tard d’un retrait en monnaie fiduciaire vers un compte bancaire récemment ajouté.

Les transferts internes comptent aussi. De nombreuses plateformes règlent les transactions entre clients dans un registre interne, sans recourir à la chaîne. Un programme de surveillance qui ne lit que les données de la chaîne de blocs ne détectera donc pas les mouvements entre clients, les transactions à perte visant à transférer de la valeur ni les conversions rapides entre actifs.

Ce que signifie le KYT et ce qu’il ne signifie pas

Le KYT (« know your transaction », ou « connaître sa transaction ») est un terme du secteur désignant le filtrage des transferts de cryptoactifs à l’aide de l’analyse de la chaîne de blocs : l’adresse et son groupe sont évalués en fonction de leur exposition à des catégories de risque telles que les marchés du darknet, les escroqueries, les fonds volés, les rançongiciels, les entités sanctionnées et les mélangeurs. Cette approche est utile, et les Orientations actualisées du GAFI pour une approche fondée sur les risques des actifs virtuels et des prestataires de services d’actifs virtuels (octobre 2021) mentionnent l’analyse de la chaîne de blocs parmi les outils pouvant contribuer à évaluer les risques et à repérer les comportements suspects.

À lui seul, le KYT ne constitue pas un programme de surveillance des transactions. En général, il :

• évalue chaque transfert en fonction de l’exposition de sa contrepartie, mais ne connaît pas le profil, la profession, les volumes attendus ni l’historique du client ;
• ne voit pas l’activité en monnaie fiduciaire, les mouvements dans le registre interne, les connexions, les données des appareils ni les changements apportés aux informations du compte ;
• détecte les fonds liés à des groupes illicites connus, mais pas un client qui blanchit des fonds d’apparence légitime au moyen d’un comportement inhabituel ;
• dépend d’étiquettes qui peuvent être manquantes, obsolètes ou erronées.

Lorsqu’une autorité de contrôle demande « comment assurez-vous la surveillance ? » et entend « nous utilisons un outil KYT », elle demandera ensuite comment les comportements sont surveillés, comment les seuils de l’outil ont été définis et qui les a validés. Un programme complet utilise l’analyse comme l’un de plusieurs éléments d’information.

Règles, scénarios et analyse comportementale

Un scénario décrit une typologie en termes détectables ; une règle est sa mise en œuvre à l’aide de paramètres (seuils, fenêtres temporelles, ratios) et d’une population à laquelle elle s’applique. Un scénario comme « mouvement rapide de fonds » peut utiliser des paramètres différents pour les clients particuliers, les entreprises et les teneurs de marché. Le regroupement des clients en segments ayant des comportements attendus similaires permet d’éviter qu’un même seuil ne submerge la file d’attente d’un groupe tout en laissant passer des activités dans un autre.

La plupart des programmes les plus matures sont hybrides : des règles pour les typologies connues et les attentes réglementaires, et des outils d’analyse pour hiérarchiser les alertes et repérer ce que les règles ne détectent pas. La leçon Paramétrage, indicateurs et gouvernance des modèles explique comment chacun de ces éléments est testé.

Temps réel et traitement par lots

Le moment du contrôle dépend de la décision que l’entreprise doit prendre.

• Les contrôles avant la transaction (en temps réel) sont effectués avant la diffusion d’un retrait sur la chaîne ou le crédit d’un dépôt. Ils conviennent aux signaux qui justifient l’interruption du transfert : destination désignée ou à haut risque, retrait vers un groupe lié à une escroquerie, schéma de prise de contrôle de compte. Une fois une transaction inscrite sur la chaîne, elle ne peut pas être rappelée.
• Les contrôles après la transaction (quasi en temps réel ou par lots) examinent les tendances sur plusieurs heures, jours ou mois : fractionnement, entrées et sorties rapides, évolution lente du comportement, liens de réseau entre clients. Ils sont généralement exécutés par lots et génèrent des alertes à examiner.

Règle de conception utile : tout élément qui vous amènerait à refuser ou à suspendre un transfert doit être contrôlé avant celui-ci ; tout élément nécessitant l’observation d’une tendance peut être contrôlé après.

Relier les données client aux données de la chaîne de blocs

La surveillance ne fonctionne que si chaque événement peut être associé à un client et enrichi. Les principales correspondances sont les suivantes :

1. Client et adresse. Chaque adresse de dépôt attribuée par l’entreprise et chaque adresse de retrait utilisée par un client sont associées à un identifiant client. La réutilisation d’adresses de retrait par plusieurs clients constitue en soi un signal.
2. Transfert et analyse. Chaque transfert comporte l’entité attribuée à la contrepartie, sa catégorie de risque et son niveau d’exposition, ainsi que la source et la date de l’étiquette.
3. Transfert et données de la Travel Rule. Prestataire de services d’actifs virtuels de la contrepartie, nom du donneur d’ordre ou du bénéficiaire (voir la leçon Données et messagerie de la Travel Rule).
4. Transfert et profil du client. Segment, niveau de risque, activité attendue et origine des fonds déclarée.
5. Cours. Chaque montant est converti dans une devise de référence au moment du transfert, à partir d’une source enregistrée, afin que les seuils s’appliquent de façon cohérente à tous les actifs.

L’absence de correspondance constitue une défaillance silencieuse : un jeton sans cours, une adresse non associée à un client ou un appel à un service d’analyse qui expire signifie qu’un transfert ne sera évalué par aucune règle. Le contrôle de l’exhaustivité de ces correspondances fait partie du programme.

Une règle simple en SQL

La règle ci-dessous met en œuvre un scénario de « mouvement rapide de fonds » pour les clients particuliers : un dépôt en cryptoactifs d’une contre-valeur d’au moins 5 000 USD, suivi dans les 24 heures de retraits totalisant au moins 80 % de ce montant.

-- Mouvement rapide de fonds : dépôt d'une contre-valeur d'au moins 5 000 USD,
-- puis retraits représentant au moins 80 % de ce montant dans les 24 heures
WITH pairs AS (
  SELECT d.customer_id, d.tx_id AS deposit_tx, d.usd_value AS deposit_usd,
         SUM(w.usd_value) AS out_usd, COUNT(w.tx_id) AS n_out,
         MAX(w.ts) - d.ts AS time_to_last_out
  FROM transfers d
  JOIN transfers w
    ON w.customer_id = d.customer_id AND w.direction = 'OUT'
   AND w.ts > d.ts AND w.ts <= d.ts + INTERVAL '24' HOUR
  WHERE d.direction = 'IN' AND d.usd_value >= 5000
  GROUP BY d.customer_id, d.tx_id, d.usd_value, d.ts
)
SELECT p.*, c.risk_rating, c.expected_monthly_usd
FROM pairs p
JOIN customers c ON c.customer_id = p.customer_id
WHERE p.out_usd >= 0.8 * p.deposit_usd
  AND c.segment = 'RETAIL';

La requête fait une jointure de la table des transferts avec elle-même : chaque dépôt répondant aux critères est associé aux retraits du même client au cours des 24 heures suivantes, puis les retraits sont additionnés. Elle effectue ensuite une jointure avec la table des clients, ne conserve que le segment des particuliers et renvoie le niveau de risque et le volume mensuel attendu afin que l’analyste puisse consulter le profil en regard de l’alerte. La syntaxe des intervalles varie selon les moteurs (certains utilisent une fonction d’ajout de date). En production, le seuil de 5 000, la fenêtre de 24 heures et le ratio de 0,8 figureraient dans une table de paramètres, avec un responsable et un historique des modifications, plutôt que dans le code, afin que les décisions de paramétrage soient consignées et testables.

Points clés pour l'examen : la surveillance comme obligation de contrôle continu au titre de la R.10, qui alimente les déclarations au titre de la R.20 ; la différence entre le filtrage, la surveillance et les vérifications au titre de la Travel Rule ; les données en monnaie fiduciaire par rapport aux données sur la chaîne de blocs et l’importance de surveiller les transferts dans le registre interne ; ce que couvre le KYT et ses limites ; les scénarios, les règles, les paramètres et les segments, ainsi que les différences entre les règles et l’analyse comportementale ou les modèles hybrides ; les contrôles à effectuer avant la transaction plutôt que par lots ; les cinq principales correspondances de données et les correspondances incomplètes comme défaillance silencieuse ; la lecture d’une règle SQL simple et la gestion des paramètres en dehors du code.