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

Su plantilla de datos para el onboarding 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 plantilla de datos para el onboarding de clientes KYC

Esta plantilla le guía en la recopilación de los datos esenciales para analizar su proceso de onboarding de clientes KYC. Describe los atributos fundamentales que debe capturar, las actividades clave que debe seguir y ofrece orientación para extraer esta información de sus sistemas de origen. Utilice este recurso para asegurarse de disponer de todos los datos necesarios para analizar y mejorar eficazmente el proceso.

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 de Process Mining.

Descargar Template

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.

3 Obligatorio 5 Recomendado 11 Opcional

	Nombre	Descripción
	Hora del evento EventTime	La marca de tiempo que indica cuándo tuvo lugar una actividad o evento específico.
Descripción Event Time proporciona la fecha y hora exactas en las que se registró una actividad. Esta marca de tiempo constituye 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 basados en el tiempo de Process Mining. Se utiliza para calcular las duraciones entre actividades, incluidos los 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 basadas en la duración, descubrir la secuencia del proceso y realizar análisis de cuellos de botella. Dónde obtenerlo Es un campo estándar en cualquier registro de eventos o tabla de registros de auditoría, normalmente denominado «Timestamp», «EventDate» o «CreationDate». Ejemplos 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
	Nombre de la actividad ActivityName	El nombre de un evento empresarial o una tarea específicos que tuvieron lugar dentro del proceso de onboarding KYC.
Descripción Activity Name describe un único paso o evento del recorrido de onboarding del cliente, como «Application Submitted», «Analyst Review Started» o «Screening Completed - Clear». Estas actividades forman los nodos del mapa de procesos y ofrecen un desglose detallado del Workflow de principio a fin. El análisis de las actividades es el núcleo de Process Mining. Al realizar 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 provocan demoras o retrabajo. Este atributo es fundamental para crear mapas de procesos y calcular métricas a nivel de 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 registros de eventos o tablas de registros de auditoría, normalmente 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 de cliente CustomerApplication	El identificador único de la solicitud de onboarding de un cliente, que actúa como identificador principal del caso.
Descripción Customer Application es el identificador central del caso que agrupa todos los eventos y actividades relacionados con el proceso de onboarding de un cliente. Permite realizar un seguimiento completo y cronológico del avance de cada cliente durante todo el proceso Know Your Customer (KYC), desde el envío inicial hasta la decisión final. En el análisis de Process Mining, este atributo es fundamental para reconstruir el recorrido integral 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 comprender las distintas rutas que puede seguir una solicitud, identificar cuellos de botella y comparar la eficiencia de diferentes procesos de onboarding. Por qué es importante Este es el identificador esencial del caso que conecta todas las actividades relacionadas y permite analizar el proceso de onboarding del cliente de principio a fin. Dónde obtenerlo Normalmente, este identificador es la clave principal de la tabla principal de solicitudes o gestión de casos del sistema Refinitiv World-Check o de un CRM integrado. Ejemplos APP-2023-00123APP-2023-00124APP-2023-00125
	Departamento DepartmentName	El departamento o equipo funcional responsable de realizar la actividad.
