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

La demande client est l'identifiant central qui relie toutes les activités et les points de données pour le parcours d'intégration d'un seul client. Elle commence lorsqu'une demande est soumise et suit le cas jusqu'à ce qu'il soit complété ou rejeté.

En process mining, cet attribut est essentiel pour regrouper tous les événements en un cas cohérent, permettant une analyse de bout en bout du cycle de vie de l'intégration. Il permet la reconstruction de l'ensemble du flux de processus pour chaque demandeur, ce qui est fondamental pour calculer les délais de cycle, analyser les variantes de processus et suivre le statut d'une demande au fil du temps.

C'est l'ID de cas fondamental. Sans lui, vous ne pouvez pas suivre le parcours de bout en bout d'une demande client, ce qui rend l'analyse des processus impossible.

C'est l'identifiant de cas principal au sein du module de gestion de cas de LexisNexis Risk Solutions.

Le nom de l'activité décrit une étape du workflow d'intégration KYC, telle que 'Demande soumise', 'Examen des documents effectué' ou 'Demande approuvée'. Chaque activité représente une action ou une étape distincte du processus.

Cet attribut est essentiel pour construire la carte des processus, qui représente visuellement le flux des activités. Il permet l'analyse des variantes de processus, des goulots d'étranglement entre des étapes spécifiques et de la fréquence des boucles de retouches. L'analyse des activités est essentielle pour comprendre ce qui se passe dans le processus.

Cet attribut constitue la colonne vertébrale de la carte des processus, vous permettant de visualiser et d'analyser la séquence des événements dans le parcours d'intégration client.

Généralement trouvé dans un journal d'événements ou une table de suivi d'audit au sein de LexisNexis Risk Solutions qui suit les étapes du processus.

Ce timestamp marque le début d'une activity, fournissant l'ordre chronologique de tous les events au sein d'un case. Il est la fondation de toutes les analyses time-based en process mining.

En utilisant l'Event Timestamp, il est possible de calculer la durée des activities, le temps d'attente entre elles, et le total end-to-end cycle time du processus d'onboarding. Cette data est essentielle pour identifier les bottlenecks, monitorer la conformité aux SLA, et comprendre l'efficacité du process.

Ce timestamp est essentiel pour ordonner les events chronologiquement et calculer toutes les métriques basées sur le temps, telles que les temps de cycle et les bottlenecks.

Situé dans les tables du journal d'événements ou du suivi d'audit, à côté du nom de l'activité.

La date cible SLA (Service Level Agreement) définit l'accord de niveau de service pour l'achèvement 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 pour le dashboard 'SLA Target Adherence Monitoring' et le KPI 'SLA Adherence Rate'. En comparant la date d'achèvement réelle avec la date cible SLA, les organisations peuvent mesurer leurs performances par rapport aux engagements, identifier les cas à risque de non-respect des SLA et enquêter sur les causes profondes des retards.

Permet la mesure des performances par rapport aux accords de niveau de service, en mettant en évidence les inefficacités de processus qui entraînent des violations de SLA.

Consultez la documentation de LexisNexis Risk Solutions ou l'administrateur système. Cela peut être stocké sur le cas ou calculé en fonction des règles métier.

L'attribut Département spécifie le groupe fonctionnel responsable d'une activité, tel que 'Conformité', 'Opérations d'intégration' ou 'Prévention de la fraude'.

Cet attribut est utilisé pour analyser le processus du point de vue départemental, permettant l'analyse des transferts entre différentes équipes. C'est une dimension primaire du tableau de bord 'Allocation des ressources et charge de travail' et il aide à identifier les inefficacités transversales ou les retards de communication entre les départements.

Permet l'analyse des transferts de processus et des performances par domaine fonctionnel, aidant à identifier les bottlenecks interdépartementaux.

Consultez la documentation de LexisNexis Risk Solutions ou l'administrateur système. Peut nécessiter une jointure à partir d'une table maîtresse de données utilisateur ou RH.

Ce timestamp marque la completion d'une activity. La différence entre l'End Time et le Start Time pour un event représente son processing time.

End Time est crucial pour calculer avec précision combien de temps chaque step prend, ce qui est un input primaire pour le dashboard 'Activity Processing & Waiting Times'. Il aide à différencier le temps qu'une ressource a activement travaillé sur une task versus le temps où le case attendait le prochain step.

