Règles KYT et scoring : vélocité et conditions

Chaque transaction soumise à Didit est évaluée au regard de toutes les règles actives de votre application. Les règles définissent des conditions, des contrôles de vélocité et des actions qui déterminent le statut final et le score de la transaction. Ce chapitre de la leçon sur le moteur de règles anti-fraude de Didit Academy reprend à la création d’une règle. La leçon du moteur de règles de Didit Academy crée une règle à l’écran à 7:54 : déclencheur, conditions, actions et notation, puis test rétrospectif avant le déploiement.

​

Lots de règles intégrés

Didit fournit une bibliothèque de règles préconfigurées couvrant les typologies réglementaires courantes. Installez les préréglages (ou des lots complets) de votre choix depuis la bibliothèque, dans la console, via l’API d’installation ou avec les outils MCP, et contrôlez le mode de chaque préréglage installé. Pour le catalogue complet de chaque règle prédéfinie, avec ses seuils et ses actions, consultez la bibliothèque de règles.

​

Sources des règles

Chaque règle possède une source qui indique qui la gère :

​

Anatomie d’une règle

Chaque règle se compose des éléments suivants :

​

Actions

Lorsqu’une règle correspond à une transaction, une ou plusieurs actions sont exécutées. Chaque règle peut comporter plusieurs actions, appliquées ensemble : La plupart des règles prédéfinies combinent ajouter un score avec changer le statut. Par exemple, une règle relative à une contrepartie sous sanctions ajoute 90 points au score et refuse immédiatement la transaction.

​

Exiger une vérification de l’utilisateur (AWAITING_USER)

Une action changer le statut → AWAITING_USER fait plus que définir un statut : Didit crée automatiquement une session de vérification hébergée pour le sujet de la transaction (même vendor_data) dès que la règle se déclenche. La session est renvoyée dans le bloc action_required de la transaction (ainsi que dans l’objet remediation) à la création et à chaque lecture ultérieure, ainsi que dans les deux webhooks de transaction. Vous pouvez donc rediriger l’utilisateur immédiatement. Voir actions requises de l’utilisateur. Les règles personnalisées doivent indiquer le workflow directement sur l’action (workflow_id) : l’éditeur de règles de la console comme l’API des règles l’exigent. Les règles de la bibliothèque intégrée ne contiennent pas de workflow. Pour elles, le workflow de la session est déterminé dans l’ordre suivant :

1. Le workflow de remédiation configuré dans vos paramètres de transaction.
2. Le workflow Authentification biométrique de votre application, lorsque le sujet dispose déjà d’un visage de référence enregistré à partir d’une vérification approuvée.
3. Le workflow par défaut de votre application.

Ainsi, les règles de la bibliothèque qui utilisent AWAITING_USER produisent toujours une session exploitable dès leur activation : une étape d’authentification biométrique renforcée pour les utilisateurs déjà vérifiés, et une vérification complète dans les autres cas. Les transactions Travel Rule sont exclues de ce mécanisme de repli automatique : leur attente AWAITING_USER concerne la preuve de propriété du portefeuille, qui suit son propre parcours. La meilleure option pour les transactions à haut risque est un workflow Authentification biométrique. Le sujet étant l’utilisateur dont vous avez déjà vérifié l’identité via un KYC, Didit réutilise le visage de référence vérifié issu de son onboarding (le selfie approuvé avec détection du vivant, la photo de la puce du passeport ou le portrait du document). L’utilisateur n’a qu’à prendre un selfie en direct : Didit effectue alors une détection du vivant et une correspondance faciale 1:1 avec l’identité qui a ouvert le compte. Les identifiants volés, les codes OTP obtenus par hameçonnage et les échanges de cartes SIM échouent tous à cette étape. Parcours complet : biométrie renforcée pour un retrait de montant élevé. Lorsque la session aboutit à une décision, la transaction suit automatiquement cette décision et un webhook transaction.status.updated est déclenché : une session approuvée approuve la transaction (decision_reason_code: user_action_approved), une session refusée refuse la transaction (user_action_declined), et une session qui se termine par un examen envoie la transaction en IN_REVIEW (user_action_in_review). Une session expirée ou abandonnée maintient la transaction en AWAITING_USER.

​

Notation

Lorsqu’une transaction correspond à une ou plusieurs règles, les scores sont combinés :

1. Chaque correspondance à une règle contribue au score de risque global de la transaction via l’action add_score.
2. Le score final détermine le statut de la transaction selon les seuils de score de votre application.
3. Si une règle comporte une action change_status, ce statut est appliqué directement. DECLINED prime toujours.

Seuils de score par défaut (configurables dans la console) :

​

Créer des règles personnalisées

Les règles personnalisées peuvent être créées depuis la Console Business ou via l’API de gestion (également accessible depuis le Didit MCP et tout assistant IA connecté au MCP). Les règles en mode Active prennent effet immédiatement pour toutes les nouvelles transactions. Les titres sont uniques par application.

​

Test rétrospectif

Avant d’activer une règle, vous pouvez la valider sur des données historiques :

