> Amélioration Continue des Processusus > Intégration client KYC > Refinitiv World Check > Template de données

Votre modèle de données d'intégration client KYC

Refinitiv World-Check

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

Votre modèle de données d'intégration client KYC

Ce modèle vous guide à travers la collecte des données essentielles pour analyser votre processus d'intégration client KYC. Il décrit les attributs essentiels à capturer, les activités clés à suivre, et fournit des conseils sur la manière d'extraire ces informations de vos systèmes sources. Utilisez cette ressource pour vous assurer d'avoir toutes les données nécessaires pour analyser et améliorer efficacement vos processus.

Attributs recommandés à collecter
Activités clés à suivre
Guide d'extraction

Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Télécharger le modèle

Attributs d'intégration client KYC

Ce sont les champs de données recommandés à inclure dans votre journal d'événements pour une analyse complète de l'intégration client KYC.

3 Obligatoire 5 Recommandé 11 Facultatif

	Nom	Descriptionn
	Demande client CustomerApplication	L'identifiant unique pour la demande d'intégration d'un seul client, servant d'identifiant principal du dossier.
Descriptionn 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 seul client. Il permet le suivi complet et chronologique de la progression de chaque client à travers l'ensemble du processus Know Your Customer (KYC), de la soumission initiale à la décision finale. Dans l'analyse du Process Mining, cet attribut est indispensable pour reconstruire le parcours complet de chaque demande. Il facilite la visualisation des flux de processus, le calcul des temps de cycle totaux et l'identification des variantes. En analysant les dossiers regroupés par cet identifiant, les organisations peuvent comprendre les différents chemins qu'une demande peut prendre, identifier les points de blocage et comparer l'efficacité de divers processus d'intégration. Pourquoi est-ce important ? : Il s'agit de l'identifiant de dossier essentiel qui relie toutes les activités associées, permettant d'analyser le processus d'intégration client complet. Source des données : Cet identifiant est généralement la clé primaire dans la table principale de gestion des applications ou des dossiers au sein du système Refinitiv World-Check ou d'un CRM intégré. Exemples APP-2023-00123APP-2023-00124APP-2023-00125
	Heure de l'événement EventTime	L'horodatage indiquant quand une activité ou un événement spécifique s'est produit.
Descriptionn Event Time fournit la date et l'heure précises auxquelles une activité a été enregistrée. Cet horodatage est la pivot chronologique du processus, permettant aux événements d'être ordonnés correctement pour reconstituer l'historique du dossier. Cet attribut est indispensable pour toutes les analyses temporelles en Process Mining. Il est utilisé pour calculer les durées entre les activités (temps de cycle et temps d'attente), mesurer la durée globale du dossier, analyser la performance des processus au fil du temps et vérifier la conformité aux Accords de Niveau de Service (SLA). Sans horodatages précis, il est impossible de comprendre la performance des processus et d'identifier les points de blocage temporels. Pourquoi est-ce important ? : L'horodatage pour chaque activité est indispensable pour calculer toutes les métriques basées sur la durée, découvrir la séquence de processus et effectuer une analyse des points de blocage. Source des données : Il s'agit d'un champ standard dans tout journal d'événements ou table de piste d'audit, souvent nommé 'Horodatage', 'EventDate' ou 'CreationDate'. Exemples 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
	Nom de l'activité ActivityName	Le nom d'un événement commercial ou d'une tâche spécifique survenu au sein du processus d'intégration KYC.
Descriptionn Le nom de l'activité décrit une étape ou un événement unique dans le parcours d'intégration client, tel que 'Demande soumise', 'Examen analyste débuté' ou 'Filtrage terminé - Clair'. Ces activités forment les nœuds de la carte de processus, fournissant une ventilation détaillée du workflow complet. L'analyse des activités est l'essence du Process Mining. En suivant la séquence et la fréquence des différentes activités, les analystes peuvent découvrir le flux de processus réel, identifier les chemins courants, détecter les écarts par rapport à la procédure standard et identifier les étapes spécifiques qui causent des retards ou du reprises. Cet attribut est impératif pour construire des cartes de processus et calculer des métriques au niveau de l'activité. Pourquoi est-ce important ? : Cet attribut définit les étapes individuelles du processus, ce qui est indispensable pour découvrir et visualiser le flux de processus et identifier les points de blocage. Source des données : Cette information se trouve généralement dans les journaux d'événements ou les tables de piste d'audit, souvent associée aux changements de statut dans l'entité de gestion de dossier. Exemples Correspondance potentielle identifiéeExamen par l'analyste initiéFaux positif confirméDemande Approuvée
	Date cible SLA SlaTargetDate	La date cible à laquelle le processus d'intégration client devrait être achevé.
Descriptionn La date cible du SLA est la date limite pour l'achèvement de l'ensemble du dossier d'intégration, telle que définie par l'accord de niveau de service avec le client ou les politiques internes. Cette date est la référence par rapport à laquelle les temps d'achèvement réels sont mesurés. Cet attribut est indispensable pour le tableau de bord 'Analyse du respect et des écarts de SLA'. Il est utilisé pour calculer si un dossier a été achevé à temps ou non. L'analyse des manquements aux SLA aide à identifier les problèmes systémiques dans le processus qui causent des retards et permet à l'organisation de prendre des mesures correctives pour améliorer la ponctualité et respecter les exigences de conformité. Pourquoi est-ce important ? : Il s'agit de la référence pour mesurer la performance dans les délais et est indispensable pour calculer le taux d'efficacité.x de respect des SLA et analyser les manquements. Source des données : Cette date est souvent calculée en fonction de la date de soumission de la demande et des règles métier. Elle peut être stockée en tant que champ dans le dossier. Exemples 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
	Département DepartmentName	Le département ou l'équipe fonctionnelle responsable de l'exécution de l'activité.
