> Amélioration continue des processus > Intégration des clients KYC > LexisNexis Risk Solutions > Modèle de données

Votre template de données pour l'intégration client KYC

LexisNexis Risk Solutions

Attributs de l’intégration des clients KYC (20) Activités d’intégration des clients KYC (14) Guides d'extraction (1)

Votre template de données pour l'intégration client KYC

Ce template fournit un guide complet pour recueillir les données nécessaires à l'analyse de votre processus d'intégration client KYC. Il présente les attributs essentiels à collecter, les principales activités à suivre et des indications pour extraire ces informations de vos systèmes sources. Utilisez cette ressource pour constituer un journal d'événements fiable et obtenir des analyses détaillées de votre parcours d'intégration.

Attributs recommandés à collecter
Activités clés à 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 et découvrir le processus d’intégration des clients KYC.

3 Obligatoire 6 Recommandé 11 Facultatif

	Nom	Description
	Demande client CustomerApplication	L’identifiant unique de chaque demande d’intégration client, qui sert d’identifiant principal du dossier.
Description La demande client est l’identifiant central qui relie toutes les activités et tous les points de données associés au parcours d’intégration d’un même client. Elle commence lorsqu’une demande est envoyée et suit le dossier jusqu’à son achèvement ou son rejet. Dans le Process Mining, cet Attribut est essentiel pour regrouper tous les événements au sein d’un dossier cohérent et permettre une analyse de bout en bout du cycle de vie de l’intégration. Il permet de reconstituer l’intégralité du flux du processus pour chaque candidat, ce qui est fondamental pour calculer les délais de cycle, analyser les variantes du processus et suivre l’évolution du statut d’une demande. Pourquoi c’est important Il s’agit de l’identifiant Case ID fondamental. Sans lui, vous ne pouvez pas suivre le parcours de bout en bout d’une demande client, ce qui rend l’analyse du processus impossible. Où les obtenir Il s’agit de l’identifiant principal du dossier dans le module de gestion des dossiers de LexisNexis Risk Solutions. Exemples APP-2023-001234APP-2023-005678APP-2024-009101
	Horodatage de l’événement EventTimestamp	La date et l’heure précises auxquelles une activité donnée a commencé.
Description Cet horodatage marque le début d’une activité et établit l’ordre chronologique de tous les événements d’un dossier. Il constitue la base de toutes les analyses temporelles en Process Mining. À partir de l’Event Timestamp, vous pouvez calculer la durée des activités, le temps d’attente entre celles-ci et le délai total de bout en bout du processus d’intégration. Ces données sont essentielles pour repérer les goulots d’étranglement, suivre le respect des SLA et comprendre l’efficacité du processus. Pourquoi c’est important Cet horodatage est essentiel pour classer les événements par ordre chronologique et calculer toutes les métriques temporelles, notamment les délais de traitement et les goulots d’étranglement. Où les obtenir Il se trouve dans les tables de l’Event Log ou de la piste d’audit, à côté de l’Activity Name. Exemples 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:15:00Z
	Nom de l’activité ActivityName	Nom de la tâche ou de l’événement précis qui s’est produit à un moment donné au cours du processus d’intégration.
Description Le nom de l’activité décrit une étape du flux de travail d’intégration KYC, comme « Application Submitted », « Document Review Performed » ou « Application Approved ». Chaque activité représente une action ou un jalon distinct du processus. Cet attribut est essentiel pour construire la cartographie du processus, qui représente visuellement le déroulement des activités. Il permet d’analyser les variantes du processus, les goulots d’étranglement entre certaines étapes et la fréquence des boucles de reprise. L’analyse des activités est indispensable pour comprendre ce qui se passe réellement dans le processus. Pourquoi c’est important Cet attribut constitue la structure de base de la cartographie du processus et vous permet de visualiser et d’analyser la séquence des événements du parcours d’intégration client. Où les obtenir Il se trouve généralement dans un Event Log ou une table de piste d’audit de LexisNexis Risk Solutions qui suit les étapes du processus. Exemples Demande envoyéeContrôle initial effectuéDocuments demandésExamen de conformité terminé
	Date cible du SLA SlaTargetDate	La date à laquelle le processus d’intégration client doit être terminé.
Description La SLA Target Date définit l’engagement de niveau de service associé au traitement d’une demande. Cette date est souvent déterminée en fonction de facteurs tels que le type de demande, le segment client ou la juridiction. Cet attribut est essentiel au Dashboard « SLA Target Adherence Monitoring » et au KPI « SLA Adherence Rate ». En comparant la date réelle d’achèvement à la SLA Target Date, les organisations peuvent mesurer leur performance par rapport à leurs engagements, repérer les dossiers susceptibles de dépasser les SLA et rechercher les causes profondes des retards. Pourquoi c’est important Il permet de mesurer les performances par rapport aux engagements de niveau de service et met en évidence les inefficacités à l’origine des dépassements de SLA. Où les obtenir Consultez la documentation de LexisNexis Risk Solutions ou l’administrateur système. Cette valeur peut être stockée dans le dossier ou calculée à partir de règles métier. Exemples 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-12-01T17:00:00Z
	Heure de fin EndTime	La date et l’heure précises auxquelles une activité a été terminée.