Permet le calcul précis du temps de traitement des activités, essentiel pour identifier les étapes inefficaces et analyser la charge de travail des ressources.

Consultez la documentation de LexisNexis Risk Solutions ou votre administrateur système. Ces données sont souvent disponibles dans les event logs enregistrant les débuts et fins d'événements.

LexisNexis Risk Solutions est spécialisée dans l'évaluation des risques. Cet attribut représente le résultat de cette évaluation, catégorisant chaque demande en fonction de son profil de risque potentiel. Le niveau de risque dicte souvent l'intensité et la durée requises du processus de diligence raisonnable.

Cet attribut est la dimension centrale pour le tableau de bord 'Niveau de risque vs. Durée d'intégration'. L'analyse du processus par niveau de risque peut révéler si les demandes à haut risque prennent beaucoup plus de temps que prévu, ou si les demandes à faible risque sont inutilement retardées. Cela aide à valider et à affiner les stratégies d'intégration basées sur les risques.

Crucial pour l'analyse basée sur les risques, aidant à comprendre comment les profils de risque des clients impactent la complexité, la durée et les parcours du processus.

Consultez la documentation de LexisNexis Risk Solutions ou l'administrateur système. Il s'agit d'un résultat essentiel des modules d'évaluation des risques.

Cet attribut reflète le statut global du cas à un moment donné ou son résultat final. Les statuts courants incluent 'En cours', 'Approuvé', 'Rejeté' ou 'En attente d'informations'.

Application Status est vital pour suivre les outcomes du processus d'onboarding. Il est utilisé dans les dashboards 'Application Rejection Reasons & Stages' et 'Daily Throughput and Application Status' pour monitorer les taux de succès et le flow opérationnel. L'analyse de la façon dont le statut change au fil du temps fournit des insights sur le cycle de vie du case.

Suit le résultat de chaque demande, ce qui est essentiel pour calculer les KPI clés comme le taux de rejet des demandes et surveiller le débit.

Consultez la documentation de LexisNexis Risk Solutions ou l'administrateur système. Il s'agit généralement d'un champ clé sur l'objet cas principal ou application.

Cet attribut identifie l'individu spécifique qui a exécuté une tâche, tel qu'un agent de conformité effectuant un examen de documents. Il aide à analyser la distribution de la charge de travail et la performance individuelle.

En analyse, Assigned User est la clé du dashboard 'Resource Allocation and Workload'. Il permet de filtrer la carte des processus par utilisateur, de comparer les performances entre les membres de l'équipe et d'identifier les opportunités de formation ou de rééquilibrage de la charge de travail. Il peut également aider à identifier les goulots d'étranglement causés par des groupes d'utilisateurs spécifiques.

Cet attribut est crucial pour analyser les performances des ressources, la distribution de la charge de travail et identifier les opportunités d'automatisation ou d'optimisation des ressources.

Consultez la documentation de LexisNexis Risk Solutions ou l'administrateur système. Généralement trouvé dans les pistes d'audit ou les tables de gestion des tâches.

L'attribut Canal 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 lors de l'intégration.

Cet attribut est utilisé pour comparer les performances du processus à travers différents canaux. Par exemple, le dashboard 'Onboarding Funnel Conversion Rates' peut être filtré par canal pour voir si les candidats mobiles abandonnent plus souvent que les candidats web, informant ainsi les améliorations de processus spécifiques à chaque canal.

Aide à analyser la performance du processus par canal de soumission, en identifiant les variations qui peuvent éclairer la stratégie de canal et les améliorations de l'expérience utilisateur.

Consultez la documentation de LexisNexis Risk Solutions ou l'administrateur système. Cette information est généralement capturée au début du processus de demande.

Cet attribut fournit un timestamp pour la dernière mise à jour du dataset. Il est typiquement appliqué à l'ensemble du dataset pendant le processus d'extraction et de chargement des données.

Cette information est critique pour que les utilisateurs du dashboard comprennent la fraîcheur des données qu'ils analysent. Elle garantit que les décisions sont basées sur des données aussi actuelles que nécessaire et aide à gérer les attentes concernant la timeliness des insights.

