> Mejora Continua de Procesos > Onboarding de Clientes KYC > Refinitiv World Check > Plantilla de Datos

Su Plantilla de Datos de Onboarding de Clientes KYC

Refinitiv World-Check

Atributos de Onboarding de Clientes KYC (20) Actividades de Onboarding de Clientes KYC (14) Guías de Extracción (2)

Su Plantilla de Datos de Onboarding de Clientes KYC

Esta template le guía a través de la recopilación de los datos esenciales para analizar su proceso de Onboarding de Clientes KYC. Describe los atributos cruciales a capturar, las actividades clave a rastrear y proporciona orientación sobre cómo extraer esta información de sus sistemas de origen. Utilice este recurso para asegurarse de tener todos los datos necesarios para un análisis y mejora efectivos del proceso.

Atributos recomendados para recopilar
Actividades clave para el seguimiento
Guía de Extracción

¿Nuevo en registros de eventos? Aprenda cómo crear un registro de eventos para Process Mining.

Descargar Plantilla

Atributos de Onboarding de Clientes KYC

Estos son los campos de datos recomendados para incluir en su registro de eventos para un análisis exhaustivo del Onboarding de Clientes KYC.

3 Requerido 5 Recomendado 12 Opcional

	Nombre	Descripción
	Hora del Evento EventTime	El timestamp que indica cuándo ocurrió una actividad o evento específico.
Descripción La Fecha y Hora del Evento proporciona la fecha y hora precisas en que se registró una actividad. Esta marca de tiempo es la columna vertebral cronológica del proceso, permitiendo que los eventos se ordenen correctamente para reconstruir el historial del caso. Este atributo es crítico para todo análisis basado en el tiempo en la minería de procesos. Se utiliza para calcular duraciones entre actividades (tiempos de ciclo y tiempos de espera), medir la duración total del caso, analizar el rendimiento del proceso a lo largo del tiempo y verificar 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 timestamp para cada actividad es esencial para calcular todas las métricas basadas en la duración, descubrir la secuencia del proceso y realizar el análisis de cuellos de botella. Dónde obtener Este es un campo estándar en cualquier registro de eventos o tabla de pista de auditoría, a menudo llamado '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 o tarea de negocio específico que ocurrió dentro del proceso de onboarding KYC.
Descripción El Nombre de la Actividad describe un solo paso o evento en el proceso de onboarding del cliente, como 'Solicitud Enviada', 'Revisión del Analista Iniciada' o 'Investigación Completada - Aprobado'. Estas actividades forman los nodos del mapa de proceso, proporcionando un desglose detallado del workflow de principio a fin. Analizar las actividades es el núcleo del Process Mining. Al rastrear la secuencia y frecuencia de diferentes actividades, los analistas pueden descubrir el flujo de proceso real, identificar rutas comunes, detectar desviaciones del procedimiento estándar e identificar pasos específicos que causan retrasos o retrabajo. Este atributo es crucial para construir mapas de proceso y calcular métricas a nivel de actividad. Por qué es importante Este atributo define los pasos individuales del proceso, lo cual es esencial para descubrir y visualizar el flujo del proceso e identificar cuellos de botella. Dónde obtener Esta información se encuentra típicamente en registros de eventos o tablas de pistas de auditoría, a menudo asociada con 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	El identificador único para la solicitud de onboarding de un solo cliente, sirviendo como el identificador principal del caso.
Descripción La Solicitud del Cliente es el identificador de caso central que agrupa todos los eventos y actividades relacionados con el proceso de onboarding de un solo cliente. Permite el seguimiento completo y cronológico del progreso de cada cliente a través de 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 viaje de principio a fin de cada solicitud. Permite la visualización de los flujos de proceso, el cálculo de los tiempos de ciclo totales y la identificación de variantes. Al analizar casos agrupados por este identificador, las organizaciones pueden comprender las diferentes rutas que puede tomar una solicitud, identificar cuellos de botella y comparar la eficiencia de varios procesos de onboarding. Por qué es importante Este es el identificador de caso esencial que conecta todas las actividades relacionadas, haciendo posible analizar el proceso de onboarding de clientes de principio a fin. Dónde obtener Este identificador es típicamente la clave primaria en la tabla principal de aplicación o gestión de casos dentro del sistema Refinitiv World-Check o 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 equipo, como 'Onboarding', 'Cumplimiento' o 'Control de Calidad', al que pertenece el usuario. Permite el análisis a un nivel organizacional más alto que el usuario individual. Analizar por departamento es fundamental para identificar cuellos de botella interdepartamentales y medir los tiempos de transferencia. Ayuda a visualizar cómo fluye el trabajo entre diferentes equipos y dónde ocurren los retrasos en estas transiciones. Esta vista es invaluable para optimizar la colaboración interfuncional y mejorar la eficiencia general del proceso. Por qué es importante Permite el análisis del rendimiento del proceso por departamento y es esencial para identificar retrasos en los traspasos entre diferentes equipos. Dónde obtener Esta información puede almacenarse con el perfil del usuario en el sistema o en un sistema de RRHH asociado. Podría necesitar unirse con los datos de eventos utilizando el ID de usuario. Ejemplos Equipo de OnboardingRevisión de CumplimientoAlta Dirección
	Fecha Objetivo de SLA SlaTargetDate	La fecha objetivo en la que debe completarse el proceso de onboarding del cliente.
