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

Votre template de données pour l’onboarding KYC client

Refinitiv World-Check

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

Votre template de données pour l’onboarding KYC client

Ce template vous guide dans la collecte des données essentielles à l’analyse de votre processus d’onboarding KYC client. Il présente les attributs importants à recueillir, les principales activités à suivre et des indications pour extraire ces informations de vos systèmes sources. Utilisez cette ressource pour vous assurer de disposer de toutes les données nécessaires à une analyse et à une amélioration efficaces du processus.

Attributs recommandés à collecter
Activités principales à suivre
Guide d’extraction

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de l’intégration des clients KYC

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

3 Obligatoire 5 Recommandé 11 Facultatif

	Nom	Description
	Demande client CustomerApplication	Identifiant unique d’une demande d’intégration client, utilisé comme identifiant principal du dossier.
Description Customer Application est l’identifiant central du cas. Il regroupe tous les événements et toutes les activités liés au parcours d’intégration d’un même client. Il permet de suivre intégralement et chronologiquement la progression de chaque client dans l’ensemble du processus Know Your Customer (KYC), depuis la soumission initiale jusqu’à la décision finale. Dans une analyse de process mining, cet attribut est fondamental pour reconstituer le parcours complet de chaque demande. Il permet de visualiser les flux de processus, de calculer les temps de cycle totaux et d’identifier les variantes. En analysant les cas regroupés 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 différents processus d’intégration. Pourquoi c’est important Il s’agit de l’identifiant de dossier essentiel qui relie toutes les activités associées et permet d’analyser le processus d’intégration client de bout en bout. Où les obtenir Cet identifiant correspond généralement à la clé primaire de la table principale des demandes ou 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 Event Time indique la date et l’heure précises auxquelles une activité a été enregistrée. Cet horodatage constitue la base chronologique du processus et permet d’ordonner correctement les événements afin de reconstituer l’historique du cas. Cet attribut est essentiel pour toutes les analyses temporelles en process mining. Il sert à calculer les durées entre les activités, notamment les temps de cycle et les temps d’attente, à mesurer la durée globale des cas, à analyser la performance du processus dans le temps et à vérifier le respect des accords de niveau de service (SLA). Sans horodatages fiables, il est impossible de comprendre la performance du processus et d’identifier les goulots d’étranglement temporels. Pourquoi c’est important L’horodatage de chaque activité est essentiel pour calculer toutes les métriques fondées sur la durée, découvrir la séquence du processus et réaliser une analyse des goulots d’étranglement. Où les obtenir Il s’agit d’un champ standard de tout journal d’événements ou table de pistes d’audit, souvent nommé « 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 survenu dans le processus d’intégration KYC.
Description Activity Name décrit une étape ou un événement unique du parcours d’intégration client, comme « Application Submitted », « Analyst Review Started » ou « Screening Completed - Clear ». 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 la séquence et la fréquence des différentes activités, les analystes peuvent découvrir le flux réel du processus, identifier les parcours courants, détecter les écarts par rapport à la procédure standard et repérer les étapes précises qui provoquent des retards ou des reprises. Cet attribut est essentiel pour créer des cartographies de processus et calculer des métriques au niveau des activités. Pourquoi c’est important Cet attribut définit les différentes étapes du processus. Il est essentiel pour découvrir et visualiser le flux du processus et identifier les goulots d’étranglement. Où les obtenir Ces informations se trouvent généralement dans les journaux d’événements ou les tables de pistes d’audit, souvent associés aux changements de statut de l’entité de gestion des dossiers. Exemples Correspondance potentielle identifiéeExamen par l’analyste commencéFaux positif confirméDemande approuvée
	Date cible du SLA SlaTargetDate	Date cible à laquelle le processus d’intégration client doit être terminé.