Descriptionn Cet attribut spécifie l'unité commerciale ou l'équipe, telle que 'Intégration', 'Conformité' ou 'Assurance Qualité', à laquelle l'utilisateur appartient. Il permet une analyse à un niveau organisationnel supérieur à celui de l'utilisateur individuel. L'analyse par département est indispensablele pour identifier les points de blocage interdépartementaux et mesurer les temps de transfert. Elle aide à visualiser comment le travail circule entre les différentes équipes et où des retards se produisent lors de ces transitions. Cette vue est très utile pour rationaliser la collaboration interfonctionnelle et améliorer l'efficacité globale des processus. Pourquoi est-ce important ? : Permet l'analyse de la performance des processus par département et est indispensable pour identifier les retards dans les transferts entre les différentes équipes. Source des données : Ces informationsns peuvent être stockées avec le profil de l'utilisateur dans le système ou un système RH associé. Elles pourraient devoir être jointes aux données d'événements à l'aide de l'ID utilisateur. Exemples Équipe d'intégrationExamen de conformitéDirection générale
	Heure de fin de l'événement EventEndTime	L'horodatage indiquant quand une activité ou un événement spécifique a été achevé.
Descriptionn L'heure de fin de l'événement marque la fin d'une activité. Alors que de nombreux événements peuvent être modélisés comme instantanés (où HeureDébut égale HeureFin), certaines activités ont une durée mesurable, comme 'Examen analyste débuté' et 'Examen analyste terminé'. Avoir à la fois les heures de début et de fin permet une mesure précise du temps de traitement. En analyse de processus, avoir une heure de fin est indispensable à calculer le temps de traitement exact d'une activité, par opposition au temps de cycle qui inclut le temps d'attente. Cela aide à différencier le temps qu'un dossier passe à être activement traité du temps qu'il reste inactif dans une file d'attente. C'est indispensable pour l'optimisation des ressources et l'analyse de l'efficacité. Pourquoi est-ce important ? : Permet le calcul précis du temps de traitement des activités, en séparant le temps de travail actif du temps d'attente inactif pour une analyse de performance plus précise. Source des données : Pour les activités ayant une durée, cela peut être stocké dans un champ séparé comme 'CompletionDate' ou 'EndDate' dans les tables du journal d'événements ou de la piste d'audit. Exemples 2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
	ID du réviseur ReviewerId	L'identifiant de l'utilisateur, de l'analyste ou de l'agent automatisé qui a effectué l'activité.
Descriptionn L'ID du réviseur, ou utilisateur, indique qui a exécuté une tâche particulière dans le processus KYC. Il peut s'agir d'un analyste de conformité, d'un spécialiste de l'intégration ou d'un compte système pour les activités automatisées. Le suivi de ces informations offre une visibilité sur la répartition de la charge de travail et la performance individuelle. Cet attribut est indispensable pour l'analyse basée sur les ressources. Il aide à comprendre les différences de performance entre les utilisateurs ou les équipes, à identifier les besoins en formation et à optimiser l'équilibrage de la charge de travail. C'est également un élément clé pour analyser les transferts, les réseaux d'interactions et l'utilisation des ressources de conformité. Pourquoi est-ce important ? : Permet l'analyse de la répartition de la charge de travail, de la performance des utilisateurs et des transferts interdépartementaux, ce qui est impératif pour l'optimisation des ressources. Source des données : Généralement trouvées dans les journaux d'événements ou les pistes d'audit, souvent nommées 'UserID', 'PerformedBy' ou 'Owner'. Exemples analyst_jdoesystem_auto_screenermanager_bsmith
	Niveau de risque RiskLevel	La classification de risque calculée de la demande client, telle que Faible, Moyenne ou Élevée.
Descriptionn Le niveau de risque est une information critique dans les processus KYC, déterminant le niveau de diligence raisonnable requis. Il est souvent déterminé en fonction de facteurs tels que le type de client, la géographie et la nature de son activité. Cette classification peut influencer considérablement le chemin de processus qu'une demande emprunte. En analyse de processus, la segmentation des dossiers par niveau de risque est indispensablele. Elle aide à expliquer les variations des temps de cycle et des flux de processus ; par exemple, les demandes à haut risque peuvent nécessiter plus d'étapes et prendre plus de temps. Cet attribut est indispensable pour les dashboards 'Taux et raisons de rejet des demandes' et 'Temps de cycle d'initiation des vérifications d'antécédents' afin de comprendre comment le risque impacte les résultats et l'efficacité. Pourquoi est-ce important ? : Segmenter le processus par niveau de risque est impératif pour comprendre pourquoi certains cas prennent plus de temps ou suivent des chemins différents, et pour analyser les taux de rejet. Source des données : Il s'agit d'un point de données central dans le dossier de demande client. Consultez le module de gestion des dossiers dans Refinitiv World-Check. Exemples FaibleMoyenÉlevé
	Canal de demande ApplicationChannel	Le canal par lequel la demande client a été soumise, tel que Portail en ligne, En agence ou Application mobile.
