> ## 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. # Notation du risque de transaction : formule et seuils > Comment Didit calcule le score de risque de chaque transaction : règles, seuils et statuts. 1,000 par mois inclus, puis $0.001 chacun. Chaque transaction reçoit un **score** : un entier qui résume son niveau de risque. Le score détermine le statut de la transaction (`APPROVED`, `IN_REVIEW`, `DECLINED`) ainsi que la décision de créer une alerte, d'ouvrir un dossier ou d'exiger une régularisation de la part de l'utilisateur. ## Le calcul ``` score = Σ(score_delta of every matched rule) ``` * Score de base : 0. * Chaque règle correspondante ajoute son `score_delta` configuré (généralement entre 25 et 35). * Une transaction sans règle correspondante obtient un score de 0. ## Seuils et statuts Les seuils de score sont configurés par application, dans *Transactions → Paramètres*. | Paramètre | Valeur par défaut | Signification | | - | - | - | | `preferred_review_score_threshold` | 75 | Les scores ≥ cette valeur passent en `IN_REVIEW` | | `preferred_decline_score_threshold` | 500 | Les scores ≥ cette valeur passent en `DECLINED`. La valeur par défaut, qui est aussi la valeur maximale (`500`), signifie « ne jamais refuser sur la base du score » ; abaissez-la pour commencer à refuser en fonction du score. | Attribution du statut : ``` if decline_threshold < 500 and score >= decline_threshold: status = DECLINED else if score >= review_threshold: status = IN_REVIEW else: status = APPROVED ``` Les actions de règles individuelles peuvent remplacer cette attribution du statut. Par exemple, une règle dotée de `action: change_status → DECLINED` refusera la transaction quel que soit son score. ## Exemple détaillé des contributions des règles Supposons que ces règles se déclenchent sur une même transaction : | Règle | `score_delta` | | - | - | | Sortie de fonds à montant élevé (>\$10,000) | 30 | | Contrepartie située dans une juridiction à haut risque | 35 | | Schéma de structuration détecté | 35 | Score total = 30 + 35 + 35 = **100**. Avec un seuil d'examen de 60 et un seuil de refus de 85, cette transaction passe en `DECLINED`. Avec les seuils par défaut (75 pour l'examen, 500 pour le refus), elle passe en `IN_REVIEW`, car la valeur par défaut ne refuse jamais sur la base du score. ## Remplacements par action Les règles peuvent aussi définir directement le statut, en contournant les seuils de score : | Action de règle | Effet | | - | - | | `change_status → DECLINED` | Transaction refusée, quel que soit le score | | `change_status → IN_REVIEW` | Transaction envoyée en cours d'examen, quel que soit le score | | `change_status → AWAITING_USER` | La transaction attend une régularisation de l'utilisateur : le workflow défini sur l'action de la règle ; pour les règles de la bibliothèque, on applique d'abord le choix de vos paramètres, puis votre workflow d'authentification biométrique (visage enregistré requis), puis votre workflow par défaut | | `add_score(n)` | Ajoute uniquement au score ; aucun statut imposé | | `add_tags([...])` | Attribue des tags pour le filtrage dans la console ; aucun effet sur le score | | `add_to_list(...)` | Ajoute un identifiant à une liste de blocage | Une même règle peut comporter plusieurs actions, par exemple `add_score(35)` + `add_tags(["structuring"])` + `add_note("Auto-tagged by structuring preset")`. ## Pourquoi les scores l'emportent sur les règles strictes Un seuil fixe (par exemple « refuser toute transaction supérieure à \$100k ») touche à la fois les transactions de montant élevé légitimes et les risques réels. En combinant plusieurs règles à `score_delta` modéré et des seuils d'examen et de refus, vous obtenez : * **Une notation par couches** : aucune règle isolée ne provoque un refus ; plusieurs signaux doivent concorder. * **Une sensibilité ajustable** : vous pouvez relever ou abaisser les seuils sans modifier la définition des règles. * **Un ordre de gravité** : une transaction au score de 65 passe en cours d'examen (à examiner) ; un score de 90 entraîne un refus (situation grave). ## Configurer les seuils Depuis *Transactions → Paramètres* : * **Seuil d'examen** : relevez-le si votre file d'attente d'examen est saturée ; abaissez-le pour détecter davantage de cas limites. * **Seuil de refus** : relevez-le pour réduire les refus engendrés par des faux positifs ; abaissez-le pour adopter un blocage plus strict. Réglez-le sur la valeur maximale (`500`) pour envoyer les scores élevés en cours d'examen au lieu de les refuser automatiquement. Les modifications ne s'appliquent qu'aux **nouvelles** transactions : les transactions historiques conservent le statut obtenu au moment de leur évaluation. ## Mode test pour les règles Les règles peuvent s'exécuter en mode `TEST` : * La règle est évaluée sur les transactions, mais elle ne contribue ni au score ni au statut. * Des enregistrements `TransactionRuleRun` sont créés avec `is_test = true`. * Vous pouvez ainsi valider la sélectivité d'une règle sans risquer de refus en production. Passez en `ACTIVE` une fois la sélectivité jugée satisfaisante. ## Gravité et champs hérités Le champ `severity` des objets Transaction et TransactionAlert peut être nul et est hérité. Les nouvelles évaluations de règles ne le renseignent pas. Utilisez `score` comme indicateur de risque principal. ## Consulter les scores ### Via l'API Chaque réponse de transaction contient `score` et un tableau `rule_runs[]` comportant une entrée par règle correspondante (consultez le [schéma de réponse](https://docs.didit.me/fr/transaction-monitoring/response-schema.md#exécutions-de-règles) pour connaître tous les champs) : ```json theme={null} { "txn_id": "tx-0002", "status": "IN_REVIEW", "score": 65, "rule_runs": [ { "rule_title": "High-value outbound", "matched": true, "score_delta": 30, "severity": null, "status_target": null, "action_summary": "score +30" }, { "rule_title": "High-risk jurisdiction counterparty", "matched": true, "score_delta": 35, "severity": "HIGH", "status_target": "IN_REVIEW", "action_summary": "score +35; add_tag:high_risk_country" } ] } ``` ### Dans la console Sur la page de détail de la transaction, l'onglet **Score** présente le détail de la contribution de chaque règle correspondante ainsi que la correspondance finale avec le statut. Survolez le badge de score pour afficher les valeurs de seuil utilisées au moment de l'évaluation. ## Étapes suivantes > [card] [Règles](https://docs.didit.me/fr/transaction-monitoring/rules.md) > > Anatomie et évaluation des règles. > [card] [Alertes](https://docs.didit.me/fr/transaction-monitoring/alerts.md) > > Ce qui se passe lorsqu'une règle se déclenche. > [card] [Paramètres](https://docs.didit.me/fr/transaction-monitoring/settings.md) > > Configurer les seuils. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.