Descripción Este atributo especifica la unidad de negocio o el equipo, como «Onboarding», «Compliance» o «Quality Assurance», al que pertenece el usuario. Permite analizar el proceso desde una perspectiva organizativa más amplia que la del usuario individual. Analizar por departamento es fundamental para identificar cuellos de botella entre departamentos y medir los tiempos de transferencia. Ayuda a visualizar cómo fluye el trabajo entre los distintos equipos y dónde se producen demoras durante estas transiciones. Esta perspectiva es muy valiosa para agilizar la colaboración interfuncional 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 las transferencias entre distintos equipos. Dónde obtenerlo Esta información puede almacenarse en el perfil del usuario dentro del sistema o en un sistema de RR. HH. asociado. Puede ser necesario combinarla 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	La fecha objetivo en la que debería completarse el proceso de onboarding del cliente.
Descripción SLA Target Date es la fecha límite para completar todo el caso de onboarding, según lo definido en el acuerdo de nivel de servicio con el cliente o en las políticas internas. Esta fecha es el punto de referencia con el que se comparan los tiempos reales de finalización. Este atributo es fundamental para el panel «SLA Adherence and Breach Analysis». 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 provocan demoras y permite a la organización tomar medidas correctivas para mejorar la puntualidad y cumplir los requisitos de cumplimiento. Por qué es importante Es el punto de referencia para medir el rendimiento puntual y resulta fundamental para calcular la tasa de cumplimiento del SLA y analizar los incumplimientos. Dónde obtenerlo Esta fecha suele calcularse a partir de la fecha de envío de la solicitud y de las reglas de negocio. Puede almacenarse como 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	La marca de tiempo que indica cuándo se completó una actividad o evento específico.
Descripción Event End Time marca la finalización de una actividad. Aunque muchos eventos pueden modelarse como instantáneos, cuando StartTime es igual a EndTime, algunas actividades tienen una duración medible, como «Analyst Review Started» y «Analyst Review Completed». Disponer de las horas de inicio y finalización permite medir con precisión el tiempo de procesamiento. En el análisis de procesos, contar con una hora de finalización es fundamental para calcular el tiempo exacto de procesamiento de una actividad, a diferencia del tiempo de ciclo, que incluye el tiempo de espera. Esto ayuda a distinguir entre el tiempo que un caso se está gestionando activamente y el tiempo que permanece inactivo en una cola. 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 obtener un análisis de rendimiento más exacto. Dónde obtenerlo En las actividades con duración, puede almacenarse en un campo independiente como «CompletionDate» o «EndDate» en el registro de eventos o en las tablas de registros de auditoría. Ejemplos 2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
	ID del revisor ReviewerId	El identificador del usuario, analista o agente automatizado que realizó la actividad.
Descripción Reviewer ID, o usuario, indica quién ejecutó una tarea concreta del proceso KYC. Puede tratarse de un analista de cumplimiento, un especialista en onboarding o una cuenta del sistema para actividades automatizadas. El seguimiento de esta información proporciona visibilidad sobre la distribución de 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, identificar necesidades de formación y optimizar el equilibrio de la carga de trabajo. También es un componente clave para analizar las transferencias, las redes sociales y la utilización 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 las transferencias entre departamentos, aspectos fundamentales para optimizar los recursos. Dónde obtenerlo Suele encontrarse en registros de eventos o registros de auditoría, normalmente con nombres como «UserID», «PerformedBy» u «Owner». Ejemplos analyst_jdoesystem_auto_screenermanager_bsmith
	Nivel de riesgo RiskLevel	La clasificación de riesgo calculada para la solicitud del cliente, como Bajo, Medio o Alto.
Descripción El nivel de riesgo es un dato fundamental en los procesos KYC, ya que determina el nivel de diligencia debida necesario. A menudo se establece según factores como el tipo de cliente, la geografía y la naturaleza de su actividad. Esta clasificación puede influir considerablemente en la ruta que sigue una aplicación. En el análisis de procesos, es esencial segmentar los casos por nivel de riesgo. Esto ayuda a explicar las variaciones en los tiempos de ciclo y los flujos de proceso. Por ejemplo, las aplicaciones de alto riesgo pueden requerir más pasos y tardar más tiempo. Este atributo es clave para los Dashboards de «Tasa y motivos de rechazo de aplicaciones» y «Tiempo de ciclo hasta el inicio de la comprobación de antecedentes», ya que permite comprender cómo afecta el riesgo a los resultados y a la eficiencia. Por qué es importante Segmentar el proceso por nivel de riesgo es fundamental para comprender por qué determinados casos tardan más o siguen rutas diferentes, así como para analizar las tasas de rechazo. Dónde obtenerlo Es un dato principal de la solicitud del cliente o del registro del caso. Consulte el módulo de gestión de casos de Refinitiv World-Check. Ejemplos BajoMedioAlto
	Canal de solicitud ApplicationChannel	El canal a través del cual se envió la solicitud del cliente, como Portal en línea, Sucursal o Aplicación móvil.
Descripción Application Channel indica el origen del envío de la solicitud del cliente. Los distintos canales pueden presentar niveles diferentes de integridad y calidad de los datos, así como perfiles demográficos distintos, lo que puede afectar al proceso posterior. Este atributo es esencial para el panel «Application Throughput by Channel». Al analizar el volumen, el tiempo de ciclo y los resultados de las solicitudes procedentes de distintos canales, una organización puede identificar cuáles son más eficientes y cuáles requieren mejoras del proceso. Este análisis respalda las decisiones estratégicas sobre asignación de recursos e inversión en canales. Por qué es importante Ayuda a analizar el rendimiento y la eficiencia de los distintos canales de envío 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 un atributo del registro de la solicitud. Ejemplos Portal en líneaAplicación móvilEn sucursalGestor de relaciones
	Es automatizado IsAutomated	Un indicador que señala si la actividad la realizó un sistema (true) o una persona (false).
