Passer au contenu principal

Vue d’ensemble

Le filtrage AML recoupe l’identité du sujet vérifié avec des jeux de données mondiaux de sanctions, de PEP, de listes de surveillance et de presse négative. Chaque occurrence renvoie l’entité correspondante, le ou les jeux de données à l’origine de la correspondance, deux scores — match_score (confiance dans l’identité) et risk_score (risque lié à l’entité) — ainsi qu’une ventilation structurée par source (pep_matches[], sanction_matches[], warning_matches[], adverse_media_matches[]). Le score global correspond au risk_score le plus élevé parmi les résultats qui ne sont pas marqués comme False Positive. Le même format est renvoyé par le filtrage AML sur les sessions d’utilisateurs (KYC), les sessions d’entreprises (KYB) et l’API AML autonome.
Capture d'écran du rapport de filtrage AML Didit avec des correspondances de sanctions, PEP et presse négative

Où il apparaît dans les réponses d’API

Sur l’endpoint de décision de la session, le filtrage AML est renvoyé sous la forme d’un tableau au pluriel aml_screenings[]. Chaque entrée correspond à une exécution AML dans le workflow (un contrôle AML exécuté deux fois génère deux entrées avec des valeurs de node_id différentes).
L’API AML autonome et les sessions d’entreprise renvoient la même structure par enregistrement. Les champs ci-dessous reflètent le schéma canonique de la page Modèles de données.

Trois scores, pas un seul verdict

Le champ status est un verdict ; les chiffres dont il découle se trouvent dans le même payload. Consultez-les lorsque vous construisez votre propre segmentation des risques (par exemple en combinant le risque AML avec les réponses à un questionnaire telles que l’origine du patrimoine ou l’auto-déclaration PEP) au lieu de vous baser uniquement sur Approved / In Review / Declined : Tous les trois sont présents à chaque endroit où le rapport AML est délivré : GET /v3/session/{sessionId}/decision/, l’objet decision des webhooks status.updated et data.updated sur toutes les versions de webhook (au pluriel aml_screenings[] en V3, et au singulier aml dans les versions héritées en V2 / V1), ainsi que sur l’API AML autonome. Un consommateur qui ne voit qu’un libellé signalé / clair lit status (ou le review_status d’une correspondance) et ignore les scores situés juste à côté. La console affiche les mêmes chiffres : l’en-tête de la section AML présente le Score de risque global, et chaque ligne du tableau des correspondances affiche le Score de correspondance et le Score de risque avec un détail au survol.

Schéma

Consultez Filtrage AML dans la référence des modèles de données pour le schéma canonique. Champs de premier niveau :

Champs par correspondance

Chaque entrée de hits[] comporte les champs suivants (extrait affiché). Les tableaux de sources de correspondance — pep_matches[], sanction_matches[], warning_matches[], adverse_media_matches[] — ne sont renseignés que pour le ou les jeux de données auxquels appartient la correspondance.
Les correspondances classées comme False Positive (parce que leur match_score était inférieur au seuil du score de correspondance ou parce qu’un réviseur les a marquées ainsi) restent dans hits[] pour permettre l’audit. Elles sont uniquement exclues du calcul du score agrégé.

Surveillance continue

Lorsque is_ongoing_monitoring_enabled est défini sur true, Didit filtre à nouveau le sujet en continu et réémet le rapport AML chaque fois qu’un résultat est ajouté, supprimé ou modifié. Les nouveaux filtrages qui modifient le statut AML déclenchent un webhook status.updated ; les nouveaux filtrages qui modifient uniquement les données des résultats déclenchent data.updated. La période de surveillance court à partir de la date last_aml_bill_date pendant 365 jours ; next_ongoing_monitoring_bill_date indique la date du prochain renouvellement annuel. Ces signaux sont tous déclenchés par des changements, de sorte qu’un sujet refiltré pendant des mois sans nouveau résultat n’en produit aucun. last_ongoing_screening_at est le seul champ mis à jour à chaque exécution terminée, et l’endpoint screening-history liste chaque exécution individuellement — y compris celles qui n’ont rien modifié. Consultez Surveillance AML continue pour découvrir l’ensemble du cycle de vie.
Trois dates sur ce rapport ont des significations différentes. next_ongoing_monitoring_bill_date correspond à votre prochaine facturation. last_ongoing_screening_at correspond à la dernière date à laquelle le sujet a réellement été filtré. last_ongoing_screening_datasets_updated_at correspond à la dernière mise à jour par le fournisseur des listes utilisées pour ce filtrage. Seule la deuxième atteste que le contrôle a bien été exécuté.

Valeurs de statut

Les seuils sont configurables par nœud de workflow — consultez Score de risque AML. Les règles de statut personnalisées se combinent avec le statut dérivé selon l’ordre de priorité Declined > In Review > Approved ; les réviseurs peuvent également remplacer le statut AML depuis la console ou via l’endpoint de statut AML.

Exemples

Approved — aucun résultat

In Review — résultat PEP + presse négative

Tous les noms, URL et articles ci-dessous sont fictifs.

Ressources associées

Dernière modification le 7 novembre 2026