• Passez une règle en mode Test : elle est évaluée sur chaque nouvelle transaction, mais ses résultats n’affectent ni le statut ni le score de la transaction. Les statistiques d’exécution (nombre de correspondances, entités concernées) s’accumulent afin de mesurer l’impact avant la mise en production.
• Utilisez la fonctionnalité backtest : dans la console ou via POST /v3/transactions/rules/backtest/, pour évaluer rétroactivement les conditions et l’agrégation d’une règle sur les transactions d’une période donnée. Le backtest renvoie le nombre de transactions évaluées et correspondantes, ainsi que les entités concernées, sans modifier aucune donnée historique. Envoyez les mêmes conditions, aggregation, evaluation_mode et scope que la règle que vous prévoyez d’activer : un périmètre omis signifie aucune restriction, donc le backtest compterait des transactions que la règle enregistrée ignore.

​

Fenêtres de vélocité (agrégation)

Les règles de vélocité agrègent les données historiques de transactions sur une période donnée pour détecter des schémas que les contrôles portant sur une seule transaction manqueraient : Chaque agrégation définit :

• Une fenêtre temporelle : <N>m (minutes), <N>h (heures) ou <N>d (jours), par exemple 30m, 6h, 7d, 30d. Attention : m correspond à des minutes, et non à des mois.
• Des filtres pour restreindre les transactions historiques incluses. Les clés sont des chemins de champs issus du catalogue des champs ; la valeur spéciale "__current__" correspond à la valeur du même champ sur la transaction évaluée (par exemple "subject_vendor_data": "__current__" limite la fenêtre au même sujet), et une liste de valeurs signifie appartenance. Les filtres comparent uniquement par égalité ou par appartenance : il n’existe pas de filtre lt/gte, donc une plage comme transactions de moins de 10,000 ne peut pas être exprimée par un filtre. Placez plutôt la plage sur la métrique (max inférieur à 10,000, min supérieur à 1,000), et rappelez-vous qu’une condition porte sur la transaction évaluée, jamais sur la fenêtre.
• Un opérateur et un seuil (eq, ne, gt, gte, lt, lte par rapport à value, par exemple count >= 20)

​

Exemples de schémas

​

Catalogue des champs

Les conditions et les filtres d’agrégation font référence aux champs de transaction par leur chemin :

​

Opérateurs de condition

Les règles prennent en charge les opérateurs de comparaison suivants pour les conditions : Tout autre opérateur exige une valeur value non vide, et l’API répond 400 sans elle. contains, not_contains et regex acceptent une seule chaîne, et non une liste ou un objet ; contains_any accepte une liste de chaînes.

​

Types de valeur de condition

Un value_type facultatif sur une condition modifie l’interprétation de value :

​

Conditions groupées

Une liste plate de conditions est combinée selon l’evaluation_mode de la règle (ALL/ANY). Pour une logique mixte, attribuez un group_index à chaque condition : les conditions qui partagent un même index forment un groupe, group_logic (AND/OR, par défaut AND) combine les conditions d’un groupe, et groups_logic sur la première condition (AND/OR, par défaut OR) combine les résultats des groupes. Lorsqu’une condition porte un group_index, l’évaluation groupée remplace evaluation_mode.

​

Référencer les propriétés personnalisées

Chaque clé envoyée dans l’objet custom_properties de POST /v3/transactions/ est enregistrée sur la transaction sous la forme custom_values et peut être utilisée dans les conditions avec le chemin de champ custom_values.<key>. Par exemple, une transaction envoyée avec "custom_properties": {"channel": "mobile_app"} correspond à la condition custom_values.channel eq "mobile_app". Tous les opérateurs ci-dessus fonctionnent avec les propriétés personnalisées, qui peuvent aussi être comparées à d’autres champs ou utilisées dans des filtres de vélocité. Dans le créateur de règles de la Console, les clés observées sur les transactions récemment ingérées apparaissent automatiquement dans le sélecteur de champs de condition, sous Propriétés personnalisées. Vous pouvez aussi référencer une clé avant qu’aucune transaction ne la porte : choisissez Saisir une propriété personnalisée dans le même groupe, puis saisissez la clé exactement comme votre intégration l’envoie (les clés sont sensibles à la casse). La règle est simplement évaluée comme non correspondante tant que des transactions portant cette clé n’arrivent pas.

​

Refus automatique par liste de blocage

Avant l’évaluation de toute règle, Didit vérifie les entités de la transaction par rapport aux listes de blocage de votre application. Si au moins une correspondance est trouvée, la transaction est immédiatement refusée : les règles ne sont pas évaluées. Les entités suivantes sont vérifiées : Lorsqu’une correspondance avec une liste de blocage est trouvée :

• Le statut de la transaction est défini sur DECLINED
• Le motif de décision est défini sur blocklisted
• Un enregistrement d’activité est créé pour le suivi d’audit

​

Filtrage des transactions

Didit s’intègre à des fournisseurs externes d’analyse AML et blockchain pour enrichir les transactions avec des informations de risque. Lorsqu’une transaction est soumise, le système peut :

• Filtrer les contreparties par rapport aux bases mondiales de sanctions et de listes de surveillance
• Évaluer les adresses de portefeuille (pour les transactions crypto) à partir des données d’analyse blockchain, y compris l’exposition à des mixeurs, les liens avec des entités sanctionnées et les interactions avec des services à haut risque
• Vérifier le statut AML du demandeur en comparant l’utilisateur lié à la transaction avec ses derniers résultats de filtrage AML

Les résultats de filtrage sont rattachés à la transaction et entrent dans le calcul du score du moteur de règles. Si une contrepartie ou un portefeuille correspond à une liste de sanctions, la règle correspondante signale ou refuse automatiquement la transaction.

​

Prochaines étapes