> Mejora continua de procesos > Incorporación de clientes KYC > Refinitiv World Check > Template de datos

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

Refinitiv World-Check

Atributos de la incorporación de clientes KYC(19) Actividades de incorporación de clientes KYC(14) Guías de extracción(2)

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

Este Template le guía en la recopilación de los datos esenciales para analizar el proceso de incorporación de clientes KYC. Describe los atributos clave que debe registrar, las actividades principales que debe seguir y cómo extraer esta información de los sistemas de origen. Utilice este recurso para reunir todos los datos necesarios y analizar y mejorar el proceso de forma eficaz.

Atributos recomendados para recopilar
Actividades clave que debe seguir
Guía de extracción

¿Es nuevo en los registros de eventos? Aprenda a crear un Registro de eventos para Process Mining.

Descargar Template

Atributos de la incorporación de clientes KYC

Estos son los campos de datos recomendados para incluir en el Registro de eventos y realizar un análisis completo de la incorporación de clientes KYC.

3 Obligatorio 5 Recomendado 11 Opcional

	Nombre	Descripción
	Hora del evento EventTime	Marca de tiempo que indica cuándo se produjo una actividad o un evento específicos.
Descripción La hora del evento indica la fecha y hora exactas en que se registró una actividad. Esta marca de tiempo es la base cronológica del proceso y permite ordenar correctamente los eventos para reconstruir el historial del caso. Este atributo es fundamental para todos los análisis temporales de Process Mining. Se utiliza para calcular la duración entre actividades (tiempos de ciclo y de espera), medir la duración total del caso, analizar el rendimiento del proceso a lo largo del tiempo y comprobar el cumplimiento de los acuerdos de nivel de servicio (SLA). Sin marcas de tiempo precisas, es imposible comprender el rendimiento del proceso e identificar cuellos de botella temporales. Por qué es importante La marca de tiempo de cada actividad es esencial para calcular todas las métricas de duración, descubrir la secuencia del proceso y analizar los cuellos de botella. Dónde obtenerlo Es un campo estándar en cualquier registro de eventos o tabla del historial de auditoría, que suele llamarse 'Timestamp', 'EventDate' o 'CreationDate'. Ejemplos 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
	Nombre de la actividad ActivityName	Nombre de un evento empresarial o una tarea específicos que tuvieron lugar durante el proceso de incorporación KYC.
Descripción El nombre de la actividad describe un paso o evento del proceso de incorporación del cliente, como 'Solicitud presentada', 'Revisión del analista iniciada' o 'Verificación completada: sin coincidencias'. Estas actividades forman los nodos del mapa del proceso y ofrecen un desglose detallado del flujo de trabajo de principio a fin. El análisis de las actividades es la base de Process Mining. Al hacer un seguimiento de la secuencia y la frecuencia de las distintas actividades, los analistas pueden descubrir el flujo real del proceso, identificar las rutas habituales, detectar desviaciones del procedimiento estándar y localizar los pasos concretos que causan demoras o retrabajo. Este atributo es fundamental para crear mapas de procesos y calcular métricas por actividad. Por qué es importante Este atributo define los pasos individuales del proceso, algo esencial para descubrir y visualizar el flujo del proceso e identificar cuellos de botella. Dónde obtenerlo Esta información suele encontrarse en los registros de eventos o en las tablas del historial de auditoría, a menudo asociada a cambios de estado en la entidad de gestión de casos. Ejemplos Posible coincidencia identificadaRevisión del analista iniciadaFalso positivo confirmadoSolicitud aprobada
	Solicitud del cliente CustomerApplication	Identificador único de la solicitud de incorporación de un cliente, que sirve como identificador principal del caso.
Descripción La solicitud del cliente es el identificador central del caso que agrupa todos los eventos y actividades relacionados con el proceso de incorporación de un cliente. Permite hacer un seguimiento cronológico completo del avance de cada cliente en todo el proceso de Conozca a su cliente (KYC), desde la presentación inicial hasta la decisión final. En el análisis de Process Mining, este atributo es fundamental para reconstruir el recorrido completo de cada solicitud. Permite visualizar los flujos del proceso, calcular los tiempos de ciclo totales e identificar variantes. Al analizar los casos agrupados por este identificador, las organizaciones pueden conocer las distintas rutas que puede seguir una solicitud, detectar cuellos de botella y comparar la eficiencia de los diferentes procesos de incorporación. Por qué es importante Este es el identificador esencial del caso que conecta todas las actividades relacionadas y permite analizar de principio a fin el proceso de incorporación del cliente. Dónde obtenerlo Suele ser la clave principal de la tabla principal de solicitudes o de gestión de casos del sistema Refinitiv World-Check o de un CRM integrado. Ejemplos APP-2023-00123APP-2023-00124APP-2023-00125
	Departamento DepartmentName	Departamento o equipo funcional responsable de realizar la actividad.
Descripción Este atributo especifica la unidad de negocio o el equipo al que pertenece el usuario, como 'Incorporación', 'Cumplimiento' o 'Control de calidad'. Permite analizar el proceso desde una perspectiva organizativa más amplia que la de cada usuario. El análisis por departamento es fundamental para identificar cuellos de botella entre departamentos y medir los tiempos de traspaso. Ayuda a visualizar cómo fluye el trabajo entre los distintos equipos y dónde se producen demoras en esas transiciones. Esta perspectiva es muy útil para agilizar la colaboración entre funciones y mejorar la eficiencia general del proceso. Por qué es importante Permite analizar el rendimiento del proceso por departamento y es esencial para identificar demoras en los traspasos entre equipos. Dónde obtenerlo Esta información puede estar almacenada en el perfil del usuario en el sistema o en un sistema de RR. HH. asociado. Es posible que deba vincularse con los datos de eventos mediante el ID de usuario. Ejemplos Equipo de incorporaciónRevisión de cumplimientoAlta dirección
	Fecha objetivo del SLA SlaTargetDate	Fecha límite para completar el proceso de incorporación del cliente.
Descripción La fecha objetivo del SLA es la fecha límite para completar todo el caso de incorporación, según lo establecido en el acuerdo de nivel de servicio con el cliente o en las políticas internas. Esta fecha sirve como referencia para medir los tiempos reales de finalización. Este atributo es fundamental para el Dashboard 'Análisis del cumplimiento y los incumplimientos del SLA'. Se utiliza para calcular si un caso se completó a tiempo. Analizar los incumplimientos del SLA ayuda a identificar problemas sistémicos del proceso que causan demoras y permite tomar medidas correctivas para mejorar la puntualidad y cumplir los requisitos de cumplimiento. Por qué es importante Es la referencia para medir el rendimiento puntual y resulta fundamental para calcular la tasa de cumplimiento del SLA y analizar sus incumplimientos. Dónde obtenerlo Esta fecha suele calcularse a partir de la fecha de presentación de la solicitud y de las reglas de negocio. Puede almacenarse en un campo del registro del caso. Ejemplos 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
	Hora de finalización del evento EventEndTime	Marca de tiempo que indica cuándo se completó una actividad o un evento específicos.
