> Amélioration continue des processus > Intégration client KYC > Refinitiv World Check > Modèle de données

Votre modèle de données pour l’intégration client KYC

Refinitiv World-Check

Attributs de l’intégration client KYC(19) Activités de l’intégration client KYC(14) Guides d’extraction(2)

Votre modèle de données pour l’intégration client KYC

Ce modèle vous guide dans la collecte des données essentielles à l’analyse de votre processus d’intégration client KYC. Il présente les principaux attributs à recueillir, les activités à suivre et la manière d’extraire ces informations de vos systèmes sources. Servez-vous de ces indications pour réunir les données nécessaires à l’analyse et à l’amélioration du processus.

Attributs recommandés à recueillir
Activités clés à suivre
Conseils pour l’extraction

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de l’intégration client KYC

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail l’intégration client KYC.

3 Obligatoire 5 Recommandé 11 Facultatif

	Nom	Description
	Demande client CustomerApplication	Identifiant unique d’une demande d’intégration d’un client, utilisé comme identifiant principal du dossier.
Description La demande client est l’identifiant central du dossier qui regroupe tous les événements et activités liés au parcours d’intégration d’un client. Elle permet de suivre chronologiquement chaque étape du processus KYC (Know Your Customer), de la soumission initiale à la décision finale. Dans une analyse de Process Mining, cet attribut est essentiel pour reconstituer le parcours complet de chaque demande. Il permet de visualiser les flux de processus, de calculer les temps de cycle totaux et de repérer les variantes. En regroupant les dossiers selon cet identifiant, les organisations peuvent comprendre les différents parcours possibles d’une demande, repérer les goulots d’étranglement et comparer l’efficacité des processus d’intégration. Pourquoi est-ce important ? Cet identifiant de dossier essentiel relie toutes les activités associées et permet d’analyser le processus d’intégration du client de bout en bout. Où trouver ces données Cet identifiant est généralement la clé primaire de la table principale des demandes ou de gestion des dossiers dans le système Refinitiv World-Check ou dans un CRM intégré. Exemples APP-2023-00123APP-2023-00124APP-2023-00125
	Heure de l’événement EventTime	Horodatage indiquant le moment où une activité ou un événement précis s’est produit.
Description L’heure de l’événement indique la date et l’heure précises auxquelles une activité a été enregistrée. Cet horodatage constitue le fil chronologique du processus et permet de remettre les événements dans le bon ordre pour reconstituer l’historique du dossier. Cet attribut est indispensable à toutes les analyses temporelles en Process Mining. Il sert à calculer les durées entre les activités, notamment les temps de cycle et d’attente, à mesurer la durée totale du dossier, à analyser l’évolution des performances du processus et à vérifier le respect des accords de niveau de service (SLA). Sans horodatages exacts, il est impossible de comprendre les performances du processus et de repérer les goulots d’étranglement liés au temps. Pourquoi est-ce important ? L’horodatage de chaque activité est indispensable pour calculer les métriques de durée, reconstituer la séquence du processus et analyser les goulots d’étranglement. Où trouver ces données Ce champ standard figure dans tout journal d’événements ou toute table de piste d’audit. Il porte souvent le nom « Timestamp », « EventDate » ou « CreationDate ». Exemples 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
	Nom de l’activité ActivityName	Nom d’un événement métier ou d’une tâche précise survenue au cours du processus d’intégration KYC.
Description Le nom de l’activité décrit une étape ou un événement du parcours d’intégration du client, par exemple « Demande soumise », « Début de l’examen par l’analyste » ou « Filtrage terminé : aucun risque détecté ». Ces activités constituent les nœuds de la cartographie du processus et détaillent le flux de travail de bout en bout. L’analyse des activités est au cœur du Process Mining. En suivant leur séquence et leur fréquence, les analystes peuvent découvrir le déroulement réel du processus, repérer les parcours fréquents, détecter les écarts par rapport à la procédure standard et identifier les étapes qui entraînent des retards ou des reprises. Cet attribut est essentiel pour créer des cartographies de processus et calculer des métriques par activité. Pourquoi est-ce important ? Cet attribut définit les étapes individuelles du processus. Il est essentiel pour découvrir et visualiser le flux du processus et repérer les goulots d’étranglement. Où trouver ces données Cette information figure généralement dans les journaux d’événements ou les tables de piste d’audit, souvent en lien avec les changements de statut de l’entité de gestion des dossiers. Exemples Correspondance potentielle détectéeDébut de l’examen par l’analysteFaux positif confirméDemande approuvée
	Date limite du SLA SlaTargetDate	Date à laquelle le processus d’intégration du client doit être terminé.
Description La date limite du SLA correspond à l’échéance fixée pour terminer le dossier d’intégration, conformément à l’accord de niveau de service conclu avec le client ou aux règles internes. Elle sert de référence pour comparer les délais réels d’exécution. Cet attribut est essentiel au Dashboard « Respect des SLA et analyse des dépassements ». Il permet de déterminer si un dossier a été traité dans les délais. L’analyse des dépassements de SLA aide à repérer les problèmes systémiques à l’origine des retards et permet à l’organisation de prendre des mesures correctives pour respecter les délais et les exigences de conformité. Pourquoi est-ce important ? Cette référence permet de mesurer le respect des délais, de calculer le taux de respect des SLA et d’analyser les dépassements. Où trouver ces données Cette date est souvent calculée à partir de la date de soumission de la demande et des règles métier. Elle peut être enregistrée dans un champ du dossier. Exemples 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
	Heure de fin de l’événement EventEndTime	Horodatage indiquant le moment où une activité ou un événement précis a pris fin.
Description L’heure de fin de l’événement indique qu’une activité est terminée. De nombreux événements peuvent être modélisés comme instantanés, avec une heure de début identique à l’heure de fin, tandis que d’autres ont une durée mesurable, comme « Début de l’examen par l’analyste » et « Fin de l’examen par l’analyste ». La présence des heures de début et de fin permet de mesurer précisément la durée de traitement. Dans l’analyse des processus, l’heure de fin est indispensable pour calculer la durée exacte de traitement d’une activité, à distinguer du temps de cycle, qui inclut les temps d’attente. Elle permet de différencier le temps consacré au traitement actif d’un dossier du temps passé sans activité dans une file d’attente. Cette distinction est importante pour optimiser l’affectation des ressources et analyser l’efficacité. Pourquoi est-ce important ? Permet de calculer précisément la durée de traitement d’une activité et de distinguer le temps de travail actif du temps d’attente, pour une analyse plus juste des performances. Où trouver ces données Pour les activités qui ont une durée, cette information peut figurer dans un champ distinct, comme « CompletionDate » ou « EndDate », dans le journal d’événements ou les tables de piste d’audit. Exemples 2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
	Identifiant de l’examinateur ReviewerId	Identifiant de l’utilisateur, de l’analyste ou de l’agent automatisé qui a effectué l’activité.