Description La date cible du SLA correspond à l’échéance de traitement de l’ensemble du dossier d’intégration, définie par l’accord de niveau de service conclu avec le client ou par les politiques internes. Cette date sert de référence pour comparer les délais réels d’achèvement. Cet attribut est fondamental pour le Dashboard « Respect et dépassement des SLA ». Il permet de déterminer si un dossier a été terminé dans les délais. L’analyse des dépassements de SLA aide à identifier les problèmes systémiques à l’origine des retards et permet à l’organisation de prendre des mesures correctives pour améliorer la ponctualité et respecter les exigences de conformité. Pourquoi c’est important Il s’agit de la référence utilisée pour mesurer la performance dans les délais. Cet attribut est essentiel au calcul du taux de respect des SLA et à l’analyse des dépassements. Où les obtenir Cette date est souvent calculée à partir de la date de soumission de la demande et de règles métier. Elle peut être stocké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 été terminé.
Description L’heure de fin de l’événement marque l’achèvement d’une activité. De nombreux événements peuvent être modélisés comme instantanés, lorsque StartTime est égal à EndTime, mais certaines activités ont une durée mesurable, comme « Analyst Review Started » et « Analyst Review Completed ». La présence d’une heure de début et d’une heure de fin permet de mesurer précisément le temps de traitement. Dans l’analyse des processus, l’heure de fin est indispensable pour calculer le temps exact consacré au traitement d’une activité, par opposition au délai de traitement qui inclut le temps d’attente. Elle permet de distinguer le temps pendant lequel un dossier est effectivement traité du temps passé en attente dans une file. Cette distinction est essentielle pour optimiser les ressources et analyser l’efficacité. Pourquoi c’est important Permet de calculer précisément le temps de traitement d’une activité en distinguant le temps de travail effectif du temps d’attente, pour une analyse plus fiable de la performance. Où les obtenir Pour les activités ayant une durée, cette information peut être stockée dans un champ distinct tel que « CompletionDate » ou « EndDate » dans le journal d’événements ou les tables de pistes d’audit. Exemples 2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
	Identifiant du réviseur ReviewerId	Identifiant de l’utilisateur, de l’analyste ou de l’agent automatisé ayant exécuté l’activité.
Description L’identifiant du réviseur, 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 ou d’un compte système pour les activités automatisées. Le suivi de cette information donne une visibilité sur la répartition de la charge de travail et la performance individuelle. Cet attribut est essentiel pour l’analyse fondée sur les ressources. Il aide à comprendre les écarts de performance entre utilisateurs ou équipes, à identifier les besoins de formation et à équilibrer la charge de travail. Il constitue également un élément important pour analyser les transferts, les réseaux sociaux et l’utilisation des ressources de conformité. Pourquoi c’est important Permet d’analyser la répartition de la charge de travail, la performance des utilisateurs et les transferts entre services, ce qui est essentiel pour optimiser les ressources. Où les obtenir Se trouve généralement dans les journaux d’événements ou les pistes d’audit, sous des noms tels que « UserID », « PerformedBy » ou « Owner ». Exemples analyst_jdoesystem_auto_screenermanager_bsmith
	Niveau de risque RiskLevel	Classification du risque calculée pour la demande client, par exemple faible, moyen ou élevé.
Description Le niveau de risque est une information essentielle dans les processus KYC, car il détermine le niveau de diligence requis. Il est souvent établi à partir de facteurs tels que le type de client, la zone géographique et la nature de son activité. Cette classification peut influencer fortement 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 variations de délais et de flux, car les demandes à haut risque peuvent nécessiter davantage d’étapes et prendre plus de temps. Cet attribut est indispensable aux Dashboards « Taux et motifs de rejet des demandes » et « Délai de lancement des contrôles d’antécédents », afin de comprendre l’incidence du risque sur les résultats et l’efficacité. Pourquoi c’est important La segmentation du processus par niveau de risque est essentielle pour comprendre pourquoi certains dossiers prennent plus de temps ou suivent des parcours différents, ainsi que pour analyser les taux de rejet. Où les obtenir Il s’agit d’une donnée centrale du dossier client ou de la demande. Consultez le module de gestion des dossiers de Refinitiv World-Check. Exemples FaibleMoyenÉlevé
	Service DepartmentName	Service ou équipe fonctionnelle responsable de l’exécution de l’activité.
Description Cet attribut indique l’unité opérationnelle ou l’équipe, comme « Onboarding », « Compliance » ou « Quality Assurance », à laquelle appartient l’utilisateur. Il permet d’analyser le processus à un niveau organisationnel plus élevé que celui de l’utilisateur individuel. L’analyse par service est essentielle pour identifier les goulots d’étranglement entre services et mesurer les temps de transmission. Elle permet de visualiser la circulation du travail entre les différentes équipes et de repérer les retards qui surviennent lors de ces transitions. Cette vue est particulièrement utile pour simplifier la collaboration entre fonctions et améliorer l’efficacité globale du processus. Pourquoi c’est important Permet d’analyser la performance du processus par service et est essentiel pour identifier les retards lors des transferts entre équipes. Où les obtenir Ces informations peuvent être stockées dans le profil de l’utilisateur du système ou dans un système RH associé. Il peut être nécessaire de les relier aux données d’événements à l’aide de l’identifiant utilisateur. Exemples Équipe d'intégrationExamen de conformitéDirection générale
	Automatisé IsAutomated	Indicateur précisant si l’activité a été exécutée par un système (true) ou par une personne (false).