Descriptionn Le canal de demande indique la source de soumission de la demande client. Différents canaux peuvent avoir des niveaux variables d'exhaustivité des données, de qualité et de données démographiques des clients, ce qui peut impacter le processus en aval. Cet attribut est indispensable pour le tableau de bord 'Débit des demandes par canal'. En analysant le volume, le temps de cycle et les résultats des demandes provenant de différents canaux, une organisation peut identifier les canaux les plus efficaces et ceux qui pourraient nécessiter des améliorations de processus. Cette analyse soutient les décisions stratégiques concernant l'allocation des ressources et l'investissement dans les canaux. Pourquoi est-ce important ? : Aide à analyser la performance et l'efficacité des différents canaux de soumission, éclairant ainsi les décisions stratégiques concernant la technologie et l'expérience client. Source des données : Cette information est généralement capturée au début du processus et stockée comme un attribut dans le dossier de demande. Exemples Portail en ligneApplication mobileEn AgenceGestionnaire de Relation
	Dernière mise à jour des données LastDataUpdate	L'horodatage de la dernière actualisation ou extraction des données de cet événement à partir du système source.
Descriptionn Cet attribut indique la la réactualisation des données. Il enregistre la date et l'heure de la dernière extraction de données de Refinitiv World-Check. C'est important pour comprendre l'actualité des dashboards et analyses de Process Mining. À des fins analytiques, cela permet aux utilisateurs de savoir s'ils consultent des données quasi-temps réel ou un instantané d'un point précis dans le temps. C'est indispensable pour la gouvernance des données et pour gérer les attentes des utilisateurs quant à la validité des informations fournies. Pourquoi est-ce important ? : Fournit un contexte essentiel sur la la réactualisation des données, garantissant que les utilisateurs comprennent l'actualité de l'analyse des processus. Source des données : Cet horodatage est généré et ajouté pendant le processus d'extraction, de transformation et de chargement des données (ETL). Exemples 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Est Automatisé IsAutomated	Un indicateur signalant si l'activité a été effectuée par un système (vrai) ou par un humain (faux).
Descriptionn Cet attribut booléen distingue les tâches système automatisées des activités manuelles effectuées par les utilisateurs. Par exemple, 'Filtrage automatisé effectué' serait marqué comme automatisé, tandis que 'Examen analyste débuté' serait manuel. Cette distinction est indispensablele pour l'analyse de l'automatisation. Elle aide à mesurer l'impact de l'automatisation sur l'efficacité des processus, à identifier quelles tâches manuelles sont candidates à une future automatisation et à comprendre l'interaction entre les acteurs humains et système. Elle permet une séparation claire entre le temps de traitement du système et le temps de manipulation manuel. Pourquoi est-ce important ? : Différencie les activités système et humaines, ce qui est indispensable pour mesurer l'impact de l'automatisation et identifier de nouvelles opportunités d'automatisation. Source des données : Ceci est généralement dérivé en fonction du nom de l'activité ou de l'ID utilisateur associé à l'événement (par exemple, si l'utilisateur est un compte 'système'). Exemples truefaux
	Est un reprises IsRework	Un indicateur signalant si une activité est exécutée une deuxième fois ou plus au sein du même dossier.
Descriptionn IsRework est un attribut booléen calculé qui identifie quand une activité est répétée au sein du même dossier de demande client. Par exemple, si 'Évaluation des risques effectuée' se produit plus d'une fois pour une seule demande, les occurrences ultérieures sont marquées comme reprises. Cet attribut est indispensable pour identifier les inefficacités de processus, les boucles et les répétitions inutiles. Il prend directement en charge le tableau de bord 'Retravail et efficacité de l'évaluation des risques' et l'indicateur clé de performance (KPI) 'Taux de reprises de l'évaluation des risques'. L'analyse du reprises aide à découvrir les problèmes de qualité, de clarté de l'information ou de prise de décision, qui entraînent des efforts gaspillés et des temps de cycle plus longs. Pourquoi est-ce important ? : Met en évidence les inefficacités de processus en signalant les activités répétées, permettant l'analyse des boucles de reprise pour améliorer la qualité et réduire les temps de cycle. Source des données : Ceci est calculé lors de la transformation des données en analysant la séquence des activités dans chaque dossier et en signalant toute occurrence non initiale d'une activité. Exemples truefaux
	ID client CustomerId	Un identifiant unique pour l'entité client en cours d'intégration.
Descriptionn L'ID client est l'identifiant unique du profil client. Il est distinct de l'ID de demande client, car un client peut soumettre plusieurs demandes au fil du temps. Cet attribut lie le processus d'intégration au dossier client de référence. En analyse, l'ID client permet de suivre les demandes répétées du même client et peut être utilisé pour enrichir les données de processus avec d'autres attributs client provenant d'un système CRM ou de données de référence. Cela permet une vision plus holistique du parcours client au-delà d'une seule instance d'intégration. Pourquoi est-ce important ? : Lie le dossier d'intégration à un client spécifique, permettant l'analyse des demandes répétées et l'enrichissement avec les données clients de référence. Source des données : Ce serait un champ clé dans le dossier de demande ou de cas, le reliant aux données de référence client. Exemples CUST-98765CUST-98766CUST-98767
	ID de correspondance MatchId	L'identifiant unique pour une correspondance potentielle trouvée lors d'un filtrage World-Check.
Descriptionn Lorsqu'un processus de filtrage automatisé détecte une correspondance potentielle avec des listes de sanctions, des listes de PPE (Personnes Politiquement Exposées) ou des informations médiatiques défavorables, un "ID de Correspondance" est souvent généré pour suivre la découverte spécifique. Cet ID relie le dossier de la demande à l'enregistrement spécifique dans la base de données World-Check qui a déclenché l'alerte. Cet attribut est utile pour une analyse détaillée de la conformité. Il permet aux analystes d'examiner la nature des correspondances, de suivre la résolution d'alertes spécifiques (par exemple, confirmer un faux positif ou une correspondance avérée) et de comprendre quels types d'alertes sont les plus courants ou prennent le plus de temps à résoudre. Il fournit un niveau de détail plus profond dans l'activité "Correspondance Potentielle Identifiée". Pourquoi est-ce important ? : Fournit un lien granulaire vers les résultats de filtrage spécifiques, permettant une analyse plus approfondie des délais de résolution des correspondances et des types d'alertes. Source des données : Cet ID serait 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 de refus RejectionReason	La raison spécifique fournie lorsqu'une demande client est rejetée.
Descriptionn Lors du rejet d'une demande, la "Raison de Rejet" indique pourquoi cette décision a été prise. Les raisons peuvent inclure "Correspondance Sanctions", "Documentation Incomplète" ou "Profil à Haut Risque". Cela fournit un retour d'information précieux et structuré sur la qualité des demandes reçues et l'efficacité du processus de filtrage. Cet attribut est le moteur principal du tableau de bord "Taux et Raisons de Rejet des Demandes". L'analyse de ces raisons aide à identifier les causes profondes des rejets, ce qui peut conduire à des améliorations de processus, une communication plus claire avec les demandeurs et potentiellement une réduction des rejets inutiles. Il fournit un contexte qualitatif au KPI quantitatif du taux de rejet. Pourquoi est-ce important ? : Fournit la cause profonde des rejets de demandes, ce qui est indispensable pour identifier les domaines à améliorer dans le processus d'intégration afin de réduire le taux de rejet. Source des données : Ceci serait enregistré lorsque l'événement 'Demande rejetée' se produit, probablement comme un champ dans le dossier ou l'enregistrement de la demande. Exemples Correspondance PEPCorrespondance liste de sanctionsVérification de document échouéeMédias défavorables
	Pays du client CustomerCountry	Le pays de résidence ou d'incorporation du client.
Descriptionn Cet attribut indique la localisation géographique du client. Le pays est un facteur significatif dans l'évaluation des risques et les exigences réglementaires pour les processus KYC. Différentes juridictions ont des règles différentes, ce qui peut affecter 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 points de blocage spécifiques à un lieu et d'assurer la conformité aux réglementations locales. Elle apporte une dimension géographique à l'analyse du processus, ce qui peut révéler d'importantes différences opérationnelles. Pourquoi est-ce important ? : Permet l'analyse géographique du processus, aidant à identifier les variations régionales en matière de performance, de risque et d'exigences de conformité. Source des données : Il s'agit d'un champ standard sur le profil client ou le formulaire de demande. Exemples États-UnisGBRSGPDEU
	SLA Non Respecté SlaBreached	Un indicateur booléen indiquant si le dossier d'intégration a été terminé après sa Date Cible de SLA.
Descriptionn Cet attribut est un indicateur calculé qui indique si un dossier a enfreint son accord de niveau de service. Il est déterminé en comparant l'horodatage de l'activité d'achèvement finale (par exemple, 'Demande approuvée' ou 'Demande rejetée') avec la 'DateCibleSla' pour le dossier. Cet indicateur est la base du tableau de bord 'Analyse du respect et des écarts de SLA' et du KPI 'Taux d'adhérence aux SLA'. Il simplifie l'analyse en permettant aux utilisateurs de filtrer rapidement tous les dossiers en infraction. En analysant les caractéristiques des processus des dossiers en infraction, les organisations peuvent identifier les causes profondes des retards et concentrer efficacement leurs efforts d'amélioration. Pourquoi est-ce important ? : Mesure directement la conformité aux accords de niveau de service, permettant un filtrage facile et une analyse des causes profondes des dossiers retardés. Source des données : Ceci 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 truefaux
	Système source SourceSystem	Le système à partir duquel les données d'événements ont été extraites, dans ce cas, Refinitiv World-Check.
Descriptionn Cet attribut identifie l'origine des données du processus. Bien qu'il puisse être une valeur constante dans une extraction à source unique, il devient crucial lorsque des données provenant de plusieurs systèmes (comme un CRM et World-Check) sont combinées pour créer une vue d'ensemble complète du processus. En analyse, cela aide à la gouvernance des données, au dépannage et à la compréhension du contexte des données. Par exemple, les activités enregistrées dans un système de filtrage central peuvent avoir des propriétés ou des niveaux de détail différents de ceux d'un système périphérique. Cela garantit que la traçabilité des données est claire et auditable. Pourquoi est-ce important ? : Identifie l'origine des données, ce qui est impératif pour la gouvernance des données, la validation et la fusion de données provenant de sources multiples. Source des données : Il s'agit souvent d'une valeur statique ajoutée pendant le processus d'extraction, de transformation et de chargement des données (ETL) pour étiqueter l'ensemble de données. Exemples Refinitiv World-CheckWorldCheckOne
	Type de client CustomerType	La classification du client, telle que Particulier, Société ou Fiducie.
Descriptionn Le Type de client catégorise l'entité en cours d'intégration. Différents types de clients ont souvent des exigences d'intégration, des profils de risque et des obligations réglementaires différents. Par exemple, l'intégration d'une entreprise est généralement plus complexe que celle d'un individu. Cet attribut est utilisé pour l'analyse de segmentation, en particulier pour le tableau de bord 'Performance par type de client KYC'. Il permet de comparer l'efficacité des processus, les temps de cycle et les taux de rejet à travers différents segments de clientèle. Cela aide les organisations à adapter et optimiser l'expérience d'intégration pour des types de clients spécifiques. Pourquoi est-ce important ? : Permet la comparaison des performances entre différents segments de clientèle, aidant à adapter et optimiser le processus d'intégration pour chaque type. Source des données : Il s'agit d'un attribut clé stocké dans le dossier client ou de demande au sein du système source. Exemples ParticulierEntrepriseOrganisation à but non lucratifFiducie

Obligatoire Recommandé Facultatif

Activités d'intégration client KYC

Voici les étapes de processus et les jalons clés à capturer dans votre `journal d'événements` pour une `découverte de processus` précise.

8 Recommandé 6 Facultatif

	Activité	Descriptionn
	Compte Activé	Le compte du client est créé et activé dans le système central, complétant le parcours d'intégration. Cela fait suite à l'approbation finale de la demande et rend le compte prêt à l'emploi.
Pourquoi est-ce important ? : Il s'agit de l'étape finale du processus, qui apporte de la valeur. La durée entre la soumission de la demande et l'activation du compte est une métrique clé pour l'efficacité opérationnelle et la satisfaction client. Source des données : Cet événement n'est pas capturé dans World-Check. Il est enregistré dans le système bancaire central ou de compte client et doit être corrélé par l'ID de demande client. Capture Événement enregistré dans le système de compte central lors de l'activation du compte. Type d'événement explicit
	Correspondance avérée confirmée	Un analyste confirme qu'une correspondance potentielle est bien le client en cours de screening, identifiant un risque potentiel. C'est une étape critique qui déclenche généralement une diligence raisonnable supplémentaire ou un rejet de la demande.
Pourquoi est-ce important ? : Il s'agit d'un résultat clé de mitigation des risques et d'un moment charnière dans le processus. Il influence directement la décision finale concernant la demande client et est impératif pour les rapports et analyses de conformité. Source des données : Il s'agit d'une action utilisateur explicite où l'analyste classe une correspondance spécifique comme 'Vraie correspondance' ou 'Correspondance confirmée'. Cet événement est enregistré dans la piste d'audit du dossier. Capture Comptabilisé lorsqu'un analyste confirme formellement une correspondance dans le système. Type d'événement explicit
	Demande de filtrage créée	Un nouveau dossier de screening est formellement créé pour une demande client au sein du système Refinitiv World-Check. Cela est déclenché par un appel API ou une saisie manuelle à partir d'un système en amont et représente le début du contrôle de renseignement sur les risques.
Pourquoi est-ce important ? : Cela marque le début officiel du sous-processus de filtrage. Le temps entre la soumission de la demande et cette activité révèle les retards de transfert entre le système métier et la fonction de conformité. Source des données : Comptabilisé 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'ID d'entité spécifique seraient utilisés. Capture Comptabilisé automatiquement lorsqu'un nouveau dossier de filtrage est créé dans le système. Type d'événement explicit
	Demande Rejetée	La demande client est formellement rejetée, souvent à la suite d'une 'Correspondance trouvée' dans World-Check ou d'autres facteurs de risque. Cet événement est le résultat négatif final du processus d'intégration.
Pourquoi est-ce important ? : Il s'agit du principal point d'échec du processus. L'analyse des événements de rejet, en particulier les raisons et les activités précédentes, est indispensablele pour l'amélioration des processus et la réduction des rejets inutiles. Source des données : Cette décision commerciale finale est enregistrée dans le CRM en amont ou le système d'application central, et non dans World-Check lui-même. Les données doivent être récupérées de ce système. Capture Événement enregistré dans le système d'application source, souvent avec un code de motif de rejet correspondant. Type d'événement explicit
	Demande soumise	Cette activité marque l'initiation du processus d'intégration KYC lorsqu'un client soumet sa demande. Cet événement est généralement capturé dans un système CRM ou une application centrale, ce qui déclenche ensuite le processus de filtrage dans Refinitiv World-Check.
Pourquoi est-ce important ? : Il s'agit de l'événement de début principal pour le parcours d'intégration client complet. L'analyse du temps écoulé entre ce point et l'achèvement fournit le temps de cycle global d'intégration, ce qui est indispensable pour mesurer l'expérience client et l'adhérence aux SLA. Source des données : Cet événement n'est pas natif de World-Check. Il doit être récupéré d'un système en amont, comme un CRM ou une plateforme de gestion de comptes clients, et corrélé par l'ID de demande client. Capture Événement enregistré dans le système d'application source lors de la soumission initiale. Type d'événement explicit
	Examen par l'analyste initié	Un analyste de conformité commence l'examen manuel des correspondances potentielles pour une demande client. Cela implique d'évaluer les détails des correspondances potentielles par rapport aux informations du client pour en déterminer la pertinence.
Pourquoi est-ce important ? : Cela marque le début de l'examen manuel de conformité, un goulot d'étranglement courant. Mesurer le temps entre 'Correspondance potentielle identifiée' et cette activité révèle les retards de file d'attente, tandis que la durée de l'examen indique l'efficacité de l'analyste. Source des données : Cela peut être déduit lorsqu'un analyste 'revendique' ou ouvre un dossier de la file d'attente de révision. Le système peut enregistrer cet événement explicitement dans une piste d'audit lorsque le statut du dossier passe à 'En révision' ou est attribué à un utilisateur spécifique. Capture Déduit d'un changement de statut de dossier à 'En revue' ou de l'affectation du dossier à un analyste. Type d'événement inferred
	Filtrage terminé - Clair	Le dossier de filtrage est officiellement clos avec un résultat 'Clair', signifiant qu'aucune correspondance réelle n'a été trouvée. Cette décision est communiquée au système d'origine, permettant au processus d'intégration de se poursuivre.
Pourquoi est-ce important ? : Cette activité représente l'achèvement réussi et le 'chemin heureux' du processus de filtrage. Elle sert de point final clé pour mesurer le temps de cycle des demandes standard et à faible risque. Source des données : Déduit du changement de statut final du dossier à 'Clair', 'Complet' ou 'Fermé - Aucune correspondance'. L'horodatage de ce changement de statut final est utilisé. Capture Dérivé de l'horodatage du statut final du dossier indiquant un résultat clair. Type d'événement inferred
	Filtrage terminé - Correspondance trouvée	Le dossier de filtrage est officiellement clos avec un résultat 'Correspondance trouvée', indiquant qu'un risque confirmé a été identifié. Cette décision déclenche un processus en aval différent, tel qu'une diligence raisonnable renforcée ou un rejet.
Pourquoi est-ce important ? : Il s'agit du point d'arrivée principal du 'chemin malheureux' pour le processus de filtrage. L'analyse de ces cas aide à comprendre les profils de risque et l'efficacité des contrôles de filtrage. Source des données : Déduit du changement de statut final du dossier à 'Correspondance trouvée', 'Risque identifié' ou 'Fermé - Positif'. L'horodatage de ce changement de statut final est utilisé. Capture Dérivé de l'horodatage du statut final du dossier indiquant une correspondance confirmée. Type d'événement inferred
	Cas Escaladé pour Examen	Un analyste de premier niveau escalade un dossier complexe ou à haut risque vers un analyste senior ou un responsable pour une décision finale. C'est un point de transfert clé dans l'équipe de conformité.
Pourquoi est-ce important ? : Les escalades créent souvent des points de blocage et augmentent le temps de cycle. L'analyse de la fréquence et des raisons des escalades peut mettre en évidence les besoins en formation pour les analystes juniors ou l'ambiguïté des politiques d'examen. Source des données : Comptabilisé comme une action explicite dans le workflow du dossier ou la piste d'audit. Cela pourrait également être déduit d'un changement d'utilisateur affecté au dossier, en particulier à un utilisateur avec des autorisations plus élevées. Capture Comptabilisé via un bouton 'Escalader' dédié ou une action de workflow au sein du dossier. Type d'événement explicit
	Correspondance potentielle identifiée	Le processus de filtrage automatisé a trouvé 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 est-ce important ? : Cette activité est un point de ramification critique dans le processus. Les dossiers avec des correspondances potentielles suivent un chemin plus long et plus complexe, et le suivi de cela aide à la planification des ressources et à l'analyse des points de blocage pour l'équipe de révision. Source des données : Déduit d'un changement de statut de dossier à 'Vérification requise', 'Correspondance potentielle' ou un état similaire au sein du module de gestion des dossiers World-Check. Capture Dérivé d'un changement de statut de 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 suite à un filtrage KYC réussi et à toutes les autres vérifications requises. Cet événement se produit généralement dans le système source après avoir reçu un résultat 'Clair' de World-Check.
Pourquoi est-ce important ? : Cela marque le résultat commercial réussi du processus d'intégration. Suivre le temps jusqu'à ce point depuis la soumission révèle le 'temps total d'approbation' pour un nouveau client. Source des données : Cet événement n'est pas natif de World-Check. Il doit être récupéré du CRM en amont ou du système d'application central, qui prend la décision commerciale finale. Capture Événement enregistré dans le système d'application source lors de l'approbation finale. Type d'événement explicit
	Faux positif confirmé	L'analyste conclut qu'une correspondance potentielle n'est pas la même que le client étant filtré. La correspondance est rejetée, et le processus de filtrage pour cette alerte spécifique est résolu.
Pourquoi est-ce important ? : Cela représente un résultat courant du processus de révision. Comprendre le temps qu'il faut pour traiter les faux positifs aide à mesurer l'efficacité de l'analyste et la précision de la logique de filtrage automatisé. Source des données : Il s'agit d'une action utilisateur explicite où l'analyste classe une correspondance spécifique comme 'Faux positif' ou 'Pas une correspondance'. Cette action est généralement enregistrée dans l'historique du dossier. Capture Comptabilisé lorsqu'un analyste rejette formellement 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é commerciale. Cela place le dossier en état d'attente jusqu'à ce que les informations soient fournies.
Pourquoi est-ce important ? : Les occurrences fréquentes de cette activité indiquent des problèmes de qualité des données initiales fournies pour le screening. Cette activité introduit des retards importants, car elle dépend d'équipes externes, et est un facteur clé de l'allongement des temps de cycle. Source des données : Il peut s'agir d'une action utilisateur explicite enregistrée dans les notes du dossier ou le journal d'audit. Alternativement, cela pourrait être déduit d'un changement de statut du dossier à 'Informations en attente' ou 'Demande d'informations' (RFI). Capture Comptabilisé lorsqu'un analyste utilise une fonctionnalité pour signaler que le dossier nécessite plus d'informations. Type d'événement explicit
	Screening automatisé effectué	Le système World-Check filtre automatiquement les détails du client par rapport à sa base de données d'intelligence des risques. Il s'agit d'une activité pilotée par le système qui produit un ensemble initial de résultats, tels que des correspondances potentielles ou un statut clair.
Pourquoi est-ce important ? : Cette activité est la première étape à valeur ajoutée du processus de filtrage. Les retards avant ce point indiquent des problèmes de système ou de prélèvement.paration des données, tandis que le résultat détermine la charge de travail manuelle subséquente. Source des données : Cet événement peut être enregistré explicitement dans la piste d'audit du dossier ou déduit de l'horodatage lorsque les résultats de filtrage initiaux deviennent disponibles pour le dossier. Capture Entrée de journal système génériqueée à l'achèvement de l'analyse automatisée de la base de données. Type d'événement explicit

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de Refinitiv World-Check

Étapes

Connectez-vous à World-Check One: Accédez au portail Refinitiv World-Check One en utilisant vos identifiants.
Naviguez vers la Gestion des dossiers: Ouvrez la section Gestion des dossiers où tous les dossiers de screening sont stockés et gérés.
Préparez l'exportation du rapport de dossier: Allez à la fonction de rapport ou d'exportation dans la Gestion des dossiers. Celle-ci peut être étiquetée comme 'Exporter les dossiers' ou 'Rapport de dossier'.
Configurez le rapport de dossier: Sélectionnez les colonnes à inclure dans l'exportation. Assurez-vous de sélectionner les champs correspondant à l'ID du dossier (CustomerApplication), la date de création, la date de résolution, le statut du dossier (par exemple, Clair, Correspondance trouvée) et le niveau de risque.
Exportez les données de gestion des dossiers: Définissez votre période, couvrant 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 sous forme de fichier CSV et nommez-le case_report.csv.
Préparez l'exportation de la piste d'audit: Naviguez vers la section de rapport de la piste d'audit ou du journal d'audit de World-Check One. Celle-ci contient les historiques d'événements détaillés pour chaque cas.
Configurez et exportez la piste d'audit: Sélectionnez toutes les colonnes pertinentes, y compris l'ID du dossier, le nom ou la description de l'événement, l'horodatage de l'événement et l'utilisateur qui a effectué l'action. Exportez ces données pour la même période que le rapport de dossier. Enregistrez le fichier sous le nom audit_trail.csv.
Sourcez les étapes de processus externes: Obtenez les données pour les activités qui se déroulent en dehors de World-Check, telles que Demande soumise, Demande approuvée, Compte activé et Demande rejetée. Ces données proviennent généralement d'un CRM ou d'un système bancaire central. Exportez ces données avec l'ID 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 du système externe) dans un outil ou un script de prélèvement.paration des données.
Mappez les événements d'audit aux activités: Traitez le fichier audit_trail.csv. Mappez les descriptions d'événements brutes du journal d'audit aux valeurs (ActivityName) standardisées. Par exemple, une entrée de journal d'audit comme 'Dossier assigné à l'analyste' devient 'Examen de l'analyste démarré'.
Mappez les changements de statut du dossier aux activités: Traitez le fichier case_report.csv pour générer des activités basées sur les changements de statut. Utilisez la date de résolution du dossier et le statut final pour créer les événements 'Screening terminé - Clair' ou 'Screening terminé - Correspondance trouvée'.
Créez le journal d'événements final: Unissez toutes les données traitées des différents fichiers source dans un seul fichier CSV. Assurez-vous que le fichier final contient les colonnes requises : CustomerApplication, (ActivityName) et (EventTime), ainsi que tout attribut recommandé. Enregistrez ce fichier pour le téléversement vers l'outil de Process Mining.

Configuration

Types de rapports: Vous devrez générer au moins deux rapports distincts : un rapport de synthèse de la gestion des dossiers et un rapport détaillé de la piste d'audit.
Période: Pour une analyse initiale, sélectionnez une période d'au moins 3 à 6 mois afin de saisir suffisamment de dossiers terminés et en cours. Assurez-vous que la période est cohérente sur tous les fichiers exportés.
Format d'exportation: Choisissez CSV (Comma Separated Values) comme format d'exportation pour un traitement facile.
Colonnes clés (rapport de dossier): Assurez-vous que l'exportation de votre dossier inclut l'ID du dossier, l'horodatage de création, l'horodatage de résolution, le statut final, l'analyste assigné et le niveau de risque.
Colonnes clés (rapport de piste d'audit): Assurez-vous que l'exportation de votre journal d'audit inclut l'ID du dossier, la description de l'événement, l'horodatage de l'événement et l'ID utilisateur.
Prérequis: L'accès au portail World-Check One avec des autorisations utilisateur permettant de consulter et d'exporter les données de gestion des dossiers et de la piste d'audit est requis. Cela peut nécessiter des privilèges élevés au-delà d'un rôle d'analyste standard.

a Exemple de requête config

/*
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: Assurez-vous d'avoir Python 3.6+ installé ainsi que les bibliothèques requests et pandas. Obtenez votre clé API et votre secret API World-Check One auprès de votre représentant Refinitiv ou du portail développeur. Stockez ces identifiants en toute sécurité.
Développez la logique d'authentification: Dans votre script Python, créez une fonction pour envoyer une requête POST au point d'accès d'authentification World-Check One. Utilisez votre clé API et votre secret pour obtenir un jeton bearer temporaire requis pour les appels API ultérieurs.
Identifiez les données du système source: Le processus commence et se termine en dehors de World-Check. Identifiez le système source, tel qu'un CRM ou une plateforme bancaire centrale, qui stocke les données initiales des demandes. Vous devrez extraire de cette source des événements comme Demande soumise, Demande approuvée, Compte activé et Demande rejetée. Cela peut être fait via une requête de base de données ou une autre API.
Récupérez les dossiers World-Check: En utilisant le jeton authentifié, faites une requête GET au point d'accès /cases de l'API World-Check One. Utilisez des paramètres de requête pour filtrer les dossiers par une période spécifique, par exemple, en fonction de leur date de création ou de modification.
Gérer la pagination de l'API: Les réponses de l'API World-Check sont paginées. Votre script doit vérifier la réponse pour les détails de pagination et parcourir toutes les pages pour récupérer la liste complète des dossiers pour votre période spécifiée.
Récupérez les détails et l'historique des dossiers: Pour chaque ID de dossier récupéré, faites des requêtes GET ultérieures aux points d'accès comme /cases/{case_system_id} et /cases/{case_system_id}/audit-trail. Ces points d'accès fournissent les changements de statut détaillés, les détails de résolution et les actions utilisateur associés au dossier.
Mappez les données brutes aux activités: Il s'agit d'une étape de transformation critique. Écrivez une logique pour itérer à travers les données de réponse de l'API (détails du dossier, piste d'audit) pour chaque cas. Mappez les changements de statut spécifiques, les codes de résultat et les événements d'audit aux activités commerciales requises. Par exemple, un événement de création de dossier devient Demande de screening créée, et une résolution de résultat de Faux positif devient Faux positif confirmé.
Combinez les sources de données: Fusionnez les données extraites de World-Check avec les données de votre système source (de l'étape 3). Utilisez l'ID CustomerApplication comme clé commune pour créer un journal d'événements complet complet pour chaque client.
Structurez et enrichissez les données: Assemblez tous les événements associés dans une seule liste d'enregistrements. Pour chaque enregistrement, assurez-vous que tous les attributs requis (CustomerApplication, (ActivityName), (EventTime)) et les attributs recommandés sont renseignés. Calculez (EventEndTime) si possible, peut-être en utilisant l'horodatage de l'événement suivant pour ce dossier.
Exportez au format CSV: Convertissez la liste finale des enregistrements d'événements en un DataFrame pandas. Réorganisez les colonnes pour correspondre au format requis et exportez le DataFrame vers un fichier CSV. Assurez-vous que le fichier est enregistré avec un encodage UTF-8 pour être compatible avec ProcessMind.

Configuration

Identifiants API: Une clé API et un secret API valides pour l'API de screening World-Check One sont requis. Ceux-ci doivent être configurés avec les autorisations nécessaires pour lire les données des dossiers et d'audit.
URL de base de l'API: Le script doit être configuré avec l'URL de base correcte pour votre environnement API 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 pour contrôler la période d'extraction. Pour une analyse initiale, une période de 3 à 6 mois est recommandée. Pour une surveillance continue, exécutez le script de manière incrémentale pour des périodes plus courtes, comme le jour ou la semaine précédente.
Connexion au système source: Les détails de connexion pour les systèmes en amont et en aval (par exemple, CRM, plateforme bancaire centrale) sont nécessaires pour récupérer les événements hors screening. Cela pourrait être une chaîne de connexion à une base de données ou un autre point d'accès API et des identifiants.
Gestion de la pagination: Le script doit spécifier une taille de page, souvent appelée limit, lors des appels API pour lister les dossiers. Une valeur entre 50 et 100 est généralement efficace. La logique doit gérer correctement la récupération de 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()

Votre modèle de données d'intégration client KYC

Votre modèle de données d'intégration client KYC

Attributs d'intégration client KYC

Activités d'intégration client KYC

Guides d'extraction

Exportation des journaux de dossiers et d'audit Refinitiv World-Check One

Étapes

Configuration

a Exemple de requête config

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

Étapes

Configuration

a Exemple de requête python

Prêt(e) à démarrer ?

Optimisez l'intégration client KYC dès maintenant, renforcez la conformité

Votre modèle de données d'intégration client KYC

Votre modèle de données d'intégration client KYC

Attributs d'intégration client KYC

Activités d'intégration client KYC

Guides d'extraction

Exportation des journaux de dossiers et d'audit Refinitiv World-Check One

Étapes

Configuration

a Exemple de requête config

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

Étapes

Configuration

a Exemple de requête python

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Optimisez l'intégration client KYC dès maintenant, renforcez la conformité