Description Cet horodatage marque la fin d’une activité. La différence entre l’End Time et le Start Time d’un événement correspond à son temps de traitement. L’End Time est essentiel pour calculer précisément la durée de chaque étape. Il constitue une donnée d’entrée principale du Dashboard « Activity Processing & Waiting Times ». Il permet de distinguer le temps pendant lequel une Ressource a travaillé activement sur une tâche du temps pendant lequel le dossier a attendu le début de l’étape suivante. Pourquoi c’est important Il permet de calculer précisément le temps de traitement des activités, ce qui est essentiel pour repérer les étapes inefficaces et analyser la charge de travail des Ressources. Où les obtenir Consultez la documentation de LexisNexis Risk Solutions ou l’administrateur système. Cette information est souvent disponible dans les journaux d’événements qui enregistrent les événements de début et de fin. Exemples 2023-10-26T10:45:10Z2023-10-26T11:55:30Z2023-10-28T09:05:00Z
	Niveau de risque RiskLevel	Le niveau de risque calculé pour la demande client, par exemple faible, moyen ou élevé.
Description LexisNexis Risk Solutions est spécialisé dans l’évaluation des risques. Cet attribut représente le résultat de cette évaluation et classe chaque demande selon son profil de risque potentiel. Le niveau de risque détermine souvent l’intensité et la durée requises pour le processus de due diligence. Cet attribut constitue la dimension centrale du Dashboard « Risk Level vs. Onboarding Duration ». L’analyse du processus par niveau de risque permet de vérifier si les demandes à haut risque prennent nettement plus de temps, comme prévu, ou si les demandes à faible risque subissent des retards injustifiés. Elle aide à valider et à affiner les stratégies d’intégration fondées sur le risque. Pourquoi c’est important Il est essentiel à l’analyse fondée sur le risque et permet de comprendre comment les profils de risque client influencent la complexité, la durée et le parcours du processus. Où les obtenir Consultez la documentation de LexisNexis Risk Solutions ou l’administrateur système. Il s’agit d’un résultat central des modules d’évaluation des risques. Exemples FaibleMoyenÉlevéFaisant l'objet de sanctions
	Service Department	Le service ou l’équipe métier auquel appartient l’utilisateur affecté.
Description L’attribut Department indique le groupe fonctionnel responsable d’une activité, par exemple « Compliance », « Onboarding Operations » ou « Fraud Prevention ». Cet attribut permet d’analyser le processus du point de vue des services et d’étudier les transferts entre différentes équipes. Il constitue une dimension principale du Dashboard « Resource Allocation and Workload » et aide à repérer les inefficacités interfonctionnelles ou les retards de communication entre services. Pourquoi c’est important Il permet d’analyser les transferts et les performances par domaine fonctionnel, afin de repérer les goulots d’étranglement entre services. Où les obtenir Consultez la documentation de LexisNexis Risk Solutions ou l’administrateur système. Cette information peut nécessiter une jointure avec une table de référence des utilisateurs ou des données RH. Exemples ComplianceÉquipe d'intégrationAnalystes KYCAssistance client
	Statut de la demande ApplicationStatus	Le statut actuel ou final de la demande client.
Description Cet attribut reflète le statut global du dossier à un moment donné ou son résultat final. Les statuts courants incluent « In Progress », « Approved », « Rejected » et « Pending Information ». L’Application Status est essentiel pour suivre les résultats du processus d’intégration. Il est utilisé dans les Dashboards « Application Rejection Reasons & Stages » et « Daily Throughput and Application Status » afin de suivre les taux de réussite et le déroulement opérationnel. L’analyse de l’évolution du statut dans le temps permet de mieux comprendre le cycle de vie du dossier. Pourquoi c’est important Il suit le résultat de chaque demande, ce qui est essentiel pour calculer des KPI importants comme le taux de rejet des demandes et suivre le débit de traitement. Où les obtenir Consultez la documentation de LexisNexis Risk Solutions ou l’administrateur système. Il s’agit généralement d’un champ clé de l’objet principal du dossier ou de la demande. Exemples En coursApprouvéRejetéInformations client en attente
	Utilisateur affecté AssignedUser	L’identifiant unique de l’utilisateur ou de l’agent chargé d’exécuter l’activité.
Description Cet attribut identifie la personne qui a exécuté une tâche, par exemple un responsable de la conformité chargé d’examiner un document. Il permet d’analyser la répartition de la charge de travail et les performances individuelles. Dans l’analyse, l’Assigned User est essentiel au Dashboard « Resource Allocation and Workload ». Il permet de filtrer la cartographie du processus par utilisateur, de comparer les performances des membres de l’équipe et de repérer les besoins de formation ou de rééquilibrage de la charge. Il peut également aider à localiser les goulots d’étranglement causés par certains groupes d’utilisateurs. Pourquoi c’est important Cet attribut est essentiel pour analyser les performances des Ressources, la répartition de la charge de travail et les possibilités d’automatisation ou d’optimisation des Ressources. Où les obtenir Consultez la documentation de LexisNexis Risk Solutions ou l’administrateur système. Cette information se trouve généralement dans les pistes d’audit ou les tables de gestion des tâches. Exemples j.doem.smithk.chen
	Canal Channel	Le canal par lequel la demande a été soumise, par exemple « Web », « Mobile » ou « In-Branch ».
Description L’attribut Channel identifie la source de soumission de la demande. Le canal peut influencer la qualité des données, le comportement des clients et les types de problèmes rencontrés pendant l’intégration. Cet attribut permet de comparer les performances du processus entre différents canaux. Par exemple, le Dashboard « Onboarding Funnel Conversion Rates » peut être filtré par canal afin de vérifier si les utilisateurs mobiles abandonnent davantage leur parcours que les utilisateurs Web et d’orienter les améliorations propres à chaque canal. Pourquoi c’est important Il aide à analyser les performances du processus selon le canal de soumission et à repérer les variations utiles à la stratégie de canal et à l’amélioration de l’expérience utilisateur. Où les obtenir Consultez la documentation de LexisNexis Risk Solutions ou l’administrateur système. Cette information est généralement recueillie au début du processus de demande. Exemples Portail webApplication mobileEn agenceAPI
	Délai de traitement CycleTime	La durée totale de bout en bout d’une demande client, de sa soumission à la décision finale.
