API de surveillance des transactions : règles en temps réel, gestion des cas et flux SAR

L'intégration d'un utilisateur avec KYC vous dit qui il est le premier jour. Cela ne vous dit rien sur ce qu'il fait le quatre-vingt-dixième jour. La surveillance des transactions est l'autre moitié de la conformité — la couche continue qui observe les mouvements d'argent et signale les schémas importants : structuration, entrées-sorties rapides, pics de vélocité, contreparties sanctionnées et juridictions à haut risque.

L'API de surveillance des transactions de Didit est un moteur de règles en temps réel conçu précisément pour cela. Vous envoyez une transaction, elle renvoie une décision en quelques millisecondes, et tout ce qui déclenche une règle est acheminé vers un gestionnaire de cas intégré où vos analystes enquêtent, escaladent et déposent des déclarations d'activités suspectes (SAR). Cela fonctionne aussi bien pour le fiat que pour la crypto, et cela coûte 0,02 $ par transaction, sans minimum.

Ce guide explique comment cela fonctionne, ce que le moteur de règles inclut et comment l'intégrer.

Points clés à retenir

• Prise de décision en temps réel. Chaque transaction renvoie l'un des quatre statuts — APPROVED, IN_REVIEW, DECLINED ou AWAITING_USER — afin que vous puissiez agir avant que l'argent ne soit réglé.
• 11 ensembles de règles intégrés couvrent l'AML/CTF, la détection d'anomalies, les schémas du GAFI, l'intelligence des appareils, la fraude, la surveillance crypto, le filtrage crypto, le jeu responsable et le commerce électronique. Construisez les vôtres par-dessus.
• Gestion de cas et flux SAR intégrés — alertes, attribution aux analystes, états d'enquête et dépôt de SAR vivent au sein du même produit, et non dans un outil séparé.
• L'auto-remédiation AWAITING_USER permet à une transaction signalée de déclencher une étape de vérification (re-KYC, preuve de fonds) et de reprendre automatiquement une fois que l'utilisateur l'a effacée.
• Fiat et crypto dans un seul moteur. Les transactions crypto peuvent déclencher automatiquement le filtrage des portefeuilles on-chain.
• 0,02 $ par transaction, paiement à l'appel, sans minimum. Le filtrage AML sur une partie signalée est facturé séparément à 0,20 $ par vérification.

Ce que fait la surveillance des transactions

Une vérification KYC est un instantané ; la surveillance des transactions est le film. Une fois qu'un utilisateur est intégré, chaque paiement, transfert, dépôt, retrait, pari ou transaction qu'il effectue est un signal. Considérés individuellement, la plupart de ces signaux sont du bruit. Considérés comme un flux — avec des fenêtres de vélocité, une agrégation et un contexte de contrepartie — les schémas qui indiquent le blanchiment d'argent, la fraude ou l'évasion des sanctions deviennent visibles.

Didit évalue chaque transaction au fur et à mesure qu'elle se produit par rapport à une bibliothèque de règles, attribue un score de risque et un statut. Les transactions à faible risque passent silencieusement. Tout ce qui dépasse un seuil est mis en attente pour examen, refusé purement et simplement, ou redirigé vers l'utilisateur pour remédiation — et une alerte est ouverte pour un analyste.

Pourquoi c'est important

Les régulateurs attendent une surveillance continue, pas seulement des vérifications d'intégration. Les directives AML de l'UE, les recommandations du GAFI et les régimes équivalents dans le monde entier exigent que les entreprises réglementées surveillent les transactions en fonction des risques et signalent les activités suspectes. Les modes de défaillance sont coûteux : structuration manquée, contreparties sanctionnées non détectées ou un schéma de vélocité qui s'avère être un réseau de mules.

Le problème opérationnel est tout aussi réel. La plupart des équipes assemblent la surveillance à partir d'un fournisseur de règles, d'un outil de gestion de cas séparé et d'un processus SAR manuel dans des feuilles de calcul. Didit réduit cette pile à une seule API et une seule console : règles, alertes, enquête et rapports au même endroit, facturés par transaction afin que le coût s'adapte à l'utilisation plutôt qu'aux licences de siège.

Détails techniques