Description L’identifiant de l’examinateur, ou de l’utilisateur, indique qui a exécuté une tâche donnée dans le processus KYC. Il peut s’agir d’un analyste conformité, d’un spécialiste de l’intégration des clients ou d’un compte système pour les activités automatisées. Le suivi de cette information permet de connaître la répartition de la charge de travail et les performances individuelles. Cet attribut est essentiel à l’analyse des ressources. Il aide à comprendre les écarts de performance entre utilisateurs ou équipes, à repérer les besoins de formation et à mieux répartir la charge de travail. Il permet également d’analyser les transmissions entre équipes, les réseaux de collaboration et l’utilisation des ressources de conformité. Pourquoi est-ce important ? Permet d’analyser la répartition de la charge de travail, les performances des utilisateurs et les transmissions entre services, afin de mieux répartir les ressources. Où trouver ces données Figure généralement dans les journaux d’événements ou les pistes d’audit, sous un nom tel que « UserID », « PerformedBy » ou « Owner ». Exemples analyst_jdoesystem_auto_screenermanager_bsmith
	Niveau de risque RiskLevel	Classification du risque calculée pour la demande du client, par exemple faible, moyen ou élevé.
Description Le niveau de risque est une information importante dans les processus KYC, car il détermine le degré de vérifications nécessaires. Il est souvent établi à partir de facteurs tels que le type de client, sa situation géographique et la nature de son activité. Cette classification peut influer fortement sur le parcours suivi par une demande. Dans l’analyse des processus, il est essentiel de segmenter les dossiers par niveau de risque. Cela permet d’expliquer les écarts de temps de cycle et de flux de processus : les demandes à haut risque peuvent, par exemple, nécessiter davantage d’étapes et prendre plus de temps. Cet attribut est essentiel aux Dashboards « Taux et motifs de rejet des demandes » et « Temps de cycle avant le lancement des vérifications d’antécédents », qui permettent de comprendre l’incidence du risque sur les résultats et l’efficacité. Pourquoi est-ce important ? La segmentation du processus par niveau de risque aide à comprendre pourquoi certains dossiers prennent plus de temps ou suivent un parcours différent, et à analyser les taux de rejet. Où trouver ces données Il s’agit d’une donnée centrale de la demande client ou du dossier. Consultez le module de gestion des dossiers de Refinitiv World-Check. Exemples FaibleMoyenÉlevé
	Service DepartmentName	Service ou équipe fonctionnelle responsable de l’activité.
Description Cet attribut indique l’unité opérationnelle ou l’équipe à laquelle appartient l’utilisateur, par exemple « Intégration des clients », « Conformité » ou « Assurance qualité ». Il permet d’analyser le processus à un niveau organisationnel plus large que celui de l’utilisateur individuel. L’analyse par service est importante pour repérer les goulots d’étranglement entre services et mesurer les délais de transmission. Elle permet de visualiser la circulation du travail entre les équipes et de localiser les retards lors de ces transitions. Cette vue aide à améliorer la collaboration entre les fonctions et l’efficacité globale du processus. Pourquoi est-ce important ? Permet d’analyser les performances du processus par service et de repérer les retards lors des transmissions entre équipes. Où trouver ces données Cette information peut être enregistrée dans le profil de l’utilisateur ou dans un système RH associé. Il peut être nécessaire de la relier aux données d’événement à l’aide de l’identifiant utilisateur. Exemples Équipe chargée de l’intégration des clientsExamen de conformitéDirection générale
	Automatisé IsAutomated	Indique si l’activité a été effectuée par un système (true) ou par une personne (false).
Description Cet attribut booléen distingue les tâches automatisées par le système des activités manuelles effectuées par les utilisateurs. Par exemple, « Filtrage automatisé effectué » serait considéré comme automatisé, tandis que « Début de l’examen par l’analyste » serait considéré comme manuel. Cette distinction est essentielle pour analyser l’automatisation. Elle aide à mesurer les effets de l’automatisation sur l’efficacité du processus, à repérer les tâches manuelles qui pourraient être automatisées à l’avenir et à comprendre les interactions entre les personnes et les systèmes. Elle permet de distinguer clairement le temps de traitement par le système du temps consacré au traitement manuel. Pourquoi est-ce important ? Distingue les activités effectuées par un système de celles réalisées par une personne, ce qui permet de mesurer les effets de l’automatisation et de repérer de nouvelles possibilités d’automatisation. Où trouver ces données Cette valeur est généralement déduite du nom de l’activité ou de l’identifiant utilisateur associé à l’événement (par exemple, lorsque l’utilisateur est un compte « système »). Exemples truefalse
	Canal de soumission de la demande ApplicationChannel	Canal par lequel la demande du client a été soumise, par exemple le portail en ligne, une agence ou l’application mobile.
Description Le canal de soumission indique par quelle voie la demande du client a été transmise. Selon le canal, l’exhaustivité et la qualité des données ainsi que le profil des clients peuvent varier, ce qui peut influer sur la suite du processus. Cet attribut est essentiel au Dashboard « Volume de demandes par canal ». L’analyse du volume, des temps de cycle et des résultats des demandes provenant de différents canaux permet à une organisation de repérer les canaux les plus efficaces et ceux qui nécessitent des améliorations. Ces résultats éclairent les décisions stratégiques concernant la répartition des ressources et les investissements dans les canaux. Pourquoi est-ce important ? Aide à comparer les performances et l’efficacité des différents canaux de soumission, et à orienter les décisions stratégiques en matière de technologie et d’expérience client. Où trouver ces données Cette information est généralement recueillie au début du processus et enregistrée comme attribut de la demande. Exemples Portail en ligneApplication mobileEn agenceGestionnaire de relation client
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière actualisation ou extraction des données de cet événement depuis le système source.
Description Cet attribut indique la fraîcheur des données. Il enregistre la date et l’heure de la dernière extraction depuis Refinitiv World-Check. Il permet de savoir si les Dashboards et les analyses de Process Mining reposent sur des données récentes. Les utilisateurs peuvent ainsi déterminer s’ils consultent des données presque en temps réel ou un instantané datant d’un moment précis. Cet attribut est essentiel à la gouvernance des données et permet de préciser aux utilisateurs le degré d’actualité des analyses présentées. Pourquoi est-ce important ? Précise l’actualité des données et permet aux utilisateurs de savoir si l’analyse du processus est à jour. Où trouver ces données Cet horodatage est généré et ajouté lors du processus d’extraction des données (ETL). Exemples 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Identifiant de la correspondance MatchId	Identifiant unique d’une correspondance potentielle détectée lors d’un filtrage World-Check.
Description Lorsque le processus de filtrage automatisé détecte une correspondance potentielle avec des listes de sanctions, de PPE ou de médias défavorables, un identifiant de correspondance est souvent généré pour suivre le résultat concerné. Cet identifiant relie le dossier de demande à l’enregistrement précis de la base de données World-Check qui a déclenché l’alerte. Cet attribut est utile pour mener une analyse détaillée de la conformité. Il permet aux analystes d’examiner la nature des correspondances, de suivre le traitement des alertes (par exemple, confirmer un faux positif ou une correspondance réelle) et de déterminer quels types d’alertes sont les plus fréquents ou prennent le plus de temps à résoudre. Il apporte un niveau de détail supplémentaire sur l’activité « Correspondance potentielle détectée ». Pourquoi est-ce important ? Établit un lien précis avec les résultats du filtrage, ce qui permet d’analyser plus en détail les délais de traitement des correspondances et les types d’alertes. Où trouver ces données Cet identifiant serait généré par le moteur de filtrage World-Check et enregistré dans le dossier de demande lorsqu’une correspondance potentielle est détectée. Exemples WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
	Identifiant du client CustomerId	Identifiant unique du client en cours d’intégration.