Description Le Cycle Time mesure le temps total écoulé entre le tout premier événement, par exemple « Application Submitted », et le tout dernier événement, comme « Customer Onboarding Completed » ou « Application Rejected », pour un même dossier. Il s’agit d’un KPI principal pour évaluer la santé globale du processus. Il est visualisé dans le Dashboard « Onboarding End-to-End Cycle Time ». Le suivi du délai moyen permet aux organisations de mesurer l’effet des améliorations du processus et de comprendre comment différents facteurs, tels que le niveau de risque ou le type de demande, influencent l’expérience client globale. Pourquoi c’est important Il s’agit d’un indicateur clé de performance qui mesure le délai total avant création de valeur pour le client et qui influence directement sa satisfaction ainsi que l’efficacité opérationnelle. Où les obtenir Il s’agit d’une métrique calculée en soustrayant l’horodatage du premier événement de celui du dernier événement pour chaque dossier. Exemples 5 jours 4 heures22 jours 8 heures1 jour 2 heures
	Dernière mise à jour des données LastDataUpdate	L’horodatage indiquant la dernière actualisation ou extraction des données depuis le système source.
Description Cet attribut indique à quel moment le jeu de données a été mis à jour pour la dernière fois. Il est généralement appliqué à l’ensemble du jeu de données lors de l’extraction et du chargement des données. Ces informations sont essentielles pour permettre aux utilisateurs des Dashboards d’évaluer l’actualité des données analysées. Elles garantissent que les décisions reposent sur des données aussi récentes que nécessaire et permettent de gérer les attentes concernant leur délai de mise à disposition. Pourquoi c’est important Il fournit un contexte important sur l’actualité des données, afin que les analyses restent pertinentes et que les décisions ne reposent pas sur des informations obsolètes. Où les obtenir Cette valeur est généralement générée et apposée au jeu de données lors du processus ETL (Extract, Transform, Load). Exemples 2024-01-15T02:00:00Z2024-01-16T02:00:00Z2024-01-17T02:00:00Z
	Est automatisé IsAutomated	Un indicateur précisant si une activité a été exécutée automatiquement par le système ou manuellement par un utilisateur.
Description Cet attribut booléen distingue les tâches exécutées par automatisation système, par exemple un contrôle de filtrage initial, de celles qui nécessitent une intervention humaine, comme l’examen manuel d’un document. « Is Automated » sert à calculer le KPI « Manual Activity Proportion » et à analyser l’efficacité des initiatives d’automatisation. Dans la cartographie du processus, il peut mettre en évidence l’interface entre les étapes automatisées et manuelles, afin de repérer les possibilités d’automatisation supplémentaires et de réduire les coûts et les délais de traitement. Pourquoi c’est important Il distingue les tâches manuelles des tâches automatisées, ce qui est essentiel pour repérer les possibilités d’automatisation et mesurer leur impact. Où les obtenir Consultez la documentation de LexisNexis Risk Solutions ou l’administrateur système. Il peut s’agir d’un indicateur présent dans l’Event Log ou d’une valeur déduite de l’« AssignedUser », par exemple lorsqu’un utilisateur est identifié comme « system ». Exemples truefalse
	Est une reprise IsRework	Un indicateur identifiant les activités qui font partie d’une boucle de reprise.
Description Cet indicateur booléen prend la valeur true lorsqu’une activité est répétée dans un même dossier, par exemple lorsque « Document Review Performed » se produit une deuxième fois après « Additional Information Requested ». Il indique que le processus est revenu à une étape antérieure. « Is Rework » est essentiel au Dashboard « Rework and Repetition Analysis » et au KPI « Rework Loop Percentage ». Il permet de quantifier les efforts inutiles et d’identifier les causes profondes des reprises, comme des consignes peu claires ou une qualité insuffisante des données, afin de cibler les améliorations du processus. Pourquoi c’est important Il quantifie directement les inefficacités et les efforts inutiles du processus, en mettant en évidence les activités fréquemment répétées qui augmentent les coûts et les délais. Où les obtenir Il s’agit d’un attribut calculé, généralement dérivé dans l’outil de Process Mining par détection des séquences d’activités répétées au sein d’un dossier. Exemples truefalse
	Motif du rejet RejectionReason	Un code ou une description expliquant pourquoi une demande a été rejetée.
Description Lorsque le statut final d’une demande est « Rejected », cet attribut en précise le motif. Les exemples incluent « Failed Identity Verification », « Sanctions Match » et « Incomplete Documentation ». Ces données constituent la principale source du Dashboard « Application Rejection Reasons & Stages ». L’analyse des motifs de rejet aide à repérer les causes fréquentes d’échec du processus et peut orienter l’amélioration des consignes de demande, de la communication avec les clients ou des critères de contrôle internes. Comprendre pourquoi les demandes sont rejetées est essentiel pour améliorer le taux d’approbation global. Pourquoi c’est important Il fournit une analyse directe des causes d’échec de l’intégration et permet de cibler les améliorations destinées à augmenter le taux d’approbation des demandes. Où les obtenir Consultez la documentation de LexisNexis Risk Solutions ou l’administrateur système. Cette information se trouve souvent dans un champ renseigné lorsque l’Application Status prend la valeur « Rejected ». Exemples Correspondance avec une liste de sanctionsDocumentation incomplèteÉchec de la vérification d'identitéProfil à risque élevé
	Pays du client CustomerCountry	Le pays de résidence ou d’immatriculation du client.
