Su Template de datos para la incorporación de clientes KYC

LexisNexis Risk Solutions
Su Template de datos para la incorporación de clientes KYC

Su Template de datos para la incorporación de clientes KYC

Esta plantilla ofrece una guía completa para recopilar los datos necesarios para analizar su proceso de incorporación de clientes KYC. Detalla los atributos esenciales que debe recopilar, las actividades clave que debe supervisar y cómo extraer esta información de sus sistemas de origen. Utilice este recurso para crear un Registro de eventos sólido que le permita obtener información detallada sobre su proceso de incorporación.
  • Atributos recomendados que debe recopilar
  • Actividades clave que debe supervisar
  • Guía de extracción
¿Es nuevo en los registros de eventos? Aprenda a crear un registro de eventos de Process Mining.

Atributos de la incorporación de clientes KYC

Estos son los campos de datos recomendados que debe incluir en su registro de eventos para analizar exhaustivamente la incorporación de clientes KYC y descubrir el proceso.
3 Obligatorio 6 Recomendado 11 Opcional
Nombre Descripción
Marca de tiempo del evento
EventTimestamp
La fecha y hora exactas en las que comenzó una actividad concreta.
Descripción

Esta marca de tiempo señala el inicio de una actividad y proporciona el orden cronológico de todos los eventos de un caso. Es la base de todos los análisis temporales de Process Mining.

Con la marca de tiempo del evento, es posible calcular la duración de las actividades, el tiempo de espera entre ellas y el tiempo total de ciclo de extremo a extremo del proceso de onboarding. Estos datos son esenciales para identificar cuellos de botella, supervisar el cumplimiento de los SLA y comprender la eficiencia del proceso.

Por qué es importante

Esta marca de tiempo es esencial para ordenar cronológicamente los eventos y calcular todas las métricas temporales, como los tiempos de ciclo y los cuellos de botella.

Dónde obtenerlo

Se encuentra en las tablas del Registro de eventos o de trazabilidad de auditoría, junto al nombre de la actividad.

Ejemplos
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:15:00Z
Nombre de la actividad
ActivityName
El nombre de la Task o el Event específico que tuvo lugar en un momento determinado durante el proceso de onboarding.
Descripción

El nombre de la actividad describe un paso del Workflow de onboarding de KYC, como «Application Submitted», «Document Review Performed» o «Application Approved». Cada actividad representa una acción o un hito concreto del proceso.

Este Atributo es fundamental para construir el mapa de procesos, que representa visualmente el flujo de actividades. Permite analizar las variantes del proceso, los cuellos de botella entre pasos concretos y la frecuencia de los bucles de retrabajo. Analizar las actividades es clave para comprender qué ocurre en el proceso.

Por qué es importante

Este Atributo constituye la base del mapa de procesos y permite visualizar y analizar la secuencia de eventos del recorrido de onboarding del cliente.

Dónde obtenerlo

Normalmente se encuentra en un Registro de eventos o en una tabla de trazabilidad de auditoría de LexisNexis Risk Solutions que registra los pasos del proceso.

Ejemplos
Solicitud enviadaEvaluación inicial realizadaDocumentos solicitadosRevisión de cumplimiento completada
Solicitud de cliente
CustomerApplication
El identificador único de cada solicitud de onboarding de cliente, que actúa como ID de caso principal.
Descripción

La solicitud de cliente es el identificador central que vincula todas las actividades y los datos relacionados con el recorrido de onboarding de una sola persona cliente. Comienza cuando se envía una solicitud y sigue el caso hasta que se completa o se rechaza.

En Process Mining, este atributo es esencial para agrupar todos los eventos en un caso coherente, lo que permite analizar el ciclo de vida completo del onboarding. Permite reconstruir el flujo completo del proceso para cada solicitante, algo fundamental para calcular los tiempos de ciclo, analizar las variantes del proceso y realizar un seguimiento del estado de una solicitud a lo largo del tiempo.

Por qué es importante

Este es el Case ID fundamental. Sin él, no puede rastrear el recorrido completo de una solicitud de cliente, lo que hace imposible analizar el proceso.

Dónde obtenerlo

Este es el identificador principal del caso dentro del módulo de gestión de casos de LexisNexis Risk Solutions.