Description Cet attribut booléen distingue les tâches automatisées du système des activités manuelles réalisées par les utilisateurs. Par exemple, « Automated Screening Performed » serait marqué comme automatisé, tandis que « Analyst Review Started » serait marqué comme manuel. Cette distinction est essentielle pour analyser l’automatisation. Elle permet de mesurer son impact sur l’efficacité du processus, d’identifier les tâches manuelles susceptibles d’être automatisées à l’avenir et de comprendre les interactions entre les acteurs humains et les systèmes. Elle permet également de distinguer clairement le temps de traitement du système du temps consacré aux opérations manuelles. Pourquoi c’est important Distingue les activités du système des activités humaines, ce qui est essentiel pour mesurer l’impact de l’automatisation et identifier de nouvelles possibilités d’automatisation. Où les obtenir Cet attribut est généralement déduit du nom de l’activité ou de l’identifiant utilisateur associé à l’événement, par exemple lorsque l’utilisateur est un compte « system ». Exemples truefalse
	Canal de demande ApplicationChannel	Canal par lequel la demande client a été soumise, par exemple portail en ligne, agence ou application mobile.
Description Le canal de demande indique l’origine de la soumission de la demande client. Les différents canaux peuvent présenter des niveaux variables de complétude et de qualité des données, ainsi que des profils de clientèle différents, ce qui peut avoir une incidence sur la suite du processus. Cet attribut est essentiel au Dashboard « Volume des demandes par canal ». L’analyse du volume, du délai de traitement et des résultats des demandes provenant de différents canaux permet d’identifier les canaux les plus efficaces et ceux qui nécessitent des améliorations. Elle aide à prendre des décisions stratégiques concernant l’allocation des ressources et les investissements dans les canaux. Pourquoi c’est important Aide à analyser la performance et l’efficacité des différents canaux de soumission et à éclairer les décisions stratégiques concernant la technologie et l’expérience client. Où les obtenir Ces informations sont généralement recueillies au début du processus et stockées comme attribut de la demande. Exemples Portail en ligneApplication mobileEn agenceResponsable de la relation client
	Dernière mise à jour des données LastDataUpdate	Horodatage auquel les données de cet événement ont été actualisées ou extraites pour la dernière fois du 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 est important pour comprendre l’actualité des Dashboards et des analyses de Process Mining. À des fins d’analyse, il permet de savoir si les données consultées sont quasi temps réel ou correspondent à un instantané pris à un moment donné. Il est essentiel pour la gouvernance des données et pour gérer les attentes des utilisateurs quant à l’actualité des analyses fournies. Pourquoi c’est important Fournit le contexte nécessaire sur la fraîcheur des données et permet aux utilisateurs de comprendre dans quelle mesure l’analyse du processus est à jour. Où les obtenir 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
	Est une reprise IsRework	Indicateur précisant si une activité est exécutée pour la deuxième fois ou davantage dans un même dossier.
Description IsRework est un attribut booléen calculé qui identifie les répétitions d’une activité dans un même dossier de demande client. Par exemple, si « Risk Assessment Performed » se produit plusieurs fois pour une même demande, les occurrences suivantes sont marqué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 alimente directement le Dashboard « Risk Assessment Rework and Efficiency » et le KPI « Risk Assessment Rework Rate ». 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 délais de traitement. Pourquoi c’est important Met en évidence les inefficacités du processus en signalant les activités répétées. Vous pouvez ainsi analyser les boucles de reprise, améliorer la qualité et réduire les délais de traitement. Où les obtenir Ce champ est calculé 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
	Identifiant client CustomerId	Identifiant unique de l’entité cliente en cours d’intégration.
Description L’identifiant client est l’identifiant unique du profil client. Il se distingue 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. Dans l’analyse, l’identifiant client 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. Il offre ainsi une vision plus complète du parcours client, au-delà d’une seule instance d’intégration. Pourquoi c’est important Relie le dossier d’intégration à un client donné et permet d’analyser les demandes répétées ainsi que d’enrichir les données avec les informations client de référence. Où les obtenir Il s’agit d’un champ clé de la fiche de demande ou du dossier, qui le relie aux données de référence du client. Exemples CUST-98765CUST-98766CUST-98767
	Identifiant de correspondance MatchId	Identifiant unique d’une correspondance potentielle trouvée lors d’un filtrage World-Check.