Description Cet attribut indique le pays du client, un facteur essentiel du KYC en raison des différences de réglementation internationale et des niveaux de risque associés aux différentes juridictions. L’analyse du processus par Customer Country peut révéler des écarts importants dans les délais et la complexité du processus. Par exemple, les demandes provenant de juridictions à haut risque peuvent nécessiter des contrôles de conformité supplémentaires et donc prendre plus de temps. Cette analyse aide à planifier les Ressources et à définir des SLA réalistes pour les différentes régions. Pourquoi c’est important Il permet d’analyser le processus par juridiction, ce qui est essentiel pour comprendre l’impact des réglementations régionales et des facteurs de risque sur les performances. Où les obtenir Consultez la documentation de LexisNexis Risk Solutions ou l’administrateur système. Il s’agit d’un champ standard des données de référence client. Exemples USAGBRDEUSGP
	Responsable du contrôle de conformité ComplianceReviewer	L’utilisateur ou l’agent spécifiquement chargé des activités de contrôle de conformité.
Description Alors que l’« AssignedUser » indique l’utilisateur associé à toute activité, cet attribut identifie précisément le spécialiste de la conformité intervenant lors des étapes de contrôle importantes. Il permet ainsi une analyse ciblée de la fonction conformité. Cet attribut est essentiel au Dashboard « Compliance Review Duration and Backlog ». Il aide à analyser la charge de travail et les performances de l’équipe conformité, et à déterminer si certains contrôleurs constituent des goulots d’étranglement ou si l’équipe manque globalement de Ressources. Pourquoi c’est important Il fournit une analyse ciblée de la fonction conformité et permet d’étudier en détail la charge et les performances des contrôleurs lors de cette étape importante, souvent source de retards. Où les obtenir Consultez la documentation de LexisNexis Risk Solutions ou l’administrateur système. Cette valeur peut être obtenue en filtrant l’« AssignedUser » pour les activités liées à la conformité. Exemples c.joness.patelsystem_escalation
	Statut du SLA SlaStatus	Indique si la demande terminée a respecté son objectif de SLA.
Description Cet attribut classe chaque dossier terminé selon son respect de l’« SlaTargetDate ». Les valeurs courantes sont « Met » et « Breached ». Ce champ calculé constitue la base du Dashboard « SLA Target Adherence Monitoring » et du KPI « SLA Adherence Rate ». Il fournit une vision claire et synthétique des performances par rapport aux engagements de service et permet d’analyser en détail les caractéristiques communes des dossiers qui dépassent leurs SLA. Pourquoi c’est important Il fournit un résultat binaire clair sur la performance par rapport au SLA, ce qui facilite le suivi, le reporting et l’analyse du respect des objectifs de niveau de service. Où les obtenir Il s’agit d’un attribut calculé, obtenu en comparant l’horodatage de la dernière activité à la « SlaTargetDate » de chaque dossier. Exemples RespectéDépasséÀ risque
	Système source SourceSystem	Le système ou l’application à l’origine des données d’événement.
Description Cet attribut identifie le système source qui a généré les données d’événement, par exemple LexisNexis Risk Solutions ou un outil tiers intégré. Dans les environnements complexes, les données d’un même processus peuvent provenir de plusieurs systèmes. La connaissance du système source est utile pour valider les données, résoudre les problèmes et analyser les variations du processus propres à un système donné. Elle contribue à garantir l’intégrité des données et fournit un contexte sur la manière et l’endroit où une activité a été enregistrée. Pourquoi c’est important Il identifie l’origine des données, un élément essentiel pour la gouvernance et la validation des données, ainsi que pour comprendre l’exécution du processus dans différents systèmes informatiques. Où les obtenir Ces informations peuvent être stockées sous forme de valeur statique ou dans un champ spécifique de l’export de données ou de la réponse de l’API. Exemples LexisNexis Risk SolutionsThreatMetrixBridger Insight XG
	Type de demande ApplicationType	Le type de demande client, par exemple « Individual » ou « Business ».
Description Cet attribut classe les demandes selon le type d’entité intégrée. Les différents types de demandes suivent souvent des parcours distincts et présentent des profils de risque et des objectifs de SLA différents. L’analyse du processus par Application Type permet de segmenter les données afin de comparer l’efficacité et la complexité de l’intégration de différents types de clients. Il s’agit d’un filtre couramment utilisé dans la plupart des Dashboards pour obtenir une vision plus détaillée des performances. Pourquoi c’est important Il permet de segmenter finement le processus et de révéler comment les différents types de demandes sont traités, ainsi que les goulots d’étranglement propres à chacun. Où les obtenir Consultez la documentation de LexisNexis Risk Solutions ou l’administrateur système. Il s’agit généralement d’un champ central de l’objet demande ou dossier. Exemples ParticulierEntrepriseParticulier fortunéFiducie

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 et analyser ses performances.

8 Recommandé 6 Facultatif

	Activité	Description
	Demande approuvée	La décision finale d’approuver la demande du client est prise et enregistrée dans le système. Il s’agit d’un résultat métier important, presque toujours enregistré comme une modification explicite du statut.
