Créer Sentinel : raisonnement IA pour le tri des alertes AML avec une piste d’audit complète

Votre système TM produit 95% de faux positifs. Vos enquêteurs le savent.

Une banque de taille moyenne génère des dizaines de milliers d’alertes AML par an. Entre 90% et 98% sont des faux positifs. Chacune est examinée manuellement par un enquêteur formé qui récupère 90 jours d’historique de transactions, vérifie les alertes antérieures du client, compare son comportement aux références de ses pairs, examine les données KYC et des parties liées, puis rédige la justification de décision. Quatre de ces cinq étapes relèvent de l’assemblage — pas du jugement.

Le modèle de mission de réglage des Big Four n’a pas fait évoluer ce chiffre en dix ans. Le goulot d’étranglement n’est pas le moteur de règles ; c’est ce qui se passe après le déclenchement de la règle.

Ce qu’est Sentinel — et ce qu’il n’est pas

Sentinel est la couche de raisonnement qui se place au-dessus de votre système de surveillance des transactions existant. Il ne remplace ni Actimize, ni SAS, ni Verafin, ni Oracle FCCM, ni votre pile interne. Pour chaque alerte émise par votre système, Sentinel :

1. Rassemble les 90 jours d’historique de transactions, les alertes antérieures, les références de pairs et le KYC dans un contexte unique.
2. Exécute une analyse Claude en deux passes — la première produit une analyse structurée, la seconde la critique à la recherche de signaux d’alerte manqués.
3. Émet une décision validée par Pydantic (clear · clear_with_note · escalate_to_l2 · escalate_to_sar · request_additional_info) avec preuves citées.
4. Journalise chaque entrée, sortie et marque de version dans la piste d’audit.

L’enquêteur voit un dossier préparé, pas un écran de tri : un score de probabilité au raisonnement calibré, des signaux d’alerte citant les identifiants de transactions, des facteurs atténuants tirés de l’historique réel du client, une décision recommandée et des questions précises lorsque le jugement est requis.

Trois modules, un schéma architectural

Le même schéma de raisonnement appliqué à trois files AML de structures différentes. La recette commune : sortie structurée validée par Pydantic, analyseur + critique en deux passes, preuves citées pour chaque affirmation et journal d’audit complet.

Les exigences non négociables qui ont guidé chaque décision

Au début du développement, nous avons fixé cinq exigences sans compromis — et refusé les fonctionnalités qui les auraient enfreintes.

• Chaque justification cite des identifiants de transactions ou des données clients précis. Aucun raisonnement vague. C’est ce qui rend le résultat justifiable en audit et c’est le premier point qu’examineront les régulateurs et responsables BSA.
• Uniquement des sorties structurées. Chaque appel Claude renvoie du JSON validé par Pydantic. Aucune analyse de texte libre en aval.
• Raisonnement en deux passes. La première passe analyse, la seconde critique la première à la recherche de signaux d’alerte manqués. Les deux sont journalisées.
• Piste d’audit complète. Chaque décision IA, la version du prompt, celle du modèle, le hachage du contexte d’entrée et la décision humaine sont journalisés. Un régulateur doit pouvoir reconstituer toute décision des mois plus tard.
• Jamais de données personnelles réelles — pour la démo. Le bac à sable utilise des données 100% synthétiques. Les missions payantes passent dans votre environnement, sous vos contrôles de risque de modèle.

Pile technique

Classique là où il le faut ; pointu là où cela compte.

• Couche de données : DuckDB — analytique embarquée dans un seul fichier. Idéal pour transporter la démo et transférable proprement vers votre entrepôt existant lors d’une mission payante.
• Backend : Python 3.11+, FastAPI, Pydantic pour la validation des schémas.
• Raisonnement : SDK Anthropic — Claude Sonnet pour les deux passes de tri et la rédaction SAR ; Haiku pour la première passe des listes de surveillance, où le coût compte et où la seconde passe effectue de toute façon une critique.
• Frontend : React + Vite, Tailwind, Recharts, shadcn/ui — autonome pour le bac à sable commercial ; remplaçable par votre interface d’enquête dans les missions payantes.
• Audit : Enregistrements JSON par analyse sous audit/logs/. Un enregistrement par décision, entièrement autonome.

Trois cas de démonstration qui font leurs preuves

La démo commerciale parcourt exactement trois alertes. Elles incarnent le produit, pas le support marketing.

Ce que nous ferons pour votre équipe

Une mission de preuve de valeur de deux semaines, à prix fixe. Nous utilisons vos données expurgées ou synthétiques. Jusqu’à cinq typologies et 10,000 alertes historiques. Vous repartez avec un bac à sable fonctionnel dans votre environnement, une bibliothèque de prompts adaptée à votre taxonomie, une documentation des risques de modèle adaptée à votre équipe MRM et une synthèse destinée au conseil d’administration.

Pour le détail — modules, schéma d’architecture, captures du bac à sable en direct et calcul des gains de temps à trois échelles — consultez la page produit Sentinel .