Fournit un contexte crucial sur la fraîcheur des données, garantissant que les analyses sont pertinentes et que les décisions ne sont pas basées sur des informations obsolètes.

Ceci est généralement généré et estampillé sur le dataset pendant le processus ETL (Extract, Transform, Load).

Cet attribut booléen distingue les tâches exécutées par l'automatisation du système (par exemple, un contrôle de filtrage initial) et celles nécessitant une intervention humaine (par exemple, un examen manuel de documents).

'Is Automated' est utilisé pour calculer le KPI 'Manual Activity Proportion' et pour analyser l'efficacité des initiatives d'automatisation. Dans la carte des processus, il peut mettre en évidence l'interface entre les étapes automatisées et manuelles, aidant à identifier les opportunités d'automatisation supplémentaire pour réduire les coûts et les temps de traitement.

Distingue les tâches manuelles et automatisées, ce qui est essentiel pour identifier les opportunités d'automatisation et mesurer leur impact.

Consultez la documentation de LexisNexis Risk Solutions ou l'administrateur système. Cela peut être un flag dans le journal d'événements ou déduit en fonction de l'« AssignedUser » (par exemple, un utilisateur « système »).

Ce drapeau booléen est défini sur true lorsqu'une activité est répétée dans le même case, tel qu'un 'Document Review Performed' se produisant une seconde fois après 'Additional Information Requested'. Il signifie que le process a reculé.

'Is Rework' est crucial pour le dashboard 'Rework and Repetition Analysis' et le KPI 'Rework Loop Percentage'. Il permet de quantifier les efforts gaspillés et aide à identifier les root causes du rework, telles que des instructions peu claires ou une mauvaise qualité des data, permettant des process improvements ciblés.

Quantifie directement l'inefficacité et les efforts gaspillés dans le processus, en mettant en évidence les activités fréquemment répétées qui augmentent les coûts et les temps de cycle.

C'est un attribut calculé, généralement dérivé au sein de l'outil de process mining en détectant des séquences d'activités répétées au sein d'un case.

Alors que 'AssignedUser' capture l'utilisateur pour toute activity, cet attribut identifie spécifiquement le spécialiste de la conformité impliqué dans les steps de review critiques. Cela permet une analyse plus ciblée de la fonction de compliance.

Cet attribut est clé pour le dashboard 'Compliance Review Duration and Backlog'. Il aide à analyser la workload et la performance de l'équipe de compliance, identifiant si des reviewers spécifiques sont des bottlenecks ou si l'équipe globale est under-resourced.

Offre un aperçu ciblé de la fonction de conformité, permettant une analyse détaillée de la charge de travail et des performances des réviseurs à cette étape critique et souvent retardée du processus.

Consultez la documentation de LexisNexis Risk Solutions ou l'administrateur système. Ceci peut être dérivé en filtrant « AssignedUser » pour les activités liées à la conformité.

Lorsque le statut final d'une application est 'Rejected', cet attribut fournit la raison spécifique. Des exemples incluent 'Failed Identity Verification', 'Sanctions Match', ou 'Incomplete Documentation'.

Ces data sont l'input primaire pour le dashboard 'Application Rejection Reasons & Stages'. L'analyse des raisons de rejet aide à identifier les points de failure communs dans le process, ce qui peut informer les améliorations aux directives d'application, à la communication client, ou aux critères de review internes. Comprendre pourquoi les applications sont rejetées est clé pour améliorer le taux d'approval global.

Fournit un aperçu direct des raisons de l'échec de l'intégration, permettant des améliorations ciblées pour augmenter le taux d'approbation des demandes.

Consultez la documentation de LexisNexis Risk Solutions ou l'administrateur système. Souvent trouvé dans un champ qui est rempli lorsque le statut de la demande est défini sur « Rejeté ».

Cet attribut spécifie le pays du client, ce qui est un facteur critique en KYC en raison des diverses réglementations internationales et des niveaux de risque associés aux différentes juridictions.

L'analyse du processus par Customer Country peut révéler des différences significatives dans les temps de cycle et la complexité du processus. Par exemple, les applications provenant de juridictions à haut risque peuvent nécessiter des contrôles de conformité supplémentaires, conduisant à des durées plus longues. Cette analyse aide à la planification des ressources et à la définition de SLAs réalistes pour différentes régions.