Description L’identifiant du client est l’identifiant unique de son profil. Il diffère de l’identifiant de la demande client, car un même client peut soumettre plusieurs demandes au fil du temps. Cet attribut relie le processus d’intégration à la fiche client de référence. L’analyse de cet identifiant permet de suivre les demandes répétées d’un même client et d’enrichir les données du processus avec d’autres attributs provenant d’un CRM ou d’un système de données de référence. Elle donne ainsi une vue plus complète du parcours client, au-delà d’une seule opération d’intégration. Pourquoi est-ce important ? Relie le dossier d’intégration à un client précis, ce qui permet d’analyser les demandes répétées et d’enrichir les données à partir de la fiche client de référence. Où trouver ces données Ce champ important figure dans la demande ou le dossier et le relie aux données de référence du client. Exemples CUST-98765CUST-98766CUST-98767
	Motif du rejet RejectionReason	Motif précis indiqué lors du rejet d’une demande client.
Description Lorsqu’une demande est rejetée, le motif du rejet précise la raison de la décision. Il peut s’agir d’une « Correspondance avec une liste de sanctions », de « Documents incomplets » ou d’un « Profil à haut risque ». Cette information fournit un retour structuré sur la qualité des demandes reçues et l’efficacité du processus de filtrage. Cet attribut est la principale source de données du Dashboard « Taux et motifs de rejet des demandes ». L’analyse des motifs aide à repérer les causes profondes des rejets, à améliorer le processus, à mieux communiquer avec les demandeurs et, éventuellement, à réduire les rejets injustifiés. Elle apporte un éclairage qualitatif à l’indicateur quantitatif du taux de rejet. Pourquoi est-ce important ? Précise les causes profondes des rejets de demandes et aide à repérer les améliorations à apporter au processus d’intégration pour réduire leur fréquence. Où trouver ces données Cette information est enregistrée lors de l’événement « Demande rejetée », probablement dans un champ du dossier ou de la demande. Exemples Correspondance avec une PPECorrespondance avec une liste de sanctionsÉchec de la vérification des documentsInformations défavorables dans les médias
	Pays du client CustomerCountry	Pays de résidence ou de constitution du client.
Description Cet attribut indique la situation géographique du client. Le pays est un facteur important dans l’évaluation des risques et les exigences réglementaires des processus KYC. Les règles varient selon les juridictions et peuvent influer sur le déroulement et la durée du processus. L’analyse par pays permet aux organisations de comparer les performances entre régions, de repérer les goulots d’étranglement propres à certaines zones et de vérifier le respect des réglementations locales. Cette dimension géographique peut révéler des différences opérationnelles importantes. Pourquoi est-ce important ? Permet d’analyser le processus par zone géographique et de repérer les écarts régionaux en matière de performances, de risques et d’exigences de conformité. Où trouver ces données Ce champ standard figure dans le profil du client ou le formulaire de demande. Exemples USAGBRSGPDEU
	Reprise IsRework	Indique si une activité est effectuée une deuxième fois ou plus dans le même dossier.
Description IsRework est un attribut booléen calculé qui repère les activités répétées dans un même dossier de demande client. Par exemple, si l’activité « Évaluation des risques effectuée » se produit plusieurs fois pour une même demande, les occurrences suivantes sont considérées comme des reprises. Cet attribut est essentiel pour repérer les inefficacités, les boucles et les répétitions inutiles dans le processus. Il contribue directement au Dashboard « Reprises et efficacité de l’évaluation des risques » et au KPI « Taux de reprises de l’évaluation des risques ». L’analyse des reprises permet de mettre au jour des problèmes de qualité, de clarté des informations ou de prise de décision, qui entraînent des efforts inutiles et allongent les temps de cycle. Pourquoi est-ce important ? Repère les inefficacités du processus en signalant les activités répétées. L’analyse des boucles de reprise permet ensuite d’améliorer la qualité et de réduire les temps de cycle. Où trouver ces données Cette valeur est calculée lors de la transformation des données, en analysant la séquence des activités de chaque dossier et en signalant toute occurrence d’une activité qui n’est pas la première. Exemples truefalse
	SLA dépassé SlaBreached	Indique si le dossier d’intégration a été clôturé après la date cible du SLA.
Description Cet attribut calculé indique si un dossier a dépassé le délai prévu par son accord de niveau de service. Pour le déterminer, on compare l’horodatage de la dernière activité de clôture (par exemple, « Demande approuvée » ou « Demande rejetée ») à la date cible du SLA du dossier. Cet indicateur sert de base au Dashboard « Respect et dépassement des SLA » et au KPI « Taux de respect des SLA ». Il simplifie l’analyse en permettant aux utilisateurs de filtrer rapidement tous les dossiers ayant dépassé le délai. L’étude des caractéristiques des processus concernés aide les organisations à trouver les causes profondes des retards et à cibler leurs efforts d’amélioration. Pourquoi est-ce important ? Mesure directement le respect des accords de niveau de service et facilite le filtrage des dossiers en retard ainsi que l’analyse de leurs causes profondes. Où trouver ces données Cette valeur est calculée lors de la transformation des données, en comparant l’horodatage de la dernière activité du dossier au champ SlaTargetDate. Exemples truefalse
	Système source SourceSystem	Système d’où proviennent les données d’événement extraites, en l’occurrence Refinitiv World-Check.
Description Cet attribut indique l’origine des données du processus. Sa valeur peut être constante lorsque l’extraction provient d’un seul système, mais il devient essentiel lorsque des données issues de plusieurs systèmes, comme un CRM et World-Check, sont réunies pour obtenir une vue d’ensemble du processus. Dans le cadre de l’analyse, il contribue à la gouvernance des données, au diagnostic des problèmes et à la compréhension de leur contexte. Par exemple, les activités consignées dans le système central de filtrage peuvent présenter des caractéristiques ou un niveau de détail différents de ceux des activités provenant d’un système périphérique. Cet attribut assure une traçabilité claire et vérifiable des données. Pourquoi est-ce important ? Indique l’origine des données, ce qui est important pour leur gouvernance et leur validation, ainsi que pour la fusion de données provenant de plusieurs sources. Où trouver ces données Il s’agit souvent d’une valeur statique ajoutée lors du processus d’extraction, de transformation et de chargement (ETL) pour identifier le jeu de données. Exemples Refinitiv World-CheckWorldCheckOne
	Type de client CustomerType	Catégorie du client, par exemple particulier, société ou fiducie.