Ejemplos
APP-2023-001234APP-2023-005678APP-2024-009101
Departamento
Department
El departamento o equipo de negocio al que pertenece el usuario asignado.
Descripción

El Atributo Departamento especifica el grupo funcional responsable de una actividad, como «Cumplimiento», «Operaciones de onboarding» o «Prevención del fraude».

Este Atributo se utiliza para analizar el proceso desde la perspectiva departamental y permite analizar las transferencias entre distintos equipos. Es una dimensión principal del Dashboard «Resource Allocation and Workload» y ayuda a identificar ineficiencias interfuncionales o retrasos en la comunicación entre departamentos.

Por qué es importante

Permite analizar las transferencias del proceso y el rendimiento por área funcional, lo que ayuda a identificar cuellos de botella entre departamentos.

Dónde obtenerlo

Consulte la documentación de LexisNexis Risk Solutions o al administrador del sistema. Puede ser necesario combinar estos datos con una tabla maestra de usuarios o de recursos humanos.

Ejemplos
ComplianceEquipo de incorporaciónAnalistas de KYCAtención al cliente
Estado de la solicitud
ApplicationStatus
El estado actual o final de la solicitud del cliente.
Descripción

Este Atributo refleja el estado general del caso en un momento determinado o su resultado final. Entre los estados habituales se incluyen «In Progress», «Approved», «Rejected» o «Pending Information».

El estado de la solicitud es esencial para realizar un seguimiento de los resultados del proceso de onboarding. Se utiliza en los Dashboards «Application Rejection Reasons & Stages» y «Daily Throughput and Application Status» para supervisar las tasas de éxito y el flujo operativo. Analizar cómo cambia el estado con el tiempo aporta información sobre el ciclo de vida del caso.

Por qué es importante

Registra el resultado de cada solicitud, algo esencial para calcular KPI clave como la tasa de rechazo de solicitudes y supervisar el rendimiento.

Dónde obtenerlo

Consulte la documentación de LexisNexis Risk Solutions o al administrador del sistema. Normalmente es un campo clave del objeto principal del caso o de la solicitud.

Ejemplos
En cursoAprobadoRechazadoInformación pendiente del cliente
Fecha objetivo del SLA
SlaTargetDate
La fecha en la que se espera completar el proceso de onboarding del cliente.
Descripción

La fecha objetivo del SLA define el acuerdo de nivel de servicio para completar una solicitud. Esta fecha suele determinarse según factores como el tipo de solicitud, el segmento de cliente o la jurisdicción.

Este Atributo es esencial para el Dashboard «SLA Target Adherence Monitoring» y el KPI «SLA Adherence Rate». Al comparar la fecha real de finalización con la fecha objetivo del SLA, las organizaciones pueden medir su rendimiento frente a los compromisos, identificar los casos en riesgo de incumplir los SLA e investigar las causas raíz de los retrasos.

Por qué es importante

Permite medir el rendimiento frente a los acuerdos de nivel de servicio y pone de relieve las ineficiencias del proceso que provocan incumplimientos de los SLA.

Dónde obtenerlo

Consulte la documentación de LexisNexis Risk Solutions o al administrador del sistema. Puede almacenarse en el caso o calcularse según las reglas de negocio.

Ejemplos
2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-12-01T17:00:00Z
Hora de finalización
EndTime
La fecha y hora exactas en las que se completó una actividad.
Descripción

Esta marca de tiempo señala la finalización de una actividad. La diferencia entre la hora de finalización y la hora de inicio de un evento representa su tiempo de procesamiento.

La hora de finalización es esencial para calcular con precisión cuánto tarda cada paso y constituye uno de los principales datos de entrada del Dashboard «Activity Processing & Waiting Times». Ayuda a diferenciar entre el tiempo durante el que un recurso trabajó activamente en una Task y el tiempo que el caso permaneció a la espera de que comenzara el siguiente paso.

Por qué es importante

Permite calcular con precisión el tiempo de procesamiento de las actividades, algo esencial para identificar pasos ineficientes y analizar la carga de trabajo de los recursos.

Dónde obtenerlo

Consulte la documentación de LexisNexis Risk Solutions o al administrador del sistema. A menudo está disponible en registros de eventos que incluyen los eventos de inicio y finalización.