Permet une analyse juridictionnelle, cruciale pour comprendre comment les réglementations régionales et les facteurs de risque impactent la performance du processus.

Consultez la documentation de LexisNexis Risk Solutions ou l'administrateur système. Il s'agit d'un champ standard dans les données maîtresses clients.

Cet attribut catégorise chaque cas complété en fonction de son respect de la 'SlaTargetDate'. Les valeurs typiques sont 'Respecté' ou 'Violé'.

Ce champ calculé est la base du dashboard 'SLA Target Adherence Monitoring' et du KPI 'SLA Adherence Rate'. Il fournit une vue claire et de haut niveau des performances par rapport aux engagements de service et permet une analyse approfondie pour comprendre les caractéristiques communes des cas qui ne respectent pas leurs SLA.

Fournit un résultat binaire clair pour la performance SLA, facilitant le suivi, le reporting et l'analyse de la conformité aux objectifs de niveau de service.

C'est un attribut calculé, dérivé en comparant le timestamp de l'activité finale à la 'SlaTargetDate' pour chaque case.

Cet attribut identifie le système source qui a généré les données d'événement, comme LexisNexis Risk Solutions ou un outil tiers intégré. Dans des environnements complexes, les données pour un seul processus peuvent provenir de plusieurs systèmes.

Comprendre le système source est utile pour la validation des données, le dépannage et l'analyse des variations de processus qui peuvent être spécifiques à un système particulier. Cela aide à 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.

Identifie l'origine des données, ce qui est crucial pour la gouvernance des données, la validation et la compréhension de l'exécution des processus à travers différents systèmes informatiques.

Cette information peut être stockée comme une valeur statique ou dans un champ spécifique au sein de l'exportation de données ou de la réponse API.

Le Temps de Cycle mesure le temps total écoulé entre le tout premier événement (ex : « Application Submitted ») et le dernier événement (ex : « Customer Onboarding Completed ») pour un dossier donné.

C'est un KPI essentiel pour mesurer la santé globale du processus, visualisé dans le dashboard « Onboarding End-to-End Cycle Time ». Le suivi du temps de cycle moyen permet de mesurer l'impact des améliorations et d'identifier comment des facteurs comme le niveau de risque ou le type de demande influencent l'expérience client.

C'est un indicateur de performance clé qui mesure le temps total de mise à la valeur pour le client, impactant directement la satisfaction client et l'efficacité opérationnelle.

C'est une métrique calculée, dérivée en soustrayant le timestamp du premier event du timestamp du dernier event pour chaque case.

Processing Time est la durée calculée à partir des horodatages de début et de fin d'une activité (EndTime - StartTime). Il représente le temps qu'une ressource a passé activement sur une tâche, par opposition au temps d'attente.

Cette métrique calculée est une pierre angulaire de l'analyse des performances et alimente directement le dashboard 'Activity Processing & Waiting Times'. Elle aide à identifier quelles activités spécifiques sont les plus chronophages, indiquant des cibles pour l'amélioration des processus, la formation ou l'automatisation. Par exemple, elle aide à calculer le KPI 'Avg. Doc. Review Processing Time'.

Mesure le temps de travail actif des activités, aidant à distinguer le temps à valeur ajoutée du temps d'attente improductif pour identifier les véritables goulots d'étranglement.

C'est un champ calculé, dérivé de la différence entre les attributs 'EndTime' et 'EventTimestamp' (StartTime).

Cet attribut catégorise les demandes en fonction du type d'entité en cours d'intégration. Différents types de demandes suivent souvent des chemins de processus distincts et ont des profils de risque et des objectifs SLA différents.

L'analyse du processus par Application Type permet de segmenter les données pour comparer l'efficacité et la complexité de l'intégration de différents types de clients. C'est un filtre courant utilisé sur la plupart des dashboards pour fournir une vue plus granulaire des performances.

Permet une segmentation puissante du processus, révélant comment différents types de demandes sont traités et où existent des bottlenecks spécifiques pour chaque type.

Consultez la documentation de LexisNexis Risk Solutions ou l'administrateur système. Il s'agit généralement d'un champ central sur l'objet application ou cas.