Description Le type de client désigne la catégorie de l’entité en cours d’intégration. Les exigences, les profils de risque et les obligations réglementaires varient souvent selon le type de client. Par exemple, l’intégration d’une société est généralement plus complexe que celle d’un particulier. Cet attribut sert à segmenter l’analyse, notamment dans le Dashboard « Performances KYC par type de client ». Il permet de comparer l’efficacité du processus, les temps de cycle et les taux de rejet entre différents segments de clientèle. Les organisations peuvent ainsi adapter et optimiser le parcours d’intégration à chaque type de client. Pourquoi est-ce important ? Permet de comparer les performances entre différents segments de clientèle et d’adapter le processus d’intégration à chaque type de client. Où trouver ces données Cet attribut fondamental est enregistré dans le profil du client ou la demande du système source. Exemples ParticulierSociétéOrganisme à but non lucratifFiducie

Obligatoire Recommandé Facultatif

Activités de l’intégration client KYC

Voici les principales étapes et les jalons du processus à consigner dans votre journal d’événements pour découvrir le processus avec précision.

8 Recommandé 6 Facultatif

	Activité	Description
	Compte activé	Le compte du client est créé et activé dans le système central, ce qui termine son parcours d’intégration. Cette étape suit l’approbation finale de la demande et rend le compte utilisable.
Pourquoi est-ce important ? Il s’agit de la dernière étape du processus, celle qui apporte le résultat attendu. Le délai entre la soumission de la demande et l’activation du compte est une métrique importante pour évaluer l’efficacité opérationnelle et la satisfaction client. Où trouver ces données Cet événement n’est pas enregistré dans World-Check. Il figure dans le système bancaire central ou le système de gestion des comptes clients et doit être rapproché à l’aide de l’identifiant de la demande client. Données à recueillir Événement consigné dans le système central de gestion des comptes lors de l’activation du compte. Type d’événement explicit
	Correspondance confirmée	Un analyste confirme que la correspondance potentielle concerne bien le client soumis au filtrage et relève un risque potentiel. Cette étape importante déclenche généralement des vérifications complémentaires ou le rejet de la demande.
Pourquoi est-ce important ? Cette issue joue un rôle important dans la réduction des risques et marque un tournant dans le processus. Elle influe directement sur la décision finale concernant la demande du client et compte pour les rapports et les analyses de conformité. Où trouver ces données Il s’agit d’une action explicite de l’utilisateur : l’analyste classe une correspondance précise comme « Correspondance confirmée » ou « Correspondance avérée ». Cet événement est consigné dans la piste d’audit du dossier. Données à recueillir Enregistré lorsqu’un analyste confirme officiellement une correspondance dans le système. Type d’événement explicit
	Début de l’examen par l’analyste	Un analyste conformité commence l’examen manuel des correspondances potentielles associées à une demande client. Il compare les informations relatives aux correspondances potentielles aux données du client afin d’en déterminer la pertinence.
Pourquoi est-ce important ? Cette étape marque le début de l’examen manuel de conformité, souvent source de goulots d’étranglement. Le délai entre la détection d’une correspondance potentielle et cette activité révèle les temps d’attente dans la file, tandis que la durée de l’examen renseigne sur l’efficacité des analystes. Où trouver ces données Cet événement peut être déduit du moment où un analyste prend en charge un dossier ou l’ouvre depuis la file d’examen. Le système peut aussi le consigner explicitement dans la piste d’audit lorsque le statut du dossier passe à « En cours d’examen » ou que le dossier est attribué à un utilisateur précis. Données à recueillir Déduit du passage du dossier au statut « En cours d’examen » ou de son attribution à un analyste. Type d’événement inferred
	Demande de contrôle créée	Un nouveau dossier de contrôle est officiellement créé pour une demande client dans le système Refinitiv World-Check. Cette création est déclenchée par un appel d’API ou une saisie manuelle depuis un système en amont et marque le début du contrôle des risques.
Pourquoi est-ce important ? Cette étape marque le début officiel du sous-processus de filtrage. Le délai entre la soumission de la demande et cette activité révèle les retards de transmission entre le système métier et la fonction conformité. Où trouver ces données Cette information figure dans les journaux de gestion des dossiers ou la piste d’audit de World-Check. L’événement de création et son horodatage pour l’identifiant du dossier ou de l’entité concernée sont utilisés. Données à recueillir L’événement est enregistré automatiquement à la création d’un nouveau dossier de filtrage dans le système. Type d’événement explicit
	Demande rejetée	La demande du client est officiellement rejetée, souvent à la suite d’une « Correspondance détectée » dans World-Check ou en raison d’autres facteurs de risque. Cet événement marque l’issue défavorable finale du processus d’intégration.
Pourquoi est-ce important ? Il s’agit de la principale issue négative du processus. L’analyse des rejets, notamment de leurs motifs et des activités qui les précèdent, est importante pour améliorer le processus et réduire les rejets injustifiés. Où trouver ces données Cette décision commerciale finale est enregistrée dans le CRM en amont ou le système applicatif central, et non dans World-Check. Les données doivent être extraites de ce système. Données à recueillir Événement consigné dans le système applicatif source, souvent avec un code indiquant le motif du rejet. Type d’événement explicit
	Demande soumise	Cette activité marque le début du processus d’intégration KYC, lorsque le client soumet sa demande. L’événement est généralement enregistré dans un CRM ou un système de gestion des demandes, qui déclenche ensuite le contrôle dans Refinitiv World-Check.
Pourquoi est-ce important ? Il s’agit de l’événement de début du parcours d’intégration client de bout en bout. Le temps écoulé entre cette étape et la fin du processus correspond au temps de cycle global de l’intégration. Cet indicateur est essentiel pour mesurer l’expérience client et le respect des SLA. Où trouver ces données Cet événement n’est pas natif de World-Check. Il doit provenir d’un système en amont, comme un CRM ou une plateforme de gestion des comptes clients, puis être associé à l’ID de la demande client. Données à recueillir Événement enregistré dans le système source au moment du dépôt initial de la demande. Type d’événement explicit
	Filtrage terminé : aucun risque détecté	Le dossier de filtrage est officiellement clôturé avec le résultat « Aucun risque détecté », ce qui signifie qu’aucune correspondance avérée n’a été trouvée. La décision est communiquée au système d’origine, qui peut alors poursuivre le processus d’intégration du client.
Pourquoi est-ce important ? Cette activité correspond à l’issue favorable du parcours nominal de filtrage. Elle sert de point de référence pour mesurer le temps de cycle des demandes standard à faible risque. Où trouver ces données Déduit du passage du statut final du dossier à « Aucun risque détecté », « Terminé » ou « Clôturé : aucune correspondance ». L’horodatage de ce changement de statut final est utilisé. Données à recueillir Déduit de l’horodatage du statut final du dossier indiquant qu’aucun risque n’a été détecté. Type d’événement inferred
	Filtrage terminé : correspondance détectée	Le dossier de filtrage est officiellement clôturé avec le résultat « Correspondance détectée », indiquant qu’un risque confirmé a été relevé. Cette décision déclenche une autre procédure, par exemple des vérifications renforcées ou le rejet de la demande.
