Règles de Vélocité et Détection de Structuration : Guide du Développeur (FR)

Regardez n'importe quel paiement unique et il ne vous dira généralement rien. 9 700 € à une contrepartie est anodin. Mais dix paiements de 9 700 € à la même contrepartie sur trois jours, ou vingt virements entrants de vingt comptes distincts en un après-midi, sont les signatures de la structuration et de l'activité de mule. Les détecter nécessite d'examiner les transactions comme un flux — dans le temps, avec des comptages et des sommes — et non une par une.

C'est ce que font les règles de vélocité, et c'est la partie la plus difficile de la surveillance des transactions à construire soi-même. Vous avez besoin d'un processeur de flux qui maintient des fenêtres glissantes par utilisateur, compte et somme et dé-duplique les contreparties à l'intérieur de ces fenêtres, et évalue les seuils en temps réel. L'API de Surveillance des Transactions de Didit vous offre ce moteur clé en main : définissez une fenêtre, choisissez une agrégation — nombre, somme ou distinct — définissez un seuil, et la règle s'exécute sur chaque transaction à 0,02 € par transaction.

Ceci est un guide du développeur pour construire des règles de vélocité et les utiliser pour détecter la structuration.

Points clés à retenir

• Les règles de vélocité évaluent sur des fenêtres temporelles — « au cours des dernières 24 heures », « sur 7 jours » — au lieu de noter une seule transaction isolément.
• Trois agrégations : count (combien), sum (montant cumulatif), et distinct (contreparties ou attributs uniques) — les éléments constitutifs de la détection de structuration et de mule.
• La structuration — de nombreux paiements juste en dessous d'un seuil de déclaration — est détectée en combinant une fenêtre de somme avec une condition de proximité de seuil.
• Les schémas de mules et de smurfing sont détectés avec des comptes de contreparties distinctes à l'intérieur d'une fenêtre.
• Aucun processeur de flux requis — le moteur maintient les fenêtres ; vous déclarez la règle dans la Console.
• 0,02 € par transaction, sans minimum. Le filtrage AML sur une partie signalée est facturé séparément à 0,20 €.

Ce que sont les règles de vélocité

Une règle de vélocité comporte trois parties : une fenêtre (la période de rétrospection — 1 heure, 24 heures, 7 jours), une agrégation sur les transactions dans cette fenêtre, et un seuil qui, lorsqu'il est franchi, déclenche une action. Les agrégations sont le cœur expressif :

• count — combien de transactions ont satisfait aux conditions de la règle dans la fenêtre. « Plus de 5 virements entrants en 24 heures. »
• sum — la valeur cumulative des transactions correspondantes. « Volume cumulatif de plus de 10 000 € en 7 jours. »
• distinct — le nombre de valeurs uniques d'un attribut, généralement la contrepartie. « Virements de plus de 8 expéditeurs distincts en 24 heures. »

Les fenêtres sont par défaut clés par sujet — chaque utilisateur a ses propres compteurs glissants — de sorte qu'une journée chargée pour l'ensemble de votre plateforme ne noie pas le signal d'un utilisateur individuel.

Pourquoi c'est important

La structuration (également appelée smurfing) est l'une des plus anciennes techniques de blanchiment et l'une des plus explicitement réglementées. Les seuils de déclaration — 10 000 € dans une grande partie de l'UE, 10 000 $ aux États-Unis — incitent à diviser de grandes sommes en plus petits paiements qui restent chacun sous la limite. Une règle ponctuelle qui ne vérifie que les montants uniques ne le verra jamais ; l'ensemble du schéma réside dans l'agrégat.

Il en va de même pour les réseaux de mules. Le signe distinctif d'une mule financière n'est pas un seul transfert — c'est l'afflux de fonds provenant de nombreux comptes distincts suivi d'un rapide écoulement. Vous ne le voyez qu'avec des comptes de contreparties distinctes sur une fenêtre. Les régulateurs s'attendent à ce que les entreprises détectent ces typologies, et les règles de vélocité sont la façon de le faire sans monter votre propre pile d'analyse de streaming.

Détails techniques

Les transactions sont créées via l'API unifiée /v3/, idempotente sur un transaction_id que vous contrôlez :

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_a19f04",
    "category": "finance",
    "amount": 9600,
    "currency": "EUR",
    "currency_kind": "fiat",
    "txn_date": "2026-05-21T13:18:00Z",
    "subject": { "vendor_data": "user_3310", "role": "SENDER", "entity_type": "INDIVIDUAL" },
    "counterparty": { "role": "RECEIVER", "entity_type": "INDIVIDUAL" },
    "payment_method": "BANK_TRANSFER"
  }'

Lorsque la transaction complète un schéma de structuration, la règle de vélocité se déclenche et la réponse la nomme :

{
  "transaction_id": "txn_a19f04",
  "status": "IN_REVIEW",
  "risk_score": 66,
  "triggered_rules": [
    {
      "name": "Structuration — somme cumulative proche du seuil",
      "bundle": "Finance",
      "aggregation": "sum",
      "window": "7d",
      "action": "CHANGE_STATUS"
    }
  ],
  "alert_id": "alrt_b4d8e1"
}