Pourquoi c’est important Cette étape marque la conclusion réussie du processus de décision. L’analyse des parcours menant à l’approbation permet d’identifier les bonnes pratiques. Où les obtenir Recherchez dans le dossier de la demande une mise à jour finale du statut indiquant « Approuvé » ou un état terminal similaire. Collecte L’événement est enregistré comme une modification finale et définitive du statut dans la table principale des demandes ou des dossiers. Type d’événement explicit
	Demande envoyée	Cet événement marque le début du processus d’intégration KYC, lorsque la demande d’un client est reçue pour la première fois par le système. Il est généralement enregistré explicitement lorsque le formulaire de demande est envoyé depuis un portail client ou un système interne de saisie intégré à LexisNexis.
Pourquoi c’est important Il s’agit de l’événement de départ principal du processus. L’analyse du temps écoulé entre cette activité et l’achèvement du processus est essentielle pour mesurer le délai de cycle de bout en bout et le respect des SLA. Où les obtenir L’événement est extrait des journaux système ou d’une table de demandes qui enregistre l’horodatage initial de création d’une nouvelle demande client. Collecte L’événement est enregistré lors de la création d’un nouveau dossier de demande ou d’une nouvelle entrée dans la table principale des demandes. Type d’événement explicit
	Demande rejetée	La décision finale de rejeter la demande du client est enregistrée. Il s’agit d’un événement terminal, capturé par une modification définitive du statut dans le système.
Pourquoi c’est important Il s’agit de l’événement final principal correspondant à un échec. L’analyse des étapes auxquelles les rejets surviennent et des raisons associées est essentielle à l’amélioration du processus. Où les obtenir L’événement est extrait du champ de statut final de la demande, défini sur « Rejeté », « Refusé » ou un état terminal similaire. Collecte L’événement est enregistré comme une modification finale et définitive du statut dans la table principale des demandes ou des dossiers. Type d’événement explicit
	Documents reçus	Cet événement confirme que le client a téléversé ou fourni les documents requis au système. Il est généralement généré explicitement par le portail de dépôt de documents ou saisi manuellement par un agent.
Pourquoi c’est important Cette activité clôt une période d’attente et déclenche les activités d’examen suivantes. Il s’agit d’une étape importante de la phase de collecte des données. Où les obtenir L’événement est extrait des journaux du système de gestion documentaire ou d’une entrée horodatée dans le dossier de la demande, lors de l’ajout de nouveaux documents. Collecte L’événement est enregistré lorsqu’un document est correctement téléversé ou marqué manuellement comme reçu dans le système. Type d’événement explicit
	Évaluation du risque effectuée	Le système calcule un score de risque pour le client à partir des informations recueillies et des contrôles effectués. Il s’agit d’une fonctionnalité centrale de LexisNexis, généralement enregistrée comme un événement automatisé explicite dans l’historique du dossier.
Pourquoi c’est important Le résultat de cette évaluation détermine souvent la suite du processus, par exemple la nécessité d’une vigilance renforcée. Il s’agit d’un point de décision essentiel du flux de travail. Où les obtenir Recherchez dans le journal d’audit ou l’historique du flux de travail de l’application un événement indiquant que le module de notation ou d’évaluation des risques est terminé. Collecte Un événement spécifique est enregistré lorsque le moteur de risque termine son analyse et attribue un profil ou un score de risque. Type d’événement explicit
	Examen de conformité lancé	Un dossier est attribué à un responsable ou à une équipe de conformité pour un examen manuel, généralement dans le cas des demandes à risque élevé. Cet événement est souvent déduit d’une modification du statut vers « Examen de conformité en attente » ou d’un journal d’affectation de tâche.
Pourquoi c’est important Cette étape marque le début d’un examen manuel, souvent long. Mesurer le temps écoulé jusqu’à son achèvement permet de quantifier les goulots d’étranglement liés à la conformité. Où les obtenir L’événement est extrait d’un journal d’affectation de tâche, d’un changement de propriétaire du dossier vers une équipe de conformité ou d’une mise à jour de l’historique du dossier. Collecte L’événement est déduit d’une modification du statut, comme « Examen de conformité en cours », ou de l’affectation du dossier à une file d’attente d’utilisateurs chargés de la conformité. Type d’événement inferred
	Examen de conformité terminé	Le responsable de la conformité termine son examen et formule une recommandation, faisant passer le dossier à l’étape suivante. L’événement peut être enregistré explicitement lorsqu’une tâche est marquée comme « terminée » ou déduit d’une modification du statut de « Conformité en attente » vers un autre état.
Pourquoi c’est important Cette étape importante clôt une partie essentielle, souvent manuelle, du processus. Elle constitue le point final pour mesurer la durée de l’examen de conformité. Où les obtenir L’événement est extrait de l’horodatage d’achèvement de la tâche de conformité ou d’une modification du statut quittant « Examen de conformité en cours ». Collecte L’événement est déduit d’une modification du statut indiquant que l’examen est terminé, par exemple vers « Approuvé », « Rejeté » ou « Décision finale ». Type d’événement inferred
	Intégration client terminée	Cet événement marque la fin réussie de l’ensemble du processus d’intégration et confirme que le client est pleinement actif. Il peut correspondre à un statut final explicite ou être déduit de l’événement « Compte activé ».
