Surveillance des Transactions : Règles Anti-Fraude en Temps Réel via des Agents IA (FR)

La surveillance des transactions est un contrôle qui ne dort jamais. Chaque paiement, virement et rechargement doit être évalué par rapport à vos règles en temps réel, les alertes doivent être triées, les risques réels doivent devenir des cas, et certains de ces cas doivent donner lieu à un rapport d'activité suspect (RAS). C'est un travail à volume élevé, procédural et basé sur des preuves — le genre que peut traiter rapidement un agent IA lorsqu'il dispose d'un ensemble d'outils fiables à utiliser. Le serveur Model Context Protocol (MCP) de Didit expose le côté opérationnel de la surveillance des transactions — ingestion, recherche, tri, analyse de portefeuilles et cycle de vie des cas — comme des outils qu'un agent peut invoquer en langage clair, de la soumission d'une transaction à la clôture d'une boucle de remédiation.

Cet article décrit l'ensemble du processus : connecter un client, soumettre des transactions à une évaluation en temps réel, trier ce qui est signalé, ouvrir et traiter des cas, réunir les éléments de preuve qui sous-tendent un dépôt et exécuter la boucle d'auto-remédiation AWAITING_USER. La configuration des ensembles de règles et le dépôt du RAS lui-même restent dans la Console Business — l'agent couvre tout ce qui se trouve entre les deux.

Points clés

• Le serveur MCP de Didit place la surveillance des transactions — faisant partie de ses 115 outils répartis dans 11 catégories — derrière des commandes en langage naturel, permettant à un agent de soumettre des transactions, de trier les alertes, d'analyser des portefeuilles et de traiter les cas dans une seule conversation.
• La surveillance des transactions exécute un moteur de règles en temps réel avec 11 ensembles de règles pré-intégrés pour les monnaies fiduciaires et les cryptomonnaies, à 0,02 $ par transaction.
• La gestion des cas et le flux de travail du RAS sont intégrés, de sorte qu'une transaction signalée peut passer de l'alerte au rapport déposé sans quitter la plateforme.
• L'état AWAITING_USER déclenche une boucle d'auto-remédiation : lorsqu'une transaction nécessite plus d'informations du client, le système se met en pause, les collecte et reprend — et un agent peut orchestrer l'ensemble du processus.
• L'authentification est OAuth 2.1 avec Preuve de Clé pour l'Échange de Code (PKCE) — "Se connecter avec Didit", sans clé d'API pour le serveur hébergé, limitée à votre rôle de console.
• Vous bénéficiez de 500 vérifications gratuites par mois, de réponses en moins de 2 secondes, et la couche MCP elle-même est gratuite — vous ne payez que 0,02 $ par transaction pour ce que vous surveillez.

Pourquoi la surveillance des transactions convient à un agent

Le travail de surveillance est une séquence de décisions bien définies. Cette transaction a-t-elle enfreint une règle ? L'alerte est-elle une réelle préoccupation ou un comportement attendu ? Cela justifie-t-il un cas ? Le cas justifie-t-il un RAS ? Chaque étape lit des preuves structurées et produit un résultat documenté — le type de tâche qu'un agent IA gère de manière fiable lorsque la plateforme sous-jacente effectue la détection. L'agent n'invente pas la logique de risque ; il orchestre un moteur de règles en temps réel, lit ses résultats et amène chaque élément à son état suivant correct, avec un humain approuvant les décisions importantes.

Le module Surveillance des Transactions de Didit fournit ce moteur : évaluation en temps réel, 11 ensembles de règles pré-intégrés couvrant les typologies courantes des monnaies fiduciaires et des cryptomonnaies, les agrégations de vitesse, la gestion des cas et un flux de travail du RAS. Via MCP, tout cela devient appelable en une seule phrase.

Connecter votre agent au serveur MCP

Le serveur se trouve à l'adresse https://mcp.didit.me/mcp via Streamable HTTP — hébergé ou auto-hébergé à partir du dépôt open source sous licence MIT. L'authentification est OAuth 2.1 avec PKCE : une invite "Se connecter avec Didit" lors de la première connexion, aucune clé d'API à coller pour le point de terminaison hébergé, et l'agent hérite de votre rôle de console via les étendues didit:management et didit:verification. Il ne peut agir que là où votre compte le peut déjà.

Ajoutez-le à Claude Code en une seule ligne, puis vérifiez avec /mcp :

claude mcp add --transport http didit https://mcp.didit.me/mcp

Claude Desktop, Cursor, VS Code, Windsurf et Zed se connectent via une configuration JSON simple pointant vers la même URL. ChatGPT Developer Mode peut se connecter via la prise en charge bêta de MCP d'OpenAI, qui est encore à ses débuts, alors considérez-la comme expérimentale. Les détails complets de la configuration sont disponibles dans la documentation d'aperçu de MCP.

Configurer vos règles, puis confier la file d'attente à l'agent