Descripción La Fecha Objetivo del SLA es la fecha límite para completar todo el caso de onboarding, según lo definido por el acuerdo de nivel de servicio con el cliente o las políticas internas. Esta fecha es el punto de referencia contra el cual se miden los tiempos de finalización reales. Este atributo es fundamental para el dashboard 'Análisis de Adherencia e Incumplimiento del SLA'. Se utiliza para calcular si un caso se completó a tiempo o no. Analizar los incumplimientos del SLA ayuda a identificar problemas sistémicos en el proceso que causan retrasos y permite a la organización tomar medidas correctivas para mejorar la puntualidad y cumplir con los requisitos de cumplimiento. Por qué es importante Este es el punto de referencia para medir el rendimiento a tiempo y es crítico para calcular la tasa de adherencia al SLA y analizar los incumplimientos. Dónde obtener Esta fecha a menudo se calcula en función de la fecha de envío de la solicitud y las reglas de negocio. Puede almacenarse como un campo en el registro del caso. Ejemplos 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
	Hora Fin del Evento EventEndTime	La marca de tiempo que indica cuándo se completó una actividad o evento específico.
Descripción La Hora de Fin del Evento marca la finalización de una actividad. Aunque muchos eventos pueden modelarse como instantáneos (donde HoraInicio es igual a HoraFin), algunas actividades tienen una duración medible, como 'Revisión del Analista Iniciada' y 'Revisión del Analista Completada'. Tener tanto la hora de inicio como la de fin permite una medición precisa del tiempo de procesamiento. En el análisis de procesos, tener una hora de fin es vital para calcular el tiempo de procesamiento exacto de una actividad, a diferencia del tiempo de ciclo que incluye el tiempo de espera. Esto ayuda a diferenciar entre el tiempo que un caso se trabaja activamente y el tiempo que permanece inactivo en una cola. Esto es clave para la optimización de recursos y el análisis de eficiencia. Por qué es importante Permite el cálculo preciso del tiempo de procesamiento de la actividad, separando el tiempo de trabajo activo del tiempo de espera inactivo para un análisis de rendimiento más preciso. Dónde obtener Para actividades con duración, esto puede almacenarse en un campo separado como 'CompletionDate' o 'EndDate' en el registro de eventos o tablas de rastro 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 El ID del Revisor, o usuario, indica quién ejecutó una tarea particular en el proceso KYC. Esto podría ser un analista de cumplimiento, un especialista en onboarding o una cuenta del sistema para actividades automatizadas. El seguimiento de esta información proporciona visibilidad de 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 capacitació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 recursos de cumplimiento. Por qué es importante Permite el análisis de la distribución de la carga de trabajo, el rendimiento del usuario y los traspasos departamentales, lo cual es crucial para la optimización de recursos. Dónde obtener Generalmente se encuentra en registros de eventos o pistas de auditoría, a menudo denominado 'UserID', 'PerformedBy' o 'Owner'. Ejemplos analyst_jdoesystem_auto_screenermanager_bsmith
	Nivel de Riesgo RiskLevel	La clasificación de riesgo calculada de la solicitud del cliente, como Baja, Media o Alta.
Descripción El Nivel de Riesgo es una pieza de información crítica en los procesos KYC, que determina el nivel de diligencia debida requerido. A menudo se determina en función de factores como el tipo de cliente, la geografía y la naturaleza de su negocio. Esta clasificación puede influir significativamente en la ruta del proceso que toma una solicitud. En el análisis de procesos, segmentar los casos por Nivel de Riesgo es esencial. Ayuda a explicar las variaciones en los tiempos de ciclo y los flujos de 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 de Rechazo de Solicitudes y Razones' y 'Tiempo de Ciclo de Inicio de Verificación de Antecedentes' para comprender cómo el riesgo impacta los resultados y la eficiencia. Por qué es importante Segmentar el proceso por nivel de riesgo es crucial para comprender por qué ciertos casos tardan más o siguen diferentes rutas, y para analizar las tasas de rechazo. Dónde obtener Este es un punto de datos central en la solicitud del cliente o el registro del caso. Consulte el módulo de gestión de casos en Refinitiv World-Check. Ejemplos BajoMedioAlto
	¿Es Retrabajo? IsRework	Un indicador que señala si una actividad se realiza por segunda o subsiguiente vez 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 del cliente. Por ejemplo, si 'Evaluación de Riesgos Realizada' ocurre más de una vez para una sola solicitud, las ocurrencias subsecuentes se marcan como retrabajo. Este atributo es crítico para identificar ineficiencias del proceso, bucles y repeticiones innecesarias. Soporta directamente el dashboard 'Retrabajo y Eficiencia en la Evaluación de Riesgos' y el KPI 'Tasa de Retrabajo en la Evaluación de Riesgos'. Analizar el retrabajo ayuda a descubrir problemas de calidad, claridad de la información o toma de decisiones, que conducen a esfuerzos desperdiciados y tiempos de ciclo más largos. Por qué es importante Destaca las ineficiencias del proceso al señalar actividades repetidas, lo que permite analizar los ciclos de retrabajo para mejorar la calidad y reducir los tiempos de ciclo. Dónde obtener Esto se calcula durante la transformación de datos analizando la secuencia de actividades dentro de cada caso y marcando cualquier ocurrencia no inicial de una actividad. Ejemplos truefalse
	Automatizado IsAutomated	Un indicador que señala si la actividad fue realizada por un sistema (verdadero) o por un humano (falso).