Webhooks. Abonnez-vous à transaction.created et transaction.status.updated pour maintenir votre grand livre synchronisé à mesure que les alertes sont résolues.

Prix. 0,02 € par transaction, facturé par appel, sans minimum. Le filtrage AML sur une partie signalée est facturé séparément à 0,20 €.

Construction de règles de structuration et de mules

Structuration (fenêtre de somme). Combinez une agrégation sum sur une fenêtre de 7 jours avec une condition par transaction selon laquelle le montant se situe juste en dessous de votre seuil de déclaration. La règle se déclenche lorsque le cumul des paiements d'un utilisateur juste en dessous du seuil dépasse une ligne que vous avez définie — la transaction agrégée importante que la structuration était censée masquer. Ajustez la proximité du seuil (à quel point la ligne de déclaration est considérée comme « juste en dessous ») et le déclencheur cumulatif.

Smurfing (fenêtre de nombre). Une agrégation count sur une courte fenêtre détecte une rafale de petits paiements. « Plus de 10 virements sortants de moins de 1 000 € en 24 heures » fait apparaître le schéma de fragmentation même lorsqu'aucun paiement unique n'est important.

Afflux de mules (fenêtre distincte). Une agrégation distinct sur la contrepartie détecte l'afflux : « Virements entrants de plus de 8 expéditeurs distincts en 24 heures. » Associez-le à une règle de nombre de sorties rapides et vous avez décrit la signature complète de la mule.

Celles-ci correspondent aux ensembles prédéfinis — la structuration et l'évitement de seuil se trouvent dans Finance, le volume cumulatif et les entrées/sorties rapides dans AML/CTF, les pics de vélocité dans la détection d'anomalies — et vous pouvez étendre n'importe lequel d'entre eux, ou créer le vôtre, dans l'ensemble Personnalisé. L'action de chaque règle peut ajouter au score de risque, modifier le statut, ajouter des balises ou ajouter la partie à une liste.

Cas d'utilisation

• Fintech — règles de structuration par somme cumulative sur les transferts et les retraits ; règles de mule par contrepartie distincte sur les dépôts entrants.
• Crypto — fenêtres de comptage sur l'activité rapide d'entrée et de sortie de portefeuille ; règles distinctes sur les fonds arrivant de nombreuses adresses avant une seule sortie importante.
• Prêt — règles de vélocité sur les schémas de décaissement et de remboursement pour détecter la fraude au « bust-out » (fraude de consommation de crédit sans intention de remboursement).
• Places de marché — règles de comptage d'acheteurs distincts pour détecter les cercles de transactions collusoires gonflant le volume d'un vendeur.
• iGaming — fenêtres de comptage de la vélocité des dépôts qui servent également de signal de jeu responsable.

Comment s'intégrer à Didit

1. Définissez les fenêtres. Dans la Console d'entreprise, créez des règles de vélocité avec la fenêtre, l'agrégation (nombre/somme/distinct) et le seuil requis par votre politique.
2. Envoyez les transactions. POST /v3/transactions/ depuis votre backend à mesure que l'argent circule, avec un transaction_id stable et un vendor_data afin que le moteur associe les fenêtres au bon sujet.
3. Gérez les webhooks. Écoutez transaction.status.updated pour réagir lorsqu'une règle de vélocité se déclenche et qu'un analyste résout l'alerte.
4. Ajustez au fil du temps. Ajustez les seuils dans la console à mesure que vous apprenez vos taux de vrais positifs et de faux positifs — aucun déploiement n'est requis.

Parce que tout est sur l'API unifiée /v3/, un utilisateur intégré avec les flux KYC passe directement dans le même moteur qui exécute ces règles de vélocité — une plateforme d'identité et de fraude, de bout en bout.

Questions fréquemment posées

Quelles agrégations une règle de vélocité peut-elle utiliser ?

Trois : count (nombre de transactions correspondantes), sum (montant cumulatif) et distinct (contreparties ou attributs uniques), chacune évaluée sur une fenêtre temporelle que vous définissez.

Comment détecter spécifiquement la structuration ?

Combinez une agrégation sum sur une fenêtre avec une condition selon laquelle chaque paiement se situe juste en dessous de votre seuil de déclaration. La règle se déclenche lorsque le total cumulatif dépasse la ligne que la structuration était censée masquer.

Ai-je besoin de mon propre processeur de flux ?

Non. Le moteur maintient les fenêtres glissantes par sujet. Vous déclarez la fenêtre, l'agrégation et le seuil dans la Console.

Combien ça coûte ?

0,02 € par transaction, facturé par appel sans minimum. Le filtrage AML sur une partie signalée est facturé séparément à 0,20 €.

Puis-je créer des règles de vélocité que les ensembles prédéfinis ne couvrent pas ?

Oui. L'ensemble Personnalisé prend en charge les conditions, les fenêtres de vélocité et les agrégations pour toute typologie unique à votre produit.

Prêt à commencer ?

Lisez l' aperçu de la surveillance des transactions dans la documentation, voyez comment cela s'intègre au reste de la plateforme sur la page produit de la surveillance des transactions, et vérifiez les prix transparents par appel sur la page de tarification. Lorsque vous êtes prêt, commencez gratuitement — 500 vérifications KYC gratuites chaque mois, et la surveillance des transactions à 0,02 € par appel.