Vous ne partez pas d'un ensemble de règles vierge. Didit fournit 11 ensembles de règles préconfigurés couvrant la monnaie fiduciaire et les cryptomonnaies, que vous installez et ajustez dans la Console Business : vous choisissez l'ensemble qui correspond à votre profil de risque, ajustez les seuils de vélocité, restreignez les listes de juridictions et effectuez des tests rétrospectifs sur votre historique avant toute mise en production.

Cette étape de configuration est délibérément une décision humaine, côté console : un ensemble de règles qui aurait signalé un tiers du volume légitime du mois dernier doit être ajusté avant de toucher la production, et c'est une décision d'appétence au risque, pas une cible d'automatisation.

Une fois les règles actives, tout ce qui suit est là où l'agent fait la différence. Soumettez le trafic à l'évaluation et lisez la décision en langage clair :

"Soumettez cette transaction à la surveillance et dites-moi la décision de risque et quelle règle s'est déclenchée."

L'agent appelle les outils de surveillance, renvoie la décision et la règle qui l'a produite, et vous continuez à travailler dans la même conversation.

Trier les alertes et ouvrir des cas

Une fois l'ensemble de règles en direct à 0,02 $ par transaction, les alertes arrivent en temps réel. Le tri est le travail quotidien, et c'est là qu'un agent justifie son existence. Demandez-lui de résumer la file d'attente :

"Montrez-moi les transactions signalées d'aujourd'hui groupées par règle, et dites-moi lesquelles semblent être un réel risque par rapport à un comportement client attendu."

L'agent lit chaque alerte avec son contexte — montant, contrepartie, modèle de vitesse, la règle qui s'est déclenchée — et les trie en probablement réelles et probablement bénignes, en expliquant son raisonnement pour celles qui comptent. Pour les transactions qui justifient un examen plus approfondi, il ouvre des cas :

"Ouvrez un cas pour les trois alertes de modèle de structuration sur le compte 4471 et joignez les transactions déclencheur."

La gestion des cas conserve les preuves, la chronologie et les notes de l'analyste au même endroit, de sorte que le dossier de l'enquête se construit au fur et à mesure que l'agent travaille.

Du cas au rapport déposé

Lorsqu'un cas franchit le seuil du suspect au déclarable, le flux de travail du RAS (rapport d'activité suspecte) prend le relais dans la console. Le travail de l'agent, c'est tout ce qui y mène : il a lu les transactions, tenu le dossier du cas et ajouté les preuves, il peut donc assembler le récit à partir duquel vous déposez.

"Escaladez le cas de structuration sur le compte 4471 et résumez le schéma, les transactions concernées et la chronologie."

L'agent escalade le cas et assemble le résumé à partir du dossier : ce qui a été observé, quelles transactions, sur quelle période, pourquoi cela atteint le seuil d'activité suspecte. Un humain relit et dépose le RAS lui-même dans la console. L'agent supprime le problème de la page blanche et s'assure que rien dans les preuves du cas n'est oublié ; comme le résumé est construit à partir du même dossier que l'agent gère depuis le début, il reste cohérent avec l'enregistrement sous-jacent au lieu de devenir un récit distinct.

Exécuter la boucle de remédiation AWAITING_USER

Toutes les alertes ne sont pas des fraudes — parfois une transaction a simplement besoin de plus d'informations du client avant de pouvoir être validée. C'est pourquoi l'état AWAITING_USER existe. Lorsqu'une transaction y arrive, la plateforme la met en pause, demande le détail manquant au client et reprend automatiquement lorsque le client répond. Un agent peut gérer l'ensemble de la boucle :

"Mettez l'alerte de virement important en attente en état AWAITING_USER, demandez une documentation sur l'origine des fonds au client et reprenez la surveillance lorsqu'il répond."

La transaction reste dans un état en attente contrôlé au lieu d'être bloquée purement et simplement ou ignorée. Lorsque le client fournit la documentation, le flux continue ; s'il ne le fait pas, l'élément reste affiché pour examen. Cette boucle d'auto-remédiation permet aux clients légitimes de continuer tout en retenant les transactions réellement non résolues, et elle permet à votre agent de résoudre une grande partie des alertes sans qu'un humain n'intervienne sur chacune d'elles.

Commencez gratuitement

La surveillance des transactions via MCP signifie qu'un analyste décrit le contrôle — soumettez la transaction, triez la file d'attente, ouvrez un cas, réunissez les preuves, exécutez la boucle de remédiation — et l'agent mène chaque transaction à son état suivant correct avec un humain prenant les décisions importantes. Didit est utilisé par plus de 2 000 entreprises, est soutenu par 7,5 millions de dollars de financement, est une entreprise Y Combinator W26, est rentable et couvre plus de 220 pays et territoires. Commencez gratuitement : 500 vérifications par mois sans frais, la couche MCP gratuite et 0,02 $ par transaction au-delà du niveau gratuit. Lisez la vue d'ensemble de MCP, parcourez le hub développeur ou auto-hébergez le serveur open source et connectez votre agent dès aujourd'hui.