Descripción La hora de finalización del evento marca el momento en que concluye una actividad. Aunque muchos eventos pueden modelarse como instantáneos (cuando StartTime es igual a EndTime), algunas actividades tienen una duración medible, como 'Revisión del analista iniciada' y 'Revisión del analista completada'. Disponer de las horas de inicio y fin permite medir con precisión el tiempo de procesamiento. En el análisis de procesos, la hora de finalización es esencial para calcular el tiempo exacto de procesamiento de una actividad, a diferencia del tiempo de ciclo, que incluye el tiempo de espera. Esto permite distinguir entre el tiempo que se dedica a trabajar activamente en un caso y el tiempo que permanece inactivo en una cola. Esta distinción es clave para optimizar los recursos y analizar la eficiencia. Por qué es importante Permite calcular con precisión el tiempo de procesamiento de una actividad y separar el tiempo de trabajo activo del tiempo de espera inactivo para analizar el rendimiento con mayor exactitud. Dónde obtenerlo En las actividades con duración, este dato puede almacenarse en un campo independiente, como 'CompletionDate' o 'EndDate', en las tablas del registro de eventos o del historial de auditoría. Ejemplos 2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
	ID del revisor ReviewerId	Identificador del usuario, analista o agente automatizado que realizó la actividad.
Descripción El ID del revisor o usuario indica quién ejecutó una tarea concreta del proceso KYC. Puede tratarse de un analista de cumplimiento, un especialista en incorporación o una cuenta del sistema para actividades automatizadas. El seguimiento de esta información permite conocer cómo se distribuye la carga de trabajo y el rendimiento individual. Este atributo es esencial para el análisis basado en recursos. Ayuda a comprender las diferencias de rendimiento entre usuarios o equipos, detectar necesidades de formación y equilibrar mejor la carga de trabajo. También es clave para analizar los traspasos, las redes sociales y el uso de los recursos de cumplimiento. Por qué es importante Permite analizar la distribución de la carga de trabajo, el rendimiento de los usuarios y los traspasos entre departamentos, algo fundamental para optimizar los recursos. Dónde obtenerlo Suele encontrarse en los registros de eventos o en los historiales de auditoría, con nombres como 'UserID', 'PerformedBy' u 'Owner'. Ejemplos analyst_jdoesystem_auto_screenermanager_bsmith
	Nivel de riesgo RiskLevel	Clasificación calculada del riesgo de la solicitud del cliente, como bajo, medio o alto.
Descripción El nivel de riesgo es un dato clave en los procesos KYC, ya que determina el grado de diligencia debida necesario. Suele establecerse en función de factores como el tipo de cliente, la ubicación geográfica y la naturaleza de su actividad. Esta clasificación puede influir considerablemente en la ruta que sigue una solicitud. En el análisis de procesos, es fundamental segmentar los casos por nivel de riesgo. Esto ayuda a explicar las variaciones en los tiempos de ciclo y los flujos del proceso. Por ejemplo, las solicitudes de alto riesgo pueden requerir más pasos y tardar más. Este atributo es clave para los Dashboards 'Tasa y motivos de rechazo de solicitudes' y 'Tiempo de ciclo hasta el inicio de la verificación de antecedentes', que permiten comprender cómo influye el riesgo en los resultados y la eficiencia. Por qué es importante Segmentar el proceso por nivel de riesgo es fundamental para comprender por qué algunos casos tardan más o siguen rutas distintas, y para analizar las tasas de rechazo. Dónde obtenerlo Es un dato esencial del registro de la solicitud del cliente o del caso. Consulte el módulo de gestión de casos de Refinitiv World-Check. Ejemplos BajoMedioAlto
	Canal de solicitud ApplicationChannel	Canal por el que se presentó la solicitud del cliente, como portal en línea, sucursal o aplicación móvil.
Descripción El canal de solicitud indica el medio por el que se presentó la solicitud del cliente. Los distintos canales pueden variar en cuanto a la integridad y calidad de los datos y al perfil demográfico de los clientes, lo que puede repercutir en las etapas posteriores del proceso. Este atributo es esencial para el Dashboard 'Volumen de solicitudes por canal'. Al analizar el volumen, el tiempo de ciclo y los resultados de las solicitudes de cada canal, una organización puede identificar cuáles son más eficientes y cuáles podrían necesitar mejoras. Este análisis respalda las decisiones estratégicas sobre la asignación de recursos y la inversión en canales. Por qué es importante Ayuda a analizar el rendimiento y la eficiencia de los distintos canales de presentación, y aporta información para tomar decisiones estratégicas sobre tecnología y experiencia del cliente. Dónde obtenerlo Esta información suele capturarse al inicio del proceso y almacenarse como atributo en el registro de la solicitud. Ejemplos Portal en líneaAplicación móvilSucursalGerente de relaciones
	Es automatizada IsAutomated	Indicador que señala si la actividad la realizó un sistema (verdadero) o una persona (falso).
Descripción Este atributo booleano distingue entre las tareas automatizadas del sistema y las actividades manuales que realizan las personas usuarias. Por ejemplo, «Verificación automatizada realizada» se marcaría como automatizada, mientras que «Revisión del analista iniciada» se marcaría como manual. Esta distinción es fundamental para analizar la automatización. Ayuda a medir su impacto en la eficiencia del proceso, identificar las tareas manuales que podrían automatizarse en el futuro y comprender la interacción entre las personas y los sistemas. Además, permite separar claramente el tiempo de procesamiento del sistema del tiempo dedicado a la gestión manual. Por qué es importante Distingue las actividades del sistema de las realizadas por personas, algo esencial para medir el impacto de la automatización e identificar nuevas oportunidades para automatizar. Dónde obtenerlo Por lo general, se determina a partir del nombre de la actividad o del ID de usuario asociado al evento (por ejemplo, si el usuario corresponde a una cuenta del sistema). Ejemplos truefalse
	Es una repetición IsRework	Indicador que señala si una actividad se realiza por segunda vez o más dentro del mismo caso.
Descripción IsRework es un atributo booleano calculado que identifica cuándo se repite una actividad dentro del mismo caso de solicitud de un cliente. Por ejemplo, si «Evaluación de riesgos realizada» ocurre más de una vez en una solicitud, las repeticiones posteriores se marcan como retrabajo. Este atributo es fundamental para detectar ineficiencias, ciclos y repeticiones innecesarias en el proceso. Sirve de apoyo directo al Dashboard «Retrabajo y eficiencia de la evaluación de riesgos» y al KPI «Tasa de retrabajo de la evaluación de riesgos». Analizar el retrabajo ayuda a detectar problemas de calidad, claridad de la información o toma de decisiones que generan esfuerzo innecesario y alargan los tiempos de ciclo. Por qué es importante Señala las actividades repetidas para poner de manifiesto las ineficiencias del proceso y analizar los ciclos de retrabajo, mejorar la calidad y reducir los tiempos de ciclo. Dónde obtenerlo Se calcula durante la transformación de datos, analizando la secuencia de actividades de cada caso y marcando todas las repeticiones posteriores a la primera. Ejemplos truefalse
	ID de coincidencia MatchId	Identificador único de una posible coincidencia detectada durante una verificación de World-Check.
