Votre template de données pour l’onboarding client KYC
Votre template de données pour l’onboarding client KYC
- Attributs recommandés à collecter
- Activités clés à suivre
- Recommandations pour l’extraction des données
Attributs de l’intégration des clients KYC
| Nom | Description | ||
|---|---|---|---|
| Demande client CustomerApplication | Identifiant unique d’un parcours d’intégration client, utilisé comme identifiant principal du dossier. | ||
| Description Customer Application est l’identifiant central qui regroupe toutes les activités et tous les événements associés au processus d’intégration KYC d’un même client. Il permet de suivre une demande de bout en bout, de sa soumission initiale à sa résolution finale, qu’elle soit approuvée, rejetée ou clôturée. Dans le Process Mining, cet attribut est fondamental pour reconstituer le parcours complet de chaque demande. Il permet d’analyser les flux de processus, les temps de cycle, les variations et les goulots d’étranglement pour chaque demande, et fournit une vue claire de la manière dont les cas individuels sont traités. Pourquoi c’est important Il s’agit du Case ID essentiel qui relie tous les événements associés et permet d’analyser le processus d’intégration client de bout en bout. Où les obtenir Il s’agit généralement de la clé primaire de l’entité centrale de gestion des dossiers ou de gestion du cycle de vie client dans Fenergo. Exemples APP-2023-00123APP-2023-00124APP-2023-00125 | |||
| Heure de début EventStartTime | Horodatage indiquant le début officiel d’une activité ou d’un événement. | ||
| Description Cet attribut enregistre la date et l’heure précises auxquelles une activité donnée a commencé. Il fournit l’ordre chronologique nécessaire à la reconstitution du flux du processus et est essentiel à toutes les analyses fondées sur le temps. Dans le Process Mining, l’heure de début sert à calculer la durée des activités, le temps d’attente entre celles-ci et le temps de cycle global du cas. Elle constitue la base temporelle du journal d’événements et joue un rôle essentiel dans l’analyse des performances et des goulots d’étranglement. Pourquoi c’est important Cet horodatage est essentiel pour classer les événements dans l’ordre chronologique et calculer toutes les métriques temporelles, telles que les durées de cycle et les temps de traitement. Où les obtenir Se trouve dans les tables de piste d’audit, de journal d’événements ou d’historique des flux de travail de Fenergo, souvent sous les intitulés « Timestamp », « StartDate » ou « CreationDate ». Exemples 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Nom de l’activité ActivityName | Nom de l’événement métier ou de la tâche spécifique survenu à un moment donné du processus d’intégration. | ||
| Description Le nom de l’activité décrit une étape ou une étape clé du parcours d’intégration client, telle que « Initial Screening Performed » ou « Application Approved ». La séquence de ces activités constitue la base de la cartographie du processus. L’analyse de cet attribut permet de visualiser le flux du processus, d’identifier les parcours courants et alternatifs et de mesurer la fréquence de chaque étape. Elle est essentielle pour comprendre quelles actions sont réalisées et dans quel ordre. Pourquoi c’est important Cet attribut définit les étapes du processus et permet de créer une cartographie du processus ainsi que d’analyser son flux et ses variations. Où les obtenir Cette information se trouve généralement dans les tables des flux de travail ou des journaux d’audit de Fenergo, associées aux transitions d’état des cas ou à l’achèvement des tâches. Exemples Données et documents demandésRevue de conformité lancéeDemande approuvée | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage indiquant la dernière actualisation ou extraction des données relatives à ce processus. | ||
| Description Cet attribut enregistre la date et l’heure de l’actualisation la plus récente des données. Il renseigne sur leur fraîcheur et permet d’évaluer l’actualité des analyses. Dans les Dashboards et les rapports, cette information indique aux utilisateurs la date de mise à jour des données. Elle permet de déterminer si l’analyse reflète les opérations en temps réel ou un instantané historique. Pourquoi c’est important Fournit un contexte important sur la fraîcheur des données et permet aux utilisateurs de comprendre l’actualité de l’analyse du processus. Où les obtenir Cette valeur est générée et ajoutée au jeu de données lors du processus d’extraction et de chargement des données (ETL). Exemples 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| Système source SourceSystem | Système de référence à partir duquel les données ont été extraites. | ||
| Description Cet attribut identifie le système d’origine des données d’événements. Pour ce processus, il s’agit toujours de Fenergo, mais dans des jeux de données combinés, il permet de distinguer les différentes sources de données. Il sert principalement à filtrer les données provenant de systèmes spécifiques ou à vérifier leur provenance. Il garantit une lecture claire dans les environnements où les données de plusieurs systèmes sont réunies pour obtenir une vue globale du processus. Pourquoi c’est important Identifie l’origine des données, ce qui est essentiel pour leur gouvernance et leur validation, ainsi que pour garantir que l’analyse repose sur la bonne source. Où les obtenir Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction des données afin d’indiquer l’origine des enregistrements. Exemples FenergoFenergo CLM | |||
| Date cible du SLA SlaTargetDate | Date à laquelle le dossier d’intégration client doit être terminé. | ||
| Description La date cible du SLA représente l’échéance convenue pour terminer l’ensemble du processus d’intégration d’une demande client. Elle constitue une référence essentielle pour mesurer la performance réelle. Cet attribut est indispensable au Dashboard « SLA Compliance Monitoring » et au calcul du KPI « SLA Adherence Rate ». Il permet de gérer en amont les dossiers susceptibles de dépasser leur SLA et de prioriser le travail. Pourquoi c’est important Définit la date cible d’achèvement, essentielle au suivi de la conformité aux SLA et à la priorisation des dossiers en retard. Où les obtenir Cette date est souvent calculée à partir de la date de soumission de la demande et des règles métier configurées dans le module de gestion des SLA de Fenergo. Exemples 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| Heure de fin EventEndTime | Horodatage indiquant la fin d’une activité ou d’un événement. | ||
| Description Cet attribut enregistre la date et l’heure précises auxquelles une activité donnée s’est terminée. Il complète l’heure de début pour définir la durée active d’une tâche. Dans le Process Mining, l’heure de fin est utilisée avec l’heure de début pour calculer le temps de traitement de chaque activité. Elle est essentielle pour identifier les étapes qui consomment le plus de temps et analyser l’efficacité des ressources. Pourquoi c’est important Permet de calculer les durées de traitement des activités, ce qui est essentiel pour identifier les tâches longues et les goulots d’étranglement qui nuisent aux performances. Où les obtenir Se trouve dans les tables de piste d’audit ou d’historique du flux de travail de Fenergo, souvent sous les noms « EndDate » ou « CompletionDate », ou peut être calculé à partir de l’heure de début de l’événement suivant. Exemples 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z | |||
| Score de risque RiskScore | Score numérique représentant le niveau de risque calculé du client. | ||
| Description Le score de risque est une mesure quantitative du risque potentiel associé à un client. Il est calculé à partir de différents facteurs, tels que la juridiction, le secteur d’activité et les résultats des contrôles. Le moteur de règles de Fenergo calcule généralement ce score. Cet attribut permet de mettre en relation les niveaux de risque et le comportement du processus. L’analyse peut par exemple révéler que les clients à haut risque connaissent des durées de cycle plus longues ou nécessitent davantage d’interventions manuelles, ce qui est utile pour le Dashboard « Risk & Compliance Review Deep Dive ». Pourquoi c’est important Quantifie le risque client et permet d’analyser l’incidence des niveaux de risque sur la durée du processus, les reprises et les résultats. Où les obtenir Il s’agit d’un résultat clé du module Client Risk Assessment de Fenergo. Il est enregistré sur le dossier ou l’entité cliente. Exemples 154585 | |||
| Service de l’utilisateur UserDepartment | Service ou unité opérationnelle auquel appartient l’utilisateur à l’origine de l’action. | ||
| Description Cet attribut fournit le contexte organisationnel de l’utilisateur qui a exécuté une activité, par exemple « Compliance », « Onboarding Operations » ou « Sales ». Il est souvent déduit des informations du profil utilisateur. Cette dimension est essentielle pour analyser les transmissions entre différents services et identifier les goulots d’étranglement transverses. Elle alimente directement le Dashboard « Staff Activity Distribution » en permettant d’agréger le travail au niveau d’une équipe ou d’un service. Pourquoi c’est important Permet d’analyser la performance du processus par service et de mettre en évidence les transferts entre services, les retards et la répartition de la charge. Où les obtenir Il peut être nécessaire de joindre ces informations à une table distincte de référence des utilisateurs ou des ressources humaines à l’aide de l’identifiant « InitiatingUser ». Fenergo peut également les stocker dans le profil de l’utilisateur. Exemples ComplianceIntégration des clientsAssurance qualité | |||
| Statut de la demande ApplicationStatus | Résultat actuel ou final de la demande client. | ||
| Description Cet attribut indique l’état de la demande à la fin du processus, ou son état actuel si elle est toujours en cours. Les valeurs courantes incluent « Approved », « Rejected » et « In Progress ». Il s’agit d’une dimension essentielle pour analyser les résultats. Elle permet de filtrer et de comparer les flux de processus selon leur résultat final, ce qui est indispensable au Dashboard « Application Rework and Rejection » et au calcul de KPI tels que le taux de rejet des demandes. Pourquoi c’est important Définit le résultat d’un dossier et permet de comparer efficacement les parcours des demandes approuvées et rejetées afin de comprendre les taux de réussite. Où les obtenir Il s’agit généralement du statut final enregistré sur l’entité du dossier dans le système de gestion des dossiers de Fenergo. Exemples ApprouvéRejetéConformité en attenteClôturé | |||
| Utilisateur à l’origine de l’action InitiatingUser | Identifiant ou nom de l’utilisateur ayant réalisé l’activité. | ||
| Description Cet attribut identifie précisément le collaborateur ou l’utilisateur système responsable de l’exécution d’une tâche ou d’un événement. Il peut s’agir d’un identifiant utilisateur unique, d’un nom ou d’un rôle. L’analyse par utilisateur permet de comprendre la répartition de la charge, les performances individuelles et les besoins de formation. Elle est essentielle au Dashboard « Staff Activity Distribution » et à l’analyse détaillée des activités réalisées par des personnes ou des équipes spécifiques. Pourquoi c’est important Indique quel utilisateur a réalisé une action et permet d’analyser la répartition de la charge, la performance des équipes et l’allocation des ressources. Où les obtenir Cette information est généralement stockée dans les journaux d’audit ou les tables d’historique des tâches de Fenergo, avec les détails de l’événement, souvent sous les libellés « UserID », « UserName » ou « ModifiedBy ». Exemples j.doea.smithSYSTEM | |||
| Automatisé IsAutomated | Indicateur booléen précisant si l’activité a été exécutée par un système plutôt que par un utilisateur humain. | ||
| Description Cet attribut distingue les tâches exécutées automatiquement par le système, par exemple le screening initial et les contrôles système, de celles réalisées manuellement par un utilisateur. Cette distinction est souvent établie en vérifiant si l’utilisateur exécutant est un compte système ou de service. L’analyse de cet indicateur est essentielle pour comprendre le niveau d’automatisation du processus. Elle permet de mesurer l’impact de l’automatisation sur l’efficacité, les coûts et la rapidité, ainsi que d’identifier de nouvelles possibilités d’automatisation. Pourquoi c’est important Distingue les activités humaines des activités système, ce qui est indispensable pour analyser l’automatisation et comprendre les coûts liés aux ressources. Où les obtenir Cet indicateur est généralement calculé à partir du champ 'InitiatingUser'. Une liste d’identifiants d’utilisateurs système connus permet de lui attribuer la valeur true. Exemples truefalse | |||
| Canal de la demande ApplicationChannel | Canal par lequel la demande client a été soumise. | ||
| Description Cet attribut identifie la source de soumission de la demande, par exemple un portail en ligne, une agence ou un chargé de relation. La source peut influer sur la qualité des données et les exigences de traitement. Cette dimension est utilisée dans le Dashboard « Application Source & Type Efficiency » pour comparer la performance des différents canaux. Elle aide les entreprises à déterminer quels canaux sont les plus efficaces et lesquels nécessitent une optimisation du processus. Pourquoi c’est important Identifie la source des demandes et permet d’analyser l’efficacité, le coût et l’expérience client associés à chaque canal. Où les obtenir Cette information peut être saisie dans un formulaire initial de collecte des données dans Fenergo ou transmise par un système en amont. Exemples Portail en ligneAgenceChargé de relation clientApplication mobile | |||
| Conforme au SLA IsSlaCompliant | Indicateur booléen précisant si le dossier a été finalisé avant la date cible de son SLA. | ||
| Description Cet attribut indique de manière binaire la performance du SLA pour un dossier finalisé. Il prend la valeur 'true' si l’horodatage de l’activité finale de clôture est antérieur ou égal à 'SlaTargetDate', et 'false' dans le cas contraire. Ce champ calculé simplifie le suivi et le reporting des SLA. Il permet d’agréger facilement les résultats afin de calculer le KPI 'SLA Adherence Rate' et de filtrer les dossiers pour analyser les caractéristiques des cas conformes et non conformes. Pourquoi c’est important Mesure directement la performance du SLA, ce qui facilite le calcul du KPI SLA Adherence Rate et le filtrage des dossiers non conformes. Où les obtenir Cet indicateur est calculé en comparant l’horodatage de la dernière activité du dossier, par exemple 'Application Approved' ou 'Application Rejected', avec 'SlaTargetDate'. Exemples truefalse | |||
| Identifiant client CustomerId | Identifiant unique du client ou de l’entité juridique faisant l’objet de l’onboarding. | ||
| Description Le Customer ID est la référence unique de l’entité cliente dans le système de données de référence. Alors que le numéro de demande constitue l’identifiant du dossier dans le processus, le Customer ID relie l’activité d’onboarding à un client précis. Cet attribut permet d’analyser l’historique d’onboarding d’un même client, notamment lorsqu’il a suivi plusieurs processus d’onboarding au fil du temps. Il permet également de rapprocher les données du processus avec d’autres données relatives au client afin d’obtenir une vision métier plus complète. Pourquoi c’est important Relie le processus d’onboarding à une entité cliente unique, ce qui permet une analyse centrée sur le client et l’enrichissement des données. Où les obtenir Cet identifiant est enregistré sur la fiche du client ou de l’entité juridique dans Fenergo et associé au dossier d’onboarding. Exemples CUST-98765CUST-98766CUST-98767 | |||
| Motif du rejet RejectionReason | Code ou description expliquant pourquoi une demande a été rejetée. | ||
| Description Lorsque le statut final d’une demande est « Rejected », cet attribut fournit le motif précis du rejet. Les exemples incluent « Failed Background Check », « Incomplete Documentation » ou « High Risk Profile ». Cet attribut est essentiel à l’analyse des causes profondes des demandes rejetées. Il alimente directement le Dashboard « Application Rework and Rejection » en catégorisant les échecs, afin d’identifier les problèmes récurrents et de mettre en place des mesures correctives pour améliorer le taux de réussite dès la première soumission. Pourquoi c’est important Fournit des informations importantes sur les causes d’échec des demandes et permet d’analyser les causes profondes afin de réduire le taux de rejet. Où les obtenir Se trouve généralement dans un code motif ou un champ de notes associé à l’état final de rejet dans le flux de travail des cas Fenergo. Exemples Correspondance avec une liste de sanctionsDocuments non validesViolation de la politiqueDésistement du client | |||
| Nombre de demandes d’informations complémentaires AdditionalInfoRequestCount | Nombre total de demandes d’informations complémentaires formulées pour une demande. | ||
| Description Cette mesure compte les occurrences de l’activité 'Additional Information Requested' pour chaque dossier. Un nombre élevé traduit davantage d’échanges successifs, susceptibles de retarder le processus et de dégrader l’expérience client. Cet attribut contribue directement au KPI 'Cases with Additional Info Requests'. Il permet d’identifier les demandes faisant l’objet d’un nombre excessif de sollicitations, ce qui peut révéler des problèmes lors de la collecte initiale des données ou des exigences particulièrement complexes. Son analyse aide à améliorer la collecte d’informations. Pourquoi c’est important Mesure les points de friction pour le client et les retards du processus liés à des informations initiales incomplètes, afin d’améliorer l’étape de collecte des données. Où les obtenir Il s’agit d’une mesure calculée, obtenue en comptant le nombre d’événements 'Additional Information Requested' pour chaque identifiant 'CustomerApplication'. Exemples 013 | |||
| Pays Country | Pays de résidence ou juridiction associé à la demande client. | ||
| Description Cet attribut précise le pays associé au client, qui détermine souvent les règles réglementaires et les facteurs de risque applicables au processus d’intégration. L’analyse du processus par pays permet de comparer les durées de cycle, les niveaux de risque et la complexité des processus selon les juridictions. Elle aide à comprendre l’incidence des différences régionales sur la performance opérationnelle et à garantir le respect des réglementations locales. Pourquoi c’est important Permet de segmenter le processus selon la zone géographique, ce qui est essentiel pour analyser l’incidence de la réglementation et la performance régionale. Où les obtenir Cette information fait partie des données client de référence recueillies lors de la demande et stockées sur l’entité client dans Fenergo. Exemples USAGBRSGPDEU | |||
| Reprise IsRework | Indicateur booléen précisant si une activité fait partie d’une boucle de reprise. | ||
| Description Cet attribut identifie les activités qui correspondent à un retour en arrière dans le processus, par exemple un retour à 'Document Review' après le début de 'Compliance Review', ou toute occurrence de 'Additional Information Requested'. L’identification des reprises est essentielle pour comprendre les inefficacités et les points de friction du processus. Cet indicateur permet de calculer directement le KPI 'Rework Loop Rate', ainsi que de visualiser et de mesurer l’impact des étapes répétitives et sans valeur ajoutée dans le flux du processus. Pourquoi c’est important Met en évidence les boucles de reprise inefficaces du processus, afin de mesurer les pertes et d’identifier les améliorations susceptibles d’augmenter le taux de traitement correct dès la première fois. Où les obtenir Cet indicateur est calculé à l’aide de techniques de Process Mining qui analysent la séquence des activités. Par exemple, si 'Activity A' est suivie de 'Activity B', puis que 'Activity A' apparaît de nouveau pour le même dossier, la seconde occurrence de 'Activity A' est considérée comme une reprise. Exemples truefalse | |||
| Responsable du dossier CaseOwner | Utilisateur ou équipe principalement chargé de gérer la demande pendant tout son cycle de vie. | ||
| Description Le responsable du dossier est la personne ou le groupe auquel incombe la responsabilité principale d’un dossier d’onboarding. Cette personne est généralement responsable de son traitement dans les délais et de sa bonne finalisation. Cet attribut permet d’analyser la charge de travail et la performance au niveau des gestionnaires de dossiers. Il peut servir à déterminer si certains responsables présentent des délais de traitement plus longs ou des taux de rejet plus élevés, ce qui peut révéler des besoins de formation ou un déséquilibre des ressources. Pourquoi c’est important Identifie la personne ou l’équipe responsable d’un dossier et permet d’analyser la performance des gestionnaires de dossiers. Où les obtenir Il s’agit généralement d’un champ spécifique de l’entité principale du dossier dans Fenergo, qui indique l’attribution du dossier. Exemples s.jonesonboarding_team_am.chen | |||
| Type de client CustomerType | Catégorie du client intégré, par exemple une personne physique, une entreprise ou une fiducie. | ||
| Description Cet attribut répartit les clients en différentes catégories selon leur structure juridique ou leur relation avec l’établissement financier. Les différents types de clients suivent souvent des parcours d’intégration distincts, avec des niveaux de complexité et des exigences de diligence variables. L’analyse du processus par type de client permet d’identifier les écarts de performance entre les segments. Elle est essentielle au Dashboard « Application Source & Type Efficiency », qui compare les durées de cycle et les taux d’approbation afin de guider des améliorations adaptées. Pourquoi c’est important Permet de comparer la performance du processus entre différents segments de clients, dont la complexité et les SLA peuvent varier. Où les obtenir Cette information est généralement stockée sur l’entité client dans Fenergo et liée au dossier de demande. Exemples ParticulierEntrepriseFiducieSociété de personnes | |||
Activités d’intégration des clients KYC
| Activité | Description | ||
|---|---|---|---|
| Demande approuvée | Cette activité représente la décision finale d’approuver la demande d’intégration du client. Elle est déduite du passage du statut du dossier à un état final tel que « Approved » ou « Onboarding Approved ». | ||
| Pourquoi c’est important Cette étape importante confirme un résultat positif avant les dernières étapes d’activation du compte. Elle est essentielle pour calculer les taux d’approbation et analyser les caractéristiques des clients intégrés avec succès. Où les obtenir Cette information est déduite de l’historique ou du journal d’audit du dossier, en recherchant l’horodatage du changement de statut final vers « Approved » ou un état positif terminal similaire. Collecte Identifiez l’horodatage du changement de statut final vers « Approved ». Type d’événement inferred | |||
| Demande rejetée | Cette activité est un événement terminal qui représente la décision finale de rejeter la demande du client. Elle est déduite du passage du statut du dossier à un état final tel que « Rejected » ou « Declined ». | ||
| Pourquoi c’est important En tant que point final important du processus, cette activité est essentielle pour calculer le « Application Rejection Rate » et analyser les causes d’échec. Elle permet d’identifier les points de rejet fréquents et d’améliorer la qualité des demandes. Où les obtenir Cette information est déduite du journal d’audit du dossier, en enregistrant l’horodatage auquel le statut final passe à « Rejected ». Le motif du rejet est souvent conservé dans un champ associé. Collecte Identifiez l’horodatage du changement de statut final vers « Rejected ». Type d’événement inferred | |||
| Dossier clôturé | Il s’agit de l’activité finale, qui indique que le dossier d’intégration est clôturé administrativement dans Fenergo et qu’aucune autre action n’est attendue. Elle s’applique aux demandes approuvées comme aux demandes rejetées et est déduite d’un statut final « Closed ». | ||
| Pourquoi c’est important Cette activité constitue le point final définitif de l’ensemble du processus. Elle garantit un calcul précis de la durée du cycle pour tous les dossiers, quel que soit leur résultat, et confirme la fin du processus. Où les obtenir Cette information est déduite du journal d’audit du dossier Fenergo, en identifiant l’horodatage auquel le statut du dossier passe à « Closed », « Completed » ou à un autre état terminal. Collecte Identifiez l’horodatage du changement de statut final vers « Closed » ou « Completed ». Type d’événement inferred | |||
| Dossier créé | Cette activité marque le début du processus d’intégration KYC, lorsqu’une nouvelle demande client est officiellement créée dans Fenergo. Il s’agit généralement d’un événement explicite, enregistré avec un horodatage précis au moment de la première sauvegarde du dossier. | ||
| Pourquoi c’est important En tant qu’événement de début, cette activité est essentielle pour calculer la durée globale du cycle d’intégration et analyser le débit du processus. Elle fournit la référence de départ pour toutes les mesures ultérieures du processus et le suivi des SLA. Où les obtenir Cette information est généralement extraite de l’horodatage de création de l’entité principale du cas dans Fenergo, souvent dans des tables liées aux cas ou aux flux de travail d’intégration des clients. Collecte Utilisez l’horodatage de création du dossier d’intégration. Type d’événement explicit | |||
| Évaluation des risques terminée | Cette activité correspond à l’achèvement du processus interne de classification des risques, au cours duquel un niveau de risque est attribué au client selon différents facteurs. Elle est déduite d’un changement de statut ou du renseignement d’un champ de niveau de risque. | ||
| Pourquoi c’est important Il s’agit d’une étape importante de prise de décision qui détermine souvent le parcours ultérieur du flux de travail. L’analyse de sa durée permet d’optimiser une étape essentielle de la conformité et de garantir la cohérence de l’évaluation des risques. Où les obtenir Cette information est déduite du journal d’historique du dossier, en identifiant le moment où le dossier passe à un statut tel que « Risk Assessed » ou celui où le champ final « Customer Risk Rating » est renseigné. Collecte Utilisez l’horodatage auquel le niveau de risque est finalisé ou un statut associé est défini. Type d’événement inferred | |||
| Revue de conformité lancée | Cette activité marque le début de la revue par le service conformité, une étape importante et souvent longue. Elle est déduite lorsque le dossier est affecté à la file de traitement de la conformité ou lorsque son statut passe à « Pending Compliance Review ». | ||
| Pourquoi c’est important Cette activité constitue le point de départ du calcul du KPI « Average Compliance Review Time ». Elle permet de mesurer le temps pendant lequel les dossiers attendent avant d’être pris en charge par l’équipe conformité. Où les obtenir Cette information est déduite du journal d’audit du dossier Fenergo, en enregistrant l’horodatage du changement de statut vers « In Compliance Review » ou de l’affectation du dossier à un responsable ou à une équipe conformité. Collecte Identifiez l’horodatage du changement de statut vers « Under Compliance Review » ou l’événement d’affectation. Type d’événement inferred | |||
| Revue de conformité terminée | Cette activité marque la validation formelle par le service conformité et indique que toutes les exigences réglementaires ont été respectées. Elle est déduite de l’achèvement d’une tâche ou d’un changement de statut vers « Compliance Approved ». | ||
| Pourquoi c’est important En tant qu’étape majeure, l’achèvement de cette activité est essentiel au temps de cycle global. Il constitue le point final pour mesurer le « Average Compliance Review Time » et repérer les goulots d’étranglement au sein de la fonction conformité. Où les obtenir Est déduit de l’horodatage d’achèvement de la tâche « Compliance Review » dans le flux de travail Fenergo ou de l’événement de mise à jour du statut dans l’historique du cas. Collecte Utilisez l’horodatage d’achèvement de la tâche de revue de conformité ou de la mise à jour du statut. Type d’événement inferred | |||
| Revue des documents terminée | Indique que le processus manuel ou automatisé de vérification de l’authenticité et de l’exactitude de tous les documents transmis par le client est terminé. Cet événement est généralement déduit de l’achèvement d’une tâche du flux de travail ou d’un changement de statut dans Fenergo. | ||
| Pourquoi c’est important Il s’agit d’une étape importante au cours de laquelle de nombreux retards peuvent se produire. L’analyse de la durée et des résultats de cette activité permet de repérer les goulots d’étranglement du traitement des documents et d’alimenter des KPI tels que « First-Time Pass Rate ». Où les obtenir Est déduit de l’horodatage d’achèvement de la tâche « Document Verification » dans le flux de travail du cas, ou d’une mise à jour du statut vers « Documents Approved » dans le journal de l’historique du cas. Collecte Utilisez l’horodatage d’achèvement de la tâche de revue des documents ou d’un changement de statut associé. Type d’événement inferred | |||
| Compte activé | Cette activité indique que le compte du client a été créé et activé avec succès dans le système bancaire central ou dans le système aval concerné, après approbation. Elle peut être déduite d’une mise à jour finale du statut dans Fenergo après l’approbation. | ||
| Pourquoi c’est important Cette activité confirme le passage réussi du processus d’intégration au statut de client actif. Mesurer le délai entre l’approbation et l’activation peut révéler des retards dans la mise en place opérationnelle. Où les obtenir Cette information peut être déduite d’un statut de dossier tel que « Account Active » ou « Onboarding Complete ». Elle peut également correspondre à un événement explicite enregistré par une intégration avec un système aval. Collecte Recherchez un changement de statut après l’approbation ou un événement de réussite enregistré par une intégration. Type d’événement inferred | |||
| Contrôle initial effectué | Représente l’achèvement des contrôles préliminaires automatisés ou manuels, comme la validation des données de base ou le contrôle des listes de sanctions. Cet événement est souvent déduit d’un changement de statut dans le flux de travail du cas Fenergo, par exemple lors du passage de « New » à « Screening Complete ». | ||
| Pourquoi c’est important Le suivi de cette étape précoce permet d’identifier les problèmes de qualité des données et les goulots d’étranglement lors de la phase de préqualification. Il distingue la phase automatisée initiale des processus de contrôle manuel plus approfondis. Où les obtenir Cette information est déduite de l’historique du dossier ou du journal d’audit, en identifiant l’horodatage auquel le statut du dossier passe à un état indiquant que le contrôle est terminé, tel que « Screening Passed » ou « Awaiting Documents ». Collecte Identifiez dans l’historique le changement de statut vers « Screening Complete » ou un statut équivalent. Type d’événement inferred | |||
| Contrôles d’antécédents lancés | Cette activité marque le déclenchement des contrôles externes d’antécédents, de lutte contre le blanchiment ou de solvabilité. Il s’agit souvent d’un événement explicite enregistré lors de l’appel à un service tiers par une intégration. | ||
| Pourquoi c’est important Le suivi du lancement et de l’achèvement de ces contrôles est essentiel pour comprendre les retards liés aux dépendances externes. Il permet de distinguer le temps de traitement interne du temps d’attente externe. Où les obtenir Cette information est généralement extraite des journaux système qui enregistrent les appels d’API aux prestataires externes de contrôle, ou de la création d’une tâche « Background Check » dans le dossier Fenergo. Collecte Recherchez les journaux des intégrations avec des services externes ou la création d’une tâche « Screening ». Type d’événement explicit | |||
| Documents reçus | Cette activité indique que le client a téléversé ou transmis les documents requis, désormais disponibles dans Fenergo pour examen. Elle est généralement déduite lorsque le statut du dossier passe à « Documents Received » ou « Pending Review ». | ||
| Pourquoi c’est important Elle marque la fin du délai d’attente du client et le début du cycle de revue interne. Elle est essentielle pour mesurer les délais de réponse du client et les temps d’attente dans les files de traitement internes. Où les obtenir Cette information est déduite de la piste d’audit du dossier, qui enregistre l’horodatage du changement de statut vers « Documents Received » ou un état similaire. Elle peut également être associée aux événements de téléversement de documents. Collecte Identifiez l’horodatage du changement de statut vers « Documents Received » ou « Ready for Review ». Type d’événement inferred | |||
| Données et documents demandés | Indique que le système ou un agent chargé de l’intégration a officiellement demandé au client les informations et les documents nécessaires. Cet événement est souvent enregistré explicitement lorsqu’un modèle de communication standardisé est envoyé. | ||
| Pourquoi c’est important Cette activité marque le début d’une phase dépendant du client. Mesurer le délai entre ce moment et la réception des documents est essentiel pour analyser le parcours client et repérer les retards de communication. Où les obtenir Cette information est extraite d’un journal d’événements associé aux communications avec le client ou d’un journal d’achèvement des tâches pour « Request Documents ». Elle peut également être déduite d’un changement de statut vers « Awaiting Customer Information ». Collecte Recherchez un événement de communication avec le client ou l’achèvement d’une tâche enregistré. Type d’événement explicit | |||
| Informations complémentaires demandées | Cette activité correspond à une boucle de reprise, au cours de laquelle l’équipe chargée de l’intégration doit revenir vers le client pour obtenir des précisions ou des documents manquants. Il s’agit d’un événement explicite, généralement enregistré lorsqu’une communication est envoyée au client. | ||
| Pourquoi c’est important Cette activité est un indicateur majeur d’inefficacité du processus et de mauvaise expérience client. Le suivi de sa fréquence permet d’identifier les causes profondes des reprises et d’alimenter le KPI « Rework Loop Rate ». Où les obtenir Cette information est extraite d’un journal d’événements des communications avec le client ou d’un changement de statut vers « Awaiting Additional Information ». Le premier élément est plus précis pour déterminer le moment exact de la demande. Collecte Recherchez les événements de communication enregistrés ou un changement de statut vers « Pending Customer Response ». Type d’événement explicit | |||
Guides d’extraction
Étapes
- Accédez au module de reporting : connectez-vous à l’application Fenergo avec un compte utilisateur disposant des autorisations suffisantes pour le module Reporting & Analytics. Accédez à ce module, généralement disponible dans le menu principal de l’application.
- Créez un rapport : lancez la création d’un rapport personnalisé. Choisissez un nom et une description qui identifient clairement son objectif, par exemple « KYC Onboarding Event Log for Process Mining ».
- Définissez la source de données principale : sélectionnez l’objet de données ou la vue centrale qui contient les informations relatives au cycle de vie des cas. Il s’agit souvent d’une vue préconfigurée telle que
[CaseWorkflowHistory]ou[LifecycleEventsView]. Cet objet doit contenir les identifiants des cas, les noms ou états des événements ainsi que les horodatages. - Configurez les colonnes du rapport (attributs) : utilisez l’interface de création de rapports pour ajouter des colonnes. Associez les champs sources du modèle de données Fenergo aux attributs requis du journal d’événements. Par exemple, associez
CaseIDde Fenergo àCustomerApplication,EventTimestampàEventStartTimeetEventPerformeràInitiatingUser. - Définissez la logique des activités : il s’agit de l’étape la plus importante. Le rapport doit générer une ligne distincte pour chacune des 14 activités requises. Pour cela, créez des blocs logiques ou des ensembles de données filtrés pour chaque activité, puis combinez-les à l’aide d’une fonction UNION ou d’une fonction équivalente dans le générateur de rapports.
- Définissez la logique « Case Created » : créez le premier bloc. Filtrez la source de données sur l’événement initial de création du cas. Celui-ci repose souvent sur l’horodatage le plus ancien associé au cas ou sur un type d’événement nommé « Case Created ». Associez
CreationDateàEventStartTime. - Définissez la logique des activités fondées sur l’état : pour les activités déduites des changements d’état, par exemple « Documents Received » ou « Application Approved », créez des blocs distincts. Filtrez la source de données sur la valeur spécifique du champ
Étatet utilisezStatusChangeDatecommeEventStartTime. - Définissez la logique des activités fondées sur les tâches : pour les activités liées aux tâches du flux de travail, par exemple « Compliance Review Completed », créez des blocs filtrant les champs
TaskNameetTaskCompletionDate. Utilisez la date d’achèvement commeEventStartTime. - Définissez les filtres généraux du rapport : appliquez des filtres au niveau du rapport pour limiter les données. Définissez une
Date Rangeprécise pourEventStartTimeafin d’éviter les exportations excessivement volumineuses. Pour une première analyse, une période de 3 à 6 mois est recommandée. Filtrez sur le type de cas concerné, par exemple « KYC Customer Onboarding ». - Exécutez et prévisualisez le rapport : exécutez le rapport dans l’interface Fenergo. Prévisualisez les 100 à 200 premières lignes afin de vérifier que la structure des données est correcte, que toutes les colonnes sont renseignées comme prévu et que différentes activités sont présentes.
- Exportez les données : exportez l’ensemble des résultats du rapport dans un fichier CSV ou Excel. Il s’agit du fichier brut du journal d’événements.
- Préparez les données finales : ouvrez le fichier CSV exporté. Si les colonnes
SourceSystemetLastDataUpdaten’ont pas pu être générées directement par le rapport, ajoutez-les manuellement. Définissez « Fenergo » comme valeur deSourceSystempour toutes les lignes et utilisez l’horodatage de l’export comme valeur deLastDataUpdate.
Configuration
- Prérequis : l’utilisateur doit avoir accès au module Reporting & Analytics de Fenergo et disposer des autorisations nécessaires pour créer et exécuter des rapports personnalisés.
- Sources de données principales : le rapport doit principalement s’appuyer sur les objets de gestion des cas et d’historique des flux de travail de Fenergo. Les sources courantes comprennent
[CaseDetails],[CaseStatusHistory]et[WorkflowTaskHistory]. Les noms exacts peuvent varier selon votre configuration Fenergo. - Période : il est essentiel de définir un filtre de période sur l’horodatage des événements afin de préserver les performances. Commencez par une période récente de 3 à 6 mois. Pour une analyse historique, exécutez le rapport par lots, par exemple par trimestre ou par année.
- Filtres principaux : filtrez toujours sur le processus ou le type de cas concerné, par exemple « KYC Customer Onboarding », afin d’exclure les données sans rapport. Selon vos objectifs d’analyse, vous devrez peut-être aussi filtrer sur le type d’entité juridique ou la juridiction.
- Définition des activités : chaque activité doit être définie à l’aide de critères de filtrage précis appliqués à des champs tels que
État,TaskNameou un champEventTypedédié. Ces champs sont indispensables pour isoler chaque événement distinct. - Considérations relatives aux performances : les rapports qui combinent de nombreuses sources de données ou couvrent une longue période peuvent être lents. Si possible, planifiez leur exécution en dehors des heures de pointe. Évitez d’inclure des colonnes inutiles dans l’exportation, car elles augmentent le temps de traitement.
a Exemple de requête sql
/*
This is a logical representation of the configuration needed in the Fenergo Reporting & Analytics module.
The module uses a graphical interface, but this query structure illustrates the required data sources, filters, and unions.
Fields like [CaseLifecycleData].[CaseID] are placeholders for actual Fenergo fields selected in the UI.
*/
-- Base data selection for common attributes
WITH CaseAttributes AS (
SELECT
C.CaseID AS CustomerApplication,
C.SlaTargetDate AS SlaTargetDate,
C.FinalRiskScore AS RiskScore,
C.CurrentStatus AS ApplicationStatus
FROM [CaseDetails] C
WHERE C.CaseType = 'KYC Customer Onboarding'
)
-- 1. Case Created
SELECT
A.CustomerApplication,
'Case Created' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
L.CompletionTimestamp AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CASE_CREATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 2. Initial Screening Performed
SELECT
A.CustomerApplication,
'Initial Screening Performed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Initial Screening' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 3. Data & Documents Requested
SELECT
A.CustomerApplication,
'Data & Documents Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Initial Document Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 4. Documents Received
SELECT
A.CustomerApplication,
'Documents Received' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 5. Document Review Completed
SELECT
A.CustomerApplication,
'Document Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Document Verification' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 6. Background Checks Initiated
SELECT
A.CustomerApplication,
'Background Checks Initiated' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'EXTERNAL_CHECK_INITIATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 7. Risk Assessment Completed
SELECT
A.CustomerApplication,
'Risk Assessment Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Risk Assessment' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 8. Compliance Review Initiated
SELECT
A.CustomerApplication,
'Compliance Review Initiated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Compliance Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 9. Additional Information Requested
SELECT
A.CustomerApplication,
'Additional Information Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Additional Information Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 10. Compliance Review Completed
SELECT
A.CustomerApplication,
'Compliance Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Compliance Review' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 11. Application Approved
SELECT
A.CustomerApplication,
'Application Approved' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Approved'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 12. Application Rejected
SELECT
A.CustomerApplication,
'Application Rejected' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Rejected'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 13. Account Activated
SELECT
A.CustomerApplication,
'Account Activated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Active'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 14. Case Closed
SELECT
A.CustomerApplication,
'Case Closed' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Closed'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]' Prêt à commencer ?
Grâce à ce template de données, vous êtes sur la bonne voie pour identifier les inefficacités et optimiser votre processus d’onboarding client KYC dans Fenergo. Commencez dès aujourd’hui à améliorer vos opérations et la satisfaction de vos clients.
Optimisez l’onboarding client KYC et accélérez les approbations dès aujourd’hui
Rejoignez les entreprises qui réduisent la durée de leur onboarding à seulement 24 heures.
Aucune carte bancaire requise. Commencez en quelques minutes.