Ejemplos
2023-10-26T10:45:10Z2023-10-26T11:55:30Z2023-10-28T09:05:00Z
Nivel de riesgo
RiskLevel
El nivel de riesgo calculado de la solicitud del cliente, como bajo, medio o alto.
Descripción

LexisNexis Risk Solutions está especializada en la evaluación de riesgos. Este Atributo representa el resultado de esa evaluación y clasifica cada solicitud según su perfil de riesgo potencial. El nivel de riesgo suele determinar la intensidad y la duración necesarias del proceso de diligencia debida.

Este Atributo es la dimensión principal del Dashboard «Risk Level vs. Onboarding Duration». Analizar el proceso por nivel de riesgo puede revelar si las solicitudes de alto riesgo tardan significativamente más, como cabría esperar, o si las solicitudes de bajo riesgo sufren retrasos innecesarios. Ayuda a validar y perfeccionar las estrategias de onboarding basadas en el riesgo.

Por qué es importante

Es fundamental para el análisis basado en el riesgo, ya que ayuda a comprender cómo los perfiles de riesgo de los clientes afectan a la complejidad, la duración y las rutas del proceso.

Dónde obtenerlo

Consulte la documentación de LexisNexis Risk Solutions o al administrador del sistema. Es un resultado central de los módulos de evaluación de riesgos.

Ejemplos
BajoMedioAltoSancionado
Usuario asignado
AssignedUser
El identificador único del usuario o agente responsable de realizar la actividad.
Descripción

Este Atributo identifica a la persona concreta que ejecutó una Task, como un responsable de cumplimiento que realiza una revisión documental. Ayuda a analizar la distribución de la carga de trabajo y el rendimiento individual.

En el análisis, el usuario asignado es clave para el Dashboard «Resource Allocation and Workload». Permite filtrar el mapa de procesos por usuario, comparar el rendimiento entre integrantes del equipo e identificar oportunidades de formación o de redistribución de la carga de trabajo. También puede ayudar a localizar cuellos de botella causados por grupos de usuarios concretos.

Por qué es importante

Este Atributo es fundamental para analizar el rendimiento de los recursos, distribuir la carga de trabajo e identificar oportunidades de automatización u optimización de recursos.

Dónde obtenerlo

Consulte la documentación de LexisNexis Risk Solutions o al administrador del sistema. Normalmente se encuentra en los registros de auditoría o en las tablas de gestión de Tasks.

Ejemplos
j.doem.smithk.chen
Canal
Channel
El canal a través del cual se presentó la solicitud, como «Web», «Mobile» o «In-Branch».
Descripción

El Atributo Canal identifica el origen de presentación de la solicitud. El canal puede influir en la calidad de los datos, el comportamiento del cliente y los tipos de problemas que surgen durante el onboarding.

Este Atributo se utiliza para comparar el rendimiento del proceso en distintos canales. Por ejemplo, el Dashboard «Onboarding Funnel Conversion Rates» puede filtrarse por canal para comprobar si los solicitantes móviles abandonan el proceso con mayor frecuencia que los solicitantes web y orientar mejoras específicas para cada canal.

Por qué es importante

Ayuda a analizar el rendimiento del proceso según el canal de presentación e identifica variaciones que pueden orientar la estrategia de canales y las mejoras de la experiencia de usuario.

Dónde obtenerlo

Consulte la documentación de LexisNexis Risk Solutions o al administrador del sistema. Esta información normalmente se registra al inicio del proceso de solicitud.

Ejemplos
Portal webAplicación móvilEn sucursalAPI
Es retrabajo
IsRework
Un indicador que identifica las actividades que forman parte de un bucle de retrabajo.
Descripción

Este indicador booleano se establece en true cuando una actividad se repite dentro del mismo caso, como cuando «Document Review Performed» ocurre por segunda vez después de «Additional Information Requested». Esto indica que el proceso ha retrocedido.

«Is Rework» es fundamental para el Dashboard «Rework and Repetition Analysis» y el KPI «Rework Loop Percentage». Permite cuantificar el esfuerzo desperdiciado e identificar las causas raíz del retrabajo, como instrucciones poco claras o una calidad de datos deficiente, para aplicar mejoras específicas en el proceso.

Por qué es importante

Cuantifica directamente la ineficiencia y el esfuerzo desperdiciado en el proceso, y pone de relieve las actividades que se repiten con frecuencia y aumentan los costes y los tiempos de ciclo.