Descripción Este atributo booleano distingue entre tareas automatizadas del sistema y actividades manuales realizadas por los usuarios. Por ejemplo, 'Investigación Automatizada Realizada' se marcaría como automatizada, mientras que 'Revisión del Analista Iniciada' sería manual. Esta distinción es crucial para el análisis de automatización. Ayuda a medir el impacto de la automatización en la eficiencia del proceso, identificar qué tareas manuales son candidatas para futuras automatizaciones y comprender la interacción entre los actores humanos y del sistema. Permite una clara separación del tiempo de procesamiento del sistema del tiempo de manejo manual. Por qué es importante Diferencia entre actividades del sistema y humanas, lo cual es clave para medir el impacto de la automatización e identificar nuevas oportunidades de automatización. Dónde obtener Esto se deriva típicamente basándose en el nombre de la actividad o el ID de usuario asociado con el evento (por ejemplo, si el usuario es una cuenta de 'sistema'). Ejemplos truefalse
	Canal de Solicitud ApplicationChannel	El canal a través del cual se envió la solicitud del cliente, como Portal Online, En Sucursal o Aplicación Móvil.
Descripción El Canal de Solicitud indica la fuente de envío de la solicitud del cliente. Diferentes canales pueden tener distintos niveles de exhaustividad, calidad de los datos y demografía del cliente, lo que puede impactar en el proceso posterior. Este atributo es esencial para el dashboard 'Rendimiento de Solicitudes por Canal'. Al analizar el volumen, el tiempo de ciclo y los resultados de las solicitudes de diferentes canales, una organización puede identificar qué canales son más eficientes y cuáles pueden requerir mejoras en el proceso. Este análisis apoya 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 diferentes canales de envío, lo que informa las decisiones estratégicas sobre tecnología y experiencia del cliente. Dónde obtener Esta información se captura típicamente al comienzo del proceso y se almacena como un atributo en el registro de la solicitud. Ejemplos Portal en LíneaApp móvilEn sucursalGerente de Relaciones
	ID de cliente CustomerId	Un identificador único para la entidad de cliente que está siendo incorporada.
Descripción El ID de Cliente es el identificador único para el perfil del cliente. Esto es distinto del ID de Solicitud de Cliente, ya que un cliente puede enviar múltiples solicitudes a lo largo del tiempo. Este atributo vincula el proceso de onboarding con el registro maestro del cliente. En el análisis, el ID de Cliente permite rastrear solicitudes repetidas del mismo cliente y puede usarse para enriquecer los datos del proceso con otros atributos del cliente de un CRM o un sistema de datos maestros. Esto permite una vista más holística del viaje del cliente más allá de una sola instancia de onboarding. Por qué es importante Vincula el caso de onboarding a un cliente específico, permitiendo el análisis de solicitudes repetidas y el enriquecimiento con datos maestros del cliente. Dónde obtener Este sería un campo clave en el registro de la solicitud o del caso, vinculándolo a los datos maestros del cliente. Ejemplos CUST-98765CUST-98766CUST-98767
	ID de Coincidencia MatchId	El identificador único para una posible coincidencia encontrada durante una investigación de World-Check.
Descripción Cuando el proceso de selección automatizado encuentra una posible coincidencia con listas de sanciones, listas PEP o medios adversos, a menudo se genera un ID de coincidencia para rastrear el hallazgo específico. Este ID vincula el caso de la solicitud con el registro específico en la base de datos de World-Check que activó la alerta. Este atributo es útil para un análisis detallado del cumplimiento. Permite a los analistas investigar la naturaleza de las coincidencias, rastrear 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 comunes o tardan más en resolverse. Proporciona un nivel de detalle más profundo sobre la actividad 'Coincidencia Potencial Identificada'. Por qué es importante Proporciona un enlace granular a los resultados específicos de la investigación, permitiendo un análisis más profundo de los tiempos de resolución de coincidencias y los tipos de alertas. Dónde obtener Este ID sería generado por el motor de investigación de World-Check y registrado contra el caso de solicitud cuando se encuentre una posible coincidencia. Ejemplos WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
	Motivo de rechazo RejectionReason	La razón específica proporcionada cuando se rechaza una solicitud de cliente.
Descripción Cuando una solicitud es rechazada, la Razón de Rechazo captura el motivo de esa decisión. Las razones pueden incluir 'Coincidencia con Sanciones', 'Documentación Incompleta' o 'Perfil de Alto Riesgo'. Esto proporciona una retroalimentación valiosa y estructurada sobre la calidad de las solicitudes entrantes y la efectividad del proceso de selección. Este atributo es el principal impulsor del dashboard 'Tasa y Razones de Rechazo de Solicitudes'. Analizar estas razones ayuda a identificar las causas raíz de los rechazos, lo que puede conducir a mejoras en el proceso, una comunicación más clara con los solicitantes y, potencialmente, una reducción de los rechazos innecesarios. Proporciona un contexto cualitativo al KPI cuantitativo de la tasa de rechazo. Por qué es importante Proporciona la causa raíz de las solicitudes rechazadas, lo cual es esencial para identificar áreas de mejora en el proceso de onboarding para reducir la tasa de rechazo. Dónde obtener Esto se registraría cuando ocurra el evento 'Solicitud Rechazada', probablemente como un campo en el registro del caso o de la solicitud. Ejemplos Coincidencia PEPCoincidencia en Lista de SancionesVerificación de Documentos FallidaMedios Adversos
	País del Cliente CustomerCountry	El país de residencia o constitución para el cliente.