Description Lorsque le processus de filtrage automatisé trouve 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 cette détection précise. Cet identifiant relie le dossier de demande à l’enregistrement spécifique de la base World-Check qui a déclenché l’alerte. Cet attribut est utile pour les analyses détaillées de conformité. Il permet aux analystes d’examiner la nature des correspondances, de suivre la résolution d’alertes précises, par exemple la confirmation d’un faux positif ou d’une correspondance avérée, et de comprendre quels types d’alertes sont les plus fréquents ou les plus longs à résoudre. Il apporte un niveau de détail supplémentaire à l’activité « Potential Match Identified ». Pourquoi c’est important Établit un lien détaillé avec les résultats précis du filtrage et permet d’analyser plus finement les délais de résolution et les types d’alertes. Où les obtenir Cet identifiant est généré par le moteur de filtrage World-Check et enregistré dans le dossier de demande lorsqu’une correspondance potentielle est trouvée. Exemples WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
	Motif du rejet RejectionReason	Motif précis fourni lors du rejet d’une demande client.
Description Lorsqu’une demande est rejetée, le motif du rejet précise la raison de cette décision. Il peut s’agir d’une « Sanctions Match », de « Incomplete Documentation » ou d’un « High Risk Profile ». Ces informations structurées fournissent un retour utile sur la qualité des demandes reçues et l’efficacité du processus de filtrage. Cet attribut constitue le principal facteur du Dashboard « Taux et motifs de rejet des demandes ». L’analyse de ces motifs aide à identifier les causes profondes des rejets, ce qui peut conduire à améliorer le processus, à communiquer plus clairement avec les demandeurs et, éventuellement, à réduire les rejets évitables. Il apporte un contexte qualitatif à l’indicateur quantitatif du taux de rejet. Pourquoi c’est important Fournit la cause profonde des rejets de demandes, ce qui est essentiel pour identifier les améliorations à apporter au processus d’intégration et réduire le taux de rejet. Où les obtenir Cette information est enregistrée lors de l’événement « Application Rejected », probablement dans un champ du dossier ou de la demande. Exemples Correspondance avec une PPEPrésence sur une liste de sanctionsÉchec de la vérification des documentsMédias défavorables
	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 constitue un facteur important pour l’évaluation des risques et les exigences réglementaires applicables aux processus KYC. Les règles varient selon les juridictions, ce qui peut influer sur le flux et la durée du processus. L’analyse du processus par pays permet aux organisations de comparer les performances entre différentes régions, d’identifier les goulots d’étranglement propres à certains territoires et de vérifier le respect des réglementations locales. Elle ajoute une dimension géographique à l’analyse du processus et peut révéler d’importantes différences opérationnelles. Pourquoi c’est important Permet d’analyser le processus selon une dimension géographique et d’identifier les variations régionales en matière de performance, de risque et d’exigences de conformité. Où les obtenir Il s’agit d’un champ standard du profil client ou du formulaire de demande. Exemples USAGBRSGPDEU
	SLA dépassé SlaBreached	Indicateur booléen précisant si le dossier d’onboarding a été terminé après la date cible du SLA.
Description Cet attribut calculé indique si un dossier a enfreint son accord de niveau de service. Il est déterminé en comparant l’horodatage de l’activité finale de clôture, par exemple « Application Approved » ou « Application Rejected », avec la valeur « SlaTargetDate » du dossier. Cet indicateur constitue la base du Dashboard « SLA Adherence and Breach Analysis » et du KPI « SLA Adherence Rate ». Il simplifie l’analyse en permettant aux utilisateurs de filtrer rapidement tous les dossiers pour lesquels le SLA a été dépassé. L’analyse des caractéristiques de ces dossiers permet aux organisations d’identifier les causes profondes des retards et de cibler efficacement leurs efforts d’amélioration. Pourquoi c’est important Mesure directement le respect des accords de niveau de service et facilite le filtrage ainsi que l’analyse des causes profondes des dossiers en retard. Où les obtenir Ce champ est calculé lors de la transformation des données, en comparant l’horodatage de l’activité finale d’un dossier avec le champ SlaTargetDate. Exemples truefalse
	Système source SourceSystem	Système depuis lequel les données d’événements ont été extraites, en l’occurrence Refinitiv World-Check.
Description Cet attribut identifie l’origine des données du processus. Il peut s’agir d’une valeur constante dans le cadre d’une extraction depuis une seule source, mais il devient essentiel lorsque des données provenant de plusieurs systèmes, comme un CRM et World-Check, sont combinées pour obtenir une vue globale du processus. Dans l’analyse, il facilite la gouvernance des données, le diagnostic des problèmes et la compréhension de leur contexte. Par exemple, les activités enregistrées dans un système central de filtrage peuvent présenter des propriétés ou un niveau de détail différents de ceux d’un système périphérique. Il garantit une traçabilité claire et vérifiable des données. Pourquoi c’est important Identifie l’origine des données, ce qui est essentiel pour la gouvernance et la validation des données, ainsi que pour la fusion de données provenant de plusieurs sources. Où les obtenir Il s’agit souvent d’une valeur statique ajoutée lors du processus d’extraction, de transformation et de chargement (ETL) afin d’identifier le jeu de données. Exemples Refinitiv World-CheckWorldCheckOne
	Type de client CustomerType	Classification du client, par exemple particulier, société ou fiducie.