Les transactions sont créées via l'API unifiée /v3/. Chaque transaction est idempotente sur un transaction_id que vous contrôlez (unique par application), de sorte que les tentatives échouées ne comptent jamais double.

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_8f3a91",
    "category": "finance",
    "amount": 9800,
    "currency": "EUR",
    "currency_kind": "fiat",
    "txn_date": "2026-05-21T10:32:00Z",
    "subject": {
      "vendor_data": "user_4521",
      "role": "SENDER",
      "entity_type": "INDIVIDUAL"
    },
    "counterparty": {
      "role": "RECEIVER",
      "entity_type": "INDIVIDUAL"
    },
    "payment_method": "BANK_TRANSFER"
  }'

Le moteur évalue la transaction par rapport à chaque règle active et renvoie un statut ainsi que les règles qui se sont déclenchées :

{
  "transaction_id": "txn_8f3a91",
  "status": "IN_REVIEW",
  "risk_score": 62,
  "triggered_rules": [
    { "name": "Structuring — amount below reporting threshold", "bundle": "AML/CTF", "action": "ADD_SCORE" },
    { "name": "High velocity — sender 24h count", "bundle": "Anomaly detection", "action": "CHANGE_STATUS" }
  ],
  "alert_id": "alrt_2c70d4"
}

Statuts. Chaque transaction se résout en l'un des quatre statuts :

Statut	Signification
APPROVED	Aucune règle n'a dépassé un seuil de refus — la transaction se poursuit.
IN_REVIEW	Une règle a signalé la transaction — une alerte est ouverte pour un analyste.
DECLINED	Une règle stricte (par exemple, contrepartie sanctionnée) a bloqué la transaction.
AWAITING_USER	La transaction est en attente d'une action de l'utilisateur — re-vérification ou preuve de fonds.

Catégories. Les transactions comportent une catégorie afin que les règles s'appliquent dans le contexte : finance, kyc, travel_rule, user_platform_event, gambling_bet, gambling_limit_change, gambling_bonus_change et audit_trail_event.

Vélocité et agrégation. Les règles personnalisées évaluent sur des fenêtres temporelles avec des agrégations de comptage, de somme et de comptage distinct — vous pouvez ainsi exprimer « plus de 5 transferts entrants de contreparties distinctes en 24 heures » ou « volume cumulé supérieur à 10 000 € en 7 jours » sans écrire votre propre processeur de flux.

Webhooks. Abonnez-vous à transaction.created et transaction.status.updated pour garder votre registre synchronisé lorsqu'un analyste résout une alerte.

Prix. 0,02 $ par transaction, facturé par appel, sans minimum. Si une transaction signalée déclenche un filtrage AML sur une partie, cette vérification est facturée séparément à 0,20 $.

Les 11 ensembles de règles intégrés

Vous ne partez pas d'un livre de règles vierge. Didit amorce le moteur avec 11 ensembles que vous pouvez activer et ajuster :

1. Finance — structuration, transactions importantes, évitement de seuils.
2. AML/CTF — volume cumulé, entrées/sorties rapides, sanctions, exposition aux PEP, juridictions à haut risque.
3. Détection d'anomalies — pics de vélocité, réactivation de comptes dormants, comportements aberrants.
4. GAFI — schémas alignés sur les indicateurs de drapeau rouge du GAFI.
5. Intelligence des appareils — empreinte numérique de l'appareil et signaux de risque de session.
6. Prévention de la fraude — schémas de mules, multi-comptes, signaux de prise de contrôle de compte.
7. Surveillance crypto — schémas de transactions on-chain.
8. Filtrage crypto — risque de portefeuille et exposition à la source de fonds.
9. Jeu responsable — vélocité des dépôts, changements de limites, abus de bonus.
10. E-commerce — schémas de rétrofacturation et d'abus de remboursement.
11. Personnalisé — vos propres règles avec des conditions, des fenêtres de vélocité et des agrégations.

L'action de chaque règle peut ajouter au score de risque, modifier le statut, ajouter des balises ou des notes, ou ajouter la partie à une liste — ainsi la politique est exprimée de manière déclarative, et les changements sont examinés dans la Console plutôt que d'être livrés dans le code.

Crypto, filtrage de portefeuille et Règle du voyage

Définissez currency_kind: "crypto" avec une direction (INBOUND ou OUTBOUND) et le moteur peut exécuter automatiquement le filtrage de portefeuille on-chain sur l'adresse de la contrepartie — vérifiant l'exposition aux entités sanctionnées, aux marchés du darknet, aux mélangeurs, aux ransomwares et aux fonds volés. Le filtrage de portefeuille commence à 0,02 $ par filtrage avec votre propre clé (Crystal ou Merkle Science).