Pourquoi est-ce important ? Il s’agit de la principale issue défavorable du processus de filtrage. L’analyse de ces dossiers aide à comprendre les profils de risque et l’efficacité des contrôles de filtrage. Où trouver ces données Déduit du passage du statut final du dossier à « Correspondance détectée », « Risque identifié » ou « Clôturé : résultat positif ». L’horodatage de ce changement de statut final est utilisé. Données à recueillir Déduit de l’horodatage du statut final du dossier indiquant qu’une correspondance a été confirmée. Type d’événement inferred
	Correspondance potentielle détectée	Le filtrage automatisé a détecté une ou plusieurs correspondances potentielles qui nécessitent l’examen manuel d’un analyste. Le dossier passe ainsi d’un traitement automatisé à une file d’attente d’enquête manuelle.
Pourquoi est-ce important ? Cette activité constitue un point de bifurcation important du processus. Les dossiers présentant des correspondances potentielles suivent un parcours plus long et plus complexe. Leur suivi aide l’équipe chargée de l’examen à planifier ses ressources et à analyser les goulots d’étranglement. Où trouver ces données Déduit du changement de statut du dossier vers « Examen requis », « Correspondance potentielle » ou un statut similaire dans le module de gestion des dossiers World-Check. Données à recueillir Déduit d’un changement de statut du dossier indiquant qu’un examen manuel est désormais nécessaire. Type d’événement inferred
	Demande approuvée	La demande du client est entièrement approuvée après un filtrage KYC concluant et la réalisation des autres vérifications requises. Cet événement survient généralement dans le système source après réception d’un résultat « Aucun risque détecté » de World-Check.
Pourquoi est-ce important ? Cette étape marque l’issue favorable du processus d’intégration du client. Le délai entre la soumission de la demande et cette étape indique le temps total nécessaire pour obtenir une décision favorable. Où trouver ces données Cet événement n’est pas natif de World-Check. Il doit provenir du CRM en amont ou du système applicatif central, qui prend la décision commerciale finale. Données à recueillir Événement consigné dans le système applicatif source après l’approbation finale. Type d’événement explicit
	Dossier transmis pour examen	Un analyste de premier niveau transmet un dossier complexe ou à haut risque à un analyste senior ou à un responsable pour décision finale. Il s’agit d’un point de transmission important au sein de l’équipe conformité.
Pourquoi est-ce important ? Les escalades créent souvent des goulots d’étranglement et allongent le temps de cycle. L’analyse de leur fréquence et de leurs motifs peut faire ressortir des besoins de formation pour les analystes juniors ou des ambiguïtés dans les règles d’examen. Où trouver ces données L’escalade est enregistrée comme une action explicite dans le flux de travail du dossier ou la piste d’audit. Elle peut aussi être déduite d’un changement d’utilisateur auquel le dossier est attribué, notamment si le nouvel utilisateur dispose de droits plus élevés. Données à recueillir Enregistré au moyen d’un bouton « Escalader » dédié ou d’une action du flux de travail dans le dossier. Type d’événement explicit
	Faux positif confirmé	L’analyste conclut que la personne correspondant potentiellement au résultat n’est pas le client soumis au filtrage. La correspondance est écartée et le traitement de cette alerte est terminé.
Pourquoi est-ce important ? Il s’agit d’une issue fréquente de l’examen. Le temps nécessaire pour statuer sur les faux positifs permet d’évaluer l’efficacité des analystes et la précision des règles de filtrage automatisé. Où trouver ces données Il s’agit d’une action explicite de l’utilisateur : l’analyste classe une correspondance précise comme « Faux positif » ou « Aucune correspondance ». Cette action est généralement consignée dans l’historique du dossier. Données à recueillir Enregistré lorsqu’un analyste écarte officiellement une correspondance potentielle dans le système. Type d’événement explicit
	Filtrage automatisé effectué	Le système World-Check compare automatiquement les informations du client à sa base de données de renseignements sur les risques. Cette activité pilotée par le système produit un premier ensemble de résultats, par exemple des correspondances potentielles ou un statut sans correspondance.
Pourquoi est-ce important ? Cette activité constitue la première étape du processus de filtrage qui apporte de la valeur. Les retards en amont signalent des problèmes de disponibilité du système ou des données, tandis que le résultat détermine la charge de travail manuel qui suit. Où trouver ces données Cet événement peut être consigné explicitement dans la piste d’audit du dossier ou déduit de l’horodatage auquel les premiers résultats du filtrage sont disponibles. Données à recueillir Entrée du journal système générée à la fin de l’analyse automatisée de la base de données. Type d’événement explicit
	Informations complémentaires demandées	L’analyste estime que des informations supplémentaires sont nécessaires pour résoudre la correspondance potentielle et les demande à l’unité opérationnelle. Le dossier reste en attente jusqu’à leur réception.
Pourquoi est-ce important ? La fréquence de cette activité peut révéler des problèmes de qualité dans les données initialement fournies pour le filtrage. Elle entraîne des retards importants, car elle dépend d’équipes externes, et contribue fortement à l’allongement des temps de cycle. Où trouver ces données Il peut s’agir d’une action explicite de l’utilisateur, consignée dans les notes du dossier ou le journal d’audit. L’événement peut aussi être déduit d’un changement de statut vers « Informations en attente » ou « Demande d’informations ». Données à recueillir Enregistré lorsqu’un analyste utilise une fonctionnalité pour signaler que le dossier nécessite des informations complémentaires. Type d’événement explicit

Recommandé Facultatif

Guides d’extraction

Comment récupérer vos données depuis Refinitiv World-Check

Étapes