Dónde obtenerlo

Es un Atributo calculado que normalmente se obtiene en la herramienta de Process Mining al detectar secuencias repetidas de actividades dentro de un caso.

Ejemplos
truefalse
Está automatizado
IsAutomated
Un 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 Tasks ejecutadas mediante automatización del sistema, como una comprobación inicial, y las que requieren intervención humana, como una revisión documental manual.

«Is Automated» se utiliza para calcular el KPI «Manual Activity Proportion» y analizar la eficacia de las iniciativas de automatización. En el mapa de procesos, puede mostrar la conexión entre los pasos automatizados y manuales, lo que ayuda a identificar oportunidades para ampliar la automatización, reducir costes y acortar los tiempos de procesamiento.

Por qué es importante

Distingue entre Tasks manuales y automatizadas, algo clave para identificar oportunidades de automatización y medir su impacto.

Dónde obtenerlo

Consulte la documentación de LexisNexis Risk Solutions o al administrador del sistema. Puede ser un indicador del Registro de eventos o inferirse a partir de «AssignedUser», por ejemplo, cuando el usuario es «system».

Ejemplos
truefalse
Estado del SLA
SlaStatus
Indica si la solicitud completada cumplió su objetivo de SLA.
Descripción

Este Atributo clasifica cada caso completado según el cumplimiento de «SlaTargetDate». Los valores habituales son «Met» o «Breached».

Este campo calculado es la base del Dashboard «SLA Target Adherence Monitoring» y del KPI «SLA Adherence Rate». Proporciona una visión clara y general del rendimiento frente a los compromisos de servicio y permite analizar en detalle las características comunes de los casos que incumplen sus SLA.

Por qué es importante

Proporciona un resultado binario claro sobre el rendimiento de los SLA, lo que facilita el seguimiento, la elaboración de informes y el análisis del cumplimiento de los objetivos de nivel de servicio.

Dónde obtenerlo

Es un Atributo calculado que se obtiene comparando la marca de tiempo de la actividad final con «SlaTargetDate» para cada caso.

Ejemplos
CumplidoIncumplidoEn riesgo
Motivo del rechazo
RejectionReason
Un código o una descripción que explica por qué se rechazó una solicitud.
Descripción

Cuando el estado final de una solicitud es «Rejected», este Atributo proporciona el motivo concreto. Algunos ejemplos son «Failed Identity Verification», «Sanctions Match» o «Incomplete Documentation».

Estos datos son la principal fuente de información del Dashboard «Application Rejection Reasons & Stages». Analizar los motivos de rechazo ayuda a identificar los puntos habituales de fallo del proceso, lo que puede orientar mejoras en las instrucciones de la solicitud, la comunicación con el cliente o los criterios de revisión interna. Comprender por qué se rechazan las solicitudes es clave para mejorar la tasa general de aprobación.

Por qué es importante

Aporta información directa sobre los motivos por los que falla el onboarding y permite aplicar mejoras específicas para aumentar la tasa de aprobación de solicitudes.

Dónde obtenerlo

Consulte la documentación de LexisNexis Risk Solutions o al administrador del sistema. A menudo se encuentra en un campo que se completa cuando el estado de la solicitud se establece en «Rejected».

Ejemplos
Coincidencia con una lista de sancionesDocumentación incompletaID&V fallidaPerfil de riesgo alto
País del cliente
CustomerCountry
El país de residencia o de constitución del cliente.
Descripción

Este Atributo especifica el país del cliente, un factor fundamental en KYC debido a las diferencias entre las normativas internacionales y los niveles de riesgo asociados a cada jurisdicción.

Analizar el proceso por país del cliente puede revelar diferencias significativas en los tiempos de ciclo y la complejidad del proceso. Por ejemplo, las solicitudes procedentes de jurisdicciones de alto riesgo pueden requerir comprobaciones adicionales de cumplimiento, lo que prolonga su duración. Este análisis ayuda a planificar los recursos y a establecer SLA realistas para cada región.

Por qué es importante

Permite realizar análisis por jurisdicción, algo esencial para comprender cómo afectan las normativas regionales y los factores de riesgo al rendimiento del proceso.

Dónde obtenerlo

Consulte la documentación de LexisNexis Risk Solutions o al administrador del sistema. Es un campo estándar de los datos maestros de clientes.

