Su Template de datos para la incorporación KYC de clientes
Su Template de datos para la incorporación KYC de clientes
- Atributos recomendados para recopilar
- Actividades clave que debe registrar
- Guía de extracción para ACTICO
Atributos de la incorporación de clientes KYC
| Nombre | Descripción | ||
|---|---|---|---|
| Hora del evento EventTime | La marca de tiempo que indica cuándo comenzó o tuvo lugar una actividad específica. | ||
| Descripción La hora del evento es la fecha y hora exactas en las que se registró una actividad en el sistema. Proporciona el orden cronológico de todos los eventos dentro de un caso individual de solicitud del cliente y forma la línea temporal del recorrido de onboarding. Este atributo es fundamental para todos los análisis basados en el tiempo. Se utiliza para calcular los tiempos de ciclo entre actividades, identificar retrasos y tiempos de espera, medir la duración total del caso y comprobar el cumplimiento de los Acuerdos de Nivel de Servicio (SLA). La secuencia de estas marcas de tiempo para un caso determinado permite a las herramientas de Process Mining reconstruir el flujo exacto del proceso tal como ocurrió. Por qué es importante Este atributo proporciona el orden cronológico de los eventos, algo esencial para calcular duraciones, descubrir cuellos de botella y analizar la línea temporal del proceso. Dónde obtenerlo Se encuentra en las tablas de registros de eventos de ACTICO y corresponde a la marca de tiempo asociada a cada actividad registrada. Consulte la documentación de ACTICO. Ejemplos 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T15:45:10Z | |||
| Nombre de la actividad ActivityName | El nombre del evento empresarial o la tarea específica realizada dentro del proceso de onboarding del cliente. | ||
| Descripción Este atributo registra el nombre de cada paso o actividad que tiene lugar durante el proceso KYC, como «Solicitud enviada», «Evaluación de riesgo realizada» o «Solicitud aprobada». Proporciona los elementos secuenciales que componen el mapa del proceso. Analizar el nombre de la actividad permite visualizar el flujo del proceso, identificar actividades frecuentes o poco habituales y detectar cuellos de botella o ciclos de retrabajo. Es fundamental para comprender qué acciones se realizan y en qué orden, algo esencial para analizar variantes y comprobar el cumplimiento. Por qué es importante Define los pasos del mapa del proceso, permite visualizar el flujo, identificar desviaciones y analizar la frecuencia y la secuencia de las actividades. Dónde obtenerlo Esta información suele encontrarse en una tabla de registro de eventos dentro de ACTICO, normalmente en un campo que describe el tipo de evento o tarea. Consulte la documentación de ACTICO. Ejemplos Solicitud enviadaEvaluación de riesgo realizadaRevisión de cumplimiento completadaSolicitud rechazada | |||
| Solicitud del cliente CustomerApplication | El identificador único de una solicitud individual de onboarding de cliente, que sirve como ID del caso para el análisis del proceso. | ||
| Descripción La solicitud del cliente es el identificador principal del caso que agrupa todos los eventos y actividades relacionados con el recorrido de onboarding de un único cliente. Representa una instancia completa del proceso KYC, desde el envío inicial hasta la decisión final de aprobación o rechazo. En Process Mining, este atributo es esencial para reconstruir el recorrido completo de cada solicitud. Permite a las personas analistas seguir la secuencia de actividades, medir los tiempos totales de ciclo y comparar las distintas rutas o variantes del proceso que siguen las solicitudes. Todos los eventos que comparten el mismo ID de solicitud del cliente se consideran parte del mismo caso. Por qué es importante Este es el atributo fundamental para Process Mining, ya que conecta todos los eventos relacionados en una única instancia de proceso coherente y permite analizar de principio a fin la experiencia de onboarding de cada cliente. Dónde obtenerlo Es una clave primaria en las tablas principales de solicitudes o gestión de casos de ACTICO. Consulte la documentación de ACTICO para conocer los nombres específicos de las tablas y los campos. Ejemplos APP-2023-001234APP-2023-001235APP-2024-000001 | |||
| Sistema de origen SourceSystem | El sistema de registro del que proceden los datos de los eventos. | ||
| Descripción Este atributo identifica el sistema de información de origen en el que se generaron los datos. En este proceso será siempre «ACTICO», pero en análisis más amplios que incluyan varios sistemas ayuda a diferenciar el origen de los datos. En el contexto de Process Mining, es fundamental para la gobernanza y la validación de los datos. Garantiza que los datos se atribuyan correctamente a su origen, algo importante al combinar datos de distintos sistemas para crear una visión integral del proceso. También ayuda a solucionar problemas de calidad de datos al rastrearlos hasta el sistema de origen. Por qué es importante Proporciona un contexto esencial sobre el origen de los datos y garantiza su trazabilidad y gobernanza, aspectos críticos al combinar información de varias fuentes. Dónde obtenerlo Normalmente es un valor estático («ACTICO») que se añade durante el proceso de extracción y transformación de datos para etiquetar el conjunto de datos. Ejemplos ACTICOACTICO PlatformActico KYC Module | |||
| Última actualización de datos LastDataUpdate | La marca de tiempo que indica la última vez que se actualizaron o extrajeron los datos del sistema de origen. | ||
| Descripción Este atributo registra la fecha y hora de la extracción más reciente de datos desde ACTICO. Es un campo de metadatos que se aplica al conjunto de datos completo, no a eventos individuales, y proporciona contexto sobre la actualidad del análisis. En Dashboards e informes, esta información es esencial para que los usuarios comprendan hasta qué punto están actualizados los datos. Ayuda a gestionar las expectativas sobre la actualidad de la información y resulta crucial para la supervisión operativa cuando son importantes los datos casi en tiempo real. Mostrar esta marca de tiempo garantiza la transparencia y la confianza en los datos presentados. Por qué es importante Indica la actualidad de los datos y permite saber si se está analizando información actualizada, algo crítico para la toma de decisiones operativas. Dónde obtenerlo Este valor se genera y almacena durante el proceso de extracción, transformación y carga (ETL) de datos. Refleja la marca de tiempo en la que el trabajo de ETL se completó correctamente. Ejemplos 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| Departamento Department | El departamento o equipo empresarial responsable de realizar la actividad. | ||
| Descripción Este atributo asigna una actividad a una unidad organizativa concreta, como «Cumplimiento», «Equipo de incorporación» o «Relaciones con clientes». Proporciona contexto organizativo al flujo del proceso. El análisis por departamento es fundamental para comprender cómo se transfiere el trabajo entre las distintas áreas de la organización. Ayuda a identificar cuellos de botella entre departamentos, medir la eficiencia departamental y analizar la asignación de recursos entre equipos. Los Dashboards pueden filtrarse por departamento para ofrecer a los responsables una visión del rendimiento específico de su equipo. Por qué es importante Proporciona una dimensión organizativa para el análisis, permite identificar retrasos entre departamentos y evaluar el rendimiento a nivel de equipo. Dónde obtenerlo Esta información puede almacenarse directamente con los datos del evento o derivarse al combinar los datos de usuarios con una tabla maestra de datos de RR. HH. que asigne cada usuario a un departamento. Consulte la documentación de ACTICO. Ejemplos ComplianceEquipo de incorporaciónServicio al cliente | |||
| Estado de la solicitud ApplicationStatus | El resultado final o el estado actual de la solicitud de onboarding del cliente. | ||
| Descripción Este atributo indica el resultado final de un caso, normalmente «Aprobada» o «Rechazada». También puede mostrar el estado de los casos en curso. Es una dimensión crítica para el análisis basado en resultados. Comprender por qué se aprueban o rechazan las solicitudes es uno de los objetivos principales de Process Mining aplicado a KYC. Este atributo permite filtrar el mapa del proceso para ver los recorridos habituales de las solicitudes aprobadas frente a las rechazadas y ayuda a identificar patrones que conducen a resultados no deseados. También sirve de base para calcular el KPI «Tasa de rechazo de solicitudes». Por qué es importante Define el resultado de cada caso, permite comparar las instancias de proceso satisfactorias y no satisfactorias y calcular las tasas de rechazo. Dónde obtenerlo Es un atributo a nivel de caso que suele encontrarse en la tabla principal de casos o solicitudes de ACTICO. Refleja el estado final de la solicitud. Ejemplos AprobadoRechazadoEn cursoInformación pendiente | |||
| Fecha objetivo del SLA SlaTargetDate | Fecha en la que se espera completar el proceso de incorporación del cliente. | ||
| Descripción La fecha objetivo del SLA es el plazo límite para completar la incorporación de un cliente, según lo establecido en los acuerdos internos de nivel de servicio. A menudo se calcula sumando un tiempo de procesamiento estándar a la fecha de envío de la solicitud. Este atributo es esencial para supervisar el cumplimiento del SLA. Al comparar la fecha real de finalización de un caso con su fecha objetivo del SLA, el sistema puede determinar si el caso se completó a tiempo o si incumplió el SLA. Es la base del Dashboard «Rendimiento del SLA de incorporación» y del KPI «Tasa de cumplimiento del SLA de incorporación». Por qué es importante Proporciona la referencia para medir el rendimiento puntual y permite supervisar e informar directamente sobre el cumplimiento del SLA. Dónde obtenerlo Puede almacenarse como un campo en la tabla principal de casos de ACTICO o derivarse a partir de reglas de negocio, por ejemplo, Fecha de envío + 5 días laborables. Ejemplos 2023-11-01T17:00:00Z2023-11-02T17:00:00Z2023-11-03T17:00:00Z | |||
| Hora de finalización EndTime | La marca de tiempo que indica cuándo se completó una actividad específica. | ||
| Descripción La hora de finalización marca la conclusión de una actividad. Junto con la hora de inicio (EventTime), permite calcular la duración exacta de cada Task, conocida como tiempo de procesamiento. No todos los eventos tienen una hora de finalización diferenciada, ya que algunos pueden ser instantáneos. Este atributo es fundamental para el análisis del rendimiento, especialmente para medir cuánto tarda cada paso. Permite crear Dashboards detallados de rendimiento, ayuda a identificar qué actividades consumen más tiempo y resulta esencial para calcular KPI como el «Tiempo medio de revisión de documentos». Por qué es importante Permite calcular la duración exacta de las actividades, es decir, el tiempo de procesamiento, algo fundamental para identificar cuellos de botella de rendimiento y analizar la eficiencia de los recursos. Dónde obtenerlo Al igual que la hora de inicio, normalmente se encuentra en las tablas de registros de eventos de ACTICO. Algunos sistemas almacenan las horas de inicio y finalización en columnas independientes dentro de un mismo registro de evento. Consulte la documentación de ACTICO. Ejemplos 2023-10-26T10:15:00Z2023-10-26T12:00:00Z2023-10-27T16:00:15Z | |||
| Motivo del rechazo RejectionReason | El motivo específico indicado cuando se rechaza una solicitud de cliente. | ||
| Descripción Cuando el estado final de una solicitud es «Rechazada», este atributo proporciona la causa subyacente. Algunos ejemplos son «Documentación incompleta», «Comprobación de antecedentes fallida» o «Perfil de alto riesgo». Es un atributo esencial para el análisis de causas raíz. Al analizar la frecuencia de los distintos motivos de rechazo, la empresa puede identificar problemas sistémicos en el proceso o en los envíos de los clientes. Por ejemplo, un número elevado de rechazos por documentación incompleta podría indicar que las instrucciones de la solicitud no son claras. Esto respalda directamente el panel «Tasa y motivos de rechazo de solicitudes». Por qué es importante Explica el motivo de los rechazos de solicitudes, permite analizar las causas raíz para reducir la tasa de rechazo y mejorar la eficiencia del proceso. Dónde obtenerlo Normalmente se encuentra en la tabla principal de casos o solicitudes de ACTICO y suele completarse únicamente cuando el estado de la solicitud es «Rechazada». Ejemplos Documentación incompletaVerificación de identidad fallidaCoincidencia con una lista de sancionesPuntuación de riesgo alta | |||
| Nivel de riesgo RiskLevel | El nivel de riesgo calculado para la solicitud del cliente, como bajo, medio o alto. | ||
| Descripción Este atributo representa la categoría de riesgo evaluada de un cliente, que a menudo determina la complejidad y el rigor del proceso KYC posterior. Un cliente de alto riesgo puede requerir comprobaciones y aprobaciones adicionales en comparación con uno de bajo riesgo. En Process Mining, Nivel de riesgo es una dimensión muy útil para el análisis comparativo. Permite a los analistas comprobar si el proceso sigue correctamente distintas rutas según el riesgo, tal como se ha definido. Por ejemplo, es posible verificar que todos los clientes de alto riesgo completen un paso de diligencia debida reforzada. Es fundamental para el Dashboard «Flujos del proceso de evaluación de riesgos». Por qué es importante Permite segmentar los casos según el riesgo y analizar si el proceso se adapta correctamente a los distintos perfiles de riesgo, tal como exigen las políticas de cumplimiento. Dónde obtenerlo Es un dato clave almacenado a nivel de caso en la tabla principal de la aplicación dentro de ACTICO. Ejemplos BajoMedioAlto | |||
| Persona usuaria que inicia InitiatingUser | El ID o nombre de la persona empleada que realizó la actividad. | ||
| Descripción Este atributo identifica al usuario o agente del sistema concreto responsable de ejecutar una actividad. Vincula los pasos del proceso con las personas o equipos que los realizaron. Analizar el rendimiento por usuario es un requisito habitual. Este atributo permite crear Dashboards que muestran la distribución de la carga de trabajo, los tiempos de procesamiento individuales y comparativas de rendimiento entre usuarios o equipos. Ayuda a identificar a las personas con mejor rendimiento y a quienes pueden necesitar formación adicional, y resulta clave para comprender la asignación y utilización de recursos. Por qué es importante Vincula las actividades del proceso con personas usuarias concretas, permite analizar el rendimiento individual o por equipo y ayuda a identificar necesidades de formación o desequilibrios en los recursos. Dónde obtenerlo Normalmente se almacena junto a cada evento en el registro de eventos o en las tablas del historial de transacciones de ACTICO. Consulte la documentación de ACTICO. Ejemplos john.doejane.smithSYSTEM_USER | |||
| Es retrabajo IsRework | Indicador calculado que identifica si una actividad es un paso repetido o forma parte de un ciclo de retrabajo. | ||
| Descripción Este atributo booleano marca las actividades que se realizan por segunda vez o posteriormente dentro del mismo caso, como una «Revisión de documentos» que tiene lugar después de solicitar información adicional. Identifica los casos de retrabajo, que suelen ser una fuente de ineficiencia del proceso. Identificar el retrabajo es uno de los objetivos principales de Process Mining. Este indicador permite cuantificarlo, por ejemplo, mediante el cálculo del KPI «Tasa de retrabajo documental». En el mapa de procesos, los ciclos de retrabajo pueden resaltarse para mostrar dónde el proceso vuelve sobre sí mismo. Esto ayuda a localizar problemas de calidad o áreas en las que el proceso no se completa correctamente a la primera. Por qué es importante Resalta los casos de trabajo repetido, lo que permite medir directamente la ineficiencia del proceso e identificar actividades con problemas de calidad o falta de claridad. Dónde obtenerlo Es un atributo calculado. La lógica se define en la herramienta de Process Mining o durante la transformación de datos para detectar actividades repetidas dentro del mismo caso. Ejemplos truefalse | |||
| Está automatizado IsAutomated | Indicador que señala si una actividad fue realizada automáticamente por el sistema o manualmente por un usuario. | ||
| Descripción Este atributo booleano distingue entre las tareas ejecutadas por una persona y las realizadas mediante automatización del sistema, como una comprobación de antecedentes automatizada o la puntuación de riesgo. Analizar este atributo ayuda a evaluar la eficacia de las iniciativas de automatización. Permite comparar los tiempos de procesamiento de los pasos automatizados y manuales, identificar qué partes del proceso siguen dependiendo en gran medida del trabajo manual y detectar oportunidades para aumentar la automatización, mejorar la eficiencia y reducir los costes operativos. Por qué es importante Distingue entre las tareas realizadas por personas y las ejecutadas por el sistema, algo fundamental para medir el impacto de la automatización e identificar futuras oportunidades de eficiencia. Dónde obtenerlo Puede inferirse a partir del atributo «InitiatingUser», por ejemplo, si el usuario es «SYSTEM», o puede existir como indicador específico en el registro de eventos. Consulte la documentación de ACTICO. Ejemplos truefalse | |||
| Estado del SLA SlaState | Estado calculado que indica si el caso cumplió el SLA, lo incumplió o está en riesgo de incumplirlo. | ||
| Descripción Este atributo ofrece una evaluación categórica del rendimiento de un caso frente a su acuerdo de nivel de servicio. Se obtiene comparando el tiempo de finalización del caso, o la hora actual en los casos abiertos, con «SlaTargetDate». Este atributo simplifica los informes del SLA al convertir las comparaciones de fechas en un estado fácil de entender. Los Dashboards pueden utilizarlo para crear visualizaciones claras, como gráficos circulares o indicadores, que muestren el porcentaje de casos que «Cumplieron» frente a los que «Incumplieron». Es un elemento clave del Dashboard «Rendimiento del SLA de incorporación» y respalda directamente el KPI «Tasa de cumplimiento del SLA de incorporación». Por qué es importante Proporciona un estado categórico claro del cumplimiento del SLA para cada caso, simplifica los informes y facilita la visualización del rendimiento frente a los objetivos. Dónde obtenerlo Es un atributo calculado derivado de una lógica de negocio que compara la marca de tiempo de finalización del caso con «SlaTargetDate». Ejemplos CumplidoIncumplidoEn riesgo | |||
| País Country | País de residencia del cliente que solicita la incorporación. | ||
| Descripción Este atributo especifica el país del cliente, lo que puede influir considerablemente en el proceso KYC. Cada jurisdicción tiene requisitos regulatorios diferentes, que pueden activar pasos adicionales o alternativos. Analizar el proceso por país permite comparar el rendimiento entre distintas regiones. Puede ayudar a identificar si determinados países presentan sistemáticamente tiempos de ciclo más largos o tasas de rechazo más elevadas, lo que podría indicar fricciones regulatorias o desafíos específicos del mercado. Esta perspectiva geográfica es importante para las organizaciones globales que buscan estandarizar sus procesos sin dejar de atender las necesidades locales de cumplimiento. Por qué es importante Proporciona una dimensión geográfica para el análisis y ayuda a comprender las variaciones del proceso y las diferencias de rendimiento entre distintas jurisdicciones regulatorias. Dónde obtenerlo Es un dato esencial del cliente, almacenado a nivel de caso o de cliente dentro del sistema ACTICO. Ejemplos USADEUGBRSGP | |||
| Tipo de cliente CustomerType | Clasificación del cliente, por ejemplo, persona física o empresa. | ||
| Descripción Este atributo clasifica al solicitante en distintas categorías, por ejemplo, una persona física frente a una entidad empresarial. El proceso KYC suele variar considerablemente entre estos tipos, ya que la incorporación de empresas es mucho más compleja. Usar Tipo de cliente como dimensión permite separar y comparar claramente estos procesos distintos dentro del mismo conjunto de datos. Los analistas pueden filtrar el mapa de procesos para ver únicamente clientes «Empresa» y comprender sus desafíos, cuellos de botella y tiempos de ciclo específicos, sin que los datos queden sesgados por el proceso mucho más sencillo de los clientes «Persona física». Por qué es importante Permite segmentar el proceso para distintas categorías de clientes, que a menudo presentan flujos de proceso y niveles de complejidad muy diferentes, lo que conduce a un análisis más preciso. Dónde obtenerlo Es un atributo fundamental almacenado a nivel de caso o de cliente dentro de ACTICO. Ejemplos Persona físicaPersona jurídicaPequeña empresa | |||
Actividades de incorporación de clientes KYC
| Actividad | Descripción | ||
|---|---|---|---|
| Documentos del cliente cargados | Esta actividad ocurre cuando el cliente proporciona los documentos de identificación y respaldo requeridos a través de un portal u otro canal integrado con ACTICO. Cada carga de documentos suele registrarse como un evento explícito e independiente en el sistema de gestión documental o en el registro del caso. | ||
| Por qué es importante Este evento marca un hito clave que depende del cliente. Realizar un seguimiento de él es fundamental para medir los tiempos de respuesta del cliente y analizar la duración de la fase posterior de revisión documental. Dónde obtenerlo Busque registros de eventos relacionados con la gestión de documentos o los archivos adjuntos del caso de solicitud. Normalmente se almacenan en tablas específicas de gestión documental o de evidencias dentro de la base de datos de ACTICO. Recopilar Evento registrado por el sistema cuando se adjunta un documento al caso. Tipo de evento explicit | |||
| Evaluación de riesgo realizada | Esta actividad representa la ejecución del motor de decisiones de ACTICO para calcular una puntuación o clasificación de riesgo para la solicitud del cliente. Como función central del sistema, se registra como un evento explícito cuando se ejecuta el conjunto de reglas de evaluación de riesgos. | ||
| Por qué es importante La evaluación de riesgos es un punto de decisión determinante que suele definir la ruta posterior del proceso. Analizar esta actividad ayuda a comprender cómo los niveles de riesgo influyen en las variantes y los plazos del proceso. Dónde obtenerlo Este es un evento central dentro de ACTICO y debería registrarse en los logs de decisiones o de ejecución. Estos registros suelen incluir el ID del caso, las reglas ejecutadas y la puntuación de riesgo resultante. Recopilar Evento registrado por el motor de decisiones de ACTICO al completar la puntuación de riesgo. Tipo de evento explicit | |||
| Onboarding del cliente completado | Esta es la actividad final del proceso e indica que el cliente ha completado el onboarding y que el caso de solicitud se ha cerrado. Se infiere a partir de la aplicación al caso de un estado final y terminal como «Onboarding completado» o «Cerrado - aprobado». | ||
| Por qué es importante Como evento final principal de éxito, esta actividad es esencial para calcular el tiempo de ciclo de principio a fin de todos los clientes cuyo onboarding se ha completado correctamente. Proporciona la marca de tiempo final para analizar la ruta ideal. Dónde obtenerlo Se infiere a partir del campo de estado final del caso de solicitud del cliente. Busque una marca de tiempo asociada al cambio del caso a un estado terminal de éxito. Recopilar Se infiere a partir de una actualización final del estado del caso a «Completado» o «Cerrado». Tipo de evento inferred | |||
| Revisión de cumplimiento completada | Marca el final de la revisión manual por parte del departamento de cumplimiento, con una decisión de aprobar, rechazar o solicitar nuevas acciones. Esta actividad se infiere a partir de un cambio de estado del caso de «Pendiente de revisión de cumplimiento» a un estado posterior como «Cumplimiento aprobado». | ||
| Por qué es importante Este es el evento de cierre de la etapa de revisión de cumplimiento. Es esencial para calcular la duración total de la revisión de cumplimiento y analizar el rendimiento del equipo. Dónde obtenerlo Se infiere a partir del registro del historial de estados de la solicitud. Busque la marca de tiempo en la que el caso abandona el estado «En revisión de cumplimiento», lo que indica que se ha tomado una decisión. Recopilar Se infiere a partir del cambio del estado del caso de «Pendiente de cumplimiento» a «Cumplimiento aprobado» o un estado similar. Tipo de evento inferred | |||
| Revisión de cumplimiento iniciada | Marca el inicio de la fase de revisión manual por parte del departamento de cumplimiento, normalmente para solicitudes de alto riesgo o marcadas. Suele inferirse a partir de un cambio del estado del caso a «Pendiente de revisión de cumplimiento» o de la asignación del caso a la cola de trabajo de una persona responsable de cumplimiento. | ||
| Por qué es importante Esta actividad es el punto de partida para medir el cuello de botella de cumplimiento. El tiempo transcurrido hasta «Revisión de cumplimiento completada» es un KPI crítico para identificar retrasos en esta etapa clave. Dónde obtenerlo Se infiere a partir del historial de estados o del registro de auditoría de la solicitud. Busque una marca de tiempo asociada a un cambio de estado a «En revisión de cumplimiento» o a la asignación a un grupo de usuarios relacionado con cumplimiento. Recopilar Se infiere a partir del cambio del estado del caso a «Pendiente de cumplimiento» o de su asignación al equipo de cumplimiento. Tipo de evento inferred | |||
| Solicitud aprobada | Esta actividad representa la decisión empresarial final de aprobar la solicitud del cliente para el onboarding. Es un hito clave que normalmente se registra como un cambio de estado independiente y final en el ciclo de vida de la solicitud. | ||
| Por qué es importante Este hito precede a la creación de la cuenta y representa un resultado satisfactorio. Analizar el tiempo necesario para llegar a este punto es fundamental para comprender la duración de la «ruta ideal». Dónde obtenerlo Se infiere a partir del campo de estado final de la tabla principal de solicitudes o casos. Busque un estado como «Aprobada», «Aprobación completada» u otro estado positivo terminal similar. Recopilar El estado final del caso se actualiza a «Aprobado» en los datos maestros del caso. Tipo de evento inferred | |||
| Solicitud enviada | Esta actividad marca el inicio del proceso de onboarding KYC, cuando el sistema ACTICO recibe formalmente una nueva solicitud de cliente. Se registra como un evento explícito, normalmente con una marca de tiempo precisa al crear un nuevo caso o registro de solicitud. | ||
| Por qué es importante Como evento inicial principal, esta actividad es esencial para calcular el tiempo total del ciclo de onboarding y realizar un seguimiento del volumen de solicitudes. Sirve como marca de tiempo de referencia para todas las mediciones posteriores del rendimiento del proceso. Dónde obtenerlo Normalmente se trata de una entrada explícita en un registro de creación de solicitudes o casos dentro de ACTICO. Busque tablas relacionadas con eventos de envío de solicitudes o con la marca de tiempo de creación del registro principal del caso. Recopilar Evento registrado al crear una nueva instancia de caso de solicitud. Tipo de evento explicit | |||
| Solicitud rechazada | Representa la decisión final de rechazar la solicitud del cliente, con lo que termina el proceso de onboarding. Es un estado final crítico que se registra mediante un cambio final en el estado del registro de la solicitud. | ||
| Por qué es importante Este es el evento final principal de fallo. Analizar los casos que terminan con esta actividad es fundamental para comprender las tasas y los motivos de rechazo, así como para mejorar el rendimiento general del proceso. Dónde obtenerlo Se infiere a partir del campo de estado final de la tabla principal de solicitudes o casos. Busque un estado terminal como «Rechazada», «Denegada» o «Cerrado - rechazado». Recopilar El estado final del caso se actualiza a «Rechazado» en los datos maestros del caso. Tipo de evento inferred | |||
| Comprobaciones de antecedentes iniciadas | Representa el momento en que comienzan las comprobaciones de antecedentes automatizadas o manuales, como las verificaciones de AML o del historial crediticio. A menudo se registra como un evento explícito cuando el sistema activa estas comprobaciones, que pueden implicar a proveedores de servicios externos. | ||
| Por qué es importante El inicio de las comprobaciones de antecedentes es un hito importante en el proceso de diligencia debida. Realizar un seguimiento de este evento ayuda a comprender las dependencias y los plazos asociados a los proveedores de datos externos. Dónde obtenerlo Busque registros en los logs del sistema o en el registro de auditoría que indiquen la activación de los procedimientos de verificación de antecedentes. Normalmente están vinculados al ID principal del caso de solicitud. Recopilar Evento registrado cuando el motor de Workflow inicia llamadas a servicios de comprobación de antecedentes. Tipo de evento explicit | |||
| Cuenta creada | Después de la aprobación, esta actividad marca la creación técnica de la cuenta del cliente en el sistema bancario central o de gestión de usuarios. A menudo se registra como un evento explícito en ACTICO después de recibir una confirmación de éxito del sistema posterior. | ||
| Por qué es importante Esta actividad confirma que el proceso produjo un resultado empresarial tangible. El tiempo entre «Solicitud aprobada» y «Cuenta creada» puede revelar retrasos de integración o ineficiencias en los pasos finales de aprovisionamiento. Dónde obtenerlo Probablemente esta información se encuentre en los registros de integración o de interfaces del sistema dentro de ACTICO, donde se registra el resultado de las llamadas a sistemas externos para aprovisionar cuentas. Recopilar Evento registrado al recibir una respuesta API satisfactoria del sistema central de cuentas. Tipo de evento explicit | |||
| Información adicional solicitada | Representa un evento en el que una persona revisora, normalmente del área de cumplimiento o suscripción, necesita más información o documentación del cliente. Esta acción suele registrarse explícitamente, ya que normalmente implica enviar una notificación al cliente y pausar el caso. | ||
| Por qué es importante Esta actividad es una de las principales causas de retrabajo y del aumento de los tiempos de ciclo. Realizar un seguimiento de su frecuencia y su impacto es esencial para identificar áreas en las que puede mejorarse la recopilación inicial de datos. Dónde obtenerlo Probablemente se trata de un evento explícito registrado en el historial del caso o en el registro de comunicaciones. Busque eventos como «RFI enviado» (solicitud de información) o un cambio de estado específico como «Pendiente de información del cliente». Recopilar Un evento explícito activado por una persona usuaria, como «Enviar RFI», se registra en el registro de auditoría del caso. Tipo de evento explicit | |||
| Revisión documental completada | Esta actividad indica que un agente ha terminado de revisar los documentos enviados por el cliente. Normalmente se infiere a partir de un cambio de estado del documento o del caso completo, como «Documentos verificados» o «Revisión completada». | ||
| Por qué es importante Este es un hito clave para medir la eficiencia del proceso de gestión documental. El tiempo transcurrido entre «Documentos del cliente cargados» y esta actividad es un KPI fundamental para identificar retrasos en el procesamiento manual. Dónde obtenerlo Se infiere a partir de los registros del historial de estados del caso de solicitud o de documentos individuales. Un cambio del estado de un documento de «Pendiente de revisión» a «Aprobado» o «Revisado» indica esta actividad. Recopilar Se infiere a partir de un cambio del estado del documento a «Verificado» o «Revisado». Tipo de evento inferred | |||
| Revisión inicial de la solicitud | Representa la primera revisión de la solicitud enviada, ya sea mediante una regla automatizada o por parte de un agente, para comprobar su integridad y elegibilidad básica. Esta actividad suele inferirse a partir de un cambio de estado de la solicitud, por ejemplo, de «Enviada» a «En revisión». | ||
| Por qué es importante Analizar el tiempo necesario para completar esta primera revisión ayuda a identificar retrasos iniciales en el procesamiento. También permite saber cuántas solicitudes superan este primer filtro sin incidencias. Dónde obtenerlo Se infiere a partir de las tablas del historial de estados o de los registros de auditoría asociados al caso de solicitud del cliente. Compare la marca de tiempo en la que el estado cambia de «nueva» o «enviada» a «en revisión». Recopilar Detectar en el registro del historial del caso el cambio de estado de «Enviada» a «En revisión». Tipo de evento inferred | |||
| Verificación de identidad realizada | Representa una comprobación automatizada o manual para validar la identidad del cliente frente a fuentes de datos externas o internas. A menudo se registra como un evento explícito cuando se realiza una llamada API a un servicio de verificación externo y se recibe una respuesta. | ||
| Por qué es importante Esta actividad es un paso crítico de cumplimiento. Analizar su duración y sus resultados ayuda a identificar dependencias de servicios externos y posibles cuellos de botella en el proceso de verificación. Dónde obtenerlo Esta información suele encontrarse en los registros de integración o en tablas de eventos específicas que almacenan los resultados de comprobaciones automatizadas y llamadas a servicios externos vinculadas al caso de solicitud. Recopilar Evento registrado a partir de una llamada de integración a un servicio externo de verificación de identidad. Tipo de evento explicit | |||
Guías de extracción
Pasos
- Obtenga acceso administrativo: Inicie sesión en la plataforma ACTICO, como Visual Modeler o una consola de administración específica, con credenciales que tengan permisos suficientes para acceder a las exportaciones de datos y configurarlas.
- Localice el módulo de exportación: Vaya al área de administración o configuración del sistema. Busque la sección responsable de los registros de auditoría, el registro de actividad o las exportaciones de datos. Puede aparecer con el nombre «Audit Export» o «Business Object Export».
- Cree una nueva configuración de exportación: Inicie el proceso para crear una nueva definición de exportación. Asigne un nombre descriptivo a la configuración, por ejemplo, «KYC_Onboarding_ProcessMind_Export».
- Defina el origen de datos: Especifique el objeto de negocio principal que se exportará, «CustomerApplication». Es fundamental aplicar un filtro de intervalo de fechas para limitar el alcance de la exportación, por ejemplo, a los últimos 6 meses, y garantizar así tamaños de archivo y rendimiento manejables.
- Configure el archivo de salida: Establezca CSV como formato de salida. Defina el nombre del archivo, por ejemplo, «kyc_event_log.csv», y confirme el delimitador, normalmente una coma. Asegúrese de que los campos de texto estén entre comillas correctamente para gestionar los caracteres especiales.
- Asigne el identificador del caso: Designe el identificador único del objeto de negocio «CustomerApplication» como ID de caso para el análisis de Process Mining. Esto vincula todos los eventos relacionados con un único caso de incorporación.
- Defina las asignaciones de atributos: Para cada columna necesaria del registro de eventos, asígnela al atributo correspondiente del modelo de objetos de negocio de ACTICO. Esto incluye el ID de caso, el nombre de la actividad, las marcas de tiempo y otros atributos recomendados, como el estado o el nivel de riesgo.
- Configure las asignaciones de eventos: Este es el paso más importante. Cree una regla o asignación específica para cada una de las 14 actividades de negocio. Utilice activadores del sistema, como la creación de objetos para «Application Submitted», cambios de estado para pasos del Workflow como «Application Approved» y patrones específicos de mensajes del registro de auditoría para eventos técnicos como «Identity Verification Performed».
- Guarde y valide la configuración: Después de definir todas las asignaciones, guarde el archivo de configuración. Utilice las herramientas de validación disponibles en ACTICO para comprobar si existen errores de sintaxis o rutas de atributos incorrectas.
- Ejecute y supervise la exportación: Ejecute el trabajo de exportación. Supervise su progreso mediante el programador de trabajos o la interfaz de monitorización del sistema. Revise los registros en busca de errores cuando finalice.
- Recupere y prepare el archivo: Descargue el archivo CSV resultante desde la ruta de salida designada en el servidor. Antes de cargarlo en ProcessMind, ábralo para verificar su estructura y asegurarse de que los formatos de fecha y hora sean coherentes y se interpreten correctamente.
Configuración
- Nivel del registro de auditoría: El nivel de registro de auditoría de todo el sistema debe configurarse con un nivel detallado, como INFO o FINE. Un nivel menos detallado, como WARNING o ERROR, no capturará los cambios de estado ni las ejecuciones de reglas necesarios para Process Mining.
- Origen de los datos de exportación: El origen de datos principal debe configurarse para utilizar el objeto de negocio
CustomerApplication. Puede ser necesario unir o referenciar objetos relacionados, comoCustomerDocument, para capturar todos los eventos relevantes. - Filtro de intervalo de fechas: Utilice siempre un filtro de intervalo de fechas para controlar el volumen de datos extraído. Para el análisis inicial, se recomienda un periodo de 3 a 6 meses. En producción, puede ajustarlo según las necesidades del negocio y el rendimiento del sistema.
- Lógica de asignación de eventos: La precisión de la extracción depende en gran medida de cómo se asignen los eventos. Los cambios de estado (
on="StatusChange") son habituales para inferir pasos de negocio. Las entradas explícitas del registro (on="LogEntry") resultan útiles para eventos técnicos o llamadas a servicios. Las ejecuciones de reglas (on="RuleExecution") son ideales para capturar pasos de toma de decisiones. - Formato de salida: Seleccione CSV como formato de salida para garantizar una amplia compatibilidad. Asegúrese de configurar correctamente los delimitadores y las comillas de texto para evitar problemas de interpretación de los datos.
- Requisitos previos: Este método requiere permisos administrativos en la plataforma ACTICO. Para configurarlo correctamente, es esencial comprender a fondo el modelo de objetos de negocio KYC, incluidos todos los campos de estado y nombres de atributos relevantes.
a Consulta de ejemplo 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> ¿Listo para comenzar?
Utilice este Template para preparar sus datos de forma eficaz y acelerar su camino hacia una incorporación KYC de clientes optimizada en ACTICO.
Optimice la incorporación KYC de clientes: reduzca el tiempo a 24 horas
Elimine los abandonos y los falsos positivos para lograr una incorporación fluida.
No necesita tarjeta de crédito. Empiece a optimizar hoy mismo.