Filtrage des sanctions en temps réel avec Didit et Kafka : Un guide complet (FR)
Découvrez comment implémenter un système robuste et performant de filtrage des sanctions grâce à l'API AML Screening de Didit et Apache Kafka.

Conformité ÉvolutiveL'intégration de l'API AML Screening de Didit avec Apache Kafka permet aux institutions financières et aux entreprises de réaliser un filtrage des sanctions en temps réel et à haut débit, essentiel pour la conformité et la gestion des risques modernes.
Efficacité ArchitecturaleL'exploitation de la plateforme de streaming distribué de Kafka permet un traitement asynchrone, la mise en mémoire tampon des requêtes et une livraison fiable des données, garantissant que même sous forte charge, les demandes de filtrage sont traitées efficacement sans impacter l'expérience utilisateur.
Évaluation Intelligente des RisquesLe système avancé à deux scores de Didit (Score de Correspondance et Score de Risque) fournit des informations granulaires sur les risques potentiels, permettant des seuils de conformité configurables et réduisant les faux positifs grâce à une évaluation basée sur l'IA.
Intégration Transparente avec DiditDidit offre une approche axée sur les développeurs avec des API claires et une architecture modulaire, facilitant l'intégration du filtrage AML en temps réel dans les systèmes à haut débit existants, complétée par un KYC de base gratuit et sans frais d'installation.
L'impératif du filtrage des sanctions en temps réel
Dans l'économie numérique rapide d'aujourd'hui, les institutions financières, les entreprises de technologie financière et toute entreprise gérant des transactions ou intégrant des utilisateurs sont confrontées à un défi croissant : rester en conformité avec les réglementations en matière de lutte contre le blanchiment d'argent (AML) et le financement du terrorisme (CTF). Les méthodes traditionnelles de filtrage des sanctions par lots ne suffisent plus à combattre la criminalité financière sophistiquée, qui opère en temps réel. La nécessité d'identifier immédiatement les individus et entités figurant sur les listes de surveillance mondiales, les listes de sanctions et les bases de données des Personnes Politiquement Exposées (PPE) est primordiale. Les retards peuvent entraîner des pénalités réglementaires importantes, des atteintes à la réputation et un risque accru de faciliter des activités illicites.
Le filtrage des sanctions en temps réel permet aux organisations d'évaluer instantanément les risques aux moments critiques, tels que l'ouverture d'un compte, l'initiation d'une transaction ou même la surveillance continue. Cette approche proactive minimise l'exposition aux individus et entités à haut risque, garantissant que les entreprises restent conformes et sécurisées. Cependant, réaliser un véritable filtrage en temps réel à grande échelle, en particulier dans des environnements à haut débit, présente des défis architecturaux et techniques importants. C'est là que la combinaison d'API puissantes et natives de l'IA comme l'AML Screening de Didit avec des courtiers de messages robustes comme Apache Kafka devient un atout majeur.
Architecture pour l'échelle : API AML de Didit avec Apache Kafka
La construction d'un système de filtrage des sanctions en temps réel capable de gérer des millions de requêtes nécessite une architecture évolutive, résiliente et performante. Apache Kafka, une plateforme de streaming distribué, est un choix idéal à cette fin en raison de sa capacité à gérer de gros volumes de données, à assurer la tolérance aux pannes et à permettre un traitement asynchrone. Lorsqu'il est intégré à l'API AML Screening de Didit, il crée un moteur de conformité puissant.
L'architecture implique généralement la production de requêtes de filtrage vers un topic Kafka. Ces requêtes peuvent provenir de diverses sources : nouvelles inscriptions d'utilisateurs, systèmes de traitement des transactions ou tâches de re-filtrage périodiques. Les applications consommatrices lisent ensuite ce topic, appellent l'API AML Screening de Didit et publient les résultats dans un autre topic Kafka. Cette approche découplée offre plusieurs avantages :
- Haut débit : Kafka peut ingérer et traiter des millions de messages par seconde, garantissant que les demandes de filtrage ne sont jamais un goulot d'étranglement.
- Évolutivité : Kafka et l'API de Didit sont conçus pour l'échelle. Vous pouvez facilement ajouter plus de courtiers Kafka ou d'instances de consommateurs pour gérer une charge croissante.
- Résilience : La nature distribuée de Kafka et la réplication des données garantissent que les messages ne sont pas perdus, même en cas de défaillance du système.
- Traitement asynchrone : Les requêtes de filtrage peuvent être traitées en arrière-plan sans bloquer l'application d'origine, améliorant ainsi l'expérience utilisateur.
- Auditabilité : Kafka fournit un journal durable de toutes les requêtes et réponses de filtrage, crucial pour les audits de conformité.
L'API AML Screening de Didit filtre les utilisateurs par rapport à plus de 1300 bases de données mondiales de sanctions, de PPE et de listes de surveillance en temps réel, ce qui la rend parfaitement adaptée à cette intégration à haut volume et en temps réel. L'API fournit un rapport complet, y compris les détails de correspondance, les scores de risque, les scores de correspondance et les informations sur les médias défavorables, qui peuvent ensuite être consommés par les systèmes en aval pour une prise de décision automatisée ou une révision manuelle.
Comprendre le système de risque à deux scores de Didit
Un filtrage AML efficace ne consiste pas seulement à identifier une correspondance potentielle ; il s'agit de comprendre les nuances de cette correspondance pour éviter les faux positifs et évaluer précisément le risque. L'AML Screening de Didit utilise un système sophistiqué à deux scores – le Score de Correspondance et le Score de Risque – offrant un contrôle granulaire et une intelligence aux équipes de conformité.
Le Score de Correspondance répond à la question : « Cette correspondance potentielle est-elle la même personne ou entité que nous examinons ? » C'est un score de confiance d'identité, calculé sur la base de facteurs tels que la similarité du nom, la date de naissance, la nationalité et les numéros de document. Ce score aide à distinguer une vraie correspondance d'un faux positif. Par exemple, un Score de Correspondance élevé (par exemple, supérieur à 93, le seuil par défaut de Didit) indique une forte probabilité que l'individu examiné soit bien celui qui figure sur la liste de surveillance. Les requêtes inférieures à ce seuil sont souvent classées comme faux positifs, ce qui rationalise le processus d'examen.
Le Score de Risque, inversement, évalue : « Quel est le niveau de risque de cette entité si c'est une vraie correspondance ? » Ce score évalue le niveau de risque inhérent à l'entité correspondante, en tenant compte de facteurs tels que le risque pays, la catégorie spécifique de la liste de surveillance (par exemple, PPE, sanctions, casier judiciaire) et d'autres informations pertinentes. Le Score de Risque détermine le statut AML final – Approuvé, En Révision ou Refusé – sur la base de seuils configurables. Par exemple, un score inférieur au 'seuil d'approbation' (par défaut 80) pourrait conduire à une approbation automatique, tandis qu'un score supérieur au 'seuil de révision' (par défaut 100) pourrait déclencher un refus automatique. Les scores intermédiaires nécessitent généralement un examen manuel par un responsable de la conformité.
Ce mécanisme de double notation, configurable via des paramètres tels que aml_match_score_threshold, aml_score_approve_threshold et aml_score_review_threshold dans la requête API, permet aux entreprises d'ajuster leurs politiques AML à leur appétit pour le risque et à leurs exigences réglementaires spécifiques, réduisant considérablement la charge de l'examen manuel tout en maintenant une conformité robuste.
Mise en œuvre de flux de travail de filtrage en temps réel
L'intégration de l'API AML Screening de Didit dans un pipeline basé sur Kafka implique plusieurs étapes clés. Tout d'abord, définissez la structure de données pour vos requêtes et réponses de filtrage. Les requêtes incluent généralement le full_name, le entity_type (personne ou entreprise), la date_of_birth, la nationality et des paramètres optionnels comme le document_number ou des seuils de score personnalisés.
Lorsqu'un nouvel utilisateur s'inscrit ou qu'une transaction est initiée, un message contenant les données utilisateur nécessaires est produit vers un topic Kafka 'aml-screening-requests'. Un microservice dédié, agissant comme un consommateur Kafka, lit ces messages. Pour chaque message, il construit une requête vers le point de terminaison /v3/aml/ de Didit. Didit traite la requête en temps réel, effectuant des vérifications par rapport aux listes de surveillance mondiales et appliquant son système intelligent de risque à deux scores. La réponse de l'API, qui inclut le statut AML global, les détails de correspondance et divers scores de risque, est ensuite reçue par le microservice.
Dès réception de la réponse de Didit, le microservice peut publier les résultats dans un topic Kafka 'aml-screening-results'. Les systèmes en aval, tels qu'un service d'intégration d'utilisateurs, un moteur de traitement des transactions ou un système de gestion des cas, peuvent ensuite consommer ces résultats. Par exemple, si le statut AML est 'Approuvé', l'intégration de l'utilisateur peut se poursuivre. S'il est 'En Révision', un indicateur peut être défini pour qu'un responsable de la conformité enquête manuellement. Pour les statuts 'Refusé', des actions appropriées peuvent être déclenchées, telles que le blocage d'une transaction ou le refus de création de compte.
Cette implémentation garantit que la logique métier principale reste découplée des contrôles de conformité, permettant à chaque composant de s'adapter indépendamment et de maintenir une haute disponibilité. L'utilisation de Kafka fournit également un mécanisme de nouvelle tentative inhérent et une gestion de la contre-pression, empêchant l'API Didit d'être submergée pendant les pics de charge, et garantissant qu'aucune demande de filtrage n'est jamais manquée.
Comment Didit vous aide
Didit est à l'avant-garde des solutions de vérification d'identité natives de l'IA, axées sur les développeurs, conçues pour les systèmes modernes à haut débit. Notre produit AML Screening est une pierre angulaire de notre offre, permettant aux entreprises de filtrer les individus ou les entreprises par rapport à plus de 1300 bases de données mondiales de sanctions, de PPE et de listes de surveillance en temps réel. Notre architecture modulaire signifie que vous pouvez intégrer de manière transparente l'AML Screening en tant qu'API autonome ou dans le cadre d'un flux de travail de vérification d'identité plus large, sans configuration complexe ni longs délais d'intégration. La fondation native de l'IA de Didit garantit que notre système de risque à deux scores (Score de Correspondance et Score de Risque) est constamment optimisé pour la précision, réduisant les faux positifs et fournissant des informations exploitables aux équipes de conformité.
Au-delà du puissant AML Screening, Didit propose une suite complète de primitives d'identité, y compris la vérification d'identité (OCR, MRZ, codes-barres), la détection de vivacité passive et active, et la correspondance faciale 1:1 et la recherche faciale. Notre approche axée sur les développeurs comprend un bac à sable instantané et des API claires, rendant l'intégration simple. Nous nous distinguons par notre engagement à rendre la vérification d'identité robuste accessible, en offrant un KYC de base gratuit et absolument aucun frais d'installation, permettant aux entreprises de toutes tailles d'automatiser la confiance et d'assurer la conformité à l'échelle mondiale et à grande échelle.
Prêt à commencer ?
Prêt à voir Didit en action ? Obtenez une démo gratuite dès aujourd'hui.
Commencez à vérifier des identités gratuitement avec le niveau gratuit de Didit.