Descripción Este atributo indica la ubicación geográfica del cliente. El país es un factor significativo en la evaluación de riesgos y los requisitos regulatorios para los procesos KYC. Diferentes jurisdicciones tienen diferentes reglas, lo que puede afectar el flujo y la duración del proceso. Analizar el proceso por país permite a las organizaciones comparar el rendimiento en diferentes regiones, identificar cuellos de botella específicos de la ubicación y asegurar el cumplimiento de las regulaciones locales. Proporciona una dimensión geográfica al análisis del proceso, que puede revelar importantes diferencias operativas. Por qué es importante Permite el análisis geográfico del proceso, ayudando a identificar variaciones regionales en el rendimiento, el riesgo y los requisitos de cumplimiento. Dónde obtener Este es un campo estándar en el perfil del cliente o en el formulario de solicitud. Ejemplos EE. UU.GBRSGPDEU
	SLA Incumplido SlaBreached	Un indicador booleano que señala si el caso de onboarding se completó después de su Fecha Objetivo de SLA.
Descripción Este atributo es un indicador calculado que señala si un caso ha violado su Acuerdo de Nivel de Servicio. Se determina comparando la timestamp de la actividad de finalización final (por ejemplo, 'Solicitud Aprobada' o 'Solicitud Rechazada') con la 'Fecha Objetivo del SLA' para el caso. Este indicador es la base para el dashboard 'Análisis de Adherencia e Incumplimiento del SLA' y el KPI 'Tasa de Adherencia al SLA'. Simplifica el análisis al permitir a los usuarios filtrar rápidamente todos los casos incumplidos. Al analizar las características del proceso de los casos incumplidos, las organizaciones pueden identificar las causas raíz de los retrasos y enfocar los esfuerzos de mejora de manera efectiva. Por qué es importante Mide directamente el cumplimiento de los acuerdos de nivel de servicio, permitiendo un fácil filtrado y análisis de la causa raíz de los casos retrasados. Dónde obtener Esto se calcula durante la transformación de datos comparando la timestamp de la actividad final de un caso con el campo SlaTargetDate. Ejemplos truefalse
	Source System SourceSystem	El sistema del que se extrajeron los datos de eventos, en este caso, Refinitiv World-Check.
Descripción Este atributo identifica el origen de los datos del proceso. Si bien podría ser un valor constante en una extracción de una sola fuente, se vuelve crucial cuando se combinan datos de múltiples sistemas (como un CRM y World-Check) para crear una vista holística del proceso. En el análisis, esto ayuda en 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 de investigación principal pueden tener diferentes propiedades o niveles de detalle que las de un sistema periférico. Asegura que la trazabilidad de los datos sea clara y auditable. Por qué es importante Identifica el origen de los datos, lo cual es crucial para la gobernanza de datos, la validación y al fusionar datos de múltiples fuentes. Dónde obtener Este es a menudo un valor estático añadido durante el proceso de extracción, transformación y carga (ETL) de datos para etiquetar el conjunto de datos. Ejemplos Refinitiv World-CheckWorldCheckOne
	Tiempo de procesamiento de la actividad ActivityProcessingTime	La duración del tiempo dedicado activamente a una actividad.
Descripción Esta métrica calcula el tiempo real que tardó una actividad en completarse, desde su inicio hasta su fin. Se calcula como la diferencia entre EventEndTime y EventTime. Esto mide el 'tiempo de contacto' o el tiempo de trabajo activo para una tarea. Este atributo calculado es esencial para el análisis de rendimiento y se utiliza en muchos KPIs, incluidos 'Tiempo de Ciclo Promedio de Revisión de Documentos' y 'Tiempo de Ciclo Promedio de Revisión de Cumplimiento'. Ayuda a distinguir entre el tiempo que una tarea está siendo procesada activamente y el tiempo que está esperando en una cola. Esto es fundamental para identificar ineficiencias de procesamiento reales y para la planificación de capacidad. Por qué es importante Mide el tiempo de trabajo activo para una actividad, ayudando a identificar qué tareas específicas están tomando más tiempo en completarse, aparte del tiempo de espera. Dónde obtener Esto se calcula durante la transformación de datos restando la timestamp de inicio de la timestamp de fin de una actividad (por ejemplo, EndTime - StartTime). Ejemplos PT1H30MP2DT4H15MPT25M
	Tipo de Cliente CustomerType	La clasificación del cliente, como Persona Natural, Corporación o Fideicomiso.