Ejemplos
USAGBRDEUSGP
Revisor de cumplimiento
ComplianceReviewer
El usuario o agente asignado específicamente a las actividades de revisión de cumplimiento.
Descripción

Mientras que «AssignedUser» registra el usuario de cualquier actividad, este Atributo identifica específicamente al especialista en cumplimiento que participa en los pasos de revisión críticos. Esto permite realizar un análisis más preciso de la función de cumplimiento.

Este Atributo es clave para el Dashboard «Compliance Review Duration and Backlog». Ayuda a analizar la carga de trabajo y el rendimiento del equipo de cumplimiento, así como a identificar si determinados revisores son cuellos de botella o si el equipo en general cuenta con recursos insuficientes.

Por qué es importante

Aporta una visión específica de la función de cumplimiento y permite analizar en detalle la carga de trabajo y el rendimiento de los revisores en esta fase crítica, que a menudo sufre retrasos.

Dónde obtenerlo

Consulte la documentación de LexisNexis Risk Solutions o al administrador del sistema. Puede derivarse filtrando «AssignedUser» para las actividades relacionadas con el cumplimiento.

Ejemplos
c.joness.patelsystem_escalation
Sistema de origen
SourceSystem
El sistema o la aplicación de la que proceden los datos del evento.
Descripción

Este Atributo identifica el sistema de origen que generó los datos del evento, como LexisNexis Risk Solutions o una herramienta de terceros integrada. En entornos complejos, los datos de un mismo proceso pueden proceder de varios sistemas.

Comprender el sistema de origen resulta útil para validar los datos, resolver problemas y analizar variaciones del proceso que pueden ser específicas de un sistema concreto. También ayuda a garantizar la integridad de los datos y aporta contexto sobre cómo y dónde se registró una actividad.

Por qué es importante

Identifica el origen de los datos, algo esencial para la gobernanza y la validación de datos, así como para comprender la ejecución del proceso en distintos sistemas de TI.

Dónde obtenerlo

Esta información puede almacenarse como un valor estático o en un campo específico de la exportación de datos o de la respuesta de la API.

Ejemplos
LexisNexis Risk SolutionsThreatMetrixBridger Insight XG
Tiempo de ciclo
CycleTime
La duración total de extremo a extremo de una solicitud de cliente, desde su presentación hasta la decisión final.
Descripción

El tiempo de ciclo mide el tiempo total transcurrido desde el primer evento, por ejemplo, «Application Submitted», hasta el último evento, como «Customer Onboarding Completed» o «Application Rejected», de un caso concreto.

Es un KPI principal para medir la salud general del proceso y se visualiza en el Dashboard «Onboarding End-to-End Cycle Time». Supervisar el tiempo de ciclo medio permite a las organizaciones evaluar el impacto de las mejoras del proceso e identificar cómo afectan distintos factores, como el nivel de riesgo o el tipo de solicitud, a la experiencia general del cliente.

Por qué es importante

Es un indicador clave de rendimiento que mide el tiempo total hasta que el cliente obtiene valor, con un impacto directo en su satisfacción y en la eficiencia operativa.

Dónde obtenerlo

Es una métrica calculada que se obtiene restando la marca de tiempo del primer evento a la marca de tiempo del último evento de cada caso.

Ejemplos
5 días 4 horas22 días 8 horas1 día 2 horas
Tipo de solicitud
ApplicationType
El tipo de solicitud del cliente, como «Individual» o «Business».
Descripción

Este Atributo clasifica las solicitudes según el tipo de entidad que se incorpora. Los distintos tipos de solicitud suelen seguir rutas de proceso diferentes y presentar perfiles de riesgo y objetivos de SLA distintos.

Analizar el proceso por tipo de solicitud permite segmentar los datos para comparar la eficiencia y la complejidad del onboarding de diferentes tipos de clientes. Es un filtro habitual en la mayoría de los Dashboards, ya que ofrece una visión más detallada del rendimiento.

Por qué es importante

Permite segmentar el proceso con precisión y muestra cómo se gestionan los distintos tipos de solicitudes y dónde existen cuellos de botella específicos para cada tipo.

Dónde obtenerlo

Consulte la documentación de LexisNexis Risk Solutions o al administrador del sistema. Normalmente es un campo principal del objeto de solicitud o de caso.