Descripción Este atributo booleano distingue entre las tareas automatizadas del sistema y las actividades manuales realizadas por usuarios. Por ejemplo, «Automated Screening Performed» se marcaría como automatizada, mientras que «Analyst Review Started» sería manual. Esta distinción es fundamental para analizar la automatización. Permite medir el impacto de la automatización en la eficiencia del proceso, identificar las tareas manuales candidatas a una futura automatización y comprender la interacción entre las personas y los sistemas. También permite separar claramente el tiempo de procesamiento del sistema del tiempo dedicado a la gestión manual. Por qué es importante Distingue entre actividades del sistema y actividades humanas, un aspecto clave para medir el impacto de la automatización e identificar nuevas oportunidades de automatización. Dónde obtenerlo Normalmente se determina a partir del nombre de la actividad o del ID de usuario asociado al evento, por ejemplo, cuando el usuario es una cuenta del «sistema». Ejemplos truefalse
	Es retrabajo IsRework	Indicador que señala si una actividad se está realizando por segunda vez o más dentro del mismo caso.
Descripción IsRework es un atributo booleano calculado que identifica cuándo una actividad se repite dentro del mismo caso de solicitud de cliente. Por ejemplo, si «Risk Assessment Performed» ocurre más de una vez para una misma solicitud, las apariciones posteriores se marcan como retrabajo. Este atributo es fundamental para identificar ineficiencias del proceso, bucles y repeticiones innecesarias. Es compatible directamente con el Dashboard «Risk Assessment Rework and Efficiency» y el KPI «Risk Assessment Rework Rate». El análisis del retrabajo ayuda a descubrir problemas de calidad, falta de claridad en la información o toma de decisiones, que generan esfuerzos desperdiciados y ciclos más largos. Por qué es importante Pone de manifiesto las ineficiencias del proceso al señalar las actividades repetidas, lo que permite analizar los bucles de retrabajo para 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 señalando cualquier aparición que no sea la primera de una actividad. Ejemplos truefalse
	ID de coincidencia MatchId	El identificador único de una posible coincidencia encontrada durante un screening de World-Check.
Descripción Cuando el proceso de screening automatizado encuentra una posible coincidencia con listas de sanciones, listas de PEP o medios adversos, suele generarse un Match ID para realizar un seguimiento del hallazgo específico. Este ID vincula el caso de la solicitud con el registro concreto de la base de datos de World-Check que activó la alerta. Este atributo es útil para el análisis detallado de cumplimiento. Permite a los analistas investigar la naturaleza de las coincidencias, realizar un seguimiento de la resolución de alertas específicas, por ejemplo, confirmar un falso positivo o una coincidencia verdadera, y comprender qué tipos de alertas son más frecuentes o tardan más en resolverse. Aporta un nivel de detalle más profundo sobre la actividad «Potential Match Identified». Por qué es importante Proporciona un vínculo detallado con los resultados específicos del screening y permite analizar con mayor profundidad los tiempos de resolución y los tipos de alerta. Dónde obtenerlo Este ID lo generaría el motor de screening de World-Check y se registraría en el caso de la solicitud cuando se encuentra una posible coincidencia. Ejemplos WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
	ID del cliente CustomerId	Un identificador único de la entidad del cliente que se está incorporando.
Descripción Customer ID es el identificador único del perfil del cliente. Se diferencia del Customer Application ID, ya que un mismo cliente puede enviar varias solicitudes a lo largo del tiempo. Este atributo vincula el proceso de onboarding con el registro maestro del cliente. En el análisis, Customer ID permite realizar un seguimiento de las solicitudes repetidas del mismo cliente y enriquecer los datos del proceso con otros atributos del cliente procedentes de un CRM o de un sistema de datos maestros. Esto proporciona una visión más completa del recorrido del cliente, más allá de una única instancia de onboarding. Por qué es importante Vincula el caso de onboarding con un cliente específico y permite analizar 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
	Motivo del rechazo RejectionReason	El motivo específico indicado cuando se rechaza una solicitud de cliente.