Connectez-vous à World-Check One : accédez au portail Refinitiv World-Check One à l’aide de vos identifiants.
Accédez à la gestion des dossiers : ouvrez la section Case Management, où sont stockés et gérés tous les dossiers de filtrage.
Préparez l’export du rapport de dossiers : accédez à la fonction de rapport ou d’export dans Case Management. Elle peut s’intituler « Export Cases » ou « Case Report ».
Configurez le rapport de dossiers : sélectionnez les colonnes à inclure dans l’export. Veillez à choisir les champs correspondant à l’identifiant du cas (CustomerApplication), à la date de création, à la date de résolution, au statut du dossier (par exemple, Clear, Match Found) et au niveau de risque.
Exportez les données de gestion des dossiers : définissez la période, qui couvre généralement les 3 à 6 derniers mois d’activité. Appliquez les filtres nécessaires, par exemple par groupe d’utilisateurs ou par type de dossier. Exportez les données au format CSV et nommez le fichier case_report.csv.
Préparez l’export de la piste d’audit : accédez à la section de rapport de la piste ou du journal d’audit de World-Check One. Elle contient l’historique détaillé des événements de chaque dossier.
Configurez et exportez la piste d’audit : sélectionnez toutes les colonnes pertinentes, notamment l’identifiant du cas, le nom ou la description de l’événement, son horodatage et l’utilisateur qui a effectué l’action. Exportez ces données pour la même période que le rapport de dossiers. Enregistrez le fichier sous le nom audit_trail.csv.
Récupérez les étapes du processus dans les systèmes externes : obtenez les données relatives aux activités qui ont lieu en dehors de World-Check, comme Application Submitted, Application Approved, Account Activated et Application Rejected. Elles proviennent généralement d’un CRM ou d’un système bancaire central. Exportez-les avec l’identifiant CustomerApplication et les horodatages pertinents.
Combinez et transformez les données : chargez les fichiers CSV exportés (case_report.csv, audit_trail.csv et les données des systèmes externes) dans un outil ou un script de préparation des données.
Associez les événements d’audit aux activités : traitez le fichier audit_trail.csv. Associez les descriptions brutes des événements du journal d’audit aux valeurs normalisées ActivityName. Par exemple, une entrée « Case Assigned to Analyst » devient « Analyst Review Started ».
Associez les changements de statut des dossiers aux activités : traitez le fichier case_report.csv pour générer des activités à partir des changements de statut. Utilisez la date de résolution et le statut final du dossier pour créer les événements « Screening Completed - Clear » ou « Screening Completed - Match Found ».
Créez le journal d’événements final : réunissez les données traitées provenant des différents fichiers sources dans un seul fichier CSV. Vérifiez qu’il contient les colonnes requises : CustomerApplication, ActivityName et EventTime, ainsi que les attributs recommandés. Enregistrez ce fichier pour l’importer dans l’outil de Process Mining.

Configuration

Types de rapports : vous devez générer au moins deux rapports distincts, un rapport récapitulatif de gestion des dossiers et un rapport détaillé de la piste d’audit.
Période : pour une première analyse, choisissez une période d’au moins 3 à 6 mois afin de couvrir suffisamment de dossiers clôturés et en cours. Veillez à utiliser la même période pour tous les fichiers exportés.
Format d’export : choisissez le format CSV (valeurs séparées par des virgules), qui facilite le traitement des données.
Colonnes clés (rapport de dossiers) : vérifiez que l’export des dossiers comprend l’identifiant du cas, l’horodatage de création, l’horodatage de résolution, le statut final, l’analyste affecté et le niveau de risque.
Colonnes clés (rapport de piste d’audit) : vérifiez que l’export du journal d’audit comprend l’identifiant du cas, la description de l’événement, son horodatage et l’identifiant de l’utilisateur.
Prérequis : vous devez pouvoir accéder au portail World-Check One avec des autorisations permettant de consulter et d’exporter les données de gestion des dossiers et du journal d’audit. Des privilèges supérieurs à ceux d’un analyste standard peuvent être nécessaires.

Exemple de requête sql

/*
This is a configuration and mapping guide, not an executable script. 
The process relies on manually exporting two reports from World-Check One and combining them with data from an upstream system (e.g., CRM).
*/

-- Step 1: Export 'Case Management Report' as case_report.csv
-- Step 2: Export 'Audit Trail Report' as audit_trail.csv
-- Step 3: Export relevant events from CRM/core system as source_system_events.csv

-- Step 4: Combine and map the files using a script or ETL tool to create the final event log.

-- Mapping logic for final_event_log.csv

-- Part A: Data from source_system_events.csv
SELECT
  ApplicationID AS CustomerApplication,
  'Application Submitted' AS ActivityName,
  SubmissionTimestamp AS EventTime,
  NULL AS EventEndTime,
  OriginatorID AS ReviewerId,
  OriginatingDept AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Submission'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Application Approved' AS ActivityName,
  ApprovalTimestamp AS EventTime,
  NULL AS EventEndTime,
  ApproverID AS ReviewerId,
  ApprovingDept AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Approval'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Account Activated' AS ActivityName,
  ActivationTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Operations' AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Activation'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Application Rejected' AS ActivityName,
  RejectionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ReviewerID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Rejection'

-- Part B: Data from World-Check audit_trail.csv
UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Request Created' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Created%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Automated Screening Performed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Automated Screening Completed%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Potential Match Identified' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Potential Match Found%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Analyst Review Started' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Assigned%' OR EventDescription LIKE '%Review Started%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Additional Information Requested' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Information Requested%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Case Escalated for Review' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Escalated%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'False Positive Confirmed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Match Dismissed as False Positive%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'True Match Confirmed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Match Confirmed as True%'

-- Part C: Data from World-Check case_report.csv
UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Completed - Clear' AS ActivityName,
  ResolutionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ResolverID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskLevel AS RiskLevel,
  NULL AS SlaTargetDate
FROM case_report.csv
WHERE FinalStatus = 'Clear'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Completed - Match Found' AS ActivityName,
  ResolutionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ResolverID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskLevel AS RiskLevel,
  NULL AS SlaTargetDate
FROM case_report.csv
WHERE FinalStatus = 'Match Found'

Étapes

Prérequis et configuration : vérifiez que Python 3.6 ou une version ultérieure est installé, ainsi que les bibliothèques requests et pandas. Demandez votre clé API et votre secret API World-Check One à votre représentant Refinitiv ou sur le portail développeur. Conservez ces identifiants en lieu sûr.
Mettez en place l’authentification : dans votre script Python, créez une fonction qui envoie une requête POST au point de terminaison d’authentification de World-Check One. Utilisez votre clé API et votre secret pour obtenir un jeton porteur temporaire, nécessaire aux appels API suivants.
Repérez les données du système source : le processus commence et se termine en dehors de World-Check. Identifiez le système source, par exemple un CRM ou une plateforme bancaire centrale, qui stocke les données initiales des demandes. Vous devrez en extraire des événements tels que Application Submitted, Application Approved, Account Activated et Application Rejected. Vous pouvez le faire au moyen d’une requête de base de données ou d’une autre API.
Récupérez les dossiers World-Check : à l’aide du jeton d’authentification, envoyez une requête GET au point de terminaison /cases de l’API World-Check One. Utilisez des paramètres de requête pour filtrer les dossiers selon une période précise, par exemple leur date de création ou de modification.
Gérez la pagination de l’API : les réponses de l’API World-Check sont paginées. Votre script doit vérifier les informations de pagination dans la réponse et parcourir toutes les pages pour récupérer la liste complète des dossiers de la période choisie.
Récupérez les détails et l’historique des dossiers : pour chaque identifiant de cas récupéré, envoyez des requêtes GET supplémentaires à des points de terminaison tels que /cases/{case_system_id} et /cases/{case_system_id}/audit-trail. Ils fournissent les changements de statut détaillés, les informations de résolution et les actions des utilisateurs associées au dossier.
Associez les données brutes aux activités : cette étape de transformation est essentielle. Écrivez une logique qui parcourt les réponses de l’API (détails du dossier et piste d’audit) pour chaque cas. Associez les changements de statut, les codes de résultat et les événements d’audit aux activités métier requises. Par exemple, un événement de création de dossier devient Screening Request Created, et la résolution avec le résultat False Positive devient False Positive Confirmed.
Combinez les sources de données : fusionnez les données extraites de World-Check avec celles du système source (étape 3). Utilisez l’identifiant CustomerApplication comme clé commune pour créer un journal d’événements complet, de bout en bout, pour chaque client.
Structurez et enrichissez les données : rassemblez tous les événements associés dans une seule liste d’enregistrements. Pour chacun, renseignez les attributs requis (CustomerApplication, ActivityName, EventTime) et les attributs recommandés. Lorsque c’est possible, calculez EventEndTime, par exemple à partir de l’horodatage de l’événement suivant pour le même dossier.
Exportez au format CSV : convertissez la liste finale des événements en DataFrame pandas. Réorganisez les colonnes selon le format requis, puis exportez le DataFrame dans un fichier CSV. Enregistrez le fichier avec l’encodage UTF-8 pour qu’il soit compatible avec ProcessMind.