Ejemplos
Persona físicaEmpresaPersona con un patrimonio elevadoFideicomiso
Ú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 proporciona la marca de tiempo de la última actualización del conjunto de datos. Normalmente se aplica al conjunto de datos completo durante el proceso de extracción y carga.

Esta información es fundamental para que quienes utilizan el Dashboard comprendan la actualidad de los datos que analizan. Garantiza que las decisiones se basen en datos tan recientes como sea necesario y ayuda a gestionar las expectativas sobre la oportunidad de los insights.

Por qué es importante

Aporta un contexto esencial sobre la actualidad de los datos, garantiza que los análisis sean relevantes y evita tomar decisiones basadas en información obsoleta.

Dónde obtenerlo

Normalmente se genera y se incorpora al conjunto de datos durante el proceso ETL (Extract, Transform, Load).

Ejemplos
2024-01-15T02:00:00Z2024-01-16T02:00:00Z2024-01-17T02:00:00Z
Obligatorio Recomendado Opcional

Actividades de incorporación de clientes KYC

Estos son los pasos e hitos clave del proceso que debe registrar en su registro de eventos para descubrir el proceso con precisión y analizar su rendimiento.
8 Recomendado 6 Opcional
Actividad Descripción
Documentos recibidos
Confirma que el cliente ha cargado o proporcionado al sistema los documentos requeridos. Normalmente es un evento explícito generado por el portal de envío de documentos o introducido manualmente por una persona agente.
Por qué es importante

Esta actividad concluye un periodo de espera y activa las actividades de revisión posteriores. Es un hito clave en la fase de recopilación de datos.

Dónde obtenerlo

Se captura a partir de los registros del sistema de gestión documental o de una entrada con marca de tiempo en el expediente del caso cuando se adjuntan nuevos documentos.

Recopilar

El evento se registra cuando un documento se carga correctamente o se marca manualmente como recibido en el sistema.

Tipo de evento explicit
Evaluación de riesgo realizada
El sistema calcula una puntuación de riesgo para el cliente a partir de la información recopilada y las comprobaciones realizadas. Esta es una función principal de LexisNexis y normalmente se captura como un evento automatizado explícito en el historial del caso.
Por qué es importante

El resultado de esta evaluación suele determinar la ruta posterior del proceso, por ejemplo, si se requiere una diligencia debida reforzada. Es un punto de decisión crítico en el Workflow.

Dónde obtenerlo

Busque un evento en el registro de auditoría o el historial del Workflow de la solicitud que registre la finalización del módulo de puntuación o evaluación de riesgos.

Recopilar

Se registra un evento específico cuando el motor de riesgos completa su análisis y asigna un perfil o una puntuación de riesgo.

Tipo de evento explicit
Onboarding de cliente completado
Este evento marca el final satisfactorio de todo el proceso de onboarding y confirma que el cliente está completamente activo. Puede ser un estado final explícito o inferirse a partir del evento «Cuenta activada».
Por qué es importante

Este es el evento final principal del estado satisfactorio. Es esencial para calcular el tiempo de ciclo completo de todos los clientes incorporados correctamente.

Dónde obtenerlo

Se infiere a partir de la marca de tiempo de «Cuenta activada» o se captura mediante un estado final terminal como «Onboarding completado» en el expediente del caso.

Recopilar

Se infiere a partir del último evento positivo relevante, como la activación de la cuenta, o de una actualización de estado final.

Tipo de evento inferred
Revisión de cumplimiento completada
La persona responsable de cumplimiento completa la revisión y formula una recomendación, trasladando el caso a la siguiente etapa. Esto puede capturarse explícitamente cuando una tarea se marca como «completada» o inferirse cuando el estado cambia de «Cumplimiento pendiente» a otro estado.
Por qué es importante

Este es un hito clave que concluye una parte crítica y a menudo manual del proceso. Es el punto final para medir la duración de la revisión de cumplimiento.

Dónde obtenerlo

Se captura a partir de la marca de tiempo de finalización de una tarea de cumplimiento o de un cambio de estado que indique la salida de «En revisión de cumplimiento».

Recopilar

Se infiere a partir de un cambio de estado que indique que la revisión ha finalizado, como el paso a «Aprobada», «Rechazada» o «Decisión final».