Description Le type de client catégorise l’entité intégrée. Les différents types de clients présentent souvent des exigences d’intégration, des profils de risque et des obligations réglementaires distincts. Par exemple, l’intégration d’une société est généralement plus complexe que celle d’un particulier. Cet attribut est utilisé pour les analyses par segment, notamment dans le Dashboard « Performance KYC par type de client ». Il permet de comparer l’efficacité du processus, les délais de traitement et les taux de rejet entre différents segments de clientèle. Les organisations peuvent ainsi adapter et optimiser le parcours d’intégration en fonction de chaque type de client. Pourquoi c’est important Permet de comparer la performance entre différents segments de clientèle et d’adapter et d’optimiser le processus d’intégration pour chaque type. Où les obtenir Il s’agit d’un attribut fondamental stocké dans la fiche client ou la fiche de demande du système source. Exemples ParticulierSociétéOrganisation à but non lucratifFiducie

Obligatoire Recommandé Facultatif

Activités d’intégration des clients KYC

Voici les principales étapes et les principaux jalons à enregistrer dans votre journal d’événements pour découvrir précisément le processus.

8 Recommandé 6 Facultatif

	Activité	Description
	Compte activé	Le compte du client est créé et activé dans le système central, ce qui achève le parcours d’intégration. Cette étape suit l’approbation finale de la demande et rend le compte utilisable.
Pourquoi c’est important Il s’agit de la dernière étape du processus, celle qui produit la valeur attendue. Le délai entre la soumission de la demande et l’activation du compte constitue un indicateur important de l’efficacité opérationnelle et de la satisfaction client. Où les obtenir Cet événement n’est pas capturé dans World-Check. Il est enregistré dans le système bancaire central ou le système de gestion des comptes clients et doit être mis en correspondance à l’aide de l’identifiant de la demande client. Collecte Événement enregistré dans le système central de gestion des comptes lors de l’activation du compte. Type d’événement explicit
	Correspondance avérée confirmée	Un analyste confirme qu’une correspondance potentielle concerne bien le client soumis au filtrage, ce qui révèle un risque potentiel. Cette étape importante déclenche généralement des contrôles renforcés ou le rejet de la demande.
Pourquoi c’est important Il s’agit d’un résultat important pour la réduction des risques et d’un moment déterminant du processus. Il influence directement la décision finale concernant la demande client et joue un rôle essentiel dans les rapports et analyses de conformité. Où les obtenir Il s’agit d’une action explicite de l’utilisateur, par laquelle l’analyste classe une correspondance donnée comme « True Match » ou « Confirmed Match ». Cet événement est enregistré dans la piste d’audit du dossier. Collecte Enregistré lorsqu’un analyste confirme officiellement une correspondance dans le système. Type d’événement explicit
	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 API ou une saisie manuelle depuis un système en amont et marque le début du contrôle des informations de risque.
Pourquoi c’est important Cet événement marque le début officiel du sous-processus de contrôle. Le délai entre Application Submitted et cette activité révèle les retards dans les transferts entre le système métier et la fonction conformité. Où les obtenir Enregistré 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 le dossier ou l’identifiant d’entité concerné seraient utilisés. Collecte Enregistré automatiquement lorsqu’un nouveau dossier de contrôle est créé dans le système. Type d’événement explicit
	Demande rejetée	La demande client est officiellement rejetée, souvent à la suite d’un résultat « Match Found » dans World-Check ou d’autres facteurs de risque. Cet événement constitue l’issue négative finale du processus d’intégration.
Pourquoi c’est important Il s’agit du principal point de sortie en échec du processus. L’analyse des rejets, notamment de leurs motifs et des activités qui les précèdent, est essentielle pour améliorer le processus et réduire les rejets évitables. Où les obtenir Cette décision opérationnelle 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. Collecte Événement enregistré dans le système applicatif source, souvent accompagné d’un code indiquant le motif du rejet. Type d’événement explicit
	Demande soumise	Cette activité marque le début du processus KYC Customer Onboarding, lorsqu’un client soumet sa demande. Cet événement est généralement enregistré dans un CRM ou un système applicatif central, qui déclenche ensuite le contrôle dans Refinitiv World-Check.