Descripción Cuando el proceso de verificación automatizada encuentra una posible coincidencia con listas de sanciones, listas de personas políticamente expuestas (PEP) o noticias desfavorables, suele generar un ID de coincidencia para identificar el hallazgo. Este ID vincula el caso de solicitud con el registro específico de la base de datos World-Check que generó la alerta. Este atributo resulta útil para realizar un análisis de cumplimiento detallado. Permite a los analistas investigar la naturaleza de las coincidencias, hacer seguimiento de la resolución de alertas específicas (por ejemplo, confirmar un falso positivo o una coincidencia real) y determinar qué tipos de alertas son más frecuentes o tardan más en resolverse. También ofrece más detalles sobre la actividad «Posible coincidencia identificada». Por qué es importante Vincula de forma precisa los resultados específicos de la verificación y permite analizar con más detalle los tiempos de resolución de coincidencias y los tipos de alertas. Dónde obtenerlo El motor de verificación de World-Check generaría este ID y lo registraría en el caso de solicitud cuando encontrara una posible coincidencia. Ejemplos WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
	ID del cliente CustomerId	Identificador único de la entidad del cliente que se está incorporando.
Descripción El ID del cliente es el identificador único del perfil del cliente. Se diferencia del ID de solicitud del cliente, ya que un mismo cliente puede presentar varias solicitudes a lo largo del tiempo. Este atributo vincula el proceso de incorporación con el registro maestro del cliente. En el análisis, el ID del cliente permite hacer un seguimiento de las solicitudes repetidas de un mismo cliente y enriquecer los datos del proceso con otros atributos del cliente procedentes de un CRM o de un sistema de datos maestros. Así se obtiene una visión más completa del recorrido del cliente, más allá de una única incorporación. Por qué es importante Vincula el caso de incorporación con un cliente específico, lo que permite analizar las solicitudes repetidas y enriquecer los datos con información maestra del cliente. Dónde obtenerlo Sería un campo clave del registro de la solicitud o del caso que lo vincula con los datos maestros del cliente. Ejemplos CUST-98765CUST-98766CUST-98767
	Incumplimiento del SLA SlaBreached	Indicador booleano que señala si el caso de incorporación se completó después de la fecha objetivo del SLA.
Descripción Este atributo calculado indica si un caso incumplió su acuerdo de nivel de servicio. Se determina comparando la marca de tiempo de la actividad final de cierre (por ejemplo, «Solicitud aprobada» o «Solicitud rechazada») con el campo «SlaTargetDate» del caso. Este indicador sirve de base para el Dashboard «Análisis del cumplimiento e incumplimiento del SLA» y el KPI «Tasa de cumplimiento del SLA». Facilita el análisis porque permite filtrar rápidamente todos los casos con incumplimientos. Al analizar las características del proceso en esos casos, las organizaciones pueden identificar las causas raíz de las demoras y orientar mejor las iniciativas de mejora. Por qué es importante Mide directamente el cumplimiento de los acuerdos de nivel de servicio y facilita el filtrado de casos demorados y el análisis de sus causas raíz. Dónde obtenerlo Se calcula durante la transformación de datos, comparando la marca de tiempo de la actividad final de cada caso con el campo SlaTargetDate. Ejemplos truefalse
	Motivo del rechazo RejectionReason	Motivo específico indicado para rechazar una solicitud de cliente.
Descripción Cuando se rechaza una solicitud, el motivo del rechazo indica por qué se tomó esa decisión. Entre los motivos posibles se incluyen 'Coincidencia en una lista de sanciones', 'Documentación incompleta' o 'Perfil de alto riesgo'. Esta información estructurada ofrece datos valiosos sobre la calidad de las solicitudes recibidas y la eficacia del proceso de verificación. Este atributo es el principal para el Dashboard 'Tasa y motivos de rechazo de solicitudes'. Analizar estos motivos ayuda a identificar las causas raíz de los rechazos, lo que puede dar lugar a mejoras en el proceso, una comunicación más clara con quienes presentan las solicitudes y una posible reducción de los rechazos innecesarios. Aporta contexto cualitativo a la tasa de rechazo cuantitativa del KPI. Por qué es importante Permite conocer las causas raíz de los rechazos de solicitudes, algo esencial para identificar aspectos que se pueden mejorar en el proceso de incorporación y reducir la tasa de rechazo. Dónde obtenerlo Se registraría cuando se produce el evento 'Solicitud rechazada', probablemente en un campo del registro del caso o de la solicitud. Ejemplos Coincidencia con una persona políticamente expuesta (PEP)Coincidencia en una lista de sancionesVerificación de documentos fallidaInformación negativa en medios
	País del cliente CustomerCountry	País de residencia o de constitución del cliente.
Descripción Este atributo indica la ubicación geográfica del cliente. El país es un factor importante en la evaluación de riesgos y los requisitos normativos de los procesos KYC. Cada jurisdicción tiene reglas distintas que pueden afectar al flujo y la duración del proceso. Analizar el proceso por país permite a las organizaciones comparar el rendimiento entre regiones, identificar cuellos de botella específicos de cada ubicación y garantizar el cumplimiento de la normativa local. Añade una dimensión geográfica al análisis del proceso y puede revelar diferencias operativas importantes. Por qué es importante Permite analizar el proceso desde una perspectiva geográfica y ayuda a identificar diferencias regionales en el rendimiento, los riesgos y los requisitos de cumplimiento. Dónde obtenerlo Es un campo estándar del perfil del cliente o del formulario de solicitud. Ejemplos USAGBRSGPDEU
	Sistema de origen SourceSystem	Sistema del que se extrajeron los datos del evento; en este caso, Refinitiv World-Check.
Descripción Este atributo identifica el origen de los datos del proceso. Aunque puede tener un valor constante cuando la extracción procede de una sola fuente, resulta fundamental al combinar datos de varios sistemas, como un CRM y World-Check, para obtener una visión integral del proceso. En el análisis, ayuda a la gobernanza de datos, la resolución de problemas y la comprensión del contexto de los datos. Por ejemplo, las actividades registradas en un sistema central de verificación pueden tener propiedades o niveles de detalle distintos de los de un sistema periférico. Así se garantiza que el linaje de los datos sea claro y auditable. Por qué es importante Identifica el origen de los datos, algo fundamental para la gobernanza y la validación de datos, así como para combinar datos de varias fuentes. Dónde obtenerlo A menudo es un valor estático que se añade durante el proceso de extracción, transformación y carga (ETL) para identificar el conjunto de datos. Ejemplos Refinitiv World-CheckWorldCheckOne
	Tipo de cliente CustomerType	Clasificación del cliente, como persona física, empresa o fideicomiso.
