Votre modèle de données pour l’intégration des clients KYC
Votre modèle de données pour l’intégration des clients KYC
- Attributs recommandés à recueillir
- Activités clés à suivre
- Conseils 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 La demande client 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 client. Elle 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. En Process Mining, cet attribut est essentiel pour reconstituer le parcours complet de chaque demande. Il permet d’analyser les flux de processus, les temps de cycle, les variantes et les goulots d’étranglement pour chaque demande, afin de comprendre clairement le traitement des dossiers. Pourquoi est-ce important ? Il s’agit de l’ID de cas essentiel qui relie tous les événements associés et permet d’analyser le processus d’intégration client de bout en bout. Où trouver ces données Il s’agit généralement de la clé primaire de l’entité de gestion des dossiers ou de gestion du cycle de vie client dans le système central de 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 pour reconstituer le flux du processus et est indispensable à toute analyse temporelle. En 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 dossier. 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 est-ce important ? Cet horodatage est essentiel pour ordonner les événements chronologiquement et calculer toutes les métriques temporelles, comme les temps de cycle et les durées. Où trouver ces données Cette information figure dans les tables de piste d’audit, de journal d’événements ou d’historique du flux de travail de Fenergo, souvent sous les noms « 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 précise qui s’est produite à un moment donné du processus d’intégration. | ||
| Description Le nom de l’activité décrit une étape ou un jalon du parcours d’intégration client, par exemple « Vérification initiale effectuée » ou « Demande approuvée ». La succession de ces activités constitue la base de la cartographie du processus. L’analyse de cet attribut permet de visualiser le flux du processus, de repérer 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 est-ce important ? Cet attribut définit les étapes du processus. Il permet de créer une cartographie du processus et d’analyser son déroulement ainsi que ses variantes. Où trouver ces données Ces informations se trouvent généralement dans les tables de flux de travail ou de journal d’audit de Fenergo, associées aux changements d’état des dossiers ou à l’achèvement des tâches. Exemples Données et documents demandésContrôle de conformité lancéDemande 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 la dernière actualisation des données. Il renseigne sur leur fraîcheur et permet de savoir si les analyses sont à jour. Dans les Dashboards et les rapports, cette information indique aux utilisateurs l’ancienneté des données. Elle leur permet de savoir si l’analyse reflète les opérations en temps réel ou un état historique. Pourquoi est-ce important ? Cet attribut indique l’ancienneté des données et permet aux utilisateurs de savoir à quel point l’analyse du processus est à jour. Où trouver ces données 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énement. Pour ce processus, il s’agit toujours de Fenergo, mais dans des jeux de données combinés, il permet de distinguer les sources de données. Il sert principalement à filtrer les données provenant de systèmes précis ou à vérifier leur provenance. Il clarifie l’analyse lorsque des données issues de plusieurs systèmes sont réunies pour obtenir une vue globale du processus. Pourquoi est-ce important ? Cet attribut indique l’origine des données, un élément essentiel pour leur gouvernance et leur validation, ainsi que pour vérifier que l’analyse repose sur la bonne source. Où trouver ces données Il s’agit généralement d’une valeur fixe ajoutée lors de l’extraction des données pour indiquer l’origine des enregistrements. Exemples FenergoFenergo CLM | |||
| Date cible du SLA SlaTargetDate | Date à laquelle le dossier d’intégration du client doit être terminé. | ||
| Description La date cible du SLA correspond à l’échéance convenue pour terminer l’ensemble du processus d’intégration d’une demande client. Elle sert de référence pour mesurer les performances réelles. Cet attribut est essentiel au Dashboard « Suivi de la conformité aux SLA » et au calcul de l’indicateur clé de performance « Taux de respect des SLA ». Il permet de gérer de manière proactive les dossiers susceptibles de dépasser leur SLA et de prioriser le travail. Pourquoi est-ce important ? Cet attribut définit la date cible de fin du processus. Il est essentiel au suivi du respect des SLA et à la priorisation des dossiers en retard. Où trouver ces données 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 et permet de déterminer la durée effective d’une tâche. En Process Mining, l’heure de fin, associée à l’heure de début, sert à calculer la durée de traitement de chaque activité. Elle permet de repérer les étapes les plus longues et d’analyser l’efficacité des ressources. Pourquoi est-ce important ? Cet attribut permet de calculer la durée de traitement des activités, ce qui est essentiel pour repérer les tâches longues et les goulots d’étranglement. Où trouver ces données Cette information figure 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 déduite 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é pour le client. | ||
| Description Le score de risque mesure quantitativement le 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 vérifications. 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 déroulement du processus. L’analyse peut, par exemple, révéler si les clients à risque élevé ont des temps de cycle plus longs ou nécessitent davantage d’interventions manuelles. Ces informations sont utiles au Dashboard « Analyse approfondie des risques et de l’examen de conformité ». Pourquoi est-ce important ? Cet attribut quantifie le risque client et permet d’analyser l’incidence du niveau de risque sur la durée du processus, les reprises et les résultats. Où trouver ces données Il s’agit d’un résultat clé du module d’évaluation des risques client de Fenergo. Il est enregistré dans l’entité du dossier ou du client. Exemples 154585 | |||
| Service de l’utilisateur UserDepartment | Service ou unité opérationnelle auquel appartient l’utilisateur à l’origine de l’activité. | ||
| Description Cet attribut fournit le contexte organisationnel de l’utilisateur qui a réalisé une activité, par exemple « Conformité », « Opérations d’intégration » ou « Ventes ». Il est souvent déduit des informations du profil utilisateur. Cette dimension est essentielle pour analyser les transferts entre services et repérer les goulots d’étranglement transversaux. Elle alimente directement le Dashboard « Répartition des activités du personnel », qui permet de regrouper le travail par équipe ou par service. Pourquoi est-ce important ? Cet attribut permet d’analyser les performances du processus par service et de mettre en évidence les transferts entre services, les retards et la répartition de la charge de travail. Où trouver ces données Il peut être nécessaire de joindre ces informations à une table distincte de données de référence sur les utilisateurs ou les ressources humaines, à l’aide de l’identifiant « InitiatingUser ». Fenergo peut également les enregistrer 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 du client. | ||
| Description Cet attribut indique l’issue de la demande à la fin du processus, ou son état actuel si le traitement est en cours. Les valeurs courantes comprennent « Approuvé », « Rejeté » ou « En cours ». Cette dimension est essentielle à l’analyse des résultats. Elle permet de filtrer et de comparer les flux de processus selon leur issue finale, ce qui est indispensable au Dashboard « Reprises et rejets des demandes » et au calcul d’indicateurs clés de performance tels que le taux de rejet des demandes. Pourquoi est-ce important ? Cet attribut définit l’issue d’un dossier et permet de comparer les parcours des demandes approuvées et rejetées, ainsi que d’analyser les taux de réussite. Où trouver ces données Il s’agit généralement du statut final enregistré pour le dossier dans le système de gestion des dossiers de Fenergo. Exemples ApprouvéRejetéConformité en attenteClôturé | |||
| Utilisateur à l’origine de l’activité InitiatingUser | Identifiant ou nom de l’utilisateur qui a réalisé l’activité. | ||
| Description Cet attribut identifie l’employé 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 unique, d’un nom ou d’un rôle. L’analyse par utilisateur permet de comprendre la répartition de la charge de travail et les performances individuelles, ainsi que de repérer les besoins de formation. Elle est essentielle au Dashboard « Répartition des activités du personnel » et permet d’examiner les activités réalisées par des personnes ou des équipes précises. Pourquoi est-ce important ? Cet attribut indique quel utilisateur a effectué une action et permet d’analyser la répartition de la charge de travail, les performances des équipes et l’affectation des ressources. Où trouver ces données Ces informations sont généralement enregistrées dans les journaux d’audit ou les tables d’historique des tâches de Fenergo, avec les détails de l’événement, sous des noms tels que « UserID », « UserName » ou « ModifiedBy ». Exemples j.doea.smithSYSTÈME | |||
| Automatisé IsAutomated | Indicateur booléen précisant si l’activité a été réalisée par un système plutôt que par un utilisateur. | ||
| Description Cet attribut distingue les tâches exécutées automatiquement par le système, comme les vérifications initiales et les contrôles système, de celles réalisées manuellement par un utilisateur. Cette distinction repose souvent sur la vérification du compte utilisateur ayant exécuté la tâche, qui peut être un compte système ou de service. L’analyse de cet indicateur est essentielle pour comprendre le degré d’automatisation du processus. Elle permet de mesurer l’incidence de l’automatisation sur l’efficacité, les coûts et la rapidité, ainsi que de repérer les possibilités d’automatisation supplémentaires. Pourquoi est-ce important ? Cet attribut distingue les activités réalisées par une personne de celles exécutées par un système. Il est essentiel à l’analyse de l’automatisation et à l’évaluation des coûts liés aux ressources. Où trouver ces données Cet attribut est généralement déduit du champ « InitiatingUser ». Une liste d’identifiants connus de comptes système permet de définir cet indicateur sur « vrai ». Exemples truefalse | |||
| Canal de soumission de la demande ApplicationChannel | Canal par lequel la demande du client a été soumise. | ||
| Description Cet attribut indique la source de la demande, par exemple un portail en ligne, une agence ou un chargé de clientèle. La source peut influer sur la qualité des données et les exigences de traitement. Cette dimension sert au Dashboard « Efficacité selon la source et le type de demande » pour comparer les performances des différents canaux. Elle aide les entreprises à déterminer quels canaux sont les plus efficaces et lesquels pourraient nécessiter une optimisation du processus. Pourquoi est-ce important ? Cet attribut indique la source des demandes et permet d’analyser l’efficacité des canaux, les coûts et l’expérience client. Où trouver ces données Ces informations peuvent être saisies dans un formulaire initial de Fenergo ou transmises par un système en amont. Exemples Portail en ligneAgenceChargé de clientèleApplication mobile | |||
| Conforme au SLA IsSlaCompliant | Indicateur booléen précisant si le dossier a été terminé au plus tard à la date cible du SLA. | ||
| Description Cet attribut indique de manière binaire la performance par rapport au SLA pour un dossier terminé. Il prend la valeur « vrai » si l’horodatage de l’activité finale de clôture est antérieur ou égal à la « SlaTargetDate », et « faux » dans le cas contraire. Ce champ calculé simplifie le suivi et le reporting des SLA. Il permet de calculer facilement l’indicateur clé de performance « Taux de respect des SLA » par agrégation et de filtrer les dossiers conformes ou non afin d’en analyser les caractéristiques. Pourquoi est-ce important ? Cet attribut mesure directement la performance par rapport aux SLA. Il facilite le calcul du taux de respect des SLA et le filtrage des dossiers non conformes. Où trouver ces données Cet attribut est calculé en comparant l’horodatage de la dernière activité du dossier, par exemple « Demande approuvée » ou « Demande rejetée », à la « SlaTargetDate ». Exemples truefalse | |||
| Identifiant client CustomerId | Identifiant unique du client ou de l’entité juridique en cours d’intégration. | ||
| Description L’identifiant client est la référence unique de l’entité client dans le système de données de référence. Le numéro de demande sert d’ID de cas pour le processus, tandis que l’identifiant client relie les activités d’intégration à un client précis. Cet attribut permet d’analyser l’historique d’intégration d’un même client, par exemple s’il a suivi plusieurs processus d’intégration au fil du temps. Il permet également de joindre les données du processus à d’autres données client pour obtenir une vue métier plus complète. Pourquoi est-ce important ? Cet attribut relie le processus d’intégration à une entité client unique et permet une analyse centrée sur le client ainsi que l’enrichissement des données. Où trouver ces données Cet identifiant est enregistré dans la fiche du client ou de l’entité juridique de Fenergo et associé au dossier d’intégration. Exemples CUST-98765CUST-98766CUST-98767 | |||
| Motif du rejet RejectionReason | Code ou description expliquant le rejet d’une demande. | ||
| Description Lorsque le statut final d’une demande est « Rejeté », cet attribut en précise le motif. Il peut s’agir, par exemple, d’une vérification des antécédents non concluante, de documents incomplets ou d’un profil de risque élevé. Cet attribut est essentiel à l’analyse des causes profondes des échecs. Il alimente directement le Dashboard « Reprises et rejets des demandes » en catégorisant les échecs. L’entreprise peut ainsi repérer les problèmes récurrents et mettre en place des mesures correctives pour augmenter le taux de réussite dès la première tentative. Pourquoi est-ce important ? Cet attribut aide à comprendre les raisons de l’échec des demandes et à en analyser les causes profondes afin de réduire les rejets. Où trouver ces données Cette information figure généralement dans un champ de code de motif ou de notes associé au statut final de rejet dans le flux de travail des dossiers Fenergo. Exemples Correspondance avec une liste de sanctionsDocuments non validesViolation des règlesRetrait de la demande par le client | |||
| Nombre de demandes d’informations complémentaires AdditionalInfoRequestCount | Nombre total de demandes d’informations complémentaires pour une demande. | ||
| Description Cette métrique compte, pour chaque dossier, les occurrences de l’activité « Informations complémentaires demandées ». Un nombre élevé indique davantage d’allers-retours, ce qui peut retarder le processus et nuire à l’expérience client. Cet attribut alimente directement l’indicateur clé de performance « Dossiers avec demandes d’informations complémentaires ». Il permet de repérer les demandes faisant l’objet de sollicitations excessives, ce qui peut révéler des problèmes de collecte initiale des données ou des exigences complexes. L’analyse de ces cas aide à simplifier la collecte des informations. Pourquoi est-ce important ? Cet attribut quantifie les difficultés rencontrées par les clients et les retards causés par des informations initiales incomplètes, afin d’améliorer l’étape de collecte des données. Où trouver ces données Il s’agit d’une métrique calculée en comptant, pour chaque ID « CustomerApplication », le nombre d’événements « Informations complémentaires demandées ». Exemples 013 | |||
| Pays Country | Pays de résidence ou juridiction associé à la demande du client. | ||
| Description Cet attribut indique 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 temps 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 les performances opérationnelles et à vérifier le respect des réglementations locales. Pourquoi est-ce important ? Cet attribut permet de segmenter le processus par zone géographique, ce qui est essentiel pour analyser l’incidence des réglementations et les performances régionales. Où trouver ces données Ces informations font partie des données client de référence recueillies lors de la demande et sont enregistrées dans l’entité client de Fenergo. Exemples USAGBRSGPDEU | |||
| Reprise IsRework | Indicateur booléen précisant si une activité fait partie d’une boucle de reprise. | ||
| Description Cet attribut repère les activités qui correspondent à un retour en arrière dans le processus, par exemple lorsque le dossier revient à l’examen des documents après le début de l’examen de conformité, ou lorsqu’une demande d’informations complémentaires est enregistrée. Repérer les reprises est essentiel pour comprendre les inefficacités et les difficultés du processus. Cet indicateur permet de calculer directement le taux de boucles de reprise et de visualiser et quantifier l’incidence des étapes répétitives sans valeur ajoutée dans le flux du processus. Pourquoi est-ce important ? Cet attribut met en évidence les boucles de reprise inefficaces, aide à en mesurer le coût et permet de repérer les améliorations susceptibles d’augmenter le taux de réussite dès la première tentative. Où trouver ces données Cet indicateur est calculé à l’aide de techniques de Process Mining qui analysent la séquence des activités. Par exemple, si l’activité A est suivie de l’activité B, puis que l’activité A apparaît de nouveau pour le même dossier, cette seconde occurrence de l’activité A constitue une reprise. Exemples truefalse | |||
| Responsable du dossier CaseOwner | Utilisateur ou équipe principalement chargé de gérer la demande tout au long de son cycle de vie. | ||
| Description Le responsable du dossier est la personne ou le groupe auquel incombe la responsabilité principale d’un dossier d’intégration. Cette personne ou cette équipe veille généralement à ce que le dossier soit traité dans les délais et mené à bien. Cet attribut permet d’analyser la charge de travail et les performances au niveau des gestionnaires de dossiers. Il peut révéler si certains responsables ont des temps de cycle plus longs ou des taux de rejet plus élevés, ce qui peut signaler des besoins de formation ou un déséquilibre des ressources. Pourquoi est-ce important ? Cet attribut identifie la personne ou l’équipe responsable d’un dossier et permet d’analyser les performances des gestionnaires de dossiers. Où trouver ces données Il s’agit généralement d’un champ spécifique de l’entité principale du dossier dans Fenergo, qui indique à qui le dossier est attribué. Exemples s.jonesequipe_integration_am.chen | |||
| Type de client CustomerType | Catégorie du client en cours d’intégration, par exemple une personne physique, une entreprise ou une fiducie. | ||
| Description Cet attribut répartit les clients en 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 raisonnable variables. L’analyse du processus par type de client permet de repérer les différences de performance entre les segments. Elle est essentielle au Dashboard « Efficacité selon la source et le type de demande », qui compare les temps de cycle et les taux d’approbation afin d’orienter les améliorations du processus. Pourquoi est-ce important ? Cet attribut permet de comparer les performances du processus entre différents segments de clientèle, dont la complexité et les SLA peuvent varier. Où trouver ces données Ces informations sont généralement enregistrées dans l’entité client de Fenergo et associées au dossier de demande. Exemples Personne physiqueEntrepriseFiducieSociété de personnes | |||
Activités liées à l’intégration des clients KYC
| Activité | Description | ||
|---|---|---|---|
| Cas créé | Cette activité marque le début du processus d’intégration KYC, lorsque la demande d’un nouveau client est officiellement créée dans Fenergo. Il s’agit généralement d’un événement explicite, horodaté au premier enregistrement du dossier. | ||
| Pourquoi est-ce important ? En tant qu’événement de début, cette activité est essentielle pour calculer le temps de cycle global de l’intégration et analyser le débit. Elle sert de référence pour toutes les mesures ultérieures du processus et le suivi des SLA. Où trouver ces données Cette activité est généralement identifiée à partir de l’horodatage de création du dossier principal dans Fenergo, souvent dans les tables liées aux dossiers ou aux flux de travail d’intégration des clients. Données à recueillir Utilisez l’horodatage de création du dossier d’intégration. Type d’événement explicit | |||
| Contrôle de conformité lancé | Cette activité marque le début du contrôle par le service conformité, une étape essentielle qui peut prendre du temps. Elle est déduite de l’affectation du dossier à la file de traitement de la conformité ou du passage au statut « En attente du contrôle de conformité ». | ||
| Pourquoi est-ce important ? Cette activité sert de point de départ au calcul du KPI « Durée moyenne du contrôle de conformité ». Elle permet de déterminer combien de temps les dossiers attendent avant d’être pris en charge par l’équipe conformité. Où trouver ces données Cette activité est déduite du journal d’audit du dossier Fenergo, à partir de l’horodatage du passage au statut « Contrôle de conformité en cours » ou de l’affectation du dossier à un responsable ou à une équipe de conformité. Données à recueillir Repérez l’horodatage du passage au statut « En cours de contrôle de conformité » ou l’événement d’affectation. Type d’événement inferred | |||
| Contrôle de conformité terminé | Cette activité marque la validation officielle du service conformité et confirme que toutes les exigences réglementaires ont été respectées. Elle est déduite de l’achèvement d’une tâche ou du passage au statut « Conformité approuvée ». | ||
| Pourquoi est-ce important ? Cette étape majeure est essentielle au calcul du temps de cycle global. Elle marque la fin de la période utilisée pour calculer la « Durée moyenne du contrôle de conformité » et repérer les goulots d’étranglement au sein de la fonction conformité. Où trouver ces données Cette activité est déduite de l’horodatage d’achèvement de la tâche « Contrôle de conformité » dans le flux de travail Fenergo, ou de l’événement de changement de statut dans l’historique du dossier. Données à recueillir Utilisez l’horodatage d’achèvement de la tâche de contrôle de conformité ou celui du changement de statut. Type d’événement inferred | |||
| Demande approuvée | Cette activité correspond à la décision finale d’approuver la demande d’intégration du client. Elle est déduite du passage du dossier à un statut final comme « Approuvé » ou « Intégration approuvée ». | ||
| Pourquoi est-ce important ? Cette étape importante marque la réussite du processus avant les dernières étapes d’activation du compte. Elle est essentielle au calcul des taux d’approbation et à l’analyse des caractéristiques des clients intégrés avec succès. Où trouver ces données Cette activité est déduite de l’historique ou du journal d’audit du dossier en repérant l’horodatage du passage au statut final « Approuvé » ou à un statut positif équivalent. Données à recueillir Repérez l’horodatage du passage au statut final « Approuvé ». Type d’événement inferred | |||
| Demande rejetée | Cet événement de fin correspond à la décision définitive de rejeter la demande du client. Il est déduit du passage du dossier à un statut final comme « Rejeté » ou « Refusé ». | ||
| Pourquoi est-ce important ? En tant qu’étape finale du processus, cette activité est essentielle au calcul du « Taux de rejet des demandes » et à l’analyse des motifs d’échec. Elle permet de repérer les causes fréquentes de rejet et d’améliorer la qualité des demandes. Où trouver ces données Cette activité est déduite du journal d’audit du dossier en repérant l’horodatage du passage au statut final « Rejeté ». Le motif du rejet est souvent enregistré dans un champ associé. Données à recueillir Repérez l’horodatage du passage au statut final « Rejeté ». 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é sur le plan administratif dans Fenergo et qu’aucune autre action n’est attendue. Cela concerne aussi bien les demandes approuvées que les demandes rejetées et se déduit d’un statut final « Clôturé ». | ||
| Pourquoi est-ce important ? Cette activité marque la fin définitive de l’ensemble du processus. Elle permet de calculer correctement le temps de cycle de tous les dossiers, quel que soit leur résultat, et confirme que le processus est terminé. Où trouver ces données Cette étape est déduite du journal d’audit des dossiers Fenergo en repérant l’horodatage auquel le statut du dossier passe à « Clôturé », « Terminé » ou à un autre état final. Données à recueillir Repérez l’horodatage de la dernière modification du statut, qui passe à « Clôturé » ou « Terminé ». Type d’événement inferred | |||
| Évaluation des risques terminée | Cette activité correspond à la fin du processus interne de classification des risques, au cours duquel un niveau de risque est attribué au client selon différents critères. Elle est déduite d’un changement de statut ou du renseignement d’un champ relatif au niveau de risque. | ||
| Pourquoi est-ce important ? Cette étape importante de prise de décision détermine souvent la suite du flux de travail. L’analyse de sa durée permet de simplifier une étape essentielle de conformité et de garantir une évaluation cohérente des risques. Où trouver ces données Cette activité est déduite de l’historique du dossier en repérant le passage à un statut comme « Risque évalué », ou le moment où le champ final « Niveau de risque du client » est renseigné. Données à recueillir Utilisez l’horodatage auquel le niveau de risque est finalisé ou le statut associé est défini. Type d’événement inferred | |||
| Vérification des documents terminée | Cette activité indique que la vérification manuelle ou automatisée de l’authenticité et de l’exactitude de tous les documents transmis par le client est terminée. Elle est généralement déduite de l’achèvement d’une tâche du flux de travail ou d’un changement de statut dans Fenergo. | ||
| Pourquoi est-ce important ? Cette étape importante est souvent source de retards. L’analyse de sa durée et de ses résultats permet de repérer les goulots d’étranglement dans le traitement des documents et de suivre des KPI comme le taux de réussite dès la première soumission. Où trouver ces données Cette activité est déduite de l’horodatage d’achèvement de la tâche « Vérification des documents » dans le flux de travail du dossier, ou du passage au statut « Documents approuvés » dans l’historique du dossier. Données à recueillir Utilisez l’horodatage d’achèvement de la tâche de vérification des documents ou celui d’un changement de statut associé. Type d’événement inferred | |||
| Compte activé | Indique que le compte du client a été créé et activé avec succès dans le système bancaire central ou le système aval concerné après approbation. Cette étape peut être déduite d’une mise à jour du statut dans Fenergo après l’approbation. | ||
| Pourquoi est-ce 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 permet de repérer les retards liés à la mise en place opérationnelle. Où trouver ces données Cette étape peut être déduite d’un statut de dossier tel que « Compte actif » ou « Intégration terminée ». Elle peut également correspondre à un événement explicite enregistré par une intégration avec un système aval. Données à recueillir Recherchez une modification du statut après l’approbation ou un événement consignant la réussite de l’intégration. Type d’événement inferred | |||
| Contrôles d’antécédents lancés | Cette activité marque le lancement des contrôles externes d’antécédents, de lutte contre le blanchiment d’argent ou de solvabilité. Elle est souvent enregistrée explicitement lors de l’appel à un service tiers par une intégration. | ||
| Pourquoi est-ce important ? Le suivi du lancement et de l’achèvement de ces contrôles est essentiel pour comprendre les retards dus à des dépendances externes. Il permet de distinguer le temps de traitement interne du temps d’attente auprès de tiers. Où trouver ces données Cette activité est généralement repérée dans les journaux système qui enregistrent les appels d’API aux prestataires externes de vérification, ou lors de la création d’une tâche « Contrôle des antécédents » dans le dossier Fenergo. Données à recueillir Recherchez les journaux des intégrations avec des services externes ou la création d’une tâche « Vérification ». Type d’événement explicit | |||
| Documents reçus | Cette activité indique que le client a importé ou transmis les documents requis, désormais disponibles dans Fenergo pour vérification. Elle est généralement déduite du passage au statut « Documents reçus » ou « En attente de vérification ». | ||
| Pourquoi est-ce important ? Cette étape marque la fin de l’attente du client et le début du cycle de vérification interne. Elle est essentielle pour mesurer le délai de réponse du client et le temps d’attente dans la file de traitement interne. Où trouver ces données Cette activité est déduite de la piste d’audit du dossier, qui enregistre l’horodatage du passage au statut « Documents reçus » ou à un statut équivalent. Elle peut également être associée aux événements d’importation de documents. Données à recueillir Repérez l’horodatage du passage au statut « Documents reçus » ou « Prêt pour vérification ». Type d’événement inferred | |||
| Données et documents demandés | Cet événement indique que le système ou un agent chargé de l’intégration a officiellement demandé au client les informations et documents nécessaires. Il est souvent enregistré explicitement lors de l’envoi d’un modèle de communication standardisé. | ||
| Pourquoi est-ce important ? Cette activité marque le début d’une étape qui dépend du client. Mesurer le délai entre cette demande et la réception des documents est essentiel pour analyser le parcours client et repérer les retards de communication. Où trouver ces données Cette activité est repérée dans un journal d’événements associé aux communications avec les clients ou dans le journal d’achèvement d’une tâche « Demander des documents ». Elle peut également être déduite du passage au statut « En attente d’informations du client ». Données à recueillir Recherchez un événement de communication avec le client ou l’achèvement d’une tâche dans le journal. Type d’événement explicit | |||
| Informations complémentaires demandées | Cette activité correspond à une boucle de reprise : l’équipe chargée de l’intégration doit recontacter le client pour obtenir des précisions ou les documents manquants. Il s’agit d’un événement explicite, généralement enregistré lors de l’envoi d’une communication au client. | ||
| Pourquoi est-ce important ? Cette activité est un indicateur majeur d’inefficacité du processus et d’expérience client insatisfaisante. Le suivi de sa fréquence permet de repérer les causes des reprises et de calculer le KPI « Taux de boucles de reprise ». Où trouver ces données Cette activité est repérée dans le journal des communications avec les clients ou lors du passage au statut « En attente d’informations complémentaires ». Le journal des communications permet de déterminer plus précisément le moment de la demande. Données à recueillir Recherchez les événements de communication enregistrés ou le passage au statut « En attente d’une réponse du client ». Type d’événement explicit | |||
| Vérification initiale effectuée | Cette activité correspond à la fin des contrôles préliminaires, automatisés ou manuels, comme la validation des données de base ou la vérification des listes de sanctions. Elle est souvent déduite d’un changement de statut dans le flux de travail du dossier Fenergo, par exemple lorsque le statut passe de « Nouveau » à « Vérification terminée ». | ||
| Pourquoi est-ce important ? Le suivi de cette première étape permet de repérer les problèmes de qualité des données et les goulots d’étranglement lors de la préqualification. Il distingue la phase initiale automatisée des contrôles manuels plus approfondis. Où trouver ces données Cette activité est déduite de l’historique du dossier ou du journal d’audit en repérant l’horodatage du passage à un statut indiquant que la vérification est terminée, comme « Vérification réussie » ou « En attente de documents ». Données à recueillir Repérez dans l’historique du dossier le passage au statut « Vérification terminée » ou à un statut équivalent. Type d’événement inferred | |||
Guides d’extraction
Étapes
- Accédez au module de reporting : Connectez-vous à l’application Fenergo avec un compte utilisateur disposant des autorisations nécessaires pour le module Reporting & Analytics. Ouvrez le module, généralement accessible depuis 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 en précisent clairement l’objectif, par exemple « Journal d’événements d’intégration KYC pour le Process Mining ».
- Définissez la source de données principale : Sélectionnez l’objet de données ou la vue qui contient les informations sur le 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 et leurs horodatages. - Configurez les colonnes du rapport (attributs) : Dans l’interface de création de rapports, ajoutez des colonnes. Associez les champs du modèle de données Fenergo aux attributs requis pour le journal d’événements. Par exemple, associez
CaseIDàCustomerApplication,EventTimestampàEventStartTimeetEventPerformeràInitiatingUser. - Définissez la logique des activités : Cette étape est la plus importante. Configurez le rapport pour qu’il génère 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 équivalente dans le générateur de rapports.
- Définissez la logique de création du cas : Créez le premier bloc. Filtrez la source de données pour isoler l’événement initial de création du cas. Celui-ci est souvent déterminé par l’horodatage le plus ancien associé au cas ou par 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, comme « Documents Received » ou « Application Approved », créez des blocs distincts. Filtrez la source de données selon la valeur du champ
Étatconcerné et 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, comme « Compliance Review Completed », créez des blocs filtrés sur
TaskNameetTaskCompletionDate. Utilisez la date d’achèvement commeEventStartTime. - Définissez les filtres généraux du rapport : Appliquez des filtres à l’échelle du rapport pour délimiter les données. Définissez une
Date Rangeprécise pourEventStartTimeafin d’éviter les exports trop volumineux. Pour une première analyse, une période de 3 à 6 mois est recommandée. Filtrez également selon le type de cas concerné, par exemple « KYC Customer Onboarding ». - Exécutez le rapport et vérifiez l’aperçu : Lancez le rapport dans l’interface Fenergo. Examinez les 100 à 200 premières lignes pour vérifier la structure des données, le remplissage des colonnes et la présence des différentes activités.
- Exportez les données : Exportez l’ensemble des résultats du rapport dans un fichier CSV ou Excel. Vous obtenez ainsi le journal d’événements brut.
- Préparez les données : Ouvrez le fichier CSV exporté. Si le rapport n’a pas pu générer directement les colonnes
SourceSystemetLastDataUpdate, ajoutez-les manuellement. Attribuez la valeur « Fenergo » àSourceSystempour toutes les lignes et indiquez l’horodatage de l’export dansLastDataUpdate.
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 Fenergo de gestion des cas et d’historique des flux de travail. Parmi les sources courantes figurent
[CaseDetails],[CaseStatusHistory]et[WorkflowTaskHistory]. Leur nom exact peut varier selon la configuration de 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 clés : Filtrez toujours selon le processus ou le type de cas concerné, par exemple « KYC Customer Onboarding », afin d’exclure les données non pertinentes. Selon vos objectifs d’analyse, vous devrez peut-être aussi filtrer par type d’entité juridique ou par juridiction.
- Définition des activités : Définissez chaque activité à l’aide de critères de filtrage précis portant sur des champs tels que
État,TaskNameou un champEventTypedédié. Ces champs permettent d’isoler chaque événement du processus. - 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’export, car elles augmentent le temps de traitement.
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 ?
Ce modèle de données vous aidera à repérer les inefficacités et à optimiser le processus d’intégration des clients KYC dans Fenergo. Commencez dès aujourd’hui à améliorer vos opérations et la satisfaction de vos clients.
Optimisez l’intégration des clients KYC et accélérez les approbations dès aujourd’hui
Rejoignez les entreprises qui réduisent la durée d’intégration à seulement 24 heures.
Aucune carte bancaire requise. Commencez en quelques minutes.