Descripción Tipo de Cliente clasifica la entidad que está siendo incorporada. Diferentes tipos de clientes a menudo tienen diferentes requisitos de onboarding, perfiles de riesgo y obligaciones regulatorias. Por ejemplo, el onboarding de una corporación es típicamente más complejo que el de un individuo. Este atributo se utiliza para el análisis de segmentación, particularmente para el dashboard 'Rendimiento por Tipo de Cliente KYC'. Permite comparar la eficiencia del proceso, los tiempos de ciclo y las tasas de rechazo entre diferentes segmentos de clientes. Esto ayuda a las organizaciones a adaptar y optimizar la experiencia de onboarding para tipos de clientes específicos. Por qué es importante Permite la comparación de rendimiento entre diferentes segmentos de clientes, ayudando a adaptar y optimizar el proceso de onboarding para cada tipo. Dónde obtener Este es un atributo fundamental almacenado en el registro del cliente o de la solicitud dentro del sistema de origen. Ejemplos Persona naturalCorporaciónSin fines de lucroConfianza
	Última actualización de datos LastDataUpdate	La timestamp de la última actualización o extracción de los datos para este evento 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 puntualidad de los dashboards y análisis de Process Mining. Para fines analíticos, esto permite a los usuarios saber si están viendo datos casi en tiempo real o una instantánea de un momento específico. Es esencial para la gobernanza de datos y para gestionar las expectativas del usuario sobre la actualidad de los hallazgos proporcionados. Por qué es importante Proporciona un contexto crucial sobre la actualidad de los datos, asegurando que los usuarios comprendan cuán actualizado está el análisis del proceso. Dónde obtener Esta timestamp se genera y añade durante el proceso de extracción, transformación y carga (ETL) de datos. Ejemplos 2023-11-01T02:00:00Z2023-11-02T02:00:00Z

Requerido Recomendado Opcional

Actividades de Onboarding de Clientes KYC

Estos son los pasos clave del proceso y los hitos a capturar en su registro de eventos para un descubrimiento preciso de procesos.

8 Recomendado 6 Opcional

	Actividad	Descripción
	Coincidencia Verdadera Confirmada	Un analista confirma que una posible coincidencia es, de hecho, el cliente que se está cribando, identificando un riesgo potencial. Este es un hito crítico que normalmente desencadena una diligencia debida adicional o el rechazo de la solicitud.
Por qué es importante Este es un resultado clave de mitigación de riesgos y un momento crucial en el proceso. Influye directamente en la decisión final sobre la solicitud del cliente y es crucial para los informes y análisis de cumplimiento. Dónde obtener Esta es una acción de usuario explícita donde el analista clasifica una coincidencia específica como 'Coincidencia Verdadera' o 'Coincidencia Confirmada'. Este evento se registra en la pista de auditoría del caso. Capturar Registrado 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, completando el proceso de onboarding. Esto sigue a la aprobación final de la solicitud y deja la cuenta lista para su uso.
Por qué es importante Este es el paso final que entrega valor en el proceso. La duración desde el envío de la solicitud hasta la activación de la cuenta es una métrica clave para la eficiencia operativa y la satisfacción del cliente. Dónde obtener Este evento no se captura en World-Check. Se registra en el sistema bancario principal o de cuentas de cliente y debe correlacionarse mediante el ID de Solicitud de Cliente. Capturar Evento registrado en el sistema de cuenta principal tras la activación de la cuenta. Tipo de evento explicit
	Investigación Completada - Aprobado	El caso de investigación se cierra oficialmente con un resultado 'Aprobado', lo que significa que no se encontraron coincidencias verdaderas. Esta decisión se comunica de vuelta al sistema de origen, permitiendo que el proceso de onboarding continúe.
Por qué es importante Esta actividad representa la finalización exitosa, el 'camino feliz', del proceso de investigación. Sirve como un punto final clave para medir el tiempo de ciclo de las solicitudes estándar y de bajo riesgo. Dónde obtener Se infiere del cambio de estado final del caso a 'Aprobado', 'Completo' o 'Cerrado - Sin Coincidencia'. Se utiliza la timestamp de este cambio de estado final. Capturar Derivado de la marca de tiempo del estado final del caso que indica un resultado sin coincidencia. Tipo de evento inferred
	Investigación Completada - Coincidencia Encontrada	El caso de investigación se cierra oficialmente con un resultado de 'Coincidencia Encontrada', indicando que se identificó un riesgo confirmado. Esta decisión desencadena un proceso posterior diferente, como una diligencia debida mejorada o el rechazo.
Por qué es importante Este es el punto final principal del 'camino infeliz' para el proceso de investigación. El análisis de estos casos ayuda a comprender los perfiles de riesgo y la efectividad de los controles de investigación. Dónde obtener Se infiere del cambio de estado final del caso a 'Coincidencia Encontrada', 'Riesgo Identificado' o 'Cerrado - Positivo'. Se utiliza la timestamp de este cambio de estado final. Capturar Derivado de la marca de tiempo del estado final del caso que indica una coincidencia confirmada. Tipo de evento inferred
	Revisión del Analista Iniciada	Un analista de cumplimiento inicia la investigación manual de posibles coincidencias para una solicitud de cliente. Esto implica evaluar los detalles de las posibles coincidencias con 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 común. Medir el tiempo desde 'Posible Coincidencia Identificada' hasta esta actividad revela retrasos en la cola, mientras que la duración de la revisión indica la eficiencia del analista. Dónde obtener Esto se puede inferir cuando un analista 'toma' o abre un caso de la cola de revisión. El sistema puede registrar este evento explícitamente en una pista de auditoría cuando el estado del caso cambia a 'En Revisión' o se asigna a un usuario específico. Capturar Se infiere de un cambio de estado del caso a 'En Revisión' o de la asignación del caso a un analista. Tipo de evento inferred
	Solicitud de Investigación Creada	Se crea formalmente un nuevo caso de cribado para una solicitud de cliente dentro del sistema Refinitiv World-Check. Esto se activa mediante una llamada a la API o una entrada manual desde un sistema ascendente y representa el inicio de la verificación de inteligencia de riesgos.