Descripción El tipo de cliente clasifica a la entidad que se incorpora. Los distintos tipos de clientes suelen tener requisitos de incorporación, perfiles de riesgo y obligaciones normativas diferentes. Por ejemplo, incorporar una empresa suele ser más complejo que incorporar a una persona física. Este atributo se utiliza para segmentar el análisis, en particular en el Dashboard 'Rendimiento KYC por tipo de cliente'. Permite comparar la eficiencia del proceso, los tiempos de ciclo y las tasas de rechazo entre distintos segmentos de clientes. Así, las organizaciones pueden adaptar y optimizar la experiencia de incorporación para cada tipo de cliente. Por qué es importante Permite comparar el rendimiento de distintos segmentos de clientes y ayuda a adaptar y optimizar el proceso de incorporación para cada tipo. Dónde obtenerlo Es un atributo fundamental que se almacena en el registro del cliente o de la solicitud en el sistema de origen. Ejemplos Persona físicaEmpresaOrganización sin fines de lucroFideicomiso
	Última actualización de datos LastDataUpdate	Marca de tiempo de la última actualización o extracción de los datos de este evento desde el sistema de origen.
Descripción Este atributo indica la actualidad de los datos. Registra la fecha y hora de la última extracción de datos de Refinitiv World-Check. Es importante para comprender la vigencia de los Dashboards y análisis de Process Mining. Desde el punto de vista analítico, permite saber si se están consultando datos casi en tiempo real o una instantánea de un momento concreto. Es fundamental para la gobernanza de datos y para gestionar las expectativas sobre la actualidad de la información proporcionada. Por qué es importante Aporta contexto clave sobre la actualidad de los datos y permite saber hasta qué fecha está actualizado el análisis del proceso. Dónde obtenerlo Esta marca de tiempo se genera y se añade durante el proceso de extracción de datos (ETL). Ejemplos 2023-11-01T02:00:00Z2023-11-02T02:00:00Z

Obligatorio Recomendado Opcional

Actividades de incorporación de clientes KYC

Estos son los pasos e hitos clave que debe registrar en el Registro de eventos para descubrir el proceso con precisión.

8 Recomendado 6 Opcional

	Actividad	Descripción
	Coincidencia verdadera confirmada	Un analista confirma que la posible coincidencia corresponde al cliente que se está verificando e identifica un posible riesgo. Este es un hito clave que suele dar lugar a una diligencia debida adicional o al rechazo de la solicitud.
Por qué es importante Este es un resultado clave para mitigar riesgos y un momento decisivo del proceso. Influye directamente en la decisión final sobre la solicitud del cliente y es fundamental para los informes y análisis de cumplimiento. Dónde obtenerlo Esta es una acción explícita del usuario: el analista clasifica una coincidencia específica como 'Coincidencia verdadera' o 'Coincidencia confirmada'. Este evento queda registrado en el historial de auditoría del caso. Capturar Se registra cuando un analista confirma formalmente una coincidencia en el sistema. Tipo de evento explicit
	Cuenta activada	La cuenta del cliente se crea y activa en el sistema central, con lo que finaliza el proceso de incorporación. Esto ocurre después de la aprobación final de la solicitud y deja la cuenta lista para su uso.
Por qué es importante Este es el último paso del proceso y el que aporta valor. El tiempo transcurrido desde la presentación de la solicitud hasta la activación de la cuenta es una métrica clave para medir la eficiencia operativa y la satisfacción del cliente. Dónde obtenerlo Este evento no se captura en World-Check. Se registra en el sistema bancario central o en el sistema de cuentas de clientes y debe vincularse mediante el ID de solicitud del cliente. Capturar Evento registrado en el sistema central de cuentas al activar la cuenta. Tipo de evento explicit
	Revisión del analista iniciada	Un analista de cumplimiento inicia la investigación manual de posibles coincidencias en una solicitud de cliente. Para determinar si son pertinentes, compara los datos de las posibles coincidencias con la información del cliente.
Por qué es importante Esto marca el inicio de la revisión manual de cumplimiento, donde suele producirse un cuello de botella. Medir el tiempo entre 'Posible coincidencia identificada' y esta actividad permite detectar demoras en la cola, mientras que la duración de la revisión indica la eficiencia del analista. Dónde obtenerlo Puede inferirse cuando un analista se asigna un caso o lo abre desde la cola de revisión. El sistema también puede registrar explícitamente este evento en el historial de auditoría cuando el estado del caso cambia a 'En revisión' o se asigna a un usuario específico. Capturar Se infiere a partir de un cambio en el estado del caso a 'En revisión' o de la asignación del caso a un analista. Tipo de evento inferred
	Solicitud de comprobación creada	Se crea formalmente un nuevo caso de comprobación para una solicitud de cliente en el sistema Refinitiv World-Check. La creación se activa mediante una llamada a la API o una entrada manual desde un sistema anterior y marca el inicio de la comprobación de inteligencia de riesgos.
Por qué es importante Esto marca el inicio oficial del subproceso de verificación. El tiempo transcurrido entre la presentación de la solicitud y esta actividad revela demoras en los traspasos entre el sistema de la unidad de negocio y la función de cumplimiento. Dónde obtenerlo Se registra en los registros de gestión de casos o en el historial de auditoría de World-Check. Se utilizarían el evento de creación y su marca de tiempo para el caso o el ID de entidad correspondiente. Capturar Se registra automáticamente cuando se crea un nuevo caso de verificación en el sistema. Tipo de evento explicit
	Solicitud enviada	Esta actividad marca el inicio del proceso de incorporación KYC, cuando el cliente envía su solicitud. El evento suele registrarse en un CRM o en un sistema central de solicitudes, que activa el proceso de comprobación en Refinitiv World-Check.
Por qué es importante Este es el evento de inicio principal del proceso integral de incorporación de clientes. Analizar el tiempo transcurrido desde este punto hasta la finalización permite calcular el tiempo de ciclo total de la incorporación, un dato esencial para medir la experiencia del cliente y el cumplimiento de los SLA. Dónde obtenerlo Este evento no es nativo de World-Check. Debe obtenerse de un sistema anterior, como un CRM o una plataforma de gestión de cuentas de clientes, y relacionarse mediante el ID de la solicitud del cliente. Capturar Evento registrado en el sistema de origen cuando se envía la solicitud inicial. Tipo de evento explicit
	Solicitud rechazada	La solicitud del cliente se rechaza formalmente, a menudo porque World-Check encontró una coincidencia u otros factores indican un riesgo. Este evento es el resultado negativo final del proceso de incorporación.
Por qué es importante Este es el principal punto final de fallo del proceso. Analizar los rechazos, en particular sus motivos y las actividades previas, es fundamental para mejorar el proceso y reducir los rechazos innecesarios. Dónde obtenerlo Esta decisión empresarial final se registra en el CRM o en el sistema central de solicitudes, no en World-Check. Los datos deben obtenerse de ese sistema. Capturar Evento registrado en el sistema de solicitudes de origen, a menudo con el código correspondiente al motivo del rechazo. Tipo de evento explicit
	Verificación completada: se encontró una coincidencia	El caso de verificación se cierra oficialmente con el resultado 'Se encontró una coincidencia', lo que indica que se identificó un riesgo confirmado. Esta decisión activa otro proceso posterior, como una diligencia debida reforzada o el rechazo de la solicitud.