Tipo de evento inferred
Revisión de cumplimiento iniciada
El caso se asigna a una persona responsable de cumplimiento o a un equipo para su revisión manual, normalmente cuando se trata de solicitudes de alto riesgo. Esto suele inferirse a partir de un cambio de estado a «Revisión de cumplimiento pendiente» o de un registro de asignación de tareas.
Por qué es importante

Esto marca el inicio de un paso de revisión manual que a menudo es prolongado. Medir el tiempo desde este punto hasta su finalización ayuda a cuantificar los cuellos de botella relacionados con el cumplimiento.

Dónde obtenerlo

Se captura a partir de un registro de asignación de tareas, un cambio de titularidad del caso a un equipo de cumplimiento o una actualización de estado en el historial del caso.

Recopilar

Se infiere a partir de un cambio de estado como «En revisión de cumplimiento» o cuando el caso se asigna a una cola de usuarios relacionada con el cumplimiento.

Tipo de evento inferred
Solicitud aprobada
Se toma y registra en el sistema la decisión final de aprobar la solicitud del cliente. Este es un resultado empresarial crítico y casi siempre se captura como un cambio de estado explícito.
Por qué es importante

Este hito marca la conclusión satisfactoria del proceso de toma de decisiones. Analizar las rutas que conducen a la aprobación ayuda a identificar las mejores prácticas.

Dónde obtenerlo

Busque una actualización de estado final en el registro del caso de la solicitud, donde el estado se establezca como «Aprobada» o como un estado terminal similar.

Recopilar

Se registra como un cambio de estado final y definitivo en la tabla principal de solicitudes o casos.

Tipo de evento explicit
Solicitud enviada
Marca el inicio del proceso de onboarding de KYC, cuando el sistema recibe por primera vez la solicitud de un cliente. Este evento suele capturarse explícitamente cuando el formulario de solicitud se envía a través de un portal de clientes o un sistema interno de introducción de datos integrado con LexisNexis.
Por qué es importante

Este es el evento de inicio principal del proceso. Analizar el tiempo transcurrido desde esta actividad hasta la finalización es fundamental para medir el tiempo de ciclo completo y el cumplimiento de los SLA.

Dónde obtenerlo

Se captura a partir de los registros del sistema o de una tabla de solicitudes que registra la marca de tiempo inicial de creación de una nueva solicitud de cliente.

Recopilar

El evento se registra al crear un nuevo caso de solicitud o una entrada en la tabla principal de solicitudes.

Tipo de evento explicit
Solicitud rechazada
Se registra la decisión final de rechazar la solicitud del cliente. Este es un evento terminal y se captura mediante un cambio de estado definitivo en el sistema.
Por qué es importante

Este es el evento final principal del estado fallido. Analizar las etapas en las que se producen los rechazos y sus motivos asociados es fundamental para mejorar el proceso.

Dónde obtenerlo

Se captura cuando el campo de estado final del registro de la solicitud se establece como «Rechazada», «Denegada» o un estado terminal similar.

Recopilar

Se registra como un cambio de estado final y definitivo en la tabla principal de solicitudes o casos.

Tipo de evento explicit
Cuenta activada
Después de la aprobación, la cuenta del cliente se crea y activa formalmente en la plataforma bancaria principal o de servicios. Esta actividad suele registrarse en un registro de auditoría o inferirse a partir de la fecha de creación de la cuenta.
Por qué es importante

Este es el paso final de entrega de valor al cliente. Las demoras entre «Solicitud aprobada» y este paso pueden indicar problemas de integración entre sistemas.

Dónde obtenerlo

Se captura a partir de un registro de creación de cuenta, una llamada a la API de otro sistema o la propia marca de tiempo de creación del registro de la cuenta.

Recopilar

Se registra como un evento independiente posterior a la aprobación o se identifica mediante la presencia de una marca de tiempo de activación en el registro del cliente.

Tipo de evento explicit
Documentos solicitados
El sistema o una persona usuaria solicita al cliente documentación específica, como un permiso de conducir o una factura de servicios. Este evento puede capturarse a partir de los registros de comunicaciones generados por el sistema o de un cambio de estado que indique que el caso está a la espera de documentos.
Por qué es importante

