> ## 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. # Statuts KYT : référence des transactions et dossiers > Statuts Didit des transactions, dossiers et Travel Rule, avec transitions. 1,000 transactions/mois incluses, puis $0.001 chacune. Le service Transaction Monitoring comporte trois machines à états distinctes : la **transaction**, chaque **dossier** et, le cas échéant, la **vérification Travel Rule**. Cette page en est la référence. ## Statut de la transaction Défini à la création et mis à jour tout au long du cycle de vie. | Statut | Signification | | - | - | | `APPROVED` | La transaction a satisfait à toutes les règles dont le niveau est inférieur au seuil d'examen. | | `IN_REVIEW` | Le score a dépassé le seuil d'examen, ou une règle a explicitement exigé un examen. Une analyse humaine est nécessaire. | | `DECLINED` | Le score a dépassé le seuil de refus, ou une règle a explicitement refusé la transaction. Transaction rejetée. | | `AWAITING_USER` | L'utilisateur doit agir avant le règlement de la transaction. Didit ne définit ce statut que par l'intermédiaire d'une règle : une action `change_status` d'une règle (par exemple la règle de bibliothèque optionnelle `travel-rule-pending-action`, qui se déclenche sur un transfert Travel Rule en `ON_HOLD`), ou une action de règle qui a exigé une vérification supplémentaire (une session de remédiation a été créée). Un transfert Travel Rule qui nécessite une preuve de contrôle du portefeuille ne définit pas ce statut à lui seul : la transaction conserve le statut attribué par vos règles (généralement `APPROVED`), et le bloc `action_required` contient l'URL permettant de prouver le contrôle du portefeuille chaque fois qu'une session de widget est en attente. Consultez le bloc `action_required` de la transaction pour connaître l'action concrète et l'URL à utiliser. | ### Transitions ```mermaid theme={null} stateDiagram-v2 [*] --> APPROVED: Score < review threshold, no blocking rules [*] --> IN_REVIEW: Score >= review threshold [*] --> DECLINED: Score >= decline threshold, or rule decline action [*] --> AWAITING_USER: Rule action change_status → AWAITING_USER IN_REVIEW --> APPROVED: Analyst cleared IN_REVIEW --> DECLINED: Analyst declined AWAITING_USER --> APPROVED: Remediation session approved AWAITING_USER --> DECLINED: Remediation session declined AWAITING_USER --> IN_REVIEW: Remediation session ended in review ``` Remarque : en dehors de la Travel Rule, il n'existe aucune transition directe depuis `APPROVED` ou `DECLINED` vers d'autres états. En cas d'expiration d'un transfert Travel Rule, votre `timeout_outcome` définit `IN_REVIEW` (`HOLD`) ou `DECLINED` (`REJECT`), quel que soit le statut actuel, et une règle déclenchée après une transition Travel Rule peut modifier une transaction `APPROVED`. Pour les corrections, utilisez les mises à jour de statut via la console ; elles sont consignées dans le journal d'audit. ## Alertes Il n'existe pas de statut d'alerte distinct. Une alerte ouverte correspond à une transaction en `IN_REVIEW` ou `AWAITING_USER`. Utilisez donc le statut de transaction indiqué ci-dessus. Voir [Alertes](https://docs.didit.me/fr/transaction-monitoring/alerts.md). ## Statut du dossier Voir [Gestion des dossiers](https://docs.didit.me/fr/console/case-management/cases.md) pour le détail complet. | Statut | Signification | | - | - | | `OPEN` | Fait l'objet d'une investigation active. | | `AWAITING_USER` | En attente d'un élément de la part de l'utilisateur. | | `RESOLVED` | Clôturé avec une résolution : `FALSE_POSITIVE`, `VALID_THREAT`, `INCONCLUSIVE`, `REQUIREMENTS_NOT_MET` ou `REQUIREMENTS_SATISFIED`. | Les dossiers portent une **priorité** distincte (`LOW`, `MEDIUM`, `HIGH`). ## Statut de la vérification Travel Rule Les transferts d'actifs virtuels soumis à la Travel Rule du GAFI suivent un **échange à 13 états** dédié, distinct du statut de transaction ci-dessus. Un transfert sortant commence en `AWAITING_COUNTERPARTY`, en `NOT_APPLICABLE` (en dessous du `threshold_amount`), en `UNCONFIRMED_OWNERSHIP` (portefeuille de la contrepartie déclaré auto-hébergé), en `COMPLETED`, ou en `COUNTERPARTY_MISMATCHED_DATA` (une correspondance `INTERNAL` sur un portefeuille vérifié, selon la correspondance du nom), en `COUNTERPARTY_VASP_NOT_FOUND`, ou en `COUNTERPARTY_VASP_NOT_REACHABLE`. Un transfert entrant peut aussi commencer en `ON_HOLD` ou en `NOT_ENOUGH_COUNTERPARTY_DATA`, et une inscription sunrise correspondant à un portefeuille vérifié, avec un nom de bénéficiaire correspondant ou absent, passe directement de `COMPLETED` à `FINISHED`. L'échange se termine en `FINISHED`, `CANCELLED` ou `EXPIRED`. | Statut | Signification | | - | - | | `AWAITING_COUNTERPARTY` | Envoyé à la contrepartie ; en attente de sa réponse. Un transfert envoyé via TRUST reste dans ce statut jusqu'à son expiration, car TRUST ne renvoie rien que Didit puisse lire. Dans une application sandbox, le transfert est envoyé au [Didit Test VASP](https://docs.didit.me/fr/transaction-monitoring/travel-rule-sandbox.md), qui répond au sein de Didit selon le scénario que vous choisissez. | | `UNCONFIRMED_OWNERSHIP` | La propriété du portefeuille du bénéficiaire n'est pas encore prouvée. | | `ON_HOLD` | Didit ne définit ce statut que pour les transferts entrants : une inscription sunrise ou une demande `TRP` entrante dont le portefeuille ne figure pas dans votre carnet d'adresses (ou, pour une demande fondée uniquement sur le nom, dont le nom ne correspond à aucun titulaire vérifié unique), ou une demande `TRP` entrante qui nécessite votre décision manuelle (l'acceptation automatique est désactivée, ou la réponse automatique n'a pas pu être livrée). Il ne modifie pas le statut de la transaction à lui seul ; la règle de bibliothèque optionnelle `travel-rule-pending-action` définit `AWAITING_USER`. Résolvez-le avec `POST /v3/transactions/{id}/travel-rule/ownership/`. | | `COMPLETED` | Les données du donneur d'ordre et du bénéficiaire correspondent : le transfert peut être diffusé on-chain en toute sécurité. | | `FINISHED` | Le hachage on-chain a été reçu ; l'échange est clos. | | `CANCELLED` | Annulé depuis un état non terminal. | | `EXPIRED` | Le délai de confirmation est écoulé. Seul un transfert encore en `AWAITING_COUNTERPARTY` à son échéance expire, l'état étant vérifié toutes les 15 minutes ; les autres statuts n'expirent jamais. Votre `timeout_outcome` est appliqué à la transaction, et ce changement n'envoie aucun webhook `transaction.status.updated`. | | `COUNTERPARTY_MISMATCHED_DATA` | Le nom du bénéficiaire ne correspond pas. | | `COUNTERPARTY_VASP_NOT_FOUND` | Aucun canal n'a pu résoudre la contrepartie. | | `COUNTERPARTY_VASP_NOT_REACHABLE` | La contrepartie a été identifiée, mais Didit n'a pas pu livrer le message : son point de terminaison `TRP` était injoignable ou signalait un LEI différent ou absent, ou un nom différent, ou un canal réseau (GTR, TRUST, VerifyVASP, Sygna Bridge) n'a pas pu livrer le message. | | `COUNTERPARTY_VASP_GENERAL_DECLINE` | La contrepartie a refusé l'échange. | | `NOT_ENOUGH_COUNTERPARTY_DATA` | Une demande `TRP` entrante n'a identifié le bénéficiaire ni par son nom ni par son adresse de portefeuille. Ce statut n'a pas de délai, et l'endpoint de vérification du contrôle du portefeuille ne peut pas le résoudre ; annulez-le donc avec `action: "cancel"`. L'expéditeur n'est pas notifié. Didit ne définit jamais ce statut sur un transfert sortant ; il n'apparaît dans ce cas que si vous l'enregistrez vous-même, et vous pouvez relancer un tel transfert avec `action: "resend"`. | | `NOT_APPLICABLE` | En dessous du `threshold_amount`, donc aucun échange n'a eu lieu ; ou une valeur que vous avez enregistrée sur un transfert que Didit n'exécute pas (Travel Rule désactivée, transaction dont le type n'est pas `travelRule`, ou valeur héritée). | Les anciennes intégrations peuvent encore envoyer les valeurs héritées `UNKNOWN`, `COMPLIANT`, `PENDING_ACTION`, `PENDING_COUNTERPARTY`, `FAILED` et `EXEMPT` ; Didit les convertit automatiquement vers les états ci-dessus. Voir [Travel Rule](https://docs.didit.me/fr/transaction-monitoring/travel-rule.md#cycle-de-vie) pour la référence faisant autorité. ## Statut du résultat du fournisseur Chaque résultat de fournisseur externe (filtrage des portefeuilles, surveillance des devises fiat, filtrage des sanctions) est enregistré avec son propre statut. Il apparaît sous `provider_results[]` dans la réponse de la transaction. | Statut | Signification | | - | - | | `PENDING` | Requête au fournisseur en cours. | | `COMPLETED` | Résultat renvoyé avec succès. | | `FAILED` | Erreur du fournisseur ou délai d'attente dépassé. | | `SKIPPED` | Fournisseur volontairement ignoré (par ex. transaction inférieure au seuil). | ## Résultats des exécutions de règles Chaque `TransactionRuleRun` contient : * `matched` (booléen) : la règle s'est-elle déclenchée ? * `is_test` (booléen) : la règle était-elle en mode TEST ? * `mode` : `ACTIVE`, `DISABLED` ou `TEST` au moment de l'évaluation. * `score_delta` : contribution au score (si la règle est déclenchée et active). * `status_target` : le statut demandé par la règle (si l'action est `change_status`). Voir [Règles](https://docs.didit.me/fr/transaction-monitoring/rules.md) pour la structure d'une règle. ## Codes de motif de décision Valeurs `reason` courantes lors des transitions de statut : | Motif | Signification | | - | - | | `rule_score_threshold` | Le score a dépassé le seuil d'examen ou de refus. | | `rule_change_status` | L'action `change_status` d'une règle a imposé un statut. | | `analyst_approved` / `analyst_declined` / `analyst_cleared` | Action manuelle de l'analyste. | | `user_action_approved` / `user_action_declined` / `user_action_in_review` | Résultat de la session de remédiation liée (l'action utilisateur demandée pendant l'état `AWAITING_USER`). | | `provider_update` | Le fournisseur externe a mis à jour le résultat. | | `aml_confirmed_sanction` | Le filtrage AML a confirmé une correspondance avec une liste de sanctions. | | `blocklist_applicant` / `blocklist_counterparty` | Application d'une liste de blocage à une partie. | ## Étapes suivantes > [card] [Notation des risques](https://docs.didit.me/fr/transaction-monitoring/risk-scoring.md) > > Comment les scores correspondent aux statuts. > [card] [Alertes](https://docs.didit.me/fr/transaction-monitoring/alerts.md) > > Cycle de vie des alertes. > [card] [Dossiers](https://docs.didit.me/fr/transaction-monitoring/cases.md) > > Cycle de vie des dossiers. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.