Por qué es importante Este es el principal punto final de la ruta no deseada del proceso de verificación. Analizar estos casos ayuda a comprender los perfiles de riesgo y la eficacia de los controles de verificación. Dónde obtenerlo Se infiere a partir del estado final del caso, que cambia a 'Se encontró una coincidencia', 'Riesgo identificado' o 'Cerrado: positivo'. Se utiliza la marca de tiempo de este cambio de estado final. Capturar Se obtiene de la marca de tiempo del estado final del caso que indica una coincidencia confirmada. Tipo de evento inferred
	Verificación completada: sin coincidencias	El caso de verificación se cierra oficialmente con el resultado 'Sin coincidencias', lo que significa que no se encontraron coincidencias verdaderas. Esta decisión se comunica al sistema de origen para que pueda continuar el proceso de incorporación.
Por qué es importante Esta actividad representa la finalización satisfactoria de la ruta ideal del proceso de verificación. Es un punto final clave para medir el tiempo de ciclo de las solicitudes estándar de bajo riesgo. Dónde obtenerlo Se infiere a partir del estado final del caso, que cambia a 'Sin coincidencias', 'Completado' o 'Cerrado: sin coincidencias'. Se utiliza la marca de tiempo de este cambio de estado final. Capturar Se obtiene de la marca de tiempo del estado final del caso que indica que no se encontraron coincidencias. Tipo de evento inferred
	Caso escalado para revisión	Un analista de primer nivel escala un caso complejo o de alto riesgo a un analista sénior o a un gerente para que tome la decisión final. Este es un punto clave de traspaso dentro del equipo de cumplimiento.
Por qué es importante Los escalamientos suelen generar cuellos de botella y aumentar el tiempo de ciclo. Analizar su frecuencia y sus motivos puede revelar necesidades de formación para los analistas júnior o ambigüedades en las políticas de revisión. Dónde obtenerlo Se registra como una acción explícita en el flujo de trabajo del caso o en el historial de auditoría. También puede inferirse a partir de un cambio en el usuario asignado al caso, especialmente si se trata de un usuario con permisos superiores. Capturar Se registra mediante un botón específico 'Escalar' o una acción del flujo de trabajo dentro del caso. Tipo de evento explicit
	Falso positivo confirmado	El analista concluye que la posible coincidencia no corresponde al cliente que se está verificando. Descarta la coincidencia y resuelve la verificación de esa alerta.
Por qué es importante Este es un resultado habitual del proceso de revisión. Conocer cuánto tiempo se tarda en resolver los falsos positivos ayuda a medir la eficiencia del analista y la precisión de la lógica de verificación automatizada. Dónde obtenerlo Esta es una acción explícita del usuario: el analista clasifica una coincidencia específica como 'Falso positivo' o 'No es una coincidencia'. Por lo general, esta acción queda registrada en el historial del caso. Capturar Se registra cuando un analista descarta formalmente una posible coincidencia en el sistema. Tipo de evento explicit
	Información adicional solicitada	El analista determina que necesita más información para resolver la posible coincidencia y la solicita a la unidad de negocio. El caso queda pendiente hasta que se proporcione la información.
Por qué es importante La frecuencia de esta actividad indica problemas con la calidad de los datos iniciales proporcionados para la verificación. Esta actividad genera demoras importantes, ya que depende de equipos externos, y es una de las principales causas de los largos tiempos de ciclo. Dónde obtenerlo Puede tratarse de una acción explícita del usuario, registrada en las notas del caso o en el registro de auditoría. También puede inferirse a partir de un cambio en el estado del caso a 'Información pendiente' o 'Solicitud de información'. Capturar Se registra cuando un analista utiliza una función para indicar que el caso necesita más información. Tipo de evento explicit
	Posible coincidencia identificada	El proceso de verificación automatizada ha encontrado una o más posibles coincidencias que requieren la revisión manual de un analista. Este evento pasa el caso de un estado automatizado a una cola de investigación manual.
Por qué es importante Esta actividad es un punto de decisión clave del proceso. Los casos con posibles coincidencias siguen una ruta más larga y compleja. Hacerles seguimiento ayuda a planificar los recursos y analizar los cuellos de botella del equipo de revisión. Dónde obtenerlo Se infiere a partir de un cambio en el estado del caso a 'Revisión requerida', 'Posible coincidencia' o un estado similar en el módulo de gestión de casos de World-Check. Capturar Se deduce de un cambio en el estado del caso que indica que ahora se necesita una revisión manual. Tipo de evento inferred
	Solicitud aprobada	La solicitud del cliente se ha aprobado por completo tras una verificación KYC satisfactoria y las demás comprobaciones necesarias. Este evento suele producirse en el sistema de origen después de recibir un resultado 'Sin coincidencias' de World-Check.
Por qué es importante Esto marca el resultado empresarial satisfactorio del proceso de incorporación. Medir el tiempo transcurrido desde la presentación hasta este punto permite conocer el tiempo total que se tarda en aprobar a un nuevo cliente. Dónde obtenerlo Este evento no es propio de World-Check. Debe obtenerse del CRM o del sistema central de solicitudes, que es donde se toma la decisión empresarial final. Capturar Evento registrado en el sistema de solicitudes de origen tras la aprobación final. Tipo de evento explicit
	Verificación automatizada realizada	El sistema World-Check compara automáticamente los datos del cliente con su base de datos de inteligencia de riesgos. Esta actividad, ejecutada por el sistema, genera un conjunto inicial de resultados, como posibles coincidencias o un estado sin coincidencias.
Por qué es importante Esta actividad es el primer paso que aporta valor al proceso de verificación. Las demoras previas indican problemas con el sistema o con la disponibilidad de los datos, mientras que el resultado determina el trabajo manual posterior. Dónde obtenerlo Este evento puede registrarse explícitamente en el historial de auditoría del caso o inferirse a partir de la marca de tiempo en que los resultados iniciales de la verificación están disponibles para el caso. Capturar Entrada del registro del sistema generada al finalizar el análisis automatizado de la base de datos. Tipo de evento explicit

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Refinitiv World-Check

Pasos