Esta actividad suele introducir un tiempo de espera considerable en el proceso. Analizar su frecuencia y duración ayuda a identificar las demoras causadas por los tiempos de respuesta de los clientes.

Dónde obtenerlo

Busque un evento en los registros de comunicaciones enviadas al cliente o un cambio de estado en la solicitud, por ejemplo, «Documentos del cliente pendientes».

Recopilar

Se infiere a partir de un cambio de estado a «A la espera de documentos» o de la marca de tiempo de un registro de comunicación saliente.

Tipo de evento inferred
Evaluación inicial realizada
Comprobación automatizada que el sistema realiza inmediatamente después del envío para validar que los datos básicos estén completos y ejecutar verificaciones preliminares. Esta actividad suele registrarse como un paso automatizado explícito en el historial del Workflow del proceso.
Por qué es importante

Identifica las solicitudes que fallan en la primera etapa y ayuda a comprender los problemas de calidad de los datos. También marca el primer paso automatizado que aporta valor al proceso.

Dónde obtenerlo

Busque registros de ejecución de reglas automatizadas o un cambio de estado en el historial del Workflow de la solicitud que indique la finalización de la evaluación inicial.

Recopilar

Se registra como una tarea automatizada completada o como una actualización de estado específica en el historial del caso.

Tipo de evento explicit
Información adicional solicitada
Una persona responsable de cumplimiento o revisora solicita al cliente más información o aclaraciones. Este evento es uno de los principales impulsores del retrabajo y normalmente se captura como un cambio de estado explícito o una entrada en el registro de comunicaciones.
Por qué es importante

Esta actividad crea bucles de retrabajo que prolongan el tiempo de ciclo del onboarding. Hacer un seguimiento de su frecuencia ayuda a identificar requisitos poco claros o deficiencias habituales en las solicitudes.

Dónde obtenerlo

Busque un cambio de estado a «Información del cliente pendiente» o un evento en el registro de comunicaciones salientes. A menudo se trata de una acción iniciada por una persona usuaria.

Recopilar

Se registra cuando una persona agente utiliza la función «Solicitar información», que cambia el estado del caso y puede registrar un evento de comunicación.

Tipo de evento explicit
Revisión documental realizada
Una persona usuaria o una herramienta automatizada revisa los documentos enviados para comprobar su autenticidad, validez e integridad. Esta actividad puede inferirse a partir de un cambio de estado de «Documentos recibidos» a «Revisión completada» o de una entrada explícita en el registro.
Por qué es importante

Esta es una fuente habitual de cuellos de botella y retrabajo. Analizar su tiempo de procesamiento y sus repeticiones es clave para mejorar la eficiencia e identificar oportunidades de automatización.

Dónde obtenerlo

Se infiere mediante el seguimiento del tiempo entre un estado de «Documentos recibidos» y un estado posterior como «Verificación superada» o «Información adicional requerida».

Recopilar

Se calcula como el tiempo transcurrido entre el evento de recepción de documentos y el evento que marca la finalización de la revisión.

Tipo de evento inferred
Verificación de identidad iniciada
Representa el momento en que el sistema inicia el proceso principal de verificación de identidad mediante los servicios de LexisNexis, como la comprobación en bases de datos. Normalmente se captura como un evento explícito en el registro de eventos cuando se llama al servicio de verificación.
Por qué es importante

Esta actividad marca el inicio de un subproceso crítico y, a menudo, prolongado. Medir su duración ayuda a aislar los cuellos de botella relacionados con las comprobaciones de identidad.

Dónde obtenerlo

Se captura a partir de los registros de llamadas a la API del módulo de verificación de identidad o de una entrada en el registro de auditoría que muestre el inicio de la tarea de verificación.

Recopilar

Se registra un evento cuando se activa el módulo o la API de verificación de identidad del sistema para la solicitud.

Tipo de evento explicit
Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de LexisNexis Risk Solutions

¿Listo para comenzar?

Aproveche esta plantilla para iniciar su recorrido de Process Mining en la incorporación de clientes KYC. Empiece hoy mismo a transformar sus datos en información útil para la toma de decisiones.

Optimice su incorporación KYC y reduzca hoy mismo el abandono

Logre una incorporación sin fricciones y reduzca el tiempo a solo 24 horas.

Iniciar la prueba gratuita

No necesita tarjeta de crédito. Empiece a optimizar hoy mismo.