Por qué es importante Esto marca el inicio oficial del subproceso de investigación. El tiempo entre 'Solicitud Enviada' y esta actividad revela retrasos en las transferencias entre el sistema de línea de negocio y la función de cumplimiento. Dónde obtener Registrado en los registros de gestión de casos o en la pista de auditoría de World-Check. Se utilizarían el evento de creación y su timestamp para el ID de caso o entidad específico. Capturar Registrado automáticamente cuando se crea un nuevo caso de investigación en el sistema. Tipo de evento explicit
	Solicitud Enviada	Esta actividad marca el inicio del proceso de onboarding KYC cuando un cliente envía su solicitud. Este evento se captura típicamente en un CRM o un sistema de aplicación principal, que luego desencadena el proceso de investigación en Refinitiv World-Check.
Por qué es importante Este es el evento de inicio principal para el viaje de onboarding de clientes de principio a fin. Analizar el tiempo desde este punto hasta la finalización proporciona el tiempo de ciclo general del onboarding, que es crítico para medir la experiencia del cliente y la adherencia al SLA. Dónde obtener Este evento no es nativo de World-Check. Debe obtenerse de un sistema upstream, como un CRM o una plataforma de gestión de cuentas de clientes, y correlacionarse mediante el ID de Solicitud de Cliente. Capturar Evento registrado en el sistema de aplicación de origen tras la presentación inicial. Tipo de evento explicit
	Solicitud Rechazada	La solicitud del cliente es formalmente rechazada, a menudo como resultado de una 'Coincidencia Encontrada' 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 punto final principal de falla del proceso. Analizar los eventos de rechazo, particularmente las razones y las actividades precedentes, es crucial para la mejora del proceso y la reducción de rechazos innecesarios. Dónde obtener Esta decisión de negocio final se registra en el CRM upstream o en el sistema de aplicación principal, no en World-Check. Los datos deben obtenerse de ese sistema. Capturar Evento registrado en el sistema de aplicación de origen, a menudo con un código de motivo de rechazo correspondiente. 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 gerente para una decisión final. Este es un punto clave de traspaso dentro del equipo de cumplimiento.
Por qué es importante Las escalaciones a menudo crean cuellos de botella y aumentan el tiempo del ciclo. Analizar la frecuencia y las razones de las escalaciones puede resaltar las necesidades de capacitación para analistas junior o la ambigüedad en las políticas de revisión. Dónde obtener Registrado como una acción explícita en el workflow del caso o en la pista de auditoría. Esto también podría inferirse por un cambio en el usuario asignado al caso, especialmente a un usuario con permisos más altos. Capturar Registrado a través de un botón 'Escalar' o una acción de workflow dedicada dentro del caso. Tipo de evento explicit
	Cribado Automatizado Realizado	El sistema World-Check investiga automáticamente los detalles del cliente contra su base de datos de inteligencia de riesgos. Esta es una actividad impulsada por el sistema que produce un conjunto inicial de resultados, como posibles coincidencias o un estado aprobado.
Por qué es importante Esta actividad es el primer paso de valor añadido dentro del proceso de investigación. Los retrasos antes de este punto indican problemas de preparación del sistema o de los datos, mientras que el resultado determina la carga de trabajo manual subsiguiente. Dónde obtener Este evento puede registrarse explícitamente en la pista de auditoría del caso o inferirse de la timestamp cuando los resultados iniciales de la investigación están disponibles para el caso. Capturar Entrada de registro del sistema generada al finalizar el escaneo automático de la base de datos. Tipo de evento explicit
	Falso Positivo Confirmado	El analista concluye que una posible coincidencia no es la misma que el cliente que está siendo investigado. La coincidencia es desestimada y el proceso de investigación para esa alerta específica se resuelve.
Por qué es importante Esto representa un resultado común del proceso de revisión. Comprender el tiempo que lleva clasificar los falsos positivos ayuda a medir la eficiencia del analista y la precisión de la lógica de investigación automatizada. Dónde obtener Esta es una acción de usuario explícita donde el analista clasifica una coincidencia específica como 'Falso Positivo' o 'No Coincidencia'. Esta acción se registra típicamente en el historial del caso. Capturar Registrado cuando un analista desestima formalmente una posible coincidencia en el sistema. Tipo de evento explicit
	Información Adicional Solicitada	El analista determina que se necesita más información para resolver la posible coincidencia y la solicita a la unidad de negocio. Esto pone el caso en estado pendiente hasta que se proporcione la información.