Pourquoi c’est important Il s’agit de l’événement final principal correspondant à un état de réussite. Il est indispensable pour calculer le délai de cycle de bout en bout de tous les clients intégrés avec succès. Où les obtenir L’événement est déduit de l’horodatage « Compte activé » ou extrait d’un statut final tel que « Intégration terminée » dans le dossier. Collecte L’événement est déduit du dernier événement positif important, comme l’activation du compte, ou d’une mise à jour finale du statut. Type d’événement inferred
	Compte activé	Après l’approbation, le compte du client est officiellement créé et activé dans la plateforme bancaire ou de services principale. Cette activité est souvent enregistrée dans une piste d’audit ou déduite de la date de création du compte.
Pourquoi c’est important Il s’agit de la dernière étape de création de valeur pour le client. Un délai entre « Demande approuvée » et cette étape peut révéler des problèmes d’intégration entre les systèmes. Où les obtenir L’événement est extrait d’un journal de création de compte, d’un appel API vers un autre système ou de l’horodatage de création du compte lui-même. Collecte L’événement est enregistré séparément après l’approbation ou identifié par la présence d’un horodatage d’activation dans la fiche client. Type d’événement explicit
	Contrôle initial effectué	Vérification automatisée effectuée par le système immédiatement après la soumission, afin de valider que les données de base sont complètes et d’exécuter des contrôles préliminaires. Cette activité est souvent enregistrée comme une étape automatisée explicite dans l’historique du flux de travail.
Pourquoi c’est important Cette activité identifie les demandes qui échouent dès la première étape et aide à comprendre les problèmes de qualité des données. Elle constitue également la première étape automatisée créatrice de valeur du processus. Où les obtenir Recherchez les journaux d’exécution des règles automatisées ou un changement d’état dans l’historique du flux de travail de l’application indiquant que l’étape de filtrage initiale est terminée. Collecte L’événement est enregistré comme une tâche automatisée terminée ou comme une mise à jour spécifique du statut dans l’historique du dossier. Type d’événement explicit
	Documents demandés	Le système ou un utilisateur demande au client des documents précis, comme une pièce d’identité ou une facture de services publics. Cet événement peut être extrait des journaux de communication générés par le système ou d’une modification du statut indiquant que le dossier est en attente de documents.
Pourquoi c’est important Cette activité introduit souvent un temps d’attente important dans le processus. L’analyse de sa fréquence et de sa durée permet d’identifier les retards liés au délai de réponse des clients. Où les obtenir Recherchez un événement dans les journaux de communication envoyés au client ou une modification du statut de la demande, par exemple « Documents du client en attente ». Collecte L’événement est déduit d’une modification du statut vers « Documents en attente » ou de l’horodatage d’une communication sortante. Type d’événement inferred
	Examen des documents effectué	Un utilisateur ou un outil automatisé examine les documents transmis afin d’en vérifier l’authenticité, la validité et l’exhaustivité. Cette activité peut être déduite d’une modification du statut de « Documents reçus » à « Examen terminé » ou d’une entrée explicite dans le journal.
Pourquoi c’est important Cette étape est une source fréquente de goulots d’étranglement et de reprises. L’analyse de son délai de traitement et de ses répétitions est essentielle pour améliorer l’efficacité et repérer les possibilités d’automatisation. Où les obtenir L’événement est déduit du suivi du temps écoulé entre le statut « Documents reçus » et un statut ultérieur tel que « Vérification réussie » ou « Informations supplémentaires requises ». Collecte La durée est calculée entre l’événement de réception des documents et l’événement indiquant la fin de l’examen. Type d’événement inferred
	Informations supplémentaires demandées	Un responsable de la conformité ou un examinateur demande au client des informations ou des précisions supplémentaires. Cet événement est une cause principale de reprise et est généralement enregistré comme une modification explicite du statut ou une entrée dans le journal de communication.
Pourquoi c’est important Cette activité crée des boucles de reprise qui prolongent le délai de cycle de l’intégration. Le suivi de sa fréquence permet d’identifier les exigences peu claires ou les insuffisances récurrentes des demandes. Où les obtenir Recherchez une modification du statut vers « Informations du client en attente » ou un événement dans le journal des communications sortantes. Cette action est souvent déclenchée par un utilisateur. Collecte L’événement est enregistré lorsqu’un agent utilise la fonctionnalité « Demander des informations », ce qui modifie le statut du dossier et peut créer un événement de communication. Type d’événement explicit
	Vérification de l’identité lancée	Cet événement correspond au moment où le système commence la vérification principale de l’identité à l’aide des services LexisNexis, notamment par des contrôles dans des bases de données. Il est généralement enregistré explicitement dans le journal d’événements lorsque le service de vérification est appelé.
Pourquoi c’est important Cette activité marque le début d’un sous-processus important, souvent long. Le suivi de sa durée permet d’isoler les goulots d’étranglement liés aux contrôles d’identité. Où les obtenir L’événement est extrait des journaux d’appels API du module de vérification de l’identité ou d’une piste d’audit indiquant le début de la tâche de vérification. Collecte Un événement est enregistré lorsque le module ou l’API de vérification de l’identité du système est déclenché pour la demande. Type d’événement explicit

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données depuis LexisNexis Risk Solutions

Étapes