Pour les fournisseurs de services d'actifs virtuels, le même moteur prend en charge la Règle du voyage du GAFI : échange de données d'origine et de bénéficiaire avec suivi des obligations sur les protocoles, et statuts dédiés à la règle du voyage (COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, EXEMPT, et plus encore). Un seul produit couvre la surveillance, le filtrage et la Règle du voyage.

Gestion de cas et flux SAR

Lorsqu'une règle se déclenche, une alerte s'ouvre. Didit fournit l'environnement de travail pour la gérer — aucun outil de cas séparé n'est nécessaire.

• Les Alertes ont une source (déclenchée par une règle, déclenchée par un fournisseur ou créée par un analyste) et passent par des états : OPEN, INVESTIGATING, AWAITING_USER, PENDING_SAR, SAR_FILED, RESOLVED, DISMISSED.
• Les Cas regroupent les alertes connexes, contiennent la priorité et la gravité, et suivent une enquête à travers OPEN, UNDER_REVIEW, AWAITING_USER, ON_HOLD et RESOLVED.
• Les Analystes sont affectés, les performances sont mesurables, et le flux de travail SAR vit dans la même console où l'alerte a été soulevée.

Le chemin AWAITING_USER rend cela pratique à grande échelle : au lieu d'un refus catégorique, une transaction signalée peut être mise en pause et demander à l'utilisateur de la débloquer — revérifier son identité, fournir une preuve de fonds — puis reprendre automatiquement une fois qu'il l'a fait. La friction n'apparaît que là où le risque est présent.

Comment s'intégrer à Didit

1. Construire le flux de travail. Dans la Console d'entreprise, activez les ensembles de règles pertinents pour votre entreprise et ajustez les seuils. Le constructeur de règles personnalisées est uniquement sur console par conception, de sorte que la conformité examine chaque changement.
2. Envoyer des transactions. POST /v3/transactions/ depuis votre backend au fur et à mesure que l'argent transite. Utilisez un transaction_id stable pour l'idempotence, et passez vendor_data afin que les transactions soient liées à l'utilisateur ou à l'entité commerciale à laquelle elles appartiennent.
3. Gérer les webhooks. Écoutez transaction.status.updated pour réagir lorsqu'un analyste résout une alerte ou qu'une remédiation AWAITING_USER est terminée.
4. Traiter les alertes dans la Console. Enquêter, escalader vers un cas et déposer des SAR depuis la même interface.

Parce que tout est sur l'API unifiée /v3/, une session KYB peut générer les sessions KYC pour ses UBOs, ces utilisateurs sont intégrés à la surveillance des transactions, et une transaction signalée peut générer une remédiation KYC — une seule plateforme d'identité et de fraude, de bout en bout.

Foire aux questions

Combien coûte la surveillance des transactions ?

0,02 $ par transaction, facturé par appel sans minimum. Le filtrage AML sur une partie signalée est facturé séparément à 0,20 $ par vérification, et le filtrage de portefeuille on-chain commence à 0,02 $ par filtrage avec votre propre clé.

Cela fonctionne-t-il aussi bien pour la crypto que pour le fiat ?

Oui. Définissez currency_kind sur fiat ou crypto. Les transactions crypto peuvent déclencher automatiquement le filtrage de portefeuille on-chain et prennent en charge la Règle du voyage du GAFI.

Dois-je créer mon propre outil de gestion de cas ?

Non. Les alertes, l'attribution aux analystes, les états d'enquête et le flux de travail SAR sont intégrés au même produit et à la même console.

Puis-je écrire mes propres règles ?

Oui. En plus des 11 ensembles prédéfinis, vous pouvez créer des règles personnalisées avec des conditions, des fenêtres de vélocité et des agrégations. Les règles sont gérées dans la Console afin que la conformité examine chaque modification.

Qu'est-ce que l'auto-remédiation AWAITING_USER ?

Au lieu d'un refus catégorique, une transaction signalée peut être mise en pause et demander une action de l'utilisateur — revérification ou preuve de fonds — puis reprendre automatiquement une fois que l'utilisateur l'a effacée.

Prêt à commencer ?

Lisez l'aperçu de la surveillance des transactions dans la documentation, voyez comment cela s'intègre au reste de la plateforme sur la page produit de la surveillance des transactions, et consultez les tarifs transparents par appel sur la page des tarifs. Lorsque vous êtes prêt, commencez gratuitement — 500 vérifications KYC gratuites chaque mois, et la surveillance des transactions à 0,02 $ par appel.