Por qué es importante La ocurrencia frecuente de esta actividad indica problemas con la calidad de los datos iniciales proporcionados para el cribado. Esta actividad introduce retrasos significativos, ya que depende de equipos externos, y es un factor clave para largos tiempos de ciclo. Dónde obtener Esto puede ser una acción de usuario explícita registrada en las notas del caso o en el registro de auditoría. Alternativamente, podría inferirse de un cambio de estado del caso a 'Información Pendiente' o 'RFI'. Capturar Registrado cuando un analista utiliza una función para marcar el caso como que necesita más información. Tipo de evento explicit
	Posible Coincidencia Identificada	El proceso de investigación automatizado ha encontrado una o más posibles coincidencias que requieren revisión manual por parte de un analista. Este evento transiciona 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 en el proceso. Los casos con posibles coincidencias siguen una ruta más larga y compleja, y su seguimiento ayuda en la planificación de recursos y el análisis de cuellos de botella para el equipo de revisión. Dónde obtener Se infiere de un cambio en el estado del caso a 'Revisión Requerida', 'Posible Coincidencia' o un estado similar dentro del módulo de gestión de casos de World-Check. Capturar Derivado de un cambio de estado de caso que indica que ahora se necesita una revisión manual. Tipo de evento inferred
	Solicitud Aprobada	La solicitud del cliente ha sido totalmente aprobada después de una exitosa investigación KYC y cualquier otra verificación requerida. Este evento ocurre típicamente en el sistema de origen después de recibir un resultado 'Aprobado' de World-Check.
Por qué es importante Esto marca el resultado de negocio exitoso del proceso de onboarding. El seguimiento del tiempo hasta este punto desde el envío revela el 'tiempo hasta el sí' completo para un nuevo cliente. Dónde obtener Este evento no es nativo de World-Check. Debe obtenerse del CRM upstream o del sistema de aplicación principal, que toma la decisión de negocio final. Capturar 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 Refinitiv World-Check One utilizando sus credenciales.
Navegue a Gestión de Casos: Abra la sección de Gestión de Casos donde se almacenan y administran todos los casos de cribado.
Prepare la exportación del informe de casos: Vaya a la función de informes o exportación dentro de Gestión de Casos. Esto puede estar etiquetado como 'Exportar Casos' o 'Informe de Casos'.
Configure el informe de casos: Seleccione las columnas a incluir en la exportación. Asegúrese de seleccionar campos correspondientes al ID del Caso (CustomerApplication), fecha de creación, fecha de resolución, estado del caso (por ejemplo, Sin Coincidencia, Coincidencia Encontrada) y nivel de riesgo.
Exporte los datos de gestión de casos: Defina su rango de fechas, que generalmente cubre los últimos 3 a 6 meses de actividad. Aplique los filtros necesarios, como por grupo de usuario o tipo de caso. Exporte los datos como un archivo CSV y nómbrelo case_report.csv.
Prepare la exportación del rastro de auditoría: Navegue a la sección de informes de rastro de auditoría o registro de auditoría de World-Check One. Esta contiene historiales detallados de eventos para cada caso.
Configure y exporte el rastro de auditoría: Seleccione todas las columnas relevantes, incluyendo el ID del Caso, el nombre o descripción del evento, la fecha y hora del evento, y el usuario que realizó la acción. Exporte estos datos para el mismo rango de fechas que el informe de casos. Guarde el archivo como audit_trail.csv.
Obtener pasos del proceso externo: Obtenga datos para actividades que ocurren fuera de World-Check, como Solicitud Enviada, Solicitud Aprobada, Cuenta Activada y Solicitud Rechazada. Estos datos suelen provenir de un CRM o un sistema bancario central. Exporte estos datos con el ID CustomerApplication y las marcas de tiempo relevantes.
Combine y transforme 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.
Mapee los eventos de auditoría a actividades: Procese el archivo audit_trail.csv. Mapee las descripciones de eventos sin procesar del registro de auditoría a los valores estandarizados de ActivityName. Por ejemplo, una entrada de registro de auditoría como 'Caso Asignado al Analista' se convierte en 'Revisión del Analista Iniciada'.
Mapee los cambios de estado del caso a actividades: Procese el archivo case_report.csv para generar actividades basadas en los cambios de estado. Utilice la fecha de resolución del caso y el estado final para crear los eventos 'Cribado Completado - Sin Coincidencia' o 'Cribado Completado - Coincidencia Encontrada'.
Cree el registro de eventos final: Una todos los datos procesados de los diferentes archivos de origen en un único archivo CSV. Asegúrese de que el archivo final contenga las columnas requeridas: CustomerApplication, ActivityName y EventTime, junto con cualquier atributo recomendado. Guarde este archivo para cargarlo en la herramienta de minería de procesos.

Configuración

Tipos de informe: Necesitará generar al menos dos informes separados: un informe resumen de Gestión de Casos y un informe detallado de Trazabilidad de Auditoría.
Rango de fechas: Para un análisis inicial, seleccione un rango de fechas de al menos 3 a 6 meses para capturar suficientes casos completados y en curso. Asegúrese de que el rango de fechas sea consistente en todos los archivos exportados.
Formato de exportación: Elija CSV (valores separados por comas) como formato de exportación para un fácil procesamiento.
Columnas clave (Informe de Casos): Asegúrese de que su exportación de casos incluya el ID del Caso, la Fecha/Hora de Creación, la Fecha/Hora de Resolución, el Estado Final, el Analista Asignado y el Nivel de Riesgo.
Columnas clave (Informe de Trazabilidad de Auditoría): Asegúrese de que su exportación del registro de auditoría incluya el ID del Caso, la Descripción del Evento, la Fecha/Hora del Evento y el ID del Usuario.
Requisitos: Se requiere acceso al portal World-Check One con permisos de usuario que permitan visualizar y exportar datos de gestión de casos y registros de auditoría. Esto puede requerir privilegios elevados más allá de un rol de analista estándar.

