> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

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

> Configurez des règles KYT avec Didit : conditions, fenêtres de vélocité, actions automatisées. 1,000 par mois inclus, puis $0.001 chacun.

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.

[Création d'une règle : Didit Academy](https://www.youtube.com/embed/Yhm63_n7HuU?start=474\&rel=0\&playsinline=1)

> [!NOTE]
>
> Les règles peuvent être gérées depuis la **Business Console**, la **Management API** et le **Didit MCP**. Utilisez la console lorsqu'une personne de votre équipe conformité doit examiner chaque modification ; utilisez l'API ou le MCP lorsque les règles sont créées et ajustées par programmation - par exemple lors de la migration d'un jeu de règles depuis un autre fournisseur. Consultez la [référence de l'API](https://docs.didit.me/fr/management-api/transactions/rules-list.md) et le [guide de gestion des règles via l'API et le MCP](https://docs.didit.me/fr/transaction-monitoring/rules-api.md). Les règles sont évaluées à chaque transaction soumise via [`POST /v3/transactions/`](https://docs.didit.me/fr/management-api/transactions/create), et le résultat apparaît dans le tableau `rule_runs[]` de la transaction (voir le [schéma de réponse](https://docs.didit.me/fr/transaction-monitoring/response-schema.md)).

## 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](https://docs.didit.me/fr/management-api/transactions/rules-install.md) 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](https://docs.didit.me/fr/transaction-monitoring/rules-library.md).

| Lot | Exemples |
| - | - |
| **Finance** | Détection du fractionnement (entrant/sortant), transactions uniques élevées au-dessus des seuils de déclaration |
| **AML/CTF** | Limites de volume cumulé, mouvements rapides d'entrée et de sortie, correspondance des contreparties avec les sanctions, mots-clés suspects dans les références de paiement |
| **Détection des anomalies** | Vélocité élevée entrante/sortante, réactivation de compte dormant après 12+ mois d'inactivité |
| **FATF** | Exposition des contreparties et des adresses IP des sujets à des juridictions à haut risque |
| **Intelligence des appareils** | Utilisation répétée d'une campagne de bonus depuis la même empreinte d'appareil, plusieurs empreintes d'appareil pour le même sujet |
| **Prévention de la fraude** | Multicompte via des empreintes d'appareil partagées entre des sujets distincts |
| **Surveillance crypto** | Exposition à des services de mixage ou d'obfuscation, adresses de portefeuille à haut risque (darknet, sanctionnées, fonds volés) |
| **Filtrage crypto** | Exposition élevée à l'origine des fonds (>30%), plusieurs contreparties risquées, refus automatique pour financement du terrorisme ou exploitation d'enfants, blocage en attente de filtrage, signalement d'un score de risque moyen du portefeuille |
| **Jeu responsable** | Rafales de dépôts rapprochés sur de courtes fenêtres |
| **E-commerce** | Schémas de transaction propres au e-commerce |

## Sources des règles

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

| Source | Description |
| - | - |
| **Préréglage** | Règles installées depuis la bibliothèque intégrée de Didit. Vous choisissez les préréglages (ou les lots complets) à installer et vous contrôlez le mode de chaque préréglage installé (`Active`, `Test`, `Disabled`). Leurs conditions et seuils sont fixes : pour en remplacer un, créez une règle personnalisée. Elles sont supprimées par désinstallation et non par suppression. |
| **Personnalisé** | Règles créées par votre équipe depuis la Business Console. Vous avez un contrôle total sur les règles personnalisées : créez-les, modifiez-les et supprimez-les selon vos besoins. |

## Anatomie d'une règle

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

| Composant | Description |
| - | - |
| **Titre et description** | Nom compréhensible par un humain et explication de ce que la règle détecte |
| **Catégorie** | Regroupement logique (par exemple `finance`, `aml_ctf`, `crypto_monitoring`, `device_intelligence`) |
| **Mode** | `Active` (évaluation en direct), `Disabled` (ignorée) ou `Test` (évaluée, mais les résultats n'affectent pas la transaction) |
| **Mode d'évaluation** | `All` (chaque condition doit être satisfaite) ou `Any` (au moins une condition doit être satisfaite) |
| **Périmètre** | Limite les transactions auxquelles la règle s'applique. Clés : `transaction_types`, `directions` (`INBOUND`/`OUTBOUND`), `action_types`. Vide ou absent signifie qu'aucune restriction ne s'applique |
| **Conditions** | Comparaison des champs de la transaction à des valeurs à l'aide d'opérateurs tels que `eq`, `lt`, `gte`, `in`, `contains_any`, `exists` |
| **Agrégation** | Fenêtres de vélocité : agrège les transactions historiques sur une période (par exemple nombre, somme ou nombre de valeurs distinctes sur 1 heure, 7 jours, 30 jours) |
| **Actions** | Ce qui se passe lorsque la règle est satisfaite (voir ci-dessous) |

## 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 :

| Action | `type` | Clés | Description |
| - | - | - | - |
| **Ajouter un score** | `add_score` | `value` (entier, peut être négatif) | Ajoute des points au score de risque de la transaction. Le score cumulé de toutes les règles correspondantes détermine si la transaction franchit le seuil d'examen ou le seuil de refus. |
| **Changer le statut** | `change_status` | `value` (`APPROVED`\|`IN_REVIEW`\|`DECLINED`\|`AWAITING_USER`, alias `status`), `workflow_id` (alias `remediation_workflow_id`) | Définit directement le statut de la transaction, indépendamment du score. `workflow_id` est obligatoire lorsque `value` vaut `AWAITING_USER` : son omission renvoie `400`. |
| **Ajouter des étiquettes** | `add_tags` | `tag_uuid` ou `tag_name` (l'un des deux), `tag_color` | Étiquette la transaction pour la catégoriser et la filtrer. Il s'agit soit du `tag_uuid` d'une étiquette existante, soit d'un `tag_name` créé à la première utilisation (stocké en majuscules). `tag_color` définit la couleur hexadécimale d'une étiquette nouvellement créée. |
| **Ajouter une note** | `add_note` | `note` (alias `value`) | Joint une note textuelle automatique à la transaction, afin de fournir un contexte aux analystes. |
| **Ajouter à une liste** | `add_to_list` | `list_id` | Ajoute le `vendor_data` du sujet à une liste de blocage, une liste d'autorisation ou une liste personnalisée. |
| **Ouvrir un dossier** | `open_case` | `blueprint` (UUID du modèle de dossier, facultatif), `grouping` (`by_applicant`\|`by_rule_and_applicant`), `attach_matched_transaction` (booléen) | Ouvre un dossier d'enquête, ou ajoute la transaction à un dossier existant. Seule la première action `open_case` d'une règle est appliquée. |

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](https://docs.didit.me/fr/transaction-monitoring/sdk-transaction-submission.md#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](https://docs.didit.me/fr/transaction-monitoring/settings.md#workflow-de-remédiation).
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](https://docs.didit.me/fr/transaction-monitoring/wallet-ownership-widget.md).

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é](https://docs.didit.me/fr/transaction-monitoring/sdk-transaction-submission.md#exemple-de-renforcement-biométrique-pour-un-retrait-d’un-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`.

> [!NOTE]
>
> Tout type de workflow, à l'exception du KYB, peut être utilisé comme action de remédiation.
> Les workflows Authentification biométrique (et les workflows dans lesquels la correspondance faciale intervient avant la vérification d'identité) exigent en outre un visage de référence enregistré pour le sujet : un selfie approuvé avec détection du vivant, une photo de la puce du passeport, un portrait du document ou un visage du profil enregistré manuellement.
> Si aucun visage de ce type n'existe, l'utilisateur est invité à effectuer à la place le workflow par défaut de votre application, qui enregistre aussi son visage pour la prochaine fois. Une note sur la transaction indique cette substitution.
> La session n'est ignorée que si aucun workflow par défaut approprié n'existe non plus, et la note en explique alors la raison.

## 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) :

| Paramètre | Par défaut | Description |
| - | - | - |
| **Seuil d'examen** | 75 | Les scores égaux ou supérieurs à cette valeur déclenchent `IN_REVIEW` |
| **Seuil de refus** | 500 | Les scores égaux ou supérieurs à cette valeur déclenchent `DECLINED`. La valeur par défaut (`500`) ne refuse jamais une transaction en fonction du score |

## 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](https://docs.didit.me/fr/integration/mcp/tools.md) et tout assistant IA connecté au MCP).

> [tab] Console
>
> 1. Accédez à **Transactions** > **Règles** dans la console
> 2. Cliquez sur **Create Rule**
> 3. Définissez le titre, la description et la catégorie de la règle
> 4. Définissez le **mode** : `Active` pour une exécution en production, ou `Test` pour évaluer sans affecter les transactions
> 5. Choisissez le **mode d'évaluation** : `All` (toutes les conditions doivent correspondre) ou `Any` (au moins une)
> 6. Définissez le **périmètre** : les types ou sens de transaction auxquels la règle s'applique
> 7. Ajoutez des **conditions** : comparaisons de champs, comme des seuils de montant, des codes pays ou des contrôles de propriétés personnalisées
> 8. Ajoutez éventuellement une **agrégation** : contrôles de vélocité sur une fenêtre temporelle (nombre, somme, nombre de valeurs distinctes, et plus encore)
> 9. Définissez une ou plusieurs **actions** : ajouter un score, modifier le statut, ajouter des tags, ajouter des notes, ajouter à une liste ou ouvrir un dossier
> 10. Enregistrez et activez la règle

> [tab] API
>
> Appelez [`POST /v3/transactions/rules/`](https://docs.didit.me/fr/management-api/transactions/rules-create) avec les mêmes champs : `title`, `category`, `mode`, `evaluation_mode`, `scope`, `conditions`, `aggregation`, `actions`. La référence complète des champs, des opérateurs et des actions se trouve sur cette page, et [gestion des règles via l'API et le MCP](https://docs.didit.me/fr/transaction-monitoring/rules-api.md) détaille le workflow recommandé : créer -> backtester -> activer, y compris la migration d'un jeu de règles depuis un export CSV d'un autre fournisseur.

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/`](https://docs.didit.me/fr/management-api/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 :

| Métrique | Description |
| - | - |
| `count` | Nombre de transactions correspondant aux filtres dans la fenêtre |
| `sum` | Total d'un `field` numérique (par exemple `preferred_currency_amount`) dans la fenêtre |
| `max` / `min` / `avg` | Valeur maximale, minimale ou moyenne d'un `field` numérique dans la fenêtre |
| `distinct_count` | Nombre de valeurs uniques d'un `field` (par exemple des empreintes d'appareil distinctes) dans la fenêtre (`unique_count` est un alias accepté) |

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](#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

| Schéma | Fonctionnement |
| - | - |
| **Structuration** | Nombre de transactions pour le même sujet sur 30 jours >= 20, avec un montant `max` inférieur à \$10,000 sur la même fenêtre |
| **Vélocité élevée** | Nombre de transactions entrantes pour le même sujet sur 7 jours >= 20 |
| **Entrée-sortie rapide** | La transaction actuelle est sortante, et le nombre de transactions entrantes pour le même sujet sur 6 heures >= 1 |
| **Multi-comptes** | Nombre de sujets distincts partageant la même empreinte d'appareil sur 7 jours >= 3 |
| **Réactivation après dormance** | Nombre de jours depuis la transaction précédente du sujet >= 365, combiné à un montant >= \$1,000 |

## Catalogue des champs

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

| Champ | Description |
| - | - |
| `amount`, `currency` | Le montant de la transaction et son code de devise |
| `preferred_currency_amount`, `default_currency_code` | Montant converti dans la devise préférée de votre application (revient à `amount_in_default_currency`) |
| `direction` | `INBOUND` ou `OUTBOUND` |
| `action_type` | Votre type d'action, par exemple `withdrawal`, `deposit`, `bet` |
| `transaction_type` | `finance`, `kyc`, `travelRule`, `userPlatformEvent` |
| `payment_details` | Référence de paiement en texte libre (la cible de `contains_any` pour les règles de mots-clés) |
| `score`, `severity` | Le score de risque actuel de la transaction et sa gravité |
| `subject_vendor_data`, `counterparty_vendor_data` | Vos identifiants pour les deux parties |
| `subject_country`, `counterparty_country` | Codes pays des parties (ISO-2 et ISO-3 sont tous deux acceptés ; ils sont normalisés avant comparaison) |
| `subject_device_fingerprint`, `counterparty_device_fingerprint` | Empreinte de l'appareil ou identifiant d'appareil persistant |
| `subject_browser_family`, `subject_browser_version`, `subject_platform`, `subject_accept_language`, `subject_session_age_ms` | Détails du contexte de l'appareil (`counterparty_browser_family` est également disponible) |
| `subject_ip_address`, `subject_ip_country`, `counterparty_ip_address`, `counterparty_ip_country` | Contexte réseau |
| `subject_payment_method_type`, `subject_payment_method_country`, `subject_payment_method_fingerprint`, `subject_payment_method_account_id` | Le moyen de paiement côté sujet (les mêmes quatre champs existent pour `counterparty_payment_method_*`) |
| `travel_rule_status`, `travel_rule_required`, `travel_rule_obligations_count` | État de la vérification Travel Rule |
| `counterparty_dd_status`, `counterparty_risk_level`, `counterparty_jurisdiction`, `counterparty_responsiveness` | Ce que vous savez de la VASP contrepartie que l'échange Travel Rule a atteinte : votre décision à son sujet (`APPROVED`, `RESTRICTED`, `BLOCKED`), son niveau de risque (`LOW`, `MEDIUM`, `HIGH` ; `HIGH` tant que votre propre filtrage de la contrepartie est signalé), son pays et sa réactivité (`RESPONSIVE`, `UNRESPONSIVE`, `UNKNOWN`). Voir [Diligence raisonnable à l'égard de la contrepartie dans le cadre de la Travel Rule](https://docs.didit.me/fr/transaction-monitoring/travel-rule.md#champs-de-règle-et-préréglages) |
| `subject_days_since_previous_transaction` | Nombre de jours depuis la transaction précédente de ce sujet, du même type (règles d'inactivité) |
| `tags` | Les noms des tags de la transaction |
| `custom_values.<key>` | Toute clé que vous avez envoyée dans `custom_properties` lors de la création de la transaction |

## Opérateurs de condition

Les règles prennent en charge les opérateurs de comparaison suivants pour les conditions :

| Opérateur | Description | Exemple |
| - | - | - |
| `eq` / `ne` | Égal / différent | `direction eq "OUTBOUND"` |
| `gt` / `gte` / `lt` / `lte` | Comparaisons numériques et de dates ; ne correspondent jamais si l'un des deux côtés est absent | `preferred_currency_amount gte 25000` |
| `in` / `not_in` | Appartenance à une liste (une valeur scalaire unique est aussi acceptée) | `counterparty_country in ["IRN", "PRK", "SYR"]` |
| `contains` / `not_contains` | Sous-chaîne sans distinction de casse dans une valeur de type chaîne | `payment_details contains "refund"` |
| `contains_any` | Au moins une chaîne d'une liste est une sous-chaîne du champ, sans distinction de casse | `payment_details contains_any ["terror", "weapon"]` |
| `regex` | Le champ correspond au motif de la valeur | `subject_vendor_data regex "^guest-"` |
| `fuzzy_match` | Similarité approximative de chaînes ; exige un seuil `score` (0-100) sur la condition | `counterparty_name fuzzy_match "Acme Corp"` avec `score: 85` |
| `exists` / `is_not_empty` / `is_not_null` | Le champ est présent (alias ; `value` est ignoré) | `subject_device_fingerprint exists` |
| `not_exists` / `is_empty` / `is_null` | Le champ est absent ou vide (alias ; `value` est ignoré) | `subject_ip_address is_empty` |

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` :

| `value_type` | Signification |
| - | - |
| `list` | `value` est un UUID de liste : les entrées de la liste de blocage, de la liste d'autorisation ou de la liste personnalisée deviennent la valeur de comparaison, ce qui permet à une règle de correspondre à « contrepartie présente dans ma liste de surveillance personnalisée ». |
| `field` | `value` est un autre chemin de champ : la condition compare deux champs de transaction, par exemple `subject_payment_method_account_id ne counterparty_payment_method_account_id`. |
| `relative_date` | `value` est une date relative, par exemple `{"direction": "past", "unit": "days", "amount": 30}`, pour des champs de date comme `txn_date`. |

### 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/`](https://docs.didit.me/fr/transaction-monitoring/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 :

| Entité | Type de liste de blocage | Ce qui est vérifié |
| - | - | - |
| **Utilisateur (demandeur)** | Liste de blocage des utilisateurs | L'identifiant `vendor_data` du demandeur |
| **Entreprise** | Liste de blocage des entreprises | L'identifiant `vendor_data` de l'entreprise |
| **Adresse du portefeuille** | Liste de blocage des adresses de portefeuille | Le `account_id` des moyens de paiement de portefeuilles crypto |
| **Compte bancaire** | Liste de blocage des comptes bancaires | Le `account_id` des moyens de paiement par virement bancaire |
| **Adresse IP** | Liste de blocage des adresses IP | L'adresse IP issue du contexte de l'appareil de la partie (prend en charge les plages CIDR) |
| **Empreinte de l'appareil** | Liste de blocage des empreintes d'appareil | L'empreinte de l'appareil ou l'identifiant persistant de l'appareil |

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

> [!NOTE]
>
> Les vérifications des listes de blocage s'exécutent avant l'évaluation des règles. Une entité figurant sur une liste de blocage est toujours refusée, quelle que soit la configuration des règles ou les seuils de score.

## 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

> [card] [Soumission de transactions](https://docs.didit.me/fr/transaction-monitoring/transactions.md)
>
> Comment les transactions sont structurées pour l'évaluation des règles.

> [card] [Filtrage crypto](https://docs.didit.me/fr/transaction-monitoring/aml-screening.md)
>
> Résultats du filtrage crypto et utilisation qu'en font les règles prédéfinies.

> [card] [Paramètres](https://docs.didit.me/fr/transaction-monitoring/settings.md)
>
> Configurez les seuils de score et les workflows de remédiation.

> [card] [Référence de l'API](https://docs.didit.me/fr/management-api/transactions/create.md)
>
> Endpoint de l'API de création de transaction.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.