Préparez l'environnement Python : installez Python 3.8 ou une version ultérieure sur votre système. Ouvrez un terminal ou une invite de commandes et installez les bibliothèques nécessaires en exécutant pip install requests pandas.
Obtenez les identifiants de l'API : contactez votre administrateur LexisNexis Risk Solutions ou votre interlocuteur commercial afin d'obtenir les identifiants de l'API. Vous aurez besoin d'une clé API, d'un secret API et de l'URL de base des points de terminaison de l'API.
Configurez le script Python : ouvrez le script Python fourni dans un éditeur de texte. Repérez la section de configuration en haut du fichier et remplacez les valeurs d'exemple de API_KEY, API_SECRET et BASE_URL par vos identifiants réels.
Définissez les paramètres d'extraction : dans cette même section, définissez la période d'extraction en renseignant les variables START_DATE et END_DATE. Formatez les dates selon le modèle « YYYY-MM-DD ». Il est recommandé de commencer par une période courte, par exemple un mois, afin de tester l'extraction.
Vérifiez la correspondance des activités : examinez le dictionnaire ACTIVITY_MAP dans le script. Il associe les types d'événements renvoyés par l'API LexisNexis aux noms d'activités standard requis pour le journal d'événements. Vous devrez peut-être ajuster les clés, c'est-à-dire les valeurs de gauche, en fonction des noms d'événements utilisés dans votre configuration LexisNexis. Vous pouvez les identifier en examinant un exemple de réponse de l'API.
Exécutez le script : lancez le script depuis votre terminal à l'aide de la commande python your_script_name.py. Le script s'authentifiera, récupérera la liste des demandes client comprises dans la période indiquée, puis récupérera l'historique des événements de chacune d'elles.
Suivez la progression du script : le script affichera dans la console des messages de progression, comme le nombre de demandes en cours de traitement. Surveillez les messages d'erreur, qui peuvent signaler un problème lié aux identifiants, aux points de terminaison de l'API ou à la limitation du débit.
Récupérez le fichier de sortie : une fois le script exécuté avec succès, il générera un fichier nommé lexisnexis_event_log.csv dans le même répertoire. Ce fichier contient le journal d'événements extrait.
Préparez l'import : avant d'importer le fichier dans un outil de Process Mining, ouvrez le fichier CSV pour vérifier qu'il contient les colonnes attendues : CustomerApplication, ActivityName, EventTimestamp et les autres colonnes nécessaires. Vérifiez que les données sont correctes et cohérentes.
Importez les données dans ProcessMind : importez le fichier lexisnexis_event_log.csv généré dans votre application de Process Mining, puis associez les colonnes aux champs correspondants pour l'identifiant de dossier, l'activité et l'horodatage.

Configuration

Identifiants de l'API : une clé API et un secret valides sont nécessaires pour l'authentification. Demandez-les à votre administrateur LexisNexis et conservez-les de manière confidentielle.
Points de terminaison de l'API : le script doit être configuré avec l'URL de base correcte de l'API REST LexisNexis. Les points de terminaison permettant de récupérer les demandes et leur historique d'événements sont définis dans le code du script.
Période : les paramètres START_DATE et END_DATE définissent la période d'extraction. Pour maîtriser les performances et éviter les limites de débit de l'API, il est recommandé d'extraire les données par lots de 3 à 6 mois.
Correspondance des activités : le dictionnaire ACTIVITY_MAP constitue un élément de configuration essentiel. Vérifiez que les noms d'événements sources renvoyés par l'API, utilisés comme clés du dictionnaire, correspondent à ceux générés par votre système. Tout événement sans correspondance sera ignoré.
Limitation du débit : le script inclut un délai de base entre les appels à l'API afin de respecter les éventuelles limites de débit. Pour les volumes très importants, vous devrez peut-être ajuster la valeur API_CALL_DELAY_SECONDS ou mettre en place une logique de temporisation progressive plus avancée.
Prérequis : cette méthode nécessite un système équipé de Python 3.x ainsi que des bibliothèques requests et pandas. L'utilisateur ou le compte de service qui exécute le script doit disposer des autorisations suffisantes pour accéder à l'API LexisNexis.

a Exemple de requête python

import requests
import pandas as pd
import time
import json
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Section --- #
class=class="hl-string">"hl-comment"># Replace with your actual LexisNexis API credentials and endpoints
API_KEY = class="hl-string">'[Your_API_Key]'
API_SECRET = class="hl-string">'[Your_API_Secret]'
BASE_URL = class="hl-string">'[https://api.example.lexisnexis.com/v1]' class=class="hl-string">"hl-comment"># e.g., your specific API gateway URL

class=class="hl-string">"hl-comment"># Set the date range for the extraction
START_DATE = class="hl-string">'2023-01-01'
END_DATE = class="hl-string">'2023-06-30'

class=class="hl-string">"hl-comment"># Delay between API calls to avoid rate limiting
API_CALL_DELAY_SECONDS = 0.5

class=class="hl-string">"hl-comment"># Mapping from LexisNexis event types to standard activity names
class=class="hl-string">"hl-comment"># CRITICAL: The keys of this dictionary must be adjusted to match the event names
class=class="hl-string">"hl-comment"># returned by your specific LexisNexis API endpoint.
ACTIVITY_MAP = {
    class="hl-string">'application.submitted': class="hl-string">'Application Submitted',
    class="hl-string">'screening.initial.performed': class="hl-string">'Initial Screening Performed',
    class="hl-string">'verification.identity.initiated': class="hl-string">'Identity Verification Initiated',
    class="hl-string">'documents.requested': class="hl-string">'Documents Requested',
    class="hl-string">'documents.received': class="hl-string">'Documents Received',
    class="hl-string">'review.document.performed': class="hl-string">'Document Review Performed',
    class="hl-string">'assessment.risk.performed': class="hl-string">'Risk Assessment Performed',
    class="hl-string">'review.compliance.initiated': class="hl-string">'Compliance Review Initiated',
    class="hl-string">'information.additional.requested': class="hl-string">'Additional Information Requested',
    class="hl-string">'review.compliance.completed': class="hl-string">'Compliance Review Completed',
    class="hl-string">'application.approved': class="hl-string">'Application Approved',
    class="hl-string">'account.activated': class="hl-string">'Account Activated',
    class="hl-string">'onboarding.completed': class="hl-string">'Customer Onboarding Completed',
    class="hl-string">'application.rejected': class="hl-string">'Application Rejected'
}

