Passer au contenu principal

Récupérer les transactions d’un utilisateur

Chaque transaction que vous soumettez avec un identifiant vendor_data (en tant que demandeur ou contrepartie) est liée à l’entité User correspondante. Le profil de l’utilisateur devient un journal continu de l’activité de la personne, et la Surveillance des transactions utilise cet historique pour alimenter les règles de vélocité et les règles comportementales. Filtrez la liste des Transactions par vendor_data :
Renvoie toutes les transactions dont l’utilisateur est le demandeur. Pour l’historique côté contrepartie, filtrez dans la Business Console (l’endpoint public de liste ne filtre que par demandeur).

Comment les transactions sont liées aux utilisateurs

Chaque transaction comprend jusqu’à quatre parties (demandeur, remetteur, bénéficiaire, contrepartie). Lorsqu’une partie contient un vendor_data, Didit le rattache à cet User. Les parties sans vendor_data sont stockées sous forme d’instantanés externes (sans lien avec une entité). Voir soumettre des transactions pour le modèle complet des parties.

Signaux de risque agrégés

Les transactions alimentent les signaux suivants au niveau de l’utilisateur : Ces signaux sont calculés en temps réel et évalués au regard de vos règles de transaction actives. Lorsqu’une règle correspond, l’utilisateur peut passer automatiquement à FLAGGED ou BLOCKED, selon l’action de la règle.

Comment les règles agissent sur les utilisateurs

Les actions d’une règle de transaction peuvent inclure :
  • add_score : augmente le score de risque de la transaction.
  • change_status : définit le statut de la transaction (IN_REVIEW, DECLINED, AWAITING_USER).
  • add_tags : ajoute des tags à la transaction.
  • add_to_list : ajoute le vendor_data de l’utilisateur à une liste de blocage ou à une liste personnalisée.
Lorsqu’une règle ajoute l’utilisateur à une liste de blocage, son entité User passe à BLOCKED et un webhook user.status.updated est déclenché.

Suivre le comportement d’un utilisateur

Utilisez l’onglet Transactions de la page de détail de l’utilisateur dans la Business Console pour :
  • Voir toutes les transactions par ordre chronologique.
  • Filtrer par statut, montant, sens et contrepartie.
  • Ouvrir une transaction pour examiner les exécutions de règles, l’enrichissement IP et les résultats du filtrage crypto.
  • Ouvrir un dossier sur l’utilisateur pour suivre une enquête.

Sessions de remédiation

Lorsqu’une transaction passe en AWAITING_USER, Didit crée une session de remédiation liée, qui oblige l’utilisateur à effectuer une vérification supplémentaire (par exemple, la documentation sur l’origine des fonds ou une pièce d’identité actualisée). La session de remédiation est rattachée au même vendor_data ; une fois celle-ci terminée, le statut de la transaction se met à jour automatiquement. Voir statuts des transactions pour la machine à états complète.

Ingestion historique

Pour rétroalimenter des transactions historiques sur une entité User existante, transmettez un txn_date correspondant à une date passée :
Les transactions historiques passent toujours par le moteur de règles. Si vous souhaitez ingérer l’historique sans déclencher les règles, utilisez le flux d’import de la console, qui propose un mode « dry ingest ».

Étapes suivantes

Soumettre des transactions

Référence complète du payload.

Règles

Comment les règles évaluent les transactions et agissent sur les utilisateurs.

Statuts

Référence des statuts de transaction et de remédiation.
Dernière modification le 7 novembre 2026