Descripción Cuando se rechaza una solicitud, Rejection Reason registra el motivo de la decisión. Entre los motivos pueden encontrarse «Sanctions Match», «Incomplete Documentation» o «High Risk Profile». Esto proporciona información estructurada y valiosa sobre la calidad de las solicitudes recibidas y la eficacia del proceso de screening. Este atributo es el principal impulsor del panel «Application Rejection Rate and Reasons». Analizar estos motivos ayuda a identificar las causas raíz de los rechazos, lo que puede conducir a mejoras del proceso, una comunicación más clara con los solicitantes y una posible reducción de los rechazos innecesarios. Aporta contexto cualitativo al KPI cuantitativo de la tasa de rechazo. Por qué es importante Proporciona la causa raíz de los rechazos de solicitudes, algo esencial para identificar áreas de mejora en el proceso de onboarding y reducir la tasa de rechazo. Dónde obtenerlo Se registraría cuando se produce el evento «Application Rejected», probablemente como un campo del registro del caso o de la solicitud. Ejemplos Coincidencia con PEPCoincidencia en lista de sancionesVerificación de documentos fallidaNoticias desfavorables
	País del cliente CustomerCountry	El país de residencia o 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 del riesgo y los requisitos regulatorios de los procesos KYC. Cada jurisdicción tiene normas diferentes, 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 las normativas locales. Aporta una dimensión geográfica al análisis del proceso que puede revelar diferencias operativas importantes. Por qué es importante Permite analizar geográficamente el proceso y ayuda a identificar variaciones regionales en el rendimiento, el riesgo 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	El 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 en una extracción de una sola fuente, resulta fundamental cuando se combinan datos de varios sistemas, como un CRM y World-Check, para crear una visión integral del proceso. En el análisis, ayuda a gestionar los datos, solucionar problemas y comprender su contexto. Por ejemplo, las actividades registradas en un sistema principal de screening pueden tener propiedades o niveles de detalle diferentes de los de un sistema periférico. Así se garantiza que la trazabilidad de los datos sea clara y auditable. Por qué es importante Identifica el origen de los datos, algo fundamental para la gestión y validación de datos y para combinar datos de varias fuentes. Dónde obtenerlo A menudo es un valor estático añadido durante el proceso de extracción, transformación y carga (ETL) para etiquetar el conjunto de datos. Ejemplos Refinitiv World-CheckWorldCheckOne
	SLA incumplido SlaBreached	Indicador booleano que señala si el caso de onboarding se completó después de su fecha objetivo del SLA.
Descripción Este atributo es un indicador calculado que señala si un caso ha incumplido su acuerdo de nivel de servicio. Se determina comparando la marca de tiempo de la actividad final de finalización, por ejemplo, «Application Approved» o «Application Rejected», con «SlaTargetDate» del caso. Este indicador constituye la base del Dashboard «SLA Adherence and Breach Analysis» y del KPI «SLA Adherence Rate». Simplifica el análisis, ya que permite filtrar rápidamente todos los casos con incumplimiento. Al analizar las características del proceso en estos casos, las organizaciones pueden identificar las causas raíz de los retrasos y orientar eficazmente sus iniciativas de mejora. Por qué es importante Mide directamente el cumplimiento de los acuerdos de nivel de servicio y facilita el filtrado y el análisis de las causas raíz de los casos retrasados. Dónde obtenerlo Se calcula durante la transformación de datos comparando la marca de tiempo de la actividad final de un caso con el campo SlaTargetDate. Ejemplos truefalse
	Tipo de cliente CustomerType	La clasificación del cliente, como Persona física, Empresa o Fideicomiso.