Pourquoi c’est important Il s’agit de l’événement de début principal du parcours d’intégration client de bout en bout. L’analyse du temps écoulé entre ce point et l’achèvement du processus fournit la durée globale du cycle d’intégration, un indicateur essentiel pour mesurer l’expérience client et le respect des SLA. Où les obtenir Cet événement n’est pas natif de World-Check. Il doit provenir d’un système en amont, tel qu’un CRM ou une plateforme de gestion des comptes clients, puis être mis en correspondance à l’aide de l’identifiant Customer Application. Collecte Événement enregistré dans le système applicatif source lors de la soumission initiale. Type d’événement explicit
	Examen par l’analyste commencé	Un analyste conformité commence l’investigation manuelle des correspondances potentielles associées à une demande client. Il compare les informations relatives aux correspondances potentielles avec celles du client afin d’en déterminer la pertinence.
Pourquoi c’est important Cette activité marque le début du contrôle manuel de conformité, qui constitue souvent un goulot d’étranglement. La mesure du temps écoulé entre « Potential Match Identified » et cette activité révèle les retards liés aux files d’attente, tandis que la durée du contrôle renseigne sur l’efficacité des analystes. Où les obtenir Cet événement peut être déduit lorsqu’un analyste « prend en charge » un dossier ou l’ouvre depuis la file d’examen. Le système peut également l’enregistrer explicitement dans une piste d’audit lorsque le statut du dossier passe à « In Review » ou qu’il est attribué à un utilisateur donné. Collecte Déduit d’un changement de statut du dossier vers « Under Review » ou de l’attribution du dossier à un analyste. Type d’événement inferred
	Filtrage terminé, aucun risque identifié	Le dossier de filtrage est officiellement clôturé avec le résultat « Clear », ce qui signifie qu’aucune correspondance avérée n’a été trouvée. Cette décision est transmise au système d’origine, permettant au processus d’intégration de se poursuivre.
Pourquoi c’est important Cette activité représente l’achèvement réussi du parcours standard du processus de filtrage. Elle constitue un point de sortie important pour mesurer le délai de traitement des demandes standard à faible risque. Où les obtenir Déduit du passage du statut final du dossier à « Clear », « Complete » ou « Closed - No Match ». L’horodatage de ce changement de statut final est utilisé. Collecte Dérivé de l’horodatage du statut final du dossier indiquant un résultat sans correspondance. Type d’événement inferred
	Filtrage terminé, correspondance trouvée	Le dossier de filtrage est officiellement clôturé avec le résultat « Match Found », indiquant qu’un risque confirmé a été identifié. Cette décision déclenche un processus en aval différent, tel qu’un contrôle renforcé ou un rejet.
Pourquoi c’est important Il s’agit du principal point de sortie du parcours 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ù les obtenir Déduit du passage du statut final du dossier à « Match Found », « Risk Identified » ou « Closed - Positive ». L’horodatage de ce changement de statut final est utilisé. Collecte Dérivé de l’horodatage du statut final du dossier indiquant une correspondance confirmée. Type d’événement inferred
	Contrôle automatisé effectué	Le système World-Check compare automatiquement les informations du client avec sa base de données de renseignement sur les risques. Il s’agit d’une activité pilotée par le système, qui produit un premier ensemble de résultats, tels que des correspondances potentielles ou un statut indiquant l’absence de correspondance.
Pourquoi c’est important Cette activité constitue la première étape créatrice de valeur du processus de filtrage. Les délais observés avant ce point signalent des problèmes liés à la disponibilité du système ou des données, tandis que le résultat détermine la charge de travail manuel à venir. Où les obtenir Cet événement peut être enregistré explicitement dans la piste d’audit du dossier ou déduit de l’horodatage auquel les premiers résultats du filtrage deviennent disponibles pour le dossier. Collecte Entrée du journal système générée à l’issue de l’analyse automatisée de la base de données. Type d’événement explicit
	Correspondance potentielle identifiée	Le processus de filtrage automatisé a identifié une ou plusieurs correspondances potentielles nécessitant un examen manuel par un analyste. Cet événement fait passer le dossier d’un état automatisé à une file d’attente d’investigation manuelle.