Configuration

Identifiants API : une clé API et un secret API valides sont requis pour l’API de filtrage World-Check One. Ils doivent disposer des autorisations nécessaires pour lire les données des dossiers et des audits.
URL de base de l’API : configurez le script avec l’URL de base correspondant à votre environnement World-Check, par exemple https://api.world-check.com/v2/.
Période : ajoutez les paramètres start_date et end_date au script pour définir la période d’extraction. Pour une première analyse, une période de 3 à 6 mois est recommandée. Pour le suivi régulier, exécutez le script par incréments sur des périodes plus courtes, par exemple la veille ou la semaine précédente.
Connexion au système source : vous aurez besoin des informations de connexion aux systèmes en amont et en aval (par exemple, le CRM ou la plateforme bancaire centrale) pour récupérer les événements qui ne relèvent pas du filtrage. Il peut s’agir d’une chaîne de connexion à une base de données ou d’un autre point de terminaison d’API et de ses identifiants.
Gestion de la pagination : lors des appels API qui répertorient les dossiers, le script doit préciser la taille de page, souvent appelée limit. Une valeur comprise entre 50 et 100 est généralement efficace. La logique doit récupérer correctement toutes les pages.

Exemple de requête python

import requests
import pandas as pd
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># --- Configuration and Placeholders ---
WC_API_KEY = class="hl-string">'[Your World-Check API Key]'
WC_API_SECRET = class="hl-string">'[Your World-Check API Secret]'
WC_API_BASE_URL = class="hl-string">'https://api.world-check.com/v2' class=class="hl-string">"hl-comment"># Use correct URL for your environment

class=class="hl-string">"hl-comment"># Date range for the extraction
START_DATE = (datetime.now() - timedelta(days=90)).strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
END_DATE = datetime.now().strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')

class=class="hl-string">"hl-comment"># --- MOCK FUNCTIONS (Replace with actual data source connections) ---

def get_source_system_events(application_ids):
    class="hl-string">"""Simulates fetching pre- and post-screening events from a CRM or core system."""
    print(fclass="hl-string">'Fetching source system events for {len(application_ids)} applications...')
    mock_events = []
    for i, app_id in enumerate(application_ids):
        class=class="hl-string">"hl-comment"># Simulate initial application events
        mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Submitted', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i+5)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Sales'})
        class=class="hl-string">"hl-comment"># Simulate final outcome events
        if i % 3 == 0:
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Approved', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Onboarding'})
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Account Activated', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i-1)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Operations'})
        else:
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Rejected', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Compliance'})
    return mock_events

def get_worldcheck_cases(token):
    class="hl-string">"""Simulates fetching a list of cases from the World-Check API."""
    print(class="hl-string">'Fetching World-Check cases...')
    class=class="hl-string">"hl-comment"># In a real implementation, you would call GET /cases with date filters and handle pagination
    mock_case_list = [
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-001', class="hl-string">'name': class="hl-string">'John Doe', class="hl-string">'caseSystemId': class="hl-string">'WC-001', class="hl-string">'customReference': class="hl-string">'APP-1001', class="hl-string">'creationDate': class="hl-string">'2023-10-01T10:00:00Z', class="hl-string">'riskLevel': class="hl-string">'Medium'},
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-002', class="hl-string">'name': class="hl-string">'Jane Smith', class="hl-string">'caseSystemId': class="hl-string">'WC-002', class="hl-string">'customReference': class="hl-string">'APP-1002', class="hl-string">'creationDate': class="hl-string">'2023-10-02T11:30:00Z', class="hl-string">'riskLevel': class="hl-string">'Low'},
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-003', class="hl-string">'name': class="hl-string">'Peter Jones', class="hl-string">'caseSystemId': class="hl-string">'WC-003', class="hl-string">'customReference': class="hl-string">'APP-1003', class="hl-string">'creationDate': class="hl-string">'2023-10-03T09:05:00Z', class="hl-string">'riskLevel': class="hl-string">'High'}
    ]
    return mock_case_list