Descripción Customer Type categoriza la entidad que se incorpora. Los distintos tipos de clientes suelen tener requisitos de onboarding, perfiles de riesgo y obligaciones regulatorias diferentes. Por ejemplo, incorporar una empresa suele ser más complejo que incorporar a una persona física. Este atributo se utiliza para el análisis de segmentación, especialmente en el panel «KYC Customer Type Performance». 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 onboarding para cada tipo de cliente. Por qué es importante Permite comparar el rendimiento entre distintos segmentos de clientes y ayuda a adaptar y optimizar el proceso de onboarding para cada tipo. Dónde obtenerlo Es un atributo fundamental almacenado en el registro del cliente o de la solicitud dentro del sistema de origen. Ejemplos Persona físicaEmpresaOrganización sin fines de lucroFideicomiso
	Última actualización de datos LastDataUpdate	La marca de tiempo en la que los datos de este evento se actualizaron o extrajeron por última vez del 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. Esto 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. Resulta esencial para la gobernanza de datos y para gestionar las expectativas de los usuarios sobre la actualidad de la información proporcionada. Por qué es importante Proporciona un contexto fundamental sobre la actualidad de los datos y garantiza que los usuarios comprendan hasta qué punto está actualizado el análisis del proceso. Dónde obtenerlo Esta marca de tiempo se genera y 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 del proceso que debe registrar en su registro de eventos para descubrir el proceso con precisión.

8 Recomendado 6 Opcional

	Actividad	Descripción
	Coincidencia verdadera confirmada	Un analista confirma que una posible coincidencia corresponde efectivamente al cliente sometido a screening, lo que identifica un posible riesgo. Este es un hito crítico que normalmente activa una diligencia debida adicional o el 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 Se trata de una acción explícita del usuario en la que el analista clasifica una coincidencia específica como «True Match» o «Confirmed Match». Este evento se registra en el registro de auditoría del caso. Recopilar 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 principal, con lo que finaliza el proceso de onboarding. Esto ocurre después de la aprobación final de la solicitud y deja la cuenta lista para utilizarse.
Por qué es importante Este es el último paso del proceso que aporta valor. La duración desde el envío de la solicitud hasta la activación de la cuenta es una métrica clave de 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 principal o en el sistema de cuentas de clientes y debe correlacionarse mediante el Customer Application ID. Recopilar Evento registrado en el sistema principal de cuentas tras la activación de la cuenta. Tipo de evento explicit
	Revisión del analista iniciada	Un analista de cumplimiento inicia la investigación manual de las posibles coincidencias de una solicitud de cliente. Esto implica evaluar los detalles de las posibles coincidencias frente a la información del cliente para determinar su relevancia.
Por qué es importante Esto marca el inicio de la revisión manual de cumplimiento, un cuello de botella habitual. Medir el tiempo desde «Potential Match Identified» hasta esta actividad revela las 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 «reclama» o abre un caso desde la cola de revisión. El sistema puede registrar explícitamente este evento en un registro de auditoría cuando el estado del caso cambia a «In Review» o se asigna a un usuario específico. Recopilar Se infiere a partir de un cambio del estado del caso a «Under Review» o de la asignación del caso a un analista. Tipo de evento inferred
	Screening completado: coincidencia encontrada	El caso de screening se cierra oficialmente con un resultado «Match Found», lo que indica que se identificó un riesgo confirmado. Esta decisión activa un proceso posterior diferente, como una diligencia debida reforzada o el rechazo.
Por qué es importante Este es el principal punto final de la «ruta no deseada» del proceso de screening. Analizar estos casos ayuda a comprender los perfiles de riesgo y la eficacia de los controles de screening. Dónde obtenerlo Se infiere a partir del cambio del estado final del caso a «Match Found», «Risk Identified» o «Closed - Positive». Se utiliza la marca de tiempo de este cambio de estado final. Recopilar Se deriva de la marca de tiempo del estado final del caso que indica una coincidencia confirmada. Tipo de evento inferred
	Screening completado: sin coincidencias	El caso de screening se cierra oficialmente con un resultado «Clear», lo que significa que no se encontraron coincidencias verdaderas. Esta decisión se comunica al sistema de origen, lo que permite continuar con el proceso de onboarding.
Por qué es importante Esta actividad representa la finalización satisfactoria, o «ruta ideal», del proceso de screening. Es un punto final clave para medir el tiempo de ciclo de las solicitudes estándar y de bajo riesgo. Dónde obtenerlo Se infiere a partir del cambio del estado final del caso a «Clear», «Complete» o «Closed - No Match». Se utiliza la marca de tiempo de este cambio de estado final. Recopilar Se deriva de la marca de tiempo del estado final del caso que indica un resultado sin coincidencias. Tipo de evento inferred
	Solicitud de revisión creada	En el sistema Refinitiv World-Check se crea formalmente un nuevo caso de comprobación para una solicitud de cliente. Esto se activa mediante una llamada a la API o una entrada manual desde un sistema anterior y representa el inicio de la comprobación de inteligencia de riesgos.
