Le monitoring recrible chaque jour les sessions approuvées contre les listes à jour et les déplace vers En révision ou Refusée selon vos seuils. 0,07 $ par an.

Réponse courte

Le monitoring recrible les sessions approuvées quotidiennement contre les listes mises à jour, pour les sessions sur lesquelles vous l'activez. Une nouvelle correspondance au-dessus de votre seuil de revue déplace la session vers En révision ; 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 Vérifications des utilisateurs dans la console Didit avec des sessions sélectionnées et l'action Surveillance continue
Le monitoring est activé pour les personnes que vous choisissez de continuer à surveiller.
  1. Contrôles quotidiens automatisés. Chaque session approuvée dont le monitoring est activé 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 révision. 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. Payé avec le crédit de votre offre ou votre solde.

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

Il existe trois interrupteurs, et chacun nécessite l'accès en écriture aux vérifications :

  • Dans le workflow, aux côtés de l'étape AML, pour les nouvelles sessions. Il est désactivé par défaut.
  • Pour les sessions que vous avez déjà, sélectionnez-les dans Vérifications des utilisateurs et cliquez sur Surveillance continue dans la barre qui apparaît, puis sur Activer pour toutes. Les sessions sans étape AML sont ignorées.
  • Sur une seule vérification, avec l'interrupteur Surveillance continue de sa section AML.

Le désactiver arrête le recriblage quotidien à partir de ce jour ; ce qui a déjà été trouvé reste sur chaque vérification.

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

Toujours bloqué ? Parlez à un humain.

Indiquez l'ID de votre organisation et l'ID de la session concernée.

Contacter le support