Monitoring AML continu

Le monitoring recrible quotidiennement les clients approuvés contre les listes mises à jour et déplace la session quand quelque chose de nouveau franchit votre seuil - 0,07 $ par an, sans intégration supplémentaire.

Rédigé par le support Didit · Mis à jour le 19 août 2026

Short answer

Le monitoring recrible chaque session précédemment approuvée quotidiennement contre les listes mises à jour. Une nouvelle correspondance au-dessus de votre seuil de revue déplace la session vers En revue ; au-dessus de votre seuil de refus, elle la déplace vers Refusée. Dans les deux cas, vous recevez un webhook status.updated. 0,07 $ par an, sans intégration supplémentaire nécessaire.

#Pourquoi un cribage unique ne suffit pas

Le cribage à l'onboarding vous indique ce que les listes disaient ce jour-là. Des désignations sont ajoutées, les médias négatifs s'accumulent, et quelqu'un qui était clean en mars peut être sanctionné en août. Si votre obligation inclut le maintien à jour de la diligence client - et pour la plupart des entreprises régulées, c'est le cas - un cribage unique ne la remplit pas.

#Comment ça fonctionne

Le monitoring est automatiquement disponible pour les sessions où un contrôle AML a tourné, sans travail d'intégration supplémentaire :

La liste des vérifications dans la console Didit avec le contrôle AML Ongoing monitoring
  1. Sélectionnez les personnes à continuer de cribler, puis activez le monitoring.
  2. Cochez les personnes à continuer de cribler : le monitoring est par personne, pas par organisation.
  3. Une nouvelle correspondance rouvre la session, elle apparaît donc ici plutôt que dans une boîte de réception.
Le monitoring est activé pour les personnes que vous choisissez de continuer à surveiller.
  1. Contrôles quotidiens automatisés. Chaque session précédemment approuvée est recriblée contre l'ensemble des listes de surveillance et de sanctions.
  2. Comparaison des seuils. Les nouveaux résultats sont comparés aux mêmes seuils de revue et de refus configurés dans votre workflow.
  3. Changement de statut. Une nouvelle correspondance au-dessus de votre seuil de revue déplace la session vers En revue. Au-dessus de votre seuil de refus, elle la déplace vers Refusée.
  4. Webhook. Votre application reçoit un webhook status.updated avec le statut mis à jour et les détails des nouvelles correspondances, dans le même format que n'importe quel autre webhook.
  5. Console. Le changement apparaît sur la session avec les nouvelles correspondances prêtes à être traitées.

#Ce pour quoi il faut concevoir

Une session approuvée peut changer de statut plus tard. Si votre intégration traite Approuvée comme définitif et arrête d'écouter, vous manquerez exactement les événements que le monitoring existe pour livrer.

Concrètement :

  • Continuez à traiter status.updated pour les sessions que vous avez déjà marquées comme vérifiées.
  • N'ignorez pas un webhook parce que la session est une session que vous avez close il y a des semaines.
  • Rendez votre propre état utilisateur capable de sortir à nouveau de « vérifié » - ce qui est en général le changement le plus difficile, car c'est une décision produit, pas seulement un gestionnaire d'événement.
Important

Les webhooks ne se déclenchent que quand le statut change réellement. Pas de nouvelle correspondance au-dessus du seuil signifie pas d'événement : le silence est donc le cas normal et n'est pas une preuve que le monitoring ne fonctionne pas. Si vous avez besoin d'une confirmation positive, vérifiez la session dans la console plutôt que d'attendre un webhook qui, à juste titre, ne viendra jamais.

#Ce que ça coûte

0,07 $ par an par personne surveillée. Ce n'est pas inclus dans le forfait gratuit.

Tarifé annuellement plutôt que par cribage, de sorte que la cadence quotidienne ne multiplie pas le coût - c'est ce qui rend le monitoring continu abordable en volume plutôt que quelque chose à rationner.

#Activer et désactiver

Le monitoring est configuré par workflow, aux côtés de l'étape AML. Comme il s'applique aux sessions à partir du moment où il est activé, l'activer ne fait pas commencer rétroactivement le monitoring de votre population déjà approuvée : prévoyez un rattrapage si vous avez besoin de couvrir vos clients existants.

#Prévoir la conséquence

Ce que les équipes sous-estiment n'est pas l'intégration, c'est que le monitoring génère une file récurrente. Une nouvelle correspondance demande le même travail de résolution qu'une correspondance à l'onboarding : est-ce votre client, est-ce que ça compte, consigner le raisonnement. Voir traiter les alertes AML.

Si personne ne prend en charge cette file, le monitoring produit des alertes qui restent non lues, ce qui est pire que de ne pas surveiller du tout : vous avez désormais la preuve qu'on vous a informé et que vous n'avez rien fait.

#Le monitoring n'est pas le monitoring de transactions

Deux choses différentes aux noms similaires :

  • Le monitoring AML recrible la personne contre les listes au fil du temps. C'est cet article.
  • Le monitoring de transactions évalue les transactions par rapport à des règles au moment où elles se produisent. Voir comment fonctionne le monitoring de transactions.

Vous aurez probablement besoin des deux, et ils sont facturés séparément.