Pourquoi c’est important Cette activité constitue un point de bifurcation essentiel du processus. Les cas présentant des correspondances potentielles suivent un parcours plus long et plus complexe. Leur suivi facilite la planification des ressources et l’analyse des goulots d’étranglement pour l’équipe chargée du contrôle. Où les obtenir Déduit du changement de statut du dossier vers « Review Required », « Potential Match » ou un état similaire dans le module de gestion des dossiers World-Check. Collecte 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 client a été entièrement approuvée à l’issue d’un filtrage KYC concluant et de tous les autres contrôles requis. Cet événement se produit généralement dans le système source après réception d’un résultat « Clear » de World-Check.
Pourquoi c’est important Cette étape marque l’issue opérationnelle réussie du processus d’intégration. Le suivi du délai entre la soumission et cette étape permet de mesurer le délai total nécessaire pour accepter un nouveau client. Où les obtenir 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 opérationnelle finale. Collecte Événement enregistré dans le système applicatif source lors de 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 transfert important au sein de l’équipe conformité.
Pourquoi c’est 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 révéler des besoins de formation pour les analystes débutants ou des ambiguïtés dans les règles de contrôle. Où les obtenir Cette action est enregistrée explicitement dans le flux de travail du cas ou dans la piste d’audit. Elle peut également être déduite d’un changement d’utilisateur affecté au cas, notamment lorsque le nouvel utilisateur dispose de droits plus élevés. Collecte L’escalade est enregistrée au moyen d’un bouton « Escalate » dédié ou d’une action du flux de travail dans le cas. Type d’événement explicit
	Faux positif confirmé	L’analyste conclut qu’une correspondance potentielle ne concerne pas le client soumis au filtrage. La correspondance est écartée et le filtrage de cette alerte est clôturé.
Pourquoi c’est important Cette situation représente une issue fréquente du processus d’examen. Comprendre le temps nécessaire au traitement des faux positifs permet de mesurer l’efficacité des analystes et la précision de la logique de filtrage automatisé. Où les obtenir Il s’agit d’une action explicite de l’utilisateur, par laquelle l’analyste classe une correspondance donnée comme « False Positive » ou « Not a Match ». Cette action est généralement enregistrée dans l’historique du dossier. Collecte Enregistré lorsqu’un analyste écarte officiellement une correspondance potentielle dans le système. Type d’événement explicit
	Informations complémentaires demandées	L’analyste détermine que des informations supplémentaires sont nécessaires pour résoudre la correspondance potentielle et les demande à l’unité opérationnelle. Le dossier passe alors en attente jusqu’à réception des informations.
Pourquoi c’est important La fréquence de cette activité révèle des problèmes de qualité dans les données initiales fournies pour le filtrage. Elle entraîne des délais importants, car elle dépend d’équipes externes, et contribue fortement à l’allongement des délais de traitement. Où les obtenir Il peut s’agir d’une action explicite de l’utilisateur, enregistrée dans les notes du dossier ou dans le journal d’audit. L’événement peut également être déduit d’un changement de statut vers « Pending Information » ou « RFI ». Collecte Enregistré lorsqu’un analyste utilise une fonctionnalité pour signaler que le dossier nécessite des informations supplémentaires. Type d’événement explicit

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Refinitiv World-Check

Étapes

Connectez-vous à World-Check One : accédez au portail Refinitiv World-Check One avec vos identifiants.
Accédez à la Gestion des dossiers : ouvrez la section Case Management, où tous les dossiers de screening sont stockés et gérés.
Préparez l’export du rapport des dossiers : accédez à la fonction de reporting ou d’export dans Case Management. Elle peut être intitulée « Export Cases » ou « Case Report ».
Configurez le rapport des dossiers : sélectionnez les colonnes à inclure dans l’export. Veillez à choisir les champs correspondant à l’identifiant du dossier (CustomerApplication), à la date de création, à la date de résolution, au statut du dossier, par exemple Clear ou Match Found, et au niveau de risque.
Exportez les données de Case Management : définissez la période, généralement les 3 à 6 derniers mois d’activité. Appliquez les filtres nécessaires, par exemple par groupe d’utilisateurs ou 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 reporting de la piste d’audit ou de l’Event Log 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 dossier, le nom ou la description de l’événement, son horodatage et l’utilisateur ayant effectué l’action. Exportez ces données pour la même période que le rapport des dossiers. Enregistrez le fichier sous le nom audit_trail.csv.
Récupérez les étapes externes du processus : obtenez les données relatives aux activités qui se déroulent en dehors de World-Check, telles que Application Submitted, Application Approved, Account Activated et Application Rejected. Ces données proviennent généralement d’un CRM ou d’un système bancaire central. Exportez-les avec l’identifiant CustomerApplication et les horodatages correspondants.
Combinez et transformez les données : chargez les fichiers CSV exportés (case_report.csv, audit_trail.csv et les données du système externe) 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 de l’Event Log d’audit aux valeurs standardisées d’ActivityName. Par exemple, une entrée telle que « Case Assigned to Analyst » devient « Analyst Review Started ».
Associez les changements de statut aux activités : traitez le fichier case_report.csv afin de 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 l’Event Log final : réunissez toutes les données traitées provenant des différents fichiers sources dans un seul fichier CSV. Vérifiez que le fichier final contient les colonnes requises : CustomerApplication, ActivityName et EventTime, ainsi que les attributs recommandés. Enregistrez ce fichier pour le charger dans l’outil de Process Mining.