a Consulta de ejemplo config

/*
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 Python 3.6+ instalado junto con las bibliotecas requests y pandas. Obtenga su clave API y secreto API de World-Check One de su representante de Refinitiv o del portal para desarrolladores. Almacene estas credenciales de forma segura.
Desarrollar lógica de autenticación: En su script de Python, cree una función para enviar una solicitud POST al endpoint de autenticación de World-Check One. Use su clave API y secreto para obtener un token de portador temporal requerido para las llamadas API posteriores.
Identificar 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 de la solicitud inicial. Necesitará extraer eventos como Solicitud Enviada, Solicitud Aprobada, Cuenta Activada y Solicitud Rechazada de esta fuente. Esto se puede hacer mediante una consulta a la base de datos o a través de otra API.
Obtener casos de World-Check: Utilizando el token autenticado, realice una solicitud GET al endpoint /cases de la API de World-Check One. Utilice los parámetros de consulta para filtrar los casos por un rango de fechas específico, por ejemplo, basándose en su fecha de creación o modificación.
Manejar la paginación de la API: Las respuestas de la API de World-Check están paginadas. Su script debe verificar la respuesta para obtener detalles de paginación y recorrer todas las páginas para recuperar la lista completa de casos para el rango de fechas especificado.
Recuperar detalles e historial del caso: Para cada ID de caso recuperado, realice solicitudes GET posteriores a endpoints como /cases/{case_system_id} y /cases/{case_system_id}/audit-trail. Estos endpoints proporcionan los cambios de estado detallados, los detalles de resolución y las acciones de usuario asociadas al caso.
Mapear datos brutos a actividades: Este es un paso de transformación crítico. Escriba la lógica para iterar a través de los datos de respuesta de la API (detalles del caso, rastro de auditoría) para cada caso. Mapee los cambios de estado específicos, los códigos de resultado y los eventos de auditoría a las actividades comerciales requeridas. Por ejemplo, un evento de creación de caso se convierte en Solicitud de Cribado Creada, y una resolución de resultado de Falso Positivo se convierte en Falso Positivo Confirmado.
Combinar fuentes de datos: Fusione los datos extraídos de World-Check con los datos de su 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.
Estructurar y enriquecer datos: Reúna todos los eventos mapeados en una sola lista de registros. Para cada registro, asegúrese de que todos los atributos requeridos (CustomerApplication, ActivityName, EventTime) y los atributos recomendados estén rellenados. Calcule EventEndTime donde sea posible, quizás utilizando la marca de tiempo del siguiente evento para ese caso.
Exportar a CSV: Convierta la lista final de registros 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. Asegúrese de que el archivo se guarde con codificación UTF-8 para ser compatible con ProcessMind.

Configuración

Credenciales de API: Se requieren una clave API y un secreto API válidos para la API de cribado de World-Check One. Estos deben ser aprovisionados con los permisos necesarios para leer datos de casos y auditoría.
URL base de la API: El script debe configurarse con la URL base correcta para su entorno de API de World-Check, por ejemplo, https://api.world-check.com/v2/.
Rango de Fechas: Implemente los parámetros start_date y end_date en el script para controlar el período de extracción. Para un análisis inicial, se recomienda un rango de 3 a 6 meses. Para una monitorización continua, ejecute el script de forma incremental para períodos más cortos, como el día o la semana anterior.
Conexión con el Sistema Origen: Se necesitan los detalles de conexión para los sistemas ascendentes y descendentes (por ejemplo, CRM, plataforma bancaria central) para obtener los eventos no relacionados con el cribado. Esto podría ser una cadena de conexión de base de datos o otro endpoint de API y credenciales.
Gestión de la Paginación: El script debe especificar un tamaño de página, a menudo llamado limit, al realizar llamadas a la API para listar casos. Un valor entre 50 y 100 suele ser eficiente. La lógica debe manejar 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()

Su Plantilla de Datos de Onboarding de Clientes KYC

Su Plantilla de Datos de Onboarding de Clientes KYC

Atributos de Onboarding de Clientes KYC

Actividades de Onboarding de Clientes KYC

Guías de Extracción

Exportación de Registro de Auditoría y Caso de Refinitiv World-Check One

Pasos

Configuración

a Consulta de ejemplo config

Script de Python utilizando la API de Screening de World-Check One

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice el Onboarding de Clientes KYC Ahora, Impulse el Cumplimiento

Su Plantilla de Datos de Onboarding de Clientes KYC

Su Plantilla de Datos de Onboarding de Clientes KYC

Atributos de Onboarding de Clientes KYC

Actividades de Onboarding de Clientes KYC

Guías de Extracción

Exportación de Registro de Auditoría y Caso de Refinitiv World-Check One

Pasos

Configuración

a Consulta de ejemplo config

Script de Python utilizando la API de Screening de World-Check One

Pasos

Configuración

a Consulta de ejemplo python

Valoramos su privacidad

¿Listo para comenzar?

Optimice el Onboarding de Clientes KYC Ahora, Impulse el Cumplimiento