def get_worldcheck_case_details(case_system_id, token):
    class="hl-string">"""Simulates fetching the audit trail and results for a single World-Check case."""
    print(fclass="hl-string">'Fetching details for case {case_system_id}...')
    class=class="hl-string">"hl-comment"># This mock data simulates a complex history for one case to generate multiple activities
    if case_system_id == class="hl-string">'WC-001':
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-01T10:05:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-01T10:06:00Z', class="hl-string">'event': class="hl-string">'MATCH_FOUND', class="hl-string">'details': class="hl-string">'Potential match identified', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T14:00:00Z', class="hl-string">'event': class="hl-string">'REVIEW_STARTED', class="hl-string">'details': class="hl-string">'Case assigned', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T15:30:00Z', class="hl-string">'event': class="hl-string">'MATCH_RESOLVED', class="hl-string">'details': class="hl-string">'Match resolved as False Positive', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T11:00:00Z', class="hl-string">'event': class="hl-string">'ESCALATED', class="hl-string">'details': class="hl-string">'Case escalated to senior analyst', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T09:00:00Z', class="hl-string">'event': class="hl-string">'INFORMATION_REQUESTED', class="hl-string">'details': class="hl-string">'Additional documents requested', class="hl-string">'user': class="hl-string">'senior_analyst'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-05T16:00:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed as Clear', class="hl-string">'user': class="hl-string">'senior_analyst'}
            ]
        }
    elif case_system_id == class="hl-string">'WC-003':
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T09:10:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T09:11:00Z', class="hl-string">'event': class="hl-string">'MATCH_FOUND', class="hl-string">'details': class="hl-string">'Potential match identified', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T10:00:00Z', class="hl-string">'event': class="hl-string">'REVIEW_STARTED', class="hl-string">'details': class="hl-string">'Case assigned', class="hl-string">'user': class="hl-string">'analyst2'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T11:25:00Z', class="hl-string">'event': class="hl-string">'MATCH_RESOLVED', class="hl-string">'details': class="hl-string">'Match resolved as True Positive', class="hl-string">'user': class="hl-string">'analyst2'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T12:00:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed with matches', class="hl-string">'user': class="hl-string">'analyst2'}
            ]
        }
    else: class=class="hl-string">"hl-comment"># Simple class="hl-string">'Clear' case
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T11:35:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T11:36:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed as Clear', class="hl-string">'user': class="hl-string">'SYSTEM'}
            ]
        }

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def main():
    class="hl-string">"""Main function to run the extraction process."""
    class=class="hl-string">"hl-comment"># 1. Authenticate (real implementation)
    class=class="hl-string">"hl-comment"># token = get_wc_auth_token()
    token = class="hl-string">'mock_token' class=class="hl-string">"hl-comment"># Using a mock token for this example

    class=class="hl-string">"hl-comment"># 2. Get list of cases from World-Check
    cases = get_worldcheck_cases(token)
    if not cases:
        print(class="hl-string">'No cases found for the specified period.')
        return

    event_log = []

    class=class="hl-string">"hl-comment"># 3. Process each case from World-Check
    for case in cases:
        app_id = case.get(class="hl-string">'customReference')
        if not app_id:
            continue

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Screening Request Created' event
        event_log.append({
            class="hl-string">'CustomerApplication': app_id,
            class="hl-string">'ActivityName': class="hl-string">'Screening Request Created',
            class="hl-string">'EventTime': case[class="hl-string">'creationDate'],
            class="hl-string">'ReviewerId': class="hl-string">'SYSTEM',
            class="hl-string">'DepartmentName': class="hl-string">'Compliance',
            class="hl-string">'RiskLevel': case.get(class="hl-string">'riskLevel')
        })

        details = get_worldcheck_case_details(case[class="hl-string">'caseSystemId'], token)
        for event in details.get(class="hl-string">'auditTrail', []):
            activity = None
            user = event.get(class="hl-string">'user', class="hl-string">'SYSTEM')
            department = class="hl-string">'Compliance' if user != class="hl-string">'SYSTEM' else class="hl-string">'System'
            
            class=class="hl-string">"hl-comment"># 4. Map audit trail events to activities
            if event[class="hl-string">'event'] == class="hl-string">'AUTOMATED_SCREENING':
                activity = class="hl-string">'Automated Screening Performed'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_FOUND':
                activity = class="hl-string">'Potential Match Identified'
            elif event[class="hl-string">'event'] == class="hl-string">'REVIEW_STARTED':
                activity = class="hl-string">'Analyst Review Started'
            elif event[class="hl-string">'event'] == class="hl-string">'INFORMATION_REQUESTED':
                activity = class="hl-string">'Additional Information Requested'
            elif event[class="hl-string">'event'] == class="hl-string">'ESCALATED':
                activity = class="hl-string">'Case Escalated for Review'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_RESOLVED' and class="hl-string">'False Positive' in event[class="hl-string">'details']:
                activity = class="hl-string">'False Positive Confirmed'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_RESOLVED' and class="hl-string">'True Positive' in event[class="hl-string">'details']:
                activity = class="hl-string">'True Match Confirmed'
            elif event[class="hl-string">'event'] == class="hl-string">'CASE_CLOSED' and class="hl-string">'Clear' in event[class="hl-string">'details']:
                activity = class="hl-string">'Screening Completed - Clear'
            elif event[class="hl-string">'event'] == class="hl-string">'CASE_CLOSED' and class="hl-string">'matches' in event[class="hl-string">'details']:
                activity = class="hl-string">'Screening Completed - Match Found'

            if activity:
                event_log.append({
                    class="hl-string">'CustomerApplication': app_id,
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': event[class="hl-string">'timestamp'],
                    class="hl-string">'ReviewerId': user,
                    class="hl-string">'DepartmentName': department,
                    class="hl-string">'RiskLevel': case.get(class="hl-string">'riskLevel')
                })
    
    class=class="hl-string">"hl-comment"># 5. Get events from source system
    application_ids = [case[class="hl-string">'customReference'] for case in cases if case.get(class="hl-string">'customReference')]
    source_events = get_source_system_events(application_ids)
    event_log.extend(source_events)

    class=class="hl-string">"hl-comment"># 6. Create and format DataFrame
    if not event_log:
        print(class="hl-string">'No events were generated.')
        return

    df = pd.DataFrame(event_log)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'CustomerApplication', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Add EventEndTime by shifting the EventTime of the next event
    df[class="hl-string">'EventEndTime'] = df.groupby(class="hl-string">'CustomerApplication')[class="hl-string">'EventTime'].shift(-1)
    
    class=class="hl-string">"hl-comment"># Add placeholder for non-extractable attribute
    df[class="hl-string">'SlaTargetDate'] = pd.NaT

    class=class="hl-string">"hl-comment"># 7. Finalize and Export
    output_columns = [
        class="hl-string">'CustomerApplication',
        class="hl-string">'ActivityName',
        class="hl-string">'EventTime',
        class="hl-string">'EventEndTime',
        class="hl-string">'ReviewerId',
        class="hl-string">'DepartmentName',
        class="hl-string">'RiskLevel',
        class="hl-string">'SlaTargetDate'
    ]
    class=class="hl-string">"hl-comment"># Ensure all required columns exist, even if empty
    for col in output_columns:
        if col not in df.columns:
            df[col] = None
    
    df = df[output_columns]

    output_filename = class="hl-string">'event_log_worldcheck.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%fZ')
    print(fclass="hl-string">'Successfully exported event log to {output_filename}')

if __name__ == class="hl-string">'__main__':
    main()

Prêt à commencer ?

Appuyez-vous sur ce modèle de données pour lancer votre démarche de Process Mining sur l’intégration client KYC. En suivant ces recommandations, vous pourrez dégager des analyses utiles et améliorer sensiblement vos opérations.

Retour au guide d’amélioration

Télécharger le modèle

Optimisez dès maintenant l’intégration client KYC et renforcez la conformité

Proposez une intégration simple à vos clients et réduisez le délai à 24 heures.

Démarrez l’essai gratuit

Aucune carte bancaire requise. Profitez de 14 jours d’essai gratuit.

Votre modèle de données pour l’intégration client KYC

Votre modèle de données pour l’intégration client KYC

Attributs de l’intégration client KYC

Activités de l’intégration client KYC

Guides d’extraction

Export des dossiers et du journal d’audit de Refinitiv World-Check One

Étapes

Configuration

Exemple de requête sql

Script Python utilisant l’API de filtrage World-Check One

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Optimisez dès maintenant l’intégration client KYC et renforcez la conformité

Votre modèle de données pour l’intégration client KYC

Votre modèle de données pour l’intégration client KYC

Attributs de l’intégration client KYC

Activités de l’intégration client KYC

Guides d’extraction

Export des dossiers et du journal d’audit de Refinitiv World-Check One

Étapes

Configuration

Exemple de requête sql

Script Python utilisant l’API de filtrage World-Check One

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Optimisez dès maintenant l’intégration client KYC et renforcez la conformité

Prêt à commencer ?