Por qué es importante Este evento marca el inicio oficial del subproceso de comprobación. El tiempo transcurrido entre «Application Submitted» y esta actividad revela retrasos en las transferencias 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 registro de auditoría de World-Check. Se utilizarían el evento de creación y su marca de tiempo para el caso o ID de entidad específico. Recopilar Se registra automáticamente cuando se crea un nuevo caso de comprobación en el sistema. Tipo de evento explicit
	Solicitud enviada	Esta actividad marca el inicio del proceso KYC onboarding, cuando un cliente envía su solicitud. Este evento suele capturarse en un CRM o en un sistema central de solicitudes, que posteriormente 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 del cliente. Analizar el tiempo transcurrido desde este punto hasta la finalización proporciona el tiempo de ciclo total de incorporación, un indicador fundamental 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 Customer Application. Recopilar Evento registrado en el sistema de la aplicación de origen tras el envío inicial. Tipo de evento explicit
	Solicitud rechazada	La solicitud del cliente se rechaza formalmente, a menudo como resultado de un «Match Found» en World-Check u otros factores de riesgo. Este evento es el resultado negativo final del proceso de onboarding.
Por qué es importante Este es el principal punto final de fallo del proceso. Analizar los eventos de rechazo, especialmente sus motivos y las actividades anteriores, es fundamental para mejorar el proceso y reducir los rechazos innecesarios. Dónde obtenerlo Esta decisión empresarial final se registra en el CRM ascendente o en el sistema de aplicación principal, no en World-Check. Los datos deben obtenerse de ese sistema. Recopilar Evento registrado en el sistema de aplicación de origen, normalmente con un código de motivo de rechazo asociado. Tipo de evento explicit
	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 responsable para que tome la decisión final. Este es un punto clave de transferencia dentro del equipo de cumplimiento.
Por qué es importante Las escalaciones suelen crear cuellos de botella y aumentar el tiempo de ciclo. Analizar su frecuencia y sus motivos puede revelar necesidades de formación para 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 Workflow o en el registro de auditoría del caso. También puede inferirse a partir de un cambio del usuario asignado al caso, especialmente cuando se asigna a un usuario con permisos superiores. Recopilar Se registra mediante un botón «Escalate» específico o una acción del Workflow dentro del caso. Tipo de evento explicit
	Falso positivo confirmado	El analista concluye que una posible coincidencia no corresponde al cliente sometido a screening. La coincidencia se descarta y el proceso de screening de esa alerta específica queda resuelto.
Por qué es importante Este es un resultado habitual del proceso de revisión. Comprender cuánto tiempo se tarda en resolver los falsos positivos ayuda a medir la eficiencia de los analistas y la precisión de la lógica de screening automatizado. Dónde obtenerlo Se trata de una acción explícita del usuario en la que el analista clasifica una coincidencia específica como «False Positive» o «Not a Match». Esta acción suele registrarse en el historial del caso. Recopilar 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 proporciona la información.
Por qué es importante La aparición frecuente de esta actividad indica problemas en la calidad de los datos iniciales proporcionados para el screening. Esta actividad introduce demoras importantes, ya que depende de equipos externos, y es uno de los principales factores de los tiempos de ciclo prolongados. 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 del estado del caso a «Pending Information» o «RFI». Recopilar Se registra cuando un analista utiliza una función para marcar que el caso necesita más información. Tipo de evento explicit
	Posible coincidencia identificada	El proceso de screening automatizado ha encontrado una o más posibles coincidencias que requieren la revisión manual de un analista. Este evento traslada el caso de un estado automatizado a una cola de investigación manual.
