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 à collecter
- Activités essentielles à suivre
- Conseils d’extraction pour ACTICO
Attributs de l’intégration des clients KYC
| Nom | Description | ||
|---|---|---|---|
| Demande client CustomerApplication | Identifiant unique d’une demande d’intégration client, utilisé comme identifiant de dossier pour l’analyse du processus. | ||
| Description La demande client est l’identifiant principal du dossier qui regroupe tous les événements et activités liés au parcours d’intégration d’un même client. Elle représente une instance complète du processus KYC, depuis la soumission initiale jusqu’à la décision finale d’approbation ou de rejet. Dans le Process Mining, cet attribut est essentiel pour reconstituer le parcours de bout en bout de chaque demande. Il permet aux analystes de suivre la séquence des activités, de mesurer les durées totales de cycle et de comparer les différents parcours, ou variantes, suivis par les demandes. Tous les événements partageant le même identifiant de demande client sont considérés comme appartenant au même dossier. Pourquoi c’est important Il s’agit de l’attribut fondamental du Process Mining, car il relie tous les événements associés au sein d’une même instance de processus et permet d’analyser de bout en bout l’expérience d’intégration de chaque client. Où les obtenir Il s’agit d’une clé primaire dans les principales tables de demandes ou de gestion des dossiers d’ACTICO. Consultez la documentation ACTICO pour connaître les noms précis des tables et des champs. Exemples APP-2023-001234APP-2023-001235APP-2024-000001 | |||
| Heure de l’événement EventTime | Horodatage indiquant le moment où une activité spécifique a commencé ou s’est produite. | ||
| Description L’heure de l’événement correspond à la date et à l’heure précises auxquelles une activité a été enregistrée dans le système. Elle définit l’ordre chronologique de tous les événements d’un même dossier de demande client et forme la chronologie du parcours d’intégration. Cet attribut est essentiel pour toutes les analyses temporelles. Il sert à calculer les durées de cycle entre les activités, à identifier les retards et les temps d’attente, à mesurer la durée globale des dossiers et à vérifier le respect des Service Level Agreements (SLA). La séquence de ces horodatages pour un dossier donné permet aux outils de Process Mining de reconstituer le flux exact du processus tel qu’il s’est déroulé. Pourquoi c’est important Cet attribut indique l’ordre chronologique des événements. Il est essentiel pour calculer les durées, découvrir les goulots d’étranglement et analyser la chronologie du processus. Où les obtenir Cet horodatage associé à chaque activité enregistrée se trouve dans les tables de journaux d’événements d’ACTICO. Consultez la documentation ACTICO. Exemples 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T15:45:10Z | |||
| Nom de l’activité ActivityName | Nom de l’événement métier ou de la tâche spécifique exécutée dans le cadre du processus d’intégration client. | ||
| Description Cet attribut enregistre le nom de chaque étape ou activité exécutée pendant le processus KYC, par exemple « Application Submitted », « Risk Assessment Performed » ou « Application Approved ». Il fournit les éléments successifs nécessaires à la construction de la carte du processus. L’analyse de l’Activité permet de visualiser le flux du processus, d’identifier les activités fréquentes ou rares et de détecter les goulots d’étranglement ou les boucles de reprise. Elle constitue un élément fondamental pour comprendre quelles actions sont exécutées et dans quel ordre, ce qui est essentiel à l’analyse des variantes et aux contrôles de conformité. Pourquoi c’est important Il définit les étapes de la cartographie du processus, permettant de visualiser le flux, d’identifier les écarts et d’analyser la fréquence et la séquence des activités. Où les obtenir Ces informations se trouvent généralement dans une table de journal d’événements d’ACTICO, souvent dans un champ décrivant le type d’événement ou de tâche. Consultez la documentation ACTICO. Exemples Demande soumiseÉvaluation du risque effectuéeContrôle de conformité terminéDemande rejetée | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage indiquant la dernière actualisation ou extraction des données depuis le système source. | ||
| Description Cet attribut enregistre la date et l’heure de la dernière extraction de données depuis ACTICO. Il s’agit d’un champ de métadonnées qui s’applique à l’ensemble du jeu de données, et non aux événements individuels, et qui fournit des informations sur l’actualité de l’analyse. Dans les Dashboards et les rapports, cette information est essentielle pour permettre aux utilisateurs de savoir à quel point les données sont récentes. Elle aide à définir les attentes concernant l’actualité des analyses et joue un rôle important dans le suivi opérationnel lorsque des données quasi en temps réel sont nécessaires. L’affichage de cet horodatage renforce la transparence et la confiance dans les données présentées. Pourquoi c’est important Indique l’actualité des données et permet aux utilisateurs de savoir s’ils analysent des informations à jour, ce qui est essentiel pour la prise de décision opérationnelle. Où les obtenir Cette valeur est générée et enregistrée lors du processus d’extraction, de transformation et de chargement (ETL) des données. Elle correspond à l’horodatage de la fin réussie du traitement ETL. Exemples 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| Système source SourceSystem | Système de référence à l’origine des données d’événements. | ||
| Description Cet attribut identifie le système d’information source dans lequel les données ont été générées. Pour ce processus, sa valeur sera toujours « ACTICO », mais dans les analyses portant sur plusieurs systèmes, il permet de distinguer l’origine des données. Dans le contexte du Process Mining, il est essentiel à la gouvernance et à la validation des données. Il garantit que les données sont correctement attribuées à leur source, ce qui est important lors de la fusion de données provenant de différents systèmes afin d’obtenir une vue globale du processus. Il facilite également le diagnostic des problèmes de qualité des données en permettant de remonter jusqu’au système d’origine. Pourquoi c’est important Fournit le contexte essentiel sur l’origine des données et garantit leur traçabilité ainsi que leur gouvernance, ce qui est important lors de la combinaison de plusieurs sources. Où les obtenir Il s’agit généralement d’une valeur statique (« ACTICO ») ajoutée lors de l’extraction et de la transformation des données pour identifier le jeu de données. Exemples ACTICOACTICO PlatformActico KYC Module | |||
| Date cible de l’accord de niveau de service SlaTargetDate | Date à laquelle le processus d’intégration du client doit être terminé. | ||
| Description La date cible de l’accord de niveau de service correspond à l’échéance fixée pour terminer l’intégration d’un client, conformément aux accords de niveau de service internes. Elle est souvent calculée à partir de la date de soumission de la demande, à laquelle s’ajoute un délai de traitement standard. Cet attribut est essentiel au suivi du respect des accords de niveau de service. En comparant la date réelle de clôture d’un dossier à sa date cible, le système peut déterminer si le dossier a été traité dans les délais ou si l’accord de niveau de service n’a pas été respecté. Il constitue la base du Dashboard « Performance des accords de niveau de service de l’intégration » et du KPI « Taux de respect des accords de niveau de service de l’intégration ». Pourquoi c’est important Fournit la référence nécessaire pour mesurer la performance dans les délais et suivre directement le respect des accords de niveau de service. Où les obtenir Cette information peut être enregistrée dans un champ de la table principale des dossiers d’ACTICO ou être calculée à partir de règles métier, par exemple : date de soumission + 5 jours ouvrés. Exemples 2023-11-01T17:00:00Z2023-11-02T17:00:00Z2023-11-03T17:00:00Z | |||
| Heure de fin EndTime | Horodatage indiquant le moment où une activité spécifique a été terminée. | ||
| Description L’heure de fin marque l’achèvement d’une activité. Associée à l’heure de début (EventTime), elle permet de calculer la durée précise de chaque tâche, appelée temps de traitement. Tous les événements ne disposent pas d’une heure de fin distincte, car certains sont instantanés. Cet attribut est fondamental pour l’analyse de la performance, notamment pour mesurer la durée de chaque étape. Il permet de créer des Dashboards détaillés sur la performance, d’identifier les activités qui consomment le plus de temps et de calculer des KPI tels que « Average Document Review Time ». Pourquoi c’est important Permet de calculer précisément la durée des activités, c’est-à-dire le temps de traitement, ce qui est essentiel pour repérer les goulots d’étranglement et analyser l’efficacité des ressources. Où les obtenir Comme l’heure de début, cette information se trouve généralement dans les tables de journaux d’événements d’ACTICO. Certains systèmes stockent les heures de début et de fin dans des colonnes distinctes d’un même enregistrement d’événement. Consultez la documentation ACTICO. Exemples 2023-10-26T10:15:00Z2023-10-26T12:00:00Z2023-10-27T16:00:15Z | |||
| Motif du rejet RejectionReason | Motif précis fourni lorsqu’une demande client est rejetée. | ||
| Description Lorsque le statut final d’une demande est « Rejected », cet attribut en indique la cause sous-jacente. Les exemples incluent « Incomplete Documentation », « Failed Background Check » ou « High Risk Profile ». Cet attribut est essentiel à l’analyse des causes profondes. En analysant la fréquence des différents motifs de rejet, l’entreprise peut identifier les problèmes systémiques du processus ou des demandes clients. Par exemple, un nombre élevé de rejets dus à des documents incomplets peut indiquer que les instructions de demande ne sont pas suffisamment claires. Il contribue directement au Dashboard « Application Rejection Rate and Reasons ». Pourquoi c’est important Explique les raisons des rejets de demandes et permet d’analyser les causes profondes afin de réduire le taux de rejet et d’améliorer l’efficacité du processus. Où les obtenir Se trouve généralement dans la table principale des dossiers ou des demandes d’ACTICO et n’est souvent renseigné que lorsque le statut de la demande est « Rejected ». Exemples Documentation incomplèteÉchec de la vérification d'identitéCorrespondance avec une liste de sanctionsScore de risque élevé | |||
| Niveau de risque RiskLevel | Niveau de risque calculé pour la demande client, par exemple faible, moyen ou élevé. | ||
| Description Cet attribut représente la catégorie de risque évaluée d’un client, qui détermine souvent la complexité et le niveau d’exigence du processus KYC qui suit. Un client présentant un risque élevé peut nécessiter des contrôles et des validations supplémentaires par rapport à un client à faible risque. Dans le Process Mining, le niveau de risque constitue une dimension particulièrement utile pour l’analyse comparative. Il permet aux analystes de vérifier que le processus suit correctement des parcours différents selon le niveau de risque, comme prévu. Il est par exemple possible de vérifier que tous les clients à haut risque font l’objet d’un contrôle renforcé. Cet attribut est essentiel au Dashboard « Flux du processus d’évaluation des risques ». Pourquoi c’est important Permet de segmenter les dossiers selon le niveau de risque et d’analyser si le processus s’adapte correctement aux différents profils de risque, conformément aux politiques de conformité. Où les obtenir Il s’agit d’une donnée essentielle enregistrée au niveau du dossier dans la table principale de l’application ACTICO. Exemples FaibleMoyenÉlevé | |||
| Service Department | Service ou équipe métier responsable de l’exécution de l’activité. | ||
| Description Cet attribut associe une activité à une unité organisationnelle précise, comme « Compliance », « Onboarding Team » ou « Client Relations ». Il fournit le contexte organisationnel du flux du processus. L’analyse par service est essentielle pour comprendre comment le travail est transmis entre les différentes composantes de l’organisation. Elle aide à repérer les goulots d’étranglement entre services, à mesurer l’efficacité de chaque service et à analyser l’affectation des ressources entre les équipes. Les Dashboards peuvent être filtrés par service afin de donner aux responsables une vue des performances propres à leur équipe. Pourquoi c’est important Fournit une dimension organisationnelle à l’analyse et permet d’identifier les retards entre services ainsi que d’évaluer la performance au niveau des équipes. Où les obtenir Ces informations peuvent être stockées directement avec les données d’événements ou obtenues en reliant les données utilisateurs à une table de référence RH qui associe les utilisateurs à leurs services. Consultez la documentation ACTICO. Exemples ComplianceÉquipe d'intégrationService client | |||
| Statut de la demande ApplicationStatus | Résultat final ou état actuel de la demande d’intégration client. | ||
| Description Cet attribut indique l’issue finale d’un dossier, généralement « Approved » ou « Rejected ». Il peut également indiquer le statut des dossiers en cours. Il s’agit d’une dimension essentielle pour l’analyse des résultats. Comprendre pourquoi les demandes sont approuvées ou rejetées est un objectif majeur du Process Mining appliqué aux processus KYC. Cet attribut permet de filtrer la cartographie du processus afin d’observer les parcours types des demandes approuvées et rejetées et d’identifier les schémas qui conduisent à des résultats indésirables. Il sert également de base au calcul du KPI « Application Rejection Rate ». Pourquoi c’est important Définit l’issue de chaque dossier, permet de comparer les instances de processus réussies et non abouties et de calculer les taux de rejet. Où les obtenir Il s’agit d’un attribut au niveau du dossier, généralement présent dans la table principale des dossiers ou des demandes d’ACTICO. Il reflète le statut final de la demande. Exemples ApprouvéRejetéEn coursInformations en attente | |||
| Utilisateur à l’origine de l’activité InitiatingUser | Identifiant ou nom du collaborateur ayant effectué l’activité. | ||
| Description Cet attribut identifie l’utilisateur ou l’agent système responsable de l’exécution d’une activité. Il relie les étapes du processus aux personnes ou aux équipes qui les ont réalisées. L’analyse de la performance par utilisateur est une exigence courante. Cet attribut permet de créer des Dashboards présentant la répartition de la charge de travail, les temps de traitement individuels et les comparaisons de performance entre utilisateurs ou équipes. Il aide à identifier les collaborateurs les plus performants ainsi que ceux qui pourraient avoir besoin d’une formation complémentaire, et il est essentiel pour comprendre l’affectation et l’utilisation des ressources. Pourquoi c’est important Relie les activités du processus à des utilisateurs précis, permettant d’analyser la performance par personne ou par équipe et d’identifier les besoins de formation ou les déséquilibres de ressources. Où les obtenir Cette information est généralement stockée avec chaque événement dans le journal d’événements ou les tables d’historique des transactions d’ACTICO. Consultez la documentation ACTICO. Exemples john.doejane.smithSYSTEM_USER | |||
| Est automatisé IsAutomated | Indicateur précisant si une activité a été exécutée automatiquement par le système ou manuellement par un utilisateur. | ||
| Description Cet attribut booléen distingue les tâches exécutées par un utilisateur de celles prises en charge par l’automatisation du système, comme un contrôle automatisé des antécédents ou un calcul du niveau de risque. L’analyse de cet attribut permet d’évaluer l’efficacité des initiatives d’automatisation. Elle permet de comparer les délais de traitement des étapes automatisées et manuelles, d’identifier les parties du processus qui restent fortement dépendantes d’interventions humaines et de repérer les possibilités d’automatisation supplémentaires pour améliorer l’efficacité et réduire les coûts opérationnels. Pourquoi c’est important Distingue les tâches humaines des tâches exécutées par le système, ce qui est essentiel pour mesurer l’impact de l’automatisation et repérer de nouvelles possibilités d’amélioration de l’efficacité. Où les obtenir Cette information peut être déduite de l’attribut « InitiatingUser », par exemple lorsque l’utilisateur est « SYSTEM », ou correspondre à un indicateur dédié dans l’Event Log. Consultez la documentation d’ACTICO. Exemples truefalse | |||
| Est une reprise IsRework | Indicateur calculé permettant d’identifier si une activité correspond à une étape répétée ou fait partie d’une boucle de reprise. | ||
| Description Cet attribut booléen signale les activités exécutées une deuxième fois ou davantage dans le même dossier, par exemple une « Revue des documents » effectuée après une demande d’informations complémentaires. Il identifie les reprises, qui sont généralement une source d’inefficacité du processus. L’identification des reprises constitue un objectif majeur du Process Mining. Cet indicateur permet de quantifier les reprises, notamment en calculant le KPI « Taux de reprise documentaire ». Sur la carte du processus, les boucles de reprise peuvent être mises en évidence afin de montrer les endroits où le processus revient sur lui-même. Cette analyse aide à repérer les problèmes de qualité ou les étapes qui ne sont pas réalisées correctement du premier coup. Pourquoi c’est important Met en évidence les tâches répétées, ce qui permet de mesurer directement l’inefficacité du processus et d’identifier les activités présentant des problèmes de qualité ou de clarté. Où les obtenir Il s’agit d’un attribut calculé. La logique est définie dans l’outil de Process Mining ou lors de la transformation des données afin de détecter les activités répétées dans un même dossier. Exemples truefalse | |||
| État de l’accord de niveau de service SlaState | Statut calculé indiquant si le dossier respecte l’accord de niveau de service, ne le respecte pas ou risque de ne pas le respecter. | ||
| Description Cet attribut fournit une évaluation catégorielle de la performance d’un dossier au regard de son accord de niveau de service. Il est calculé en comparant le délai de clôture du dossier, ou l’heure actuelle pour les dossiers ouverts, à « SlaTargetDate ». Cet attribut simplifie le reporting des accords de niveau de service en transformant les comparaisons de dates en un statut facile à comprendre. Les Dashboards peuvent l’utiliser pour créer des visualisations claires, comme des diagrammes circulaires ou des jauges indiquant le pourcentage de dossiers « Respectés » et « Non respectés ». Il constitue un élément essentiel du Dashboard « Performance des accords de niveau de service de l’intégration » et contribue directement au KPI « Taux de respect des accords de niveau de service de l’intégration ». Pourquoi c’est important Fournit pour chaque dossier un statut clair et catégorisé du respect de l’accord de niveau de service, ce qui simplifie le reporting et facilite la visualisation de la performance par rapport aux objectifs. Où les obtenir Il s’agit d’un attribut calculé à partir d’une règle métier qui compare l’horodatage de clôture du dossier à « SlaTargetDate ». Exemples RespectéDépasséÀ risque | |||
| Pays Country | Pays de résidence du client qui demande son intégration. | ||
| Description Cet attribut indique le pays du client, qui peut avoir une incidence importante sur le processus KYC. Les différentes juridictions appliquent des exigences réglementaires distinctes, susceptibles d’entraîner des étapes supplémentaires ou différentes. L’analyse du processus par pays permet de comparer les performances entre plusieurs régions. Elle peut révéler que certains pays connaissent systématiquement des délais de traitement plus longs ou des taux de rejet plus élevés, ce qui peut signaler des contraintes réglementaires ou des difficultés propres à certains marchés. Cette dimension géographique est importante pour les organisations internationales qui souhaitent harmoniser leurs processus tout en respectant les exigences locales de conformité. Pourquoi c’est important Fournit une dimension géographique pour l’analyse et aide à comprendre les variations du processus ainsi que les écarts de performance entre les différentes juridictions réglementaires. Où les obtenir Il s’agit d’une information client fondamentale, enregistrée au niveau du dossier ou du client dans le système ACTICO. Exemples USADEUGBRSGP | |||
| Type de client CustomerType | Catégorie du client, par exemple particulier ou entreprise. | ||
| Description Cet attribut classe le demandeur dans différentes catégories, par exemple une personne physique ou une entité juridique. Le processus KYC diffère souvent fortement selon le type de demandeur, l’intégration d’une entreprise étant généralement beaucoup plus complexe. L’utilisation de Type de client comme dimension permet de distinguer clairement ces processus et de les comparer au sein du même jeu de données. Les analystes peuvent filtrer la carte du processus pour n’afficher que les clients « Corporate » et comprendre leurs difficultés, leurs goulots d’étranglement et leurs temps de cycle propres, sans que les données soient influencées par le processus beaucoup plus simple des clients « Individual ». Pourquoi c’est important Permet de segmenter le processus selon les catégories de clients, dont les parcours et la complexité peuvent être très différents, afin d’obtenir une analyse plus précise. Où les obtenir Il s’agit d’un attribut fondamental enregistré au niveau du dossier ou du client dans ACTICO. Exemples ParticulierEntreprisePetite entreprise | |||
Activités d’intégration des clients KYC
| Activité | Description | ||
|---|---|---|---|
| Contrôle de conformité lancé | Cette activité marque le début de la phase d’examen manuel par le service conformité, généralement pour les demandes présentant un risque élevé ou ayant été signalées. Elle est souvent déduite d’un changement de statut du dossier vers « Pending Compliance Review » ou de l’affectation du dossier à la file de travail d’un responsable conformité. | ||
| Pourquoi c’est important Cette activité marque le début de la mesure du goulot d’étranglement lié à la conformité. Le temps écoulé jusqu’à « Compliance Review Completed » constitue un KPI essentiel pour repérer les retards à cette étape importante. Où les obtenir Cette activité est déduite de l’historique des statuts de la demande ou de la piste d’audit. Recherchez un horodatage associé au passage à « In Compliance Review » ou à l’affectation à un groupe d’utilisateurs chargé de la conformité. Collecte Déduit du passage du statut du dossier à « Pending Compliance » ou de son affectation à l’équipe conformité. Type d’événement inferred | |||
| Contrôle de conformité terminé | Cette activité marque la fin de l’examen manuel par le service conformité, avec une décision d’approuver, de rejeter ou de demander une action complémentaire. Elle est déduite du passage du statut du dossier de « Pending Compliance Review » à un état ultérieur tel que « Compliance Approved ». | ||
| Pourquoi c’est important Il s’agit de l’événement de clôture de l’étape de contrôle de conformité. Il est essentiel pour calculer la durée totale de cet examen et analyser le débit de traitement de l’équipe. Où les obtenir Cette activité est déduite du journal d’historique des statuts de la demande. Recherchez l’horodatage correspondant à la sortie du dossier de l’état « In Compliance Review », qui indique qu’une décision a été prise. Collecte Déduit du passage du statut du dossier de « Pending Compliance » à « Compliance Approved » ou à un statut similaire. Type d’événement inferred | |||
| Demande approuvée | Cette activité correspond à la décision métier finale d’approuver la demande d’intégration du client. Il s’agit d’un jalon important, généralement enregistré comme un changement de statut distinct et final dans le cycle de vie de la demande. | ||
| Pourquoi c’est important Ce jalon précède la création du compte et indique une issue favorable. L’analyse du temps nécessaire pour l’atteindre est essentielle pour comprendre la durée du « happy path ». Où les obtenir Cette activité est déduite du champ de statut final de la table principale des demandes ou des dossiers. Recherchez un statut tel que « Approved », « Approval Complete » ou un état positif terminal similaire. Collecte Le statut final du dossier est mis à jour sur « Approved » dans les données de référence du dossier. Type d’événement inferred | |||
| Demande rejetée | Cette activité correspond à la décision finale de rejeter la demande du client, ce qui met fin au processus d’intégration. Il s’agit d’un état final important, enregistré par un changement de statut final de la demande. | ||
| Pourquoi c’est important Il s’agit de l’événement final principal en cas d’échec. L’analyse des dossiers qui se terminent par cette activité est essentielle pour comprendre les taux et les motifs de rejet et améliorer le rendement global du processus. Où les obtenir Cette activité est déduite du champ de statut final de la table principale des demandes ou des dossiers. Recherchez un statut terminal tel que « Rejected », « Declined » ou « Closed - Rejected ». Collecte Le statut final du dossier est mis à jour sur « Rejected » dans les données de référence du dossier. Type d’événement inferred | |||
| Demande soumise | Cette activité marque le début du processus d’intégration KYC, lorsqu’une nouvelle demande client est officiellement reçue par le système ACTICO. Elle est enregistrée comme un événement explicite, généralement avec un horodatage précis au moment de la création d’un nouveau dossier ou enregistrement de demande. | ||
| Pourquoi c’est important En tant que premier événement du processus, cette activité est essentielle pour calculer la durée globale du cycle d’intégration et suivre le volume de demandes. Elle sert d’horodatage de référence pour toutes les mesures ultérieures de performance du processus. Où les obtenir Il s’agit généralement d’une entrée explicite dans un journal de création de demande ou de dossier au sein d’ACTICO. Recherchez les tables liées aux événements de soumission des demandes ou à l’horodatage de création du dossier principal. Collecte Événement enregistré lors de la création d’une nouvelle instance de dossier de demande. Type d’événement explicit | |||
| Documents client téléversés | Cette activité intervient lorsque le client fournit les documents d’identification et les justificatifs requis via un portail ou un autre canal intégré à ACTICO. Chaque téléversement de document est généralement enregistré comme un événement explicite et distinct dans le système de gestion documentaire ou le journal du dossier. | ||
| Pourquoi c’est important Cette étape constitue un jalon important dépendant du client. Le suivi de cet événement est essentiel pour mesurer les délais de réponse du client et analyser la durée de la phase d’examen documentaire qui suit. Où les obtenir Recherchez les journaux d’événements liés à la gestion des documents ou aux pièces jointes du dossier de demande. Ils sont souvent enregistrés dans des tables dédiées à la gestion des documents ou des justificatifs dans la base de données ACTICO. Collecte Événement enregistré par le système lorsqu’un document est joint au dossier. Type d’événement explicit | |||
| Évaluation du risque effectuée | Cette activité correspond à l’exécution du moteur de décision d’ACTICO pour calculer un score ou un niveau de risque pour la demande client. En tant que fonction centrale du système, elle est enregistrée comme un événement explicite lorsque le jeu de règles d’évaluation du risque est exécuté. | ||
| Pourquoi c’est important L’évaluation du risque constitue un point de décision déterminant qui définit souvent la suite du parcours. Son analyse permet de comprendre comment les niveaux de risque influencent les variantes et les délais du processus. Où les obtenir Il s’agit d’un événement central dans ACTICO, qui doit être enregistré dans les journaux de décision ou d’exécution. Ces journaux contiennent généralement l’identifiant du dossier, les règles exécutées et le score de risque obtenu. Collecte Événement enregistré par le moteur de décision ACTICO à l’issue du calcul du score de risque. Type d’événement explicit | |||
| Intégration client terminée | Il s’agit de la dernière activité du processus. Elle indique que le client est entièrement intégré et que le dossier de demande est clôturé. Elle est déduite de l’application au dossier d’un statut final tel que « Onboarded » ou « Closed - Approved ». | ||
| Pourquoi c’est important En tant qu’événement final de réussite, cette activité est essentielle pour calculer la durée de bout en bout de l’intégration des clients effectivement intégrés. Elle fournit l’horodatage final nécessaire à l’analyse du happy path. Où les obtenir Cette activité est déduite du champ de statut final du dossier de demande client. Recherchez un horodatage associé au passage du dossier à un statut terminal de réussite. Collecte Déduit d’une mise à jour finale du statut du dossier vers « Completed » ou « Closed ». Type d’événement inferred | |||
| Compte créé | Après l’approbation, cette activité marque la création technique du compte client dans le système bancaire central ou le système de gestion des utilisateurs. Il s’agit souvent d’un événement explicite enregistré par ACTICO après réception d’une confirmation de réussite du système en aval. | ||
| Pourquoi c’est important Cette activité confirme que le processus a abouti à un résultat métier concret. Le délai entre « Application Approved » et « Account Created » peut révéler des retards d’intégration ou des inefficacités lors des dernières étapes de mise à disposition. Où les obtenir Ces informations se trouvent probablement dans les journaux d’intégration ou d’interface système d’ACTICO, qui enregistrent le résultat des appels aux systèmes externes pour la mise à disposition du compte. Collecte Événement enregistré à la réception d’une réponse API positive du système central de gestion des comptes. Type d’événement explicit | |||
| Contrôles d’antécédents lancés | Cette activité correspond au lancement de contrôles automatisés ou manuels des antécédents, tels que les contrôles AML ou l’examen de l’historique de crédit. Elle est souvent enregistrée comme un événement explicite lorsque le système déclenche ces contrôles, qui peuvent faire intervenir des prestataires de services externes. | ||
| Pourquoi c’est important Le lancement des contrôles d’antécédents constitue un jalon important du processus de due diligence. Son suivi permet de comprendre les dépendances et les délais associés aux fournisseurs de données externes. Où les obtenir Recherchez dans les journaux système ou la piste d’audit les enregistrements indiquant le déclenchement des procédures de contrôle des antécédents. Ils sont souvent associés à l’identifiant principal du dossier de demande. Collecte Événement enregistré lorsque le moteur du flux de travail lance des appels vers les services de vérification des antécédents. Type d’événement explicit | |||
| Examen des documents terminé | Cette activité indique qu’un agent a terminé l’examen des documents soumis par le client. Elle est généralement déduite d’un changement de statut du document ou du dossier dans son ensemble, par exemple « Documents Verified » ou « Review Complete ». | ||
| Pourquoi c’est important Il s’agit d’un jalon important pour mesurer l’efficacité du processus de gestion documentaire. Le délai entre « Customer Documents Uploaded » et cette activité constitue un KPI essentiel pour identifier les retards de traitement manuel. Où les obtenir Cette activité est déduite des journaux d’historique des statuts du dossier de demande ou des documents individuels. Le passage du statut d’un document de « Pending Review » à « Approved » ou « Reviewed » indique que cette activité a eu lieu. Collecte Déduit d’un changement du statut du document à « Verified » ou « Reviewed ». Type d’événement inferred | |||
| Examen initial de la demande | Cette activité correspond au premier examen de la demande soumise, effectué par une règle automatisée ou un agent, afin de vérifier son exhaustivité et son éligibilité de base. Elle est souvent déduite d’un changement de statut de la demande, par exemple de « Submitted » à « In Review ». | ||
| Pourquoi c’est important L’analyse du temps nécessaire à ce premier examen permet d’identifier les retards initiaux de traitement. Elle indique également combien de demandes franchissent cette première étape sans difficulté. Où les obtenir Cette activité est déduite des tables d’historique des statuts ou des journaux d’audit associés au dossier de demande client. Comparez l’horodatage du passage d’un état « new » ou « submitted » à un état « review ». Collecte Détecter dans le journal d’historique du dossier le changement de statut de « Submitted » à « Under Review ». Type d’événement inferred | |||
| Informations complémentaires demandées | Cette activité correspond au moment où un contrôleur, souvent du service conformité ou de la souscription, demande au client des informations ou des documents supplémentaires. Elle est généralement enregistrée explicitement, car elle implique souvent l’envoi d’une notification au client et la mise en pause du dossier. | ||
| Pourquoi c’est important Cette activité est une cause majeure de reprises et d’allongement des délais de traitement. Le suivi de sa fréquence et de son impact est essentiel pour identifier les points où la collecte initiale des données peut être améliorée. Où les obtenir Il s’agit probablement d’un événement explicite enregistré dans l’historique du dossier ou le journal des communications. Recherchez des événements tels que « RFI Sent » (Request for Information) ou un changement de statut comme « Pending Customer Information ». Collecte Un événement explicite déclenché par l’utilisateur, tel que « Send RFI », est enregistré dans la piste d’audit du dossier. Type d’événement explicit | |||
| Vérification de l’identité effectuée | Cette activité correspond à un contrôle automatisé ou manuel visant à valider l’identité du client à partir de sources de données internes ou externes. Elle est souvent enregistrée comme un événement explicite lorsqu’un appel d’API est effectué auprès d’un service de vérification tiers et qu’une réponse est reçue. | ||
| Pourquoi c’est important Cette activité constitue une étape essentielle de la conformité. L’analyse de sa durée et de ses résultats permet d’identifier les dépendances à l’égard de services externes ainsi que les goulots d’étranglement potentiels du processus de vérification. Où les obtenir Ces informations se trouvent généralement dans les journaux d’intégration ou dans des tables d’événements spécifiques qui enregistrent les résultats des contrôles automatisés et des appels aux services tiers associés au dossier de demande. Collecte Événement enregistré à la suite d’un appel d’intégration vers un service tiers de vérification d’identité. Type d’événement explicit | |||
Guides d’extraction
Étapes
- Obtenez les droits d’administration : connectez-vous à la plateforme ACTICO, par exemple au Visual Modeler ou à une console d’administration dédiée, avec des identifiants disposant des autorisations suffisantes pour accéder aux exportations de données et les configurer.
- Repérez le module d’exportation : accédez à la zone d’administration ou de configuration du système. Recherchez la section consacrée aux pistes d’audit, à la journalisation ou aux exportations de données. Elle peut être intitulée « Audit Export » ou « Business Object Export ».
- Créez une nouvelle configuration d’exportation : lancez la création d’une nouvelle définition d’exportation. Donnez à la configuration un nom explicite, par exemple
KYC_Onboarding_ProcessMind_Export. - Définissez la source de données : indiquez l’objet métier principal à exporter, à savoir
CustomerApplication. Il est essentiel d’appliquer un filtre de période, par exemple sur les 6 derniers mois, afin de limiter le périmètre de l’exportation et de conserver des tailles de fichiers ainsi que des performances maîtrisables. - Configurez le fichier de sortie : sélectionnez le format CSV. Définissez le nom du fichier, par exemple
kyc_event_log.csv, et confirmez le séparateur, généralement une virgule. Vérifiez que les champs texte sont correctement placés entre guillemets afin de gérer les caractères spéciaux. - Associez l’identifiant du cas : désignez l’identifiant unique de l’objet métier
CustomerApplicationcomme ID de cas pour l’analyse de Process Mining. Il relie tous les événements associés à un même cas d’intégration. - Définissez les associations d’attributs : pour chaque colonne requise du journal d’événements, associez-la à l’attribut correspondant du modèle d’objets métier ACTICO. Cela comprend l’ID de cas, le nom de l’activité, les horodatages et d’autres attributs recommandés, comme le statut ou le niveau de risque.
- Configurez les associations d’événements : il s’agit de l’étape la plus importante. Créez une règle ou une association spécifique pour chacune des 14 activités métier. Utilisez des déclencheurs système, comme la création d’un objet pour « Application Submitted », les changements de statut pour les étapes du flux de travail telles que « Application Approved », et des schémas précis de messages de journal d’audit pour les événements techniques comme « Identity Verification Performed ».
- Enregistrez et validez la configuration : après avoir défini toutes les associations, enregistrez le fichier de configuration. Utilisez les outils de validation disponibles dans ACTICO pour rechercher les erreurs de syntaxe ou les chemins d’attributs incorrects.
- Exécutez et surveillez l’exportation : lancez la tâche d’exportation. Suivez sa progression dans le planificateur de tâches ou l’interface de supervision du système. Consultez les journaux pour vérifier la présence éventuelle d’erreurs à la fin de l’opération.
- Récupérez et préparez le fichier : téléchargez le fichier CSV obtenu depuis le chemin de sortie indiqué sur le serveur. Avant de l’importer dans ProcessMind, ouvrez-le pour vérifier sa structure et vous assurer que les formats de date et d’horodatage sont cohérents et correctement interprétés.
Configuration
- Niveau du journal d’audit : Le niveau de journalisation d’audit à l’échelle du système doit être configuré sur un niveau détaillé, comme INFO ou FINE. Un niveau moins détaillé, comme WARNING ou ERROR, ne consignera pas les changements de statut et les exécutions de règles nécessaires au Process Mining.
- Source des données à exporter : La source principale doit utiliser l’objet métier
CustomerApplication. Il peut être nécessaire de joindre ou de référencer des objets associés, commeCustomerDocument, afin de capturer tous les événements pertinents. - Filtre de dates : Utilisez toujours un filtre de dates pour contrôler le volume de données extraites. Pour une première analyse, une période de 3 à 6 mois est recommandée. En production, cette période peut être adaptée aux besoins métier et aux performances du système.
- Logique de mapping des événements : La précision de l’extraction dépend largement de la manière dont les événements sont mappés. Les changements de statut (
on="StatusChange") sont couramment utilisés pour déduire les étapes métier. Les entrées explicites du journal (on="LogEntry") conviennent aux événements techniques ou aux appels de service. Les exécutions de règles (on="RuleExecution") sont adaptées à la capture des étapes de prise de décision. - Format de sortie : Sélectionnez CSV pour garantir une large compatibilité. Vérifiez que la configuration du séparateur et du placement des champs texte entre guillemets est correcte afin d’éviter les problèmes d’interprétation des données.
- Prérequis : Cette méthode nécessite des autorisations d’administration sur la plateforme ACTICO. Une bonne compréhension du modèle d’objets métier KYC, notamment de tous les champs de statut et noms d’attributs pertinents, est indispensable pour configurer correctement l’export.
a Exemple de requête xml
<!-- This is a representative ACTICO export configuration in XML format. -->
<!-- Actual syntax may vary based on your ACTICO version. -->
<AuditExportConfiguration name="KYC_ProcessMind_Export">
<DataSource type="BusinessObject">
<ObjectName>CustomerApplication</ObjectName>
<DateRange from="[Start Date YYYY-MM-DD]" to="[End Date YYYY-MM-DD]"/>
</DataSource>
<OutputFile format="CSV" name="kyc_event_log.csv" delimiter=","/>
<CaseId mapping="customerApplication.id"/>
<Attributes>
<Attribute name="CustomerApplication" mapping="customerApplication.id"/>
<Attribute name="ActivityName" mapping="[generated_activity_name]"/>
<Attribute name="EventTime" mapping="[event_timestamp]"/>
<Attribute name="SourceSystem" value="ACTICO"/>
<Attribute name="LastDataUpdate" value="[CURRENT_TIMESTAMP]"/>
<Attribute name="EndTime" mapping="[event_timestamp]"/>
<Attribute name="InitiatingUser" mapping="event.user"/>
<Attribute name="Department" mapping="event.user.department"/>
<Attribute name="ApplicationStatus" mapping="customerApplication.status"/>
<Attribute name="RejectionReason" mapping="customerApplication.rejectionDetails.reasonCode"/>
<Attribute name="RiskLevel" mapping="customerApplication.risk.level"/>
<Attribute name="SlaTargetDate" mapping="customerApplication.slaDate"/>
</Attributes>
<EventMappings>
<Event on="Create" object="CustomerApplication">
<Set name="[generated_activity_name]" value="Application Submitted"/>
<Set name="[event_timestamp]" mapping="customerApplication.creationDate"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" from="Submitted" to="In Review">
<Set name="[generated_activity_name]" value="Initial Application Review"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="Create" object="CustomerDocument">
<Set name="[generated_activity_name]" value="Customer Documents Uploaded"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
<CaseId mapping="event.relatedObject.customerApplication.id"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="IDV Service Call Completed.*">
<Set name="[generated_activity_name]" value="Identity Verification Performed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Documents Verified">
<Set name="[generated_activity_name]" value="Document Review Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="Background Check Initiated.*">
<Set name="[generated_activity_name]" value="Background Checks Initiated"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="RuleExecution" object="CustomerApplication" ruleSet="KYC Risk Assessment">
<Set name="[generated_activity_name]" value="Risk Assessment Performed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Pending Compliance Review">
<Set name="[generated_activity_name]" value="Compliance Review Initiated"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Pending Customer Information">
<Set name="[generated_activity_name]" value="Additional Information Requested"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" from="Pending Compliance Review" to="Compliance Approved">
<Set name="[generated_activity_name]" value="Compliance Review Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Approved">
<Set name="[generated_activity_name]" value="Application Approved"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="Account successfully created.*">
<Set name="[generated_activity_name]" value="Account Created"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Closed - Approved">
<Set name="[generated_activity_name]" value="Customer Onboarding Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Rejected">
<Set name="[generated_activity_name]" value="Application Rejected"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
</EventMappings>
</AuditExportConfiguration> Prêt à commencer ?
Utilisez ce modèle pour préparer efficacement vos données et accélérer l’optimisation de l’intégration des clients KYC dans ACTICO.
Optimisez l’intégration KYC des clients : réduisez le délai à 24 heures dès maintenant
Éliminez les abandons et les faux positifs pour obtenir une intégration simple et efficace.
Aucune carte bancaire requise. Commencez votre optimisation dès aujourd’hui.