def get_auth_token():
    class="hl-string">"""Handles authentication and returns an access token."""
    class=class="hl-string">"hl-comment"># This is a placeholder for the actual authentication mechanism.
    class=class="hl-string">"hl-comment"># Adjust according to LexisNexis API documentation (e.g., OAuth2).
    class=class="hl-string">"hl-comment"># For simplicity, we assume the API Key can be used directly in a header.
    class=class="hl-string">"hl-comment"># In a real scenario, you might POST to a token endpoint.
    print(class="hl-string">"Authentication successful (simulated).")
    return fclass="hl-string">'Bearer {API_KEY}' class=class="hl-string">"hl-comment"># Simplified for example purposes

def main():
    class="hl-string">"""Main function to orchestrate the data extraction process."""
    auth_token = get_auth_token()
    if not auth_token:
        print(class="hl-string">"Failed to authenticate. Exiting.")
        return

    headers = {
        class="hl-string">'Authorization': auth_token,
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }

    print(fclass="hl-string">"Fetching applications from {START_DATE} to {END_DATE}...")
    
    class=class="hl-string">"hl-comment"># 1. Fetch all application IDs within the date range
    try:
        applications_endpoint = fclass="hl-string">'{BASE_URL}/applications'
        params = {class="hl-string">'startDate': START_DATE, class="hl-string">'endDate': END_DATE}
        response = requests.get(applications_endpoint, headers=headers, params=params)
        response.raise_for_status()
        applications = response.json().get(class="hl-string">'applications', [])
        print(fclass="hl-string">"Found {len(applications)} applications to process.")
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching applications: {e}")
        return

    all_events = []

    class=class="hl-string">"hl-comment"># 2. For each application, fetch its detailed event history
    for i, app in enumerate(applications):
        app_id = app.get(class="hl-string">'customerApplicationId')
        if not app_id:
            continue

        print(fclass="hl-string">"Processing application {i+1}/{len(applications)}: {app_id}")
        try:
            events_endpoint = fclass="hl-string">'{BASE_URL}/applications/{app_id}/events'
            event_response = requests.get(events_endpoint, headers=headers)
            event_response.raise_for_status()
            events_data = event_response.json().get(class="hl-string">'events', [])
            
            class=class="hl-string">"hl-comment"># 3. Parse events and map them to the event log format
            for event in events_data:
                event_type = event.get(class="hl-string">'eventType')
                if event_type in ACTIVITY_MAP:
                    activity_name = ACTIVITY_MAP[event_type]
                    
                    class=class="hl-string">"hl-comment"># Extract attributes, using .get() to handle missing data gracefully
                    record = {
                        class="hl-string">'CustomerApplication': app_id,
                        class="hl-string">'ActivityName': activity_name,
                        class="hl-string">'EventTimestamp': event.get(class="hl-string">'eventTimestamp'),
                        class="hl-string">'EndTime': event.get(class="hl-string">'eventCompletionTimestamp', None), class=class="hl-string">"hl-comment"># Optional
                        class="hl-string">'AssignedUser': event.get(class="hl-string">'userId', class="hl-string">'System'),
                        class="hl-string">'Department': event.get(class="hl-string">'userDepartment', None),
                        class="hl-string">'ApplicationStatus': event.get(class="hl-string">'applicationStatusAfterEvent'),
                        class="hl-string">'RiskLevel': event.get(class="hl-string">'riskAssessment', {}).get(class="hl-string">'level', None),
                        class="hl-string">'SlaTargetDate': app.get(class="hl-string">'slaTargetDate', None)
                    }
                    all_events.append(record)

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Could not fetch events for application {app_id}: {e}")
        
        time.sleep(API_CALL_DELAY_SECONDS)

    if not all_events:
        print(class="hl-string">"No events were extracted. The output file will be empty.")
        return

    class=class="hl-string">"hl-comment"># 4. Create a DataFrame and save to CSV
    df = pd.DataFrame(all_events)
    df[class="hl-string">'EventTimestamp'] = pd.to_datetime(df[class="hl-string">'EventTimestamp'])
    df.sort_values(by=[class="hl-string">'CustomerApplication', class="hl-string">'EventTimestamp'], inplace=True)
    
    output_filename = class="hl-string">'lexisnexis_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%d %H:%M:%S')
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

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

Prêt à commencer ?

Utilisez ce template pour lancer votre démarche de Process Mining appliquée à l'intégration client KYC. Commencez dès aujourd'hui à transformer vos données en analyses concrètes.

Retour au guide d’amélioration Télécharger le modèle

Optimisez votre intégration KYC et réduisez les abandons dès aujourd'hui

Mettez en place une intégration simple et réduisez le délai à seulement 24 heures.

Démarrer l'essai gratuit

Aucune carte bancaire requise, commencez à optimiser dès aujourd'hui.

Votre template de données pour l'intégration client KYC

Votre template de données pour l'intégration client KYC

Attributs de l’intégration des clients KYC

Activités d’intégration des clients KYC

Guides d'extraction

Extraction des données de l'API LexisNexis à l'aide d'un script Python

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez votre intégration KYC et réduisez les abandons dès aujourd'hui

Nous attachons de l’importance à votre confidentialité