Por qué es importante Esta actividad es un punto de bifurcación crítico del proceso. Los casos con posibles coincidencias siguen una ruta más larga y compleja, y su seguimiento ayuda a planificar los recursos y analizar los cuellos de botella del equipo de revisión. Dónde obtenerlo Se infiere a partir del cambio del estado del caso a «Review Required», «Potential Match» o un estado similar dentro del módulo de gestión de casos de World-Check. Recopilar Se deriva de un cambio en el estado del caso que indica que ahora se necesita una revisión manual. Tipo de evento inferred
	Revisión automatizada realizada	El sistema World-Check comprueba automáticamente los datos del cliente frente a su base de datos de inteligencia de riesgos. Esta actividad, impulsada 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 dentro del proceso de screening. Las demoras anteriores indican problemas de disponibilidad del sistema o de preparación de los datos, mientras que el resultado determina la carga de trabajo manual posterior. Dónde obtenerlo Este evento puede registrarse explícitamente en el registro de auditoría del caso o inferirse a partir de la marca de tiempo en la que los resultados iniciales del screening están disponibles para el caso. Recopilar Entrada del registro del sistema generada al completar el escaneo automatizado de la base de datos. Tipo de evento explicit
	Solicitud aprobada	La solicitud del cliente se ha aprobado por completo tras un screening KYC satisfactorio y cualquier otra comprobación necesaria. Este evento suele producirse en el sistema de origen después de recibir un resultado «Clear» de World-Check.
Por qué es importante Esto marca el resultado empresarial satisfactorio del proceso de onboarding. Medir el tiempo desde el envío hasta este punto revela el «tiempo hasta la aprobación» completo de un nuevo cliente. Dónde obtenerlo Este evento no es nativo de World-Check. Debe obtenerse del CRM ascendente o del sistema de aplicación principal, que es el que toma la decisión empresarial final. Recopilar Evento registrado en el sistema de aplicación de origen tras la aprobación final. 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 Case Management: Abra la sección Case Management, donde se almacenan y gestionan todos los casos de screening.
Prepare la exportación del informe de casos: Acceda a la función de informes o exportación dentro de Case Management. Puede aparecer como «Export Cases» o «Case Report».
Configure el informe de casos: Seleccione las columnas que desea incluir en la exportación. Asegúrese de seleccionar los campos correspondientes al ID del caso (CustomerApplication), la fecha de creación, la fecha de resolución, el estado del caso, por ejemplo, Clear o Match Found, y el nivel de riesgo.
Exporte los datos de Case Management: Defina el intervalo de fechas, normalmente 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 informes del registro de auditoría de World-Check One. Esta sección contiene el historial detallado de eventos de cada caso.
Configure y exporte el registro de auditoría: Seleccione todas las columnas relevantes, incluido 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 del informe de casos. Guarde el archivo como audit_trail.csv.
Obtenga los pasos del proceso externo: Recopile los datos de las actividades que tienen lugar fuera de World-Check, como Application Submitted, Application Approved, Account Activated y Application Rejected. Normalmente, estos datos proceden de un CRM o de un sistema bancario central. Exporte los datos con el ID CustomerApplication y las marcas de tiempo correspondientes.
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 script de preparación de datos.
Asigne los eventos de auditoría a las actividades: Procese el archivo audit_trail.csv. Asigne las descripciones de eventos sin procesar del registro de auditoría a los valores estandarizados de ActivityName. Por ejemplo, una entrada del registro como «Case Assigned to Analyst» se convierte en «Analyst Review Started».
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 del caso y el estado final para crear los eventos «Screening Completed - Clear» o «Screening Completed - Match Found».
Cree el registro de eventos final: Una todos los datos procesados de los distintos archivos de origen en un único archivo CSV. Asegúrese de que el archivo final contenga las columnas obligatorias: CustomerApplication, ActivityName y EventTime, además de los atributos recomendados. Guarde este archivo para cargarlo en la herramienta de Process Mining.

Configuración

Tipos de informe: Deberá generar al menos dos informes independientes: un informe resumido de Case Management y un informe detallado del registro de auditoría.
Intervalo de fechas: Para un análisis inicial, seleccione un intervalo de al menos 3 a 6 meses que incluya suficientes casos completados y en curso. Asegúrese de que el intervalo sea coherente en todos los archivos exportados.
Formato de exportación: Elija CSV (valores separados por comas) como formato de exportación para facilitar el procesamiento.
Columnas clave (informe de casos): Asegúrese de que la exportación de casos 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: Necesita acceso al portal de World-Check One con permisos que permitan consultar y exportar datos de Case Management y del registro de auditoría. Es posible que necesite privilegios superiores a los de un rol de analista estándar.

