Statuts KYT : référence des transactions et dossiers

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

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.

Statut du dossier

Voir Gestion des dossiers 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, 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 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 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

Notation des risques

Comment les scores correspondent aux statuts.

Alertes

Cycle de vie des alertes.

Dossiers

Cycle de vie des dossiers.

Prise en main

Fonctionnalités

Référence

Console

Statuts KYT : référence des transactions et dossiers

Statut de la transaction

Transitions

Alertes

Statut du dossier

Statut de la vérification Travel Rule

Statut du résultat du fournisseur

Résultats des exécutions de règles

Codes de motif de décision

Étapes suivantes

Notation des risques

Alertes

Dossiers

​Statut de la transaction

​Transitions

​Alertes

​Statut du dossier

​Statut de la vérification Travel Rule

​Statut du résultat du fournisseur

​Résultats des exécutions de règles

​Codes de motif de décision

​Étapes suivantes

Notation des risques

Alertes

Dossiers

Statut de la transaction

Transitions

Alertes

Statut du dossier

Statut de la vérification Travel Rule

Statut du résultat du fournisseur

Résultats des exécutions de règles

Codes de motif de décision

Étapes suivantes