Configuration

Types de rapports : vous devrez générer au moins deux rapports distincts : un rapport récapitulatif de Case Management et un rapport détaillé de la piste d’audit.
Période : pour une première analyse, sélectionnez une période d’au moins 3 à 6 mois afin de couvrir suffisamment de dossiers terminé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) pour faciliter le traitement.
Colonnes clés du rapport des dossiers : vérifiez que l’export contient l’identifiant du dossier, l’horodatage de création, l’horodatage de résolution, le statut final, l’analyste affecté et le niveau de risque.
Colonnes clés du rapport de la piste d’audit : vérifiez que l’export de l’Event Log d’audit contient l’identifiant du dossier, la description de l’événement, son horodatage et l’identifiant utilisateur.
Prérequis : vous devez disposer d’un accès au portail World-Check One avec des autorisations permettant de consulter et d’exporter les données de Case Management et de l’Event Log d’audit. Des privilèges supérieurs à ceux d’un rôle d’analyste standard peuvent être nécessaires.

a 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. Obtenez votre clé API et votre secret API World-Check One auprès de votre interlocuteur Refinitiv ou du portail développeur. Stockez ces identifiants de manière sécurisée.
Développez la logique d’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é et votre secret API pour obtenir un jeton bearer temporaire, nécessaire aux appels API suivants.
Identifiez 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 de la demande. Vous devrez en extraire des événements tels que Application Submitted, Application Approved, Account Activated et Application Rejected. Cette extraction peut être réalisée au moyen d’une requête de base de données ou d’une autre API.
Récupérez les dossiers World-Check : avec le jeton authentifié, 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 donnée, par exemple à partir de 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 afin de récupérer la liste complète des dossiers correspondant à la période sélectionnée.
Récupérez les détails et l’historique des dossiers : pour chaque identifiant de dossier récupéré, envoyez des requêtes GET supplémentaires vers des points de terminaison tels que /cases/{case_system_id} et /cases/{case_system_id}/audit-trail. Ces points de terminaison 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 données de réponse de l’API, notamment les détails du dossier et la piste d’audit, pour chaque dossier. 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, tandis qu’un résultat False Positive devient False Positive Confirmed.
Combinez les sources de données : fusionnez les données extraites de World-Check avec celles de votre système source, à partir de l’étape 3. Utilisez l’identifiant CustomerApplication comme clé commune afin de créer un Event Log complet pour chaque client.
Structurez et enrichissez les données : rassemblez tous les événements associés dans une seule liste d’enregistrements. Pour chaque enregistrement, vérifiez que les attributs requis (CustomerApplication, ActivityName, EventTime) et les attributs recommandés sont renseignés. Calculez EventEndTime lorsque cela est possible, par exemple en utilisant l’horodatage de l’événement suivant pour le dossier concerné.
Exportez au format CSV : convertissez la liste finale des enregistrements en DataFrame pandas. Réorganisez les colonnes selon le format requis, puis exportez le DataFrame dans un fichier CSV. Enregistrez le fichier avec un encodage UTF-8 afin qu’il soit compatible avec ProcessMind.

Configuration

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

a 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 ?

Utilisez ce template de données pour lancer votre démarche de Process Mining appliquée à l’onboarding KYC client. En suivant ces recommandations, vous pourrez obtenir 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’onboarding KYC client et renforcez la conformité

Mettez en place un onboarding client simple et réduisez le délai à seulement 24 heures.

Démarrer l’essai gratuit

Aucune carte bancaire requise. Profitez de 14 jours gratuits.

Votre template de données pour l’onboarding KYC client

Votre template de données pour l’onboarding KYC client

Attributs de l’intégration des clients KYC

Activités d’intégration des clients KYC

Guides d’extraction

Export du dossier et de l’Event Log d’audit de Refinitiv World-Check One

Étapes

Configuration

a Exemple de requête sql

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

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

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

Votre template de données pour l’onboarding KYC client

Votre template de données pour l’onboarding KYC client

Attributs de l’intégration des clients KYC

Activités d’intégration des clients KYC

Guides d’extraction

Export du dossier et de l’Event Log d’audit de Refinitiv World-Check One

Étapes

Configuration

a Exemple de requête sql

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

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

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

Nous attachons de l’importance à votre confidentialité