a 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. Obtenga su API Key y API Secret de World-Check One a través de su representante de Refinitiv o del portal para desarrolladores. 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 su API Key y API Secret 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, que almacena los datos iniciales de la solicitud. 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: Utilizando el token autenticado, realice una solicitud GET al endpoint /cases de la API de World-Check One. Use parámetros de consulta para filtrar los casos por un intervalo de fechas específico, por ejemplo, según su 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. Su script debe comprobar los detalles de paginación de la respuesta y recorrer todas las páginas para recuperar la lista completa de casos del intervalo especificado.
Recupere los detalles y el historial de los casos: Para cada ID de caso recuperado, realice 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 sin procesar a las actividades: Este es un paso de transformación fundamental. Escriba la lógica necesaria para recorrer los datos de respuesta de la API, incluidos los detalles del caso y el registro de auditoría, para cada caso. Asigne determinados cambios de estado, códigos de resultado y eventos de auditoría a las actividades empresariales requeridas. Por ejemplo, un evento de creación de caso se convierte en Screening Request Created, y una resolución con el resultado False Positive se convierte en False Positive Confirmed.
Combine las fuentes de datos: Combine los datos extraídos de World-Check con los datos del sistema de origen del paso 3. Utilice el ID CustomerApplication como clave común para crear un registro de eventos completo de extremo a extremo para cada cliente.
Estructure y enriquezca los datos: Reúna todos los eventos asignados en una única lista de registros. Para cada registro, asegúrese de completar todos los atributos obligatorios (CustomerApplication, ActivityName, EventTime) y los atributos recomendados. Calcule EventEndTime cuando sea posible, por ejemplo, utilizando la marca de tiempo del evento siguiente de ese caso.
Exporte a CSV: Convierta la lista final de registros en un DataFrame de pandas. Reordene las columnas para que coincidan con el formato requerido y exporte el DataFrame a un archivo CSV. Asegúrese de guardar el archivo con codificación UTF-8 para que sea compatible con ProcessMind.

Configuración

Credenciales de la API: Se necesitan una API Key y una API Secret válidas para la API de screening de World-Check One. Deben contar con los permisos necesarios para leer los datos de casos y auditoría.
URL base de la API: El script debe configurarse 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: Implemente los parámetros start_date y end_date en el script para controlar el periodo de extracción. Para el análisis inicial, se recomienda un intervalo de 3 a 6 meses. Para la supervisión continua, ejecute el script de forma incremental en periodos más cortos, como el día o la semana anteriores.
Conexión con el sistema de origen: Necesita los datos de conexión de los sistemas anteriores y posteriores, por ejemplo, el CRM o la plataforma bancaria central, para obtener los eventos que no pertenecen al screening. Puede tratarse de una cadena de conexión a una base de datos u otro endpoint de API, junto con sus credenciales.
Gestión de la paginación: El script debe especificar un tamaño de página, normalmente denominado limit, al realizar llamadas a la API para enumerar los casos. Un valor entre 50 y 100 suele ser eficiente. La lógica debe gestionar correctamente la recuperación de todas las páginas.

a 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()

¿Listo para comenzar?

Utilice esta plantilla de datos para iniciar su recorrido de Process Mining en el onboarding de clientes KYC. Si sigue estas directrices, descubrirá información valiosa e impulsará mejoras significativas en sus operaciones.

Volver a la guía de mejora Descargar Template

Optimice ahora el onboarding de clientes KYC y refuerce el cumplimiento

Consiga un onboarding de clientes sin fricciones y reduzca el tiempo a solo 24 horas.

Iniciar la prueba gratuita

No necesita tarjeta de crédito. Disfrute de 14 días gratis.

Su plantilla de datos para el onboarding de clientes KYC

Su plantilla de datos para el onboarding 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 registro de auditoría de Refinitiv World-Check One

Pasos

Configuración

a Consulta de ejemplo sql

Script de Python con la API de screening de World-Check One

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice ahora el onboarding de clientes KYC y refuerce el cumplimiento

Su plantilla de datos para el onboarding de clientes KYC

Su plantilla de datos para el onboarding 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 registro de auditoría de Refinitiv World-Check One

Pasos

Configuración

a Consulta de ejemplo sql

Script de Python con la API de screening de World-Check One

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice ahora el onboarding de clientes KYC y refuerce el cumplimiento

Valoramos su privacidad