Inicie sesión en World-Check One: Acceda al portal de Refinitiv World-Check One con sus credenciales.
Vaya a la gestión de casos: Abra la sección de gestión de casos, donde se almacenan y administran todos los casos de verificación.
Prepare la exportación del informe de casos: Vaya a la función de informes o exportación de la sección de gestión de casos. Puede aparecer como «Exportar casos» o «Informe de casos».
Configure el informe de casos: Seleccione las columnas que desea incluir en la exportación. Asegúrese de incluir los campos correspondientes al ID del caso (CustomerApplication), la fecha de creación, la fecha de resolución, el estado del caso (por ejemplo, «Sin coincidencias» o «Coincidencia encontrada») y el nivel de riesgo.
Exporte los datos de gestión de casos: Defina el intervalo de fechas, que normalmente abarca los últimos 3 a 6 meses de actividad. Aplique los filtros necesarios, por ejemplo, por grupo de usuarios o tipo de caso. Exporte los datos como archivo CSV y asígnele el nombre case_report.csv.
Prepare la exportación del registro de auditoría: Vaya a la sección de registro de auditoría o informes de auditoría de World-Check One. Allí encontrará el historial detallado de eventos de cada caso.
Configure y exporte el registro de auditoría: Seleccione todas las columnas pertinentes, como el ID del caso, el nombre o la descripción del evento, la marca de tiempo del evento y el usuario que realizó la acción. Exporte estos datos para el mismo intervalo de fechas que el informe de casos. Guarde el archivo como audit_trail.csv.
Obtenga los pasos del proceso externos: Recopile los datos de las actividades que tienen lugar fuera de World-Check, como Application Submitted, Application Approved, Account Activated y Application Rejected. Estos datos suelen proceder de un CRM o de un sistema bancario central. Expórtelos con el ID CustomerApplication y las marcas de tiempo pertinentes.
Combine y transforme los datos: Cargue los archivos CSV exportados (case_report.csv, audit_trail.csv y los datos del sistema externo) en una herramienta o un script de preparación de datos.
Asigne los eventos de auditoría a las actividades: Procese el archivo audit_trail.csv. Asigne las descripciones originales de los eventos del registro de auditoría a los valores estandarizados de ActivityName. Por ejemplo, una entrada como «Caso asignado a un analista» se convierte en «Revisión del analista iniciada».
Asigne los cambios de estado del caso a las actividades: Procese el archivo case_report.csv para generar actividades a partir de los cambios de estado. Utilice la fecha de resolución y el estado final del caso para crear los eventos «Verificación completada: sin coincidencias» o «Verificación completada: coincidencia encontrada».
Cree el Registro de eventos final: Combine todos los datos procesados de los distintos archivos de origen en un único archivo CSV. Asegúrese de que incluya las columnas obligatorias: CustomerApplication, ActivityName y EventTime, además de los atributos recomendados. Guarde el archivo para cargarlo en la herramienta de Process Mining.

Configuración

Tipos de informes: Deberá generar al menos dos informes distintos: un informe resumido de gestión de casos y un informe detallado del registro de auditoría.
Intervalo de fechas: Para el análisis inicial, seleccione un intervalo de al menos 3 a 6 meses que incluya suficientes casos completados y en curso. Asegúrese de utilizar el mismo intervalo en todos los archivos exportados.
Formato de exportación: Elija CSV (valores separados por comas) para facilitar el procesamiento.
Columnas clave (informe de casos): Asegúrese de que la exportación incluya el ID del caso, la marca de tiempo de creación, la marca de tiempo de resolución, el estado final, el analista asignado y el nivel de riesgo.
Columnas clave (informe del registro de auditoría): Asegúrese de que la exportación del registro de auditoría incluya el ID del caso, la descripción del evento, la marca de tiempo del evento y el ID de usuario.
Requisitos previos: Necesitará acceso al portal de World-Check One con permisos para consultar y exportar datos de gestión de casos y del registro de auditoría. Es posible que necesite privilegios superiores a los de un analista estándar.

Consulta de ejemplo sql

/*
This is a configuration and mapping guide, not an executable script. 
The process relies on manually exporting two reports from World-Check One and combining them with data from an upstream system (e.g., CRM).
*/

-- Step 1: Export 'Case Management Report' as case_report.csv
-- Step 2: Export 'Audit Trail Report' as audit_trail.csv
-- Step 3: Export relevant events from CRM/core system as source_system_events.csv

-- Step 4: Combine and map the files using a script or ETL tool to create the final event log.

-- Mapping logic for final_event_log.csv

-- Part A: Data from source_system_events.csv
SELECT
  ApplicationID AS CustomerApplication,
  'Application Submitted' AS ActivityName,
  SubmissionTimestamp AS EventTime,
  NULL AS EventEndTime,
  OriginatorID AS ReviewerId,
  OriginatingDept AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Submission'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Application Approved' AS ActivityName,
  ApprovalTimestamp AS EventTime,
  NULL AS EventEndTime,
  ApproverID AS ReviewerId,
  ApprovingDept AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Approval'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Account Activated' AS ActivityName,
  ActivationTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Operations' AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Activation'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Application Rejected' AS ActivityName,
  RejectionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ReviewerID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Rejection'

-- Part B: Data from World-Check audit_trail.csv
UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Request Created' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Created%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Automated Screening Performed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Automated Screening Completed%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Potential Match Identified' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Potential Match Found%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Analyst Review Started' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Assigned%' OR EventDescription LIKE '%Review Started%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Additional Information Requested' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Information Requested%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Case Escalated for Review' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Escalated%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'False Positive Confirmed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Match Dismissed as False Positive%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'True Match Confirmed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Match Confirmed as True%'

-- Part C: Data from World-Check case_report.csv
UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Completed - Clear' AS ActivityName,
  ResolutionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ResolverID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskLevel AS RiskLevel,
  NULL AS SlaTargetDate
FROM case_report.csv
WHERE FinalStatus = 'Clear'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Completed - Match Found' AS ActivityName,
  ResolutionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ResolverID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskLevel AS RiskLevel,
  NULL AS SlaTargetDate
FROM case_report.csv
WHERE FinalStatus = 'Match Found'

Pasos

Requisitos previos y configuración: Asegúrese de tener instalado Python 3.6 o una versión posterior, junto con las bibliotecas requests y pandas. Solicite a su representante de Refinitiv o al portal para desarrolladores la clave y el secreto de la API de World-Check One. Guarde estas credenciales de forma segura.
Desarrolle la lógica de autenticación: En su script de Python, cree una función que envíe una solicitud POST al endpoint de autenticación de World-Check One. Utilice la clave y el secreto de la API para obtener un token bearer temporal, necesario para las llamadas posteriores a la API.
Identifique los datos del sistema de origen: El proceso comienza y termina fuera de World-Check. Identifique el sistema de origen, como un CRM o una plataforma bancaria central, donde se almacenan los datos iniciales de las solicitudes. Deberá extraer de este sistema eventos como Application Submitted, Application Approved, Account Activated y Application Rejected. Puede hacerlo mediante una consulta a la base de datos u otra API.
Obtenga los casos de World-Check: Con el token de autenticación, envíe una solicitud GET al endpoint /cases de la API de World-Check One. Utilice parámetros de consulta para filtrar los casos por un intervalo de fechas específico, por ejemplo, según la fecha de creación o modificación.
Gestione la paginación de la API: Las respuestas de la API de World-Check están paginadas. El script debe comprobar los datos de paginación de la respuesta y recorrer todas las páginas para obtener la lista completa de casos del intervalo especificado.
Recupere los detalles y el historial de los casos: Para cada ID de caso obtenido, envíe solicitudes GET adicionales a endpoints como /cases/{case_system_id} y /cases/{case_system_id}/audit-trail. Estos endpoints proporcionan los cambios de estado detallados, la información de resolución y las acciones de los usuarios asociadas al caso.
Asigne los datos originales a las actividades: Este paso de transformación es fundamental. Escriba la lógica para recorrer los datos de respuesta de la API (detalles del caso y registro de auditoría) de cada caso. Asigne los cambios de estado, los códigos de resultado y los eventos de auditoría a las actividades de negocio correspondientes. Por ejemplo, un evento de creación de caso se convierte en Screening Request Created, y un resultado de resolución False Positive se convierte en False Positive Confirmed.
Combine las fuentes de datos: Combine los datos extraídos de World-Check con los del sistema de origen (del paso 3). Utilice el ID CustomerApplication como clave común para crear un Registro de eventos completo de principio a fin para cada cliente.
Estructure y enriquezca los datos: Reúna todos los eventos asignados en una única lista de registros. Asegúrese de que cada registro incluya los atributos obligatorios (CustomerApplication, ActivityName, EventTime) y los atributos recomendados. Cuando sea posible, calcule EventEndTime, por ejemplo, utilizando la marca de tiempo del siguiente evento del caso.
Exporte a CSV: Convierta la lista final de eventos en un DataFrame de pandas. Reordene las columnas para que coincidan con el formato requerido y exporte el DataFrame a un archivo CSV. Guárdelo con codificación UTF-8 para que sea compatible con ProcessMind.

Configuración

Credenciales de la API: Necesitará una clave y un secreto válidos para la API de verificación de World-Check One. Deben contar con los permisos necesarios para consultar los datos de casos y auditoría.
URL base de la API: Configure el script con la URL base correcta para su entorno de la API de World-Check, por ejemplo, https://api.world-check.com/v2/.
Intervalo de fechas: Incluya en el script los parámetros start_date y end_date para definir el período de extracción. Para el análisis inicial, se recomienda un intervalo de 3 a 6 meses. Para el seguimiento continuo, ejecute el script de forma incremental en períodos más cortos, como el día o la semana anteriores.
Conexión al sistema de origen: Necesitará los datos de conexión a los sistemas anteriores y posteriores (por ejemplo, un CRM o una plataforma bancaria central) para obtener los eventos que no corresponden a la verificación. Puede tratarse de una cadena de conexión a una base de datos o de otro endpoint de API con sus credenciales.
Gestión de la paginación: Al consultar la lista de casos mediante la API, el script debe especificar el tamaño de página, que suele indicarse con limit. Normalmente, un valor entre 50 y 100 ofrece un buen rendimiento. La lógica debe recuperar correctamente todas las páginas.

Consulta de ejemplo python

import requests
import pandas as pd
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># --- Configuration and Placeholders ---
WC_API_KEY = class="hl-string">'[Your World-Check API Key]'
WC_API_SECRET = class="hl-string">'[Your World-Check API Secret]'
WC_API_BASE_URL = class="hl-string">'https://api.world-check.com/v2' class=class="hl-string">"hl-comment"># Use correct URL for your environment

class=class="hl-string">"hl-comment"># Date range for the extraction
START_DATE = (datetime.now() - timedelta(days=90)).strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
END_DATE = datetime.now().strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')

class=class="hl-string">"hl-comment"># --- MOCK FUNCTIONS (Replace with actual data source connections) ---

def get_source_system_events(application_ids):
    class="hl-string">"""Simulates fetching pre- and post-screening events from a CRM or core system."""
    print(fclass="hl-string">'Fetching source system events for {len(application_ids)} applications...')
    mock_events = []
    for i, app_id in enumerate(application_ids):
        class=class="hl-string">"hl-comment"># Simulate initial application events
        mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Submitted', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i+5)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Sales'})
        class=class="hl-string">"hl-comment"># Simulate final outcome events
        if i % 3 == 0:
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Approved', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Onboarding'})
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Account Activated', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i-1)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Operations'})
        else:
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Rejected', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Compliance'})
    return mock_events

def get_worldcheck_cases(token):
    class="hl-string">"""Simulates fetching a list of cases from the World-Check API."""
    print(class="hl-string">'Fetching World-Check cases...')
    class=class="hl-string">"hl-comment"># In a real implementation, you would call GET /cases with date filters and handle pagination
    mock_case_list = [
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-001', class="hl-string">'name': class="hl-string">'John Doe', class="hl-string">'caseSystemId': class="hl-string">'WC-001', class="hl-string">'customReference': class="hl-string">'APP-1001', class="hl-string">'creationDate': class="hl-string">'2023-10-01T10:00:00Z', class="hl-string">'riskLevel': class="hl-string">'Medium'},
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-002', class="hl-string">'name': class="hl-string">'Jane Smith', class="hl-string">'caseSystemId': class="hl-string">'WC-002', class="hl-string">'customReference': class="hl-string">'APP-1002', class="hl-string">'creationDate': class="hl-string">'2023-10-02T11:30:00Z', class="hl-string">'riskLevel': class="hl-string">'Low'},
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-003', class="hl-string">'name': class="hl-string">'Peter Jones', class="hl-string">'caseSystemId': class="hl-string">'WC-003', class="hl-string">'customReference': class="hl-string">'APP-1003', class="hl-string">'creationDate': class="hl-string">'2023-10-03T09:05:00Z', class="hl-string">'riskLevel': class="hl-string">'High'}
    ]
    return mock_case_list

def get_worldcheck_case_details(case_system_id, token):
    class="hl-string">"""Simulates fetching the audit trail and results for a single World-Check case."""
    print(fclass="hl-string">'Fetching details for case {case_system_id}...')
    class=class="hl-string">"hl-comment"># This mock data simulates a complex history for one case to generate multiple activities
    if case_system_id == class="hl-string">'WC-001':
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-01T10:05:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-01T10:06:00Z', class="hl-string">'event': class="hl-string">'MATCH_FOUND', class="hl-string">'details': class="hl-string">'Potential match identified', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T14:00:00Z', class="hl-string">'event': class="hl-string">'REVIEW_STARTED', class="hl-string">'details': class="hl-string">'Case assigned', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T15:30:00Z', class="hl-string">'event': class="hl-string">'MATCH_RESOLVED', class="hl-string">'details': class="hl-string">'Match resolved as False Positive', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T11:00:00Z', class="hl-string">'event': class="hl-string">'ESCALATED', class="hl-string">'details': class="hl-string">'Case escalated to senior analyst', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T09:00:00Z', class="hl-string">'event': class="hl-string">'INFORMATION_REQUESTED', class="hl-string">'details': class="hl-string">'Additional documents requested', class="hl-string">'user': class="hl-string">'senior_analyst'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-05T16:00:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed as Clear', class="hl-string">'user': class="hl-string">'senior_analyst'}
            ]
        }
    elif case_system_id == class="hl-string">'WC-003':
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T09:10:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T09:11:00Z', class="hl-string">'event': class="hl-string">'MATCH_FOUND', class="hl-string">'details': class="hl-string">'Potential match identified', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T10:00:00Z', class="hl-string">'event': class="hl-string">'REVIEW_STARTED', class="hl-string">'details': class="hl-string">'Case assigned', class="hl-string">'user': class="hl-string">'analyst2'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T11:25:00Z', class="hl-string">'event': class="hl-string">'MATCH_RESOLVED', class="hl-string">'details': class="hl-string">'Match resolved as True Positive', class="hl-string">'user': class="hl-string">'analyst2'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T12:00:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed with matches', class="hl-string">'user': class="hl-string">'analyst2'}
            ]
        }
    else: class=class="hl-string">"hl-comment"># Simple class="hl-string">'Clear' case
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T11:35:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T11:36:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed as Clear', class="hl-string">'user': class="hl-string">'SYSTEM'}
            ]
        }

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def main():
    class="hl-string">"""Main function to run the extraction process."""
    class=class="hl-string">"hl-comment"># 1. Authenticate (real implementation)
    class=class="hl-string">"hl-comment"># token = get_wc_auth_token()
    token = class="hl-string">'mock_token' class=class="hl-string">"hl-comment"># Using a mock token for this example

    class=class="hl-string">"hl-comment"># 2. Get list of cases from World-Check
    cases = get_worldcheck_cases(token)
    if not cases:
        print(class="hl-string">'No cases found for the specified period.')
        return

    event_log = []

    class=class="hl-string">"hl-comment"># 3. Process each case from World-Check
    for case in cases:
        app_id = case.get(class="hl-string">'customReference')
        if not app_id:
            continue

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Screening Request Created' event
        event_log.append({
            class="hl-string">'CustomerApplication': app_id,
            class="hl-string">'ActivityName': class="hl-string">'Screening Request Created',
            class="hl-string">'EventTime': case[class="hl-string">'creationDate'],
            class="hl-string">'ReviewerId': class="hl-string">'SYSTEM',
            class="hl-string">'DepartmentName': class="hl-string">'Compliance',
            class="hl-string">'RiskLevel': case.get(class="hl-string">'riskLevel')
        })

        details = get_worldcheck_case_details(case[class="hl-string">'caseSystemId'], token)
        for event in details.get(class="hl-string">'auditTrail', []):
            activity = None
            user = event.get(class="hl-string">'user', class="hl-string">'SYSTEM')
            department = class="hl-string">'Compliance' if user != class="hl-string">'SYSTEM' else class="hl-string">'System'
            
            class=class="hl-string">"hl-comment"># 4. Map audit trail events to activities
            if event[class="hl-string">'event'] == class="hl-string">'AUTOMATED_SCREENING':
                activity = class="hl-string">'Automated Screening Performed'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_FOUND':
                activity = class="hl-string">'Potential Match Identified'
            elif event[class="hl-string">'event'] == class="hl-string">'REVIEW_STARTED':
                activity = class="hl-string">'Analyst Review Started'
            elif event[class="hl-string">'event'] == class="hl-string">'INFORMATION_REQUESTED':
                activity = class="hl-string">'Additional Information Requested'
            elif event[class="hl-string">'event'] == class="hl-string">'ESCALATED':
                activity = class="hl-string">'Case Escalated for Review'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_RESOLVED' and class="hl-string">'False Positive' in event[class="hl-string">'details']:
                activity = class="hl-string">'False Positive Confirmed'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_RESOLVED' and class="hl-string">'True Positive' in event[class="hl-string">'details']:
                activity = class="hl-string">'True Match Confirmed'
            elif event[class="hl-string">'event'] == class="hl-string">'CASE_CLOSED' and class="hl-string">'Clear' in event[class="hl-string">'details']:
                activity = class="hl-string">'Screening Completed - Clear'
            elif event[class="hl-string">'event'] == class="hl-string">'CASE_CLOSED' and class="hl-string">'matches' in event[class="hl-string">'details']:
                activity = class="hl-string">'Screening Completed - Match Found'

            if activity:
                event_log.append({
                    class="hl-string">'CustomerApplication': app_id,
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': event[class="hl-string">'timestamp'],
                    class="hl-string">'ReviewerId': user,
                    class="hl-string">'DepartmentName': department,
                    class="hl-string">'RiskLevel': case.get(class="hl-string">'riskLevel')
                })
    
    class=class="hl-string">"hl-comment"># 5. Get events from source system
    application_ids = [case[class="hl-string">'customReference'] for case in cases if case.get(class="hl-string">'customReference')]
    source_events = get_source_system_events(application_ids)
    event_log.extend(source_events)

    class=class="hl-string">"hl-comment"># 6. Create and format DataFrame
    if not event_log:
        print(class="hl-string">'No events were generated.')
        return

    df = pd.DataFrame(event_log)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'CustomerApplication', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Add EventEndTime by shifting the EventTime of the next event
    df[class="hl-string">'EventEndTime'] = df.groupby(class="hl-string">'CustomerApplication')[class="hl-string">'EventTime'].shift(-1)
    
    class=class="hl-string">"hl-comment"># Add placeholder for non-extractable attribute
    df[class="hl-string">'SlaTargetDate'] = pd.NaT

    class=class="hl-string">"hl-comment"># 7. Finalize and Export
    output_columns = [
        class="hl-string">'CustomerApplication',
        class="hl-string">'ActivityName',
        class="hl-string">'EventTime',
        class="hl-string">'EventEndTime',
        class="hl-string">'ReviewerId',
        class="hl-string">'DepartmentName',
        class="hl-string">'RiskLevel',
        class="hl-string">'SlaTargetDate'
    ]
    class=class="hl-string">"hl-comment"># Ensure all required columns exist, even if empty
    for col in output_columns:
        if col not in df.columns:
            df[col] = None
    
    df = df[output_columns]

    output_filename = class="hl-string">'event_log_worldcheck.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%fZ')
    print(fclass="hl-string">'Successfully exported event log to {output_filename}')

if __name__ == class="hl-string">'__main__':
    main()

¿Todo listo para comenzar?

Utilice este Template de datos para iniciar su recorrido de Process Mining en la incorporación de clientes KYC. Siga estas pautas para obtener información valiosa e impulsar mejoras importantes en sus operaciones.

Volver a la guía de mejora

Descargar Template

Optimice ahora la incorporación de clientes KYC y refuerce el cumplimiento

Ofrezca una incorporación de clientes sin fricciones y reduzca el tiempo a solo 24 horas.

Comience la prueba gratuita

No se requiere tarjeta de crédito. Pruebe el servicio gratis durante 14 días.

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

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

Atributos de la incorporación de clientes KYC

Actividades de incorporación de clientes KYC

Guías de extracción

Exportación de casos y registros de auditoría de Refinitiv World-Check One

Pasos

Configuración

Consulta de ejemplo sql

Script de Python con la API de verificación de World-Check One

Pasos

Configuración

Consulta de ejemplo python

¿Todo listo para comenzar?

Optimice ahora la incorporación de clientes KYC y refuerce el cumplimiento