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

# Transactions utilisateur : historique KYT et risques

> Historique des transactions d'un utilisateur via l'API Didit, pour la Surveillance des transactions. 1,000 inclus/mois, puis $0.001 chacun.

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

```bash theme={null}
curl -G https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  --data-urlencode "vendor_data=user-42" \
  --data-urlencode "page_size=50"
```

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

```mermaid theme={null}
flowchart LR
    T["Transaction<br/>txn_id=tx-0001"]
    A["applicant:<br/>vendor_data=user-42"]
    C["counterparty:<br/>vendor_data=user-99"]
    U1[User: user-42]
    U2[User: user-99]
    T --> A
    T --> C
    A -.-> U1
    C -.-> U2
```

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](https://docs.didit.me/fr/transaction-monitoring/transactions.md) pour le modèle complet des parties.

## Signaux de risque agrégés

Les transactions alimentent les signaux suivants au niveau de l'utilisateur :

| Signal | Utilisé par |
| - | - |
| Volume total entrant / sortant | Règles de vélocité, seuils |
| Nombre de transactions sur une fenêtre temporelle | Règles de vélocité |
| Contreparties uniques | Règles comportementales |
| Juridictions à haut risque concernées | Règles géographiques |
| Exposition à des contreparties sanctionnées | Règles de filtrage |
| Variété des moyens de paiement | Règles de fraude |

Ces signaux sont calculés en temps réel et évalués au regard de vos [règles de transaction](https://docs.didit.me/fr/transaction-monitoring/rules.md) 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](https://docs.didit.me/fr/transaction-monitoring/statuses.md) 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 :

```bash theme={null}
curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "txn_id": "legacy-0001",
    "txn_date": "2024-03-15T10:00:00Z",
    "direction": "INBOUND",
    "amount": "2500.00",
    "currency": "EUR",
    "applicant": { "vendor_data": "user-42" },
    "counterparty": { "name": "Historic payer" }
  }'
```

> [!NOTE]
>
> 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

> [card] [Soumettre des transactions](https://docs.didit.me/fr/transaction-monitoring/transactions.md)
>
> Référence complète du payload.

> [card] [Règles](https://docs.didit.me/fr/transaction-monitoring/rules.md)
>
> Comment les règles évaluent les transactions et agissent sur les utilisateurs.

> [card] [Statuts](https://docs.didit.me/fr/transaction-monitoring/statuses.md)
>
> Référence des statuts de transaction et de remédiation.


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