Su Template de datos para la incorporación de clientes KYC
Su Template de datos para la incorporación de clientes KYC
- Atributos recomendados para recopilar
- Actividades clave que debe seguir
- Indicaciones para extraer los datos
Atributos de la incorporación de clientes KYC
| Nombre | Descripción | ||
|---|---|---|---|
| Hora de inicio EventStartTime | Marca de tiempo que indica cuándo comenzó oficialmente una actividad o un evento. | ||
| Descripción Este atributo registra la fecha y hora exactas en que comenzó una actividad específica. Proporciona el orden cronológico necesario para reconstruir el flujo del proceso y es esencial para todos los análisis basados en el tiempo. En Process Mining, la hora de inicio se utiliza para calcular la duración de las actividades, el tiempo de espera entre ellas y el tiempo de ciclo total del caso. Constituye la base temporal del registro de eventos y es fundamental para analizar el rendimiento y los cuellos de botella. Por qué es importante Esta marca de tiempo es fundamental para ordenar cronológicamente los eventos y calcular todas las métricas basadas en el tiempo, como los tiempos de ciclo y las duraciones. Dónde obtenerlo Se encuentra en las tablas del registro de auditoría, el registro de eventos o el historial del flujo de trabajo de Fenergo. Suele aparecer con nombres como 'Timestamp', 'StartDate' o 'CreationDate'. Ejemplos 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Nombre de la actividad ActivityName | Nombre del evento de negocio o la tarea específica que tuvo lugar en un momento determinado del proceso de incorporación. | ||
| Descripción El nombre de la actividad describe un paso o hito del proceso de incorporación del cliente, como 'Verificación inicial realizada' o 'Solicitud aprobada'. La secuencia de actividades constituye la base del mapa del proceso. El análisis de este atributo permite visualizar el flujo del proceso, identificar las rutas habituales y alternativas, y medir la frecuencia de cada paso. Es fundamental para entender qué acciones se realizan y en qué orden. Por qué es importante Este atributo define los pasos del proceso y permite crear un mapa del proceso y analizar su flujo y sus variaciones. Dónde obtenerlo Esta información suele encontrarse en las tablas de flujo de trabajo o de registro de auditoría de Fenergo, asociada a cambios de estado del caso o a la finalización de tareas. Ejemplos Datos y documentos solicitadosRevisión de cumplimiento iniciadaSolicitud aprobada | |||
| Solicitud del cliente CustomerApplication | Identificador único de un proceso de incorporación de un cliente, que sirve como identificador principal del caso. | ||
| Descripción La solicitud del cliente es el identificador central que agrupa todas las actividades y los eventos relacionados con el proceso de incorporación KYC de un cliente. Permite hacer un seguimiento integral de la solicitud, desde su envío inicial hasta la resolución final, ya sea aprobada, rechazada o cerrada. En Process Mining, este atributo es fundamental para reconstruir el recorrido completo de cada solicitud. Permite analizar los flujos del proceso, los tiempos de ciclo, las variaciones y los cuellos de botella de cada solicitud, y ofrece una visión clara de cómo se gestionan los casos individuales. Por qué es importante Este es el ID del caso esencial que conecta todos los eventos relacionados y permite analizar de principio a fin el proceso de incorporación del cliente. Dónde obtenerlo Suele ser la clave principal de la entidad de gestión de casos o de gestión del ciclo de vida del cliente en el sistema central de Fenergo. Ejemplos APP-2023-00123APP-2023-00124APP-2023-00125 | |||
| Sistema de origen SourceSystem | Sistema de registro del que se extrajeron los datos. | ||
| Descripción Este atributo identifica el sistema de origen de los datos de los eventos. En este proceso, será siempre Fenergo, pero en conjuntos de datos combinados permite distinguir las fuentes de datos. Su principal uso en el análisis es filtrar los datos de sistemas específicos o verificar su procedencia. Aporta claridad en entornos donde se combinan datos de varios sistemas para obtener una visión integral del proceso. Por qué es importante Identifica el origen de los datos, algo fundamental para la gobernanza de datos, la validación y la verificación de que el análisis se basa en la fuente correcta. Dónde obtenerlo Suele ser un valor estático que se añade durante la extracción de datos para indicar el origen de los registros. Ejemplos FenergoFenergo CLM | |||
| Última actualización de datos LastDataUpdate | Marca de tiempo que indica cuándo se actualizaron o extrajeron por última vez los datos de este proceso. | ||
| Descripción Este atributo registra la fecha y hora de la actualización de datos más reciente. Indica la antigüedad de los datos analizados y ayuda a entender si la información está actualizada. En los Dashboards y los informes, esta información permite comunicar a los usuarios la vigencia de los datos. También ayuda a aclarar si el análisis refleja las operaciones en tiempo real o una instantánea histórica. Por qué es importante Aporta contexto esencial sobre la actualidad de los datos y permite entender hasta qué fecha está actualizado el análisis del proceso. Dónde obtenerlo Este valor se genera y se añade al conjunto de datos durante el proceso de extracción, transformación y carga (ETL). Ejemplos 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| Departamento del usuario UserDepartment | Departamento o unidad de negocio a la que pertenece el usuario que inició la actividad. | ||
| Descripción Este atributo aporta contexto organizativo sobre el usuario que realizó una actividad, por ejemplo, 'Cumplimiento', 'Operaciones de incorporación' o 'Ventas'. A menudo se obtiene de la información del perfil de usuario. Esta dimensión es fundamental para analizar los traspasos del proceso entre departamentos e identificar cuellos de botella entre áreas. También contribuye directamente al Dashboard 'Distribución de la actividad del personal', ya que permite agrupar el trabajo por equipo o departamento. Por qué es importante Permite analizar el rendimiento del proceso por departamento y destacar los traspasos entre departamentos, las demoras y la distribución de la carga de trabajo. Dónde obtenerlo Es posible que deba combinarse con una tabla independiente de datos maestros de usuarios o de RR. HH. mediante el ID de 'InitiatingUser'. Fenergo también puede almacenar esta información en el perfil del usuario. Ejemplos ComplianceIncorporación de clientesControl de calidad | |||
| Estado de la solicitud ApplicationStatus | Resultado actual o final de la solicitud del cliente. | ||
| Descripción Este atributo indica el resultado de la solicitud al final del proceso o su estado actual si sigue en curso. Entre los valores habituales se incluyen 'Aprobado', 'Rechazado' o 'En curso'. Es una dimensión fundamental para analizar los resultados. Permite filtrar y comparar los flujos del proceso según el resultado final, algo esencial para el Dashboard 'Reprocesamiento y rechazo de solicitudes' y para calcular KPI como la tasa de rechazo de solicitudes. Por qué es importante Define el resultado de un caso y permite comparar las rutas de las solicitudes aprobadas y rechazadas, así como entender las tasas de éxito. Dónde obtenerlo Suele ser el estado final registrado en la entidad del caso dentro del sistema de gestión de casos de Fenergo. Ejemplos AprobadoRechazadoCumplimiento pendienteCerrado | |||
| Fecha objetivo del SLA SlaTargetDate | Fecha prevista para completar el caso de incorporación del cliente. | ||
| Descripción La fecha objetivo del SLA es la fecha límite acordada para completar todo el proceso de incorporación de una solicitud de cliente. Es un punto de referencia fundamental para medir el rendimiento real. Este atributo es esencial para el Dashboard 'Supervisión del cumplimiento de los SLA' y para calcular el KPI de tasa de cumplimiento de los SLA. Permite gestionar de forma proactiva los casos que corren el riesgo de incumplir el SLA y ayuda a priorizar el trabajo. Por qué es importante Define la fecha objetivo de finalización, fundamental para supervisar el cumplimiento de los SLA y priorizar los casos atrasados. Dónde obtenerlo Esta fecha suele calcularse a partir de la fecha de envío de la solicitud y de las reglas de negocio configuradas en el módulo de gestión de SLA de Fenergo. Ejemplos 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| Hora de finalización EventEndTime | Marca de tiempo que indica cuándo se completó una actividad o un evento. | ||
| Descripción Este atributo registra la fecha y hora exactas en que finalizó una actividad específica. Complementa la hora de inicio y permite determinar la duración activa de una tarea. En Process Mining, la hora de finalización se utiliza junto con la hora de inicio para calcular el tiempo de procesamiento de cada actividad. Esto es esencial para identificar qué pasos del proceso consumen más tiempo y analizar la eficiencia de los recursos. Por qué es importante Permite calcular los tiempos de procesamiento de las actividades, algo fundamental para identificar tareas de larga duración y cuellos de botella en el rendimiento. Dónde obtenerlo Se encuentra en las tablas del registro de auditoría o del historial del flujo de trabajo de Fenergo. Suele aparecer con nombres como 'EndDate' o 'CompletionDate', o puede derivarse de la hora de inicio del evento siguiente. Ejemplos 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z | |||
| Puntuación de riesgo RiskScore | Puntuación numérica que representa el nivel de riesgo calculado del cliente. | ||
| Descripción La puntuación de riesgo es una medida cuantitativa del riesgo potencial asociado a un cliente, calculada a partir de diversos factores, como la jurisdicción, el sector y los resultados de las verificaciones. Por lo general, el motor de reglas de Fenergo calcula esta puntuación. Este atributo permite relacionar los niveles de riesgo con el comportamiento del proceso. Por ejemplo, el análisis puede revelar si los clientes de alto riesgo tienen tiempos de ciclo más largos o requieren más intervención manual. Esta información resulta útil para el Dashboard 'Análisis detallado de riesgos y revisión de cumplimiento'. Por qué es importante Cuantifica el riesgo del cliente y permite analizar cómo afectan los niveles de riesgo a la duración del proceso, el reprocesamiento y los resultados. Dónde obtenerlo Es un resultado clave del módulo de evaluación del riesgo del cliente de Fenergo. Se almacena en la entidad del caso o del cliente. Ejemplos 154585 | |||
| Usuario que inició la actividad InitiatingUser | ID de usuario o nombre de la persona que realizó la actividad. | ||
| Descripción Este atributo identifica al empleado o usuario del sistema responsable de realizar una tarea o un evento. Puede ser un ID de usuario único, un nombre o un rol. El análisis por usuario ayuda a entender la distribución de la carga de trabajo y el rendimiento individual, así como a identificar necesidades de formación. Es clave para el Dashboard 'Distribución de la actividad del personal' y para analizar en detalle las actividades realizadas por personas o equipos específicos. Por qué es importante Registra qué usuario realizó una acción y permite analizar la distribución de la carga de trabajo, el rendimiento del equipo y la asignación de recursos. Dónde obtenerlo Esta información suele almacenarse en los registros de auditoría o las tablas del historial de tareas de Fenergo, junto con los detalles del evento. Puede aparecer como 'UserID', 'UserName' o 'ModifiedBy'. Ejemplos j.doea.smithSYSTEM | |||
| Canal de solicitud ApplicationChannel | Canal por el que se envió la solicitud del cliente. | ||
| Descripción Este atributo identifica el origen de la solicitud, por ejemplo, un portal en línea, una sucursal física o un gestor de relaciones. El canal puede influir en la calidad de los datos y en los requisitos de procesamiento. Esta dimensión se utiliza en el Dashboard 'Eficiencia por origen y tipo de solicitud' para comparar el rendimiento de los distintos canales. Ayuda a las empresas a entender cuáles son más eficientes y cuáles podrían necesitar mejoras en el proceso. Por qué es importante Identifica el origen de las solicitudes y permite analizar la eficiencia, el coste y la experiencia del cliente en cada canal. Dónde obtenerlo Esta información puede recogerse en un formulario de entrada de datos inicial de Fenergo o recibirse de un sistema anterior. Ejemplos Portal en líneaSucursalGestor de relacionesAplicación móvil | |||
| Cumple el SLA IsSlaCompliant | Indicador booleano que señala si el caso se completó antes de la fecha objetivo del SLA. | ||
| Descripción Este atributo es un indicador binario del rendimiento del SLA en un caso completado. Se establece en 'true' si la marca de tiempo de la actividad final de cierre es anterior o igual a 'SlaTargetDate', y en 'false' en caso contrario. Este campo calculado simplifica la supervisión y la elaboración de informes sobre los SLA. Permite calcular fácilmente la tasa general de cumplimiento de los SLA y filtrar los casos para analizar las características del proceso en los que cumplen y no cumplen el SLA. Por qué es importante Mide directamente el rendimiento del SLA, facilita el cálculo de la tasa de cumplimiento de los SLA y permite filtrar los casos que no cumplen. Dónde obtenerlo Se obtiene comparando la marca de tiempo de la actividad final del caso, como 'Solicitud aprobada' o 'Solicitud rechazada', con 'SlaTargetDate'. Ejemplos truefalse | |||
| Es automatizada IsAutomated | Indicador booleano que señala si la actividad la realizó el sistema en lugar de una persona. | ||
| Descripción Este atributo distingue entre las tareas que el sistema ejecuta automáticamente, como la verificación inicial y las comprobaciones del sistema, y las que realiza una persona. A menudo se determina comprobando si el usuario que ejecutó la tarea es una cuenta de sistema o de servicio. Analizar este indicador es fundamental para entender el nivel de automatización del proceso. Ayuda a cuantificar el impacto de la automatización en la eficiencia, el coste y la velocidad, e identifica oportunidades para automatizar más actividades. Por qué es importante Distingue las actividades realizadas por personas de las ejecutadas por el sistema, algo esencial para analizar la automatización y entender los costes de recursos. Dónde obtenerlo Suele derivarse del campo 'InitiatingUser'. Se utiliza una lista de ID de usuario del sistema conocidos para establecer este indicador como verdadero. Ejemplos truefalse | |||
| Es reprocesamiento IsRework | Indicador booleano que señala si una actividad forma parte de un ciclo de reprocesamiento. | ||
| Descripción Este atributo identifica las actividades que representan un paso atrás en el proceso, como volver a 'Revisión de documentos' después de que ya haya comenzado una 'Revisión de cumplimiento', o cualquier aparición de 'Información adicional solicitada'. Identificar el reprocesamiento es fundamental para entender las ineficiencias y los obstáculos del proceso. Este indicador permite calcular directamente el KPI de tasa de ciclos de reprocesamiento y ayuda a visualizar y cuantificar el impacto de los pasos repetitivos que no aportan valor en el flujo del proceso. Por qué es importante Destaca los ciclos de reprocesamiento ineficientes, ayuda a cuantificar el trabajo innecesario y permite identificar áreas de mejora para aumentar la tasa de éxito en el primer intento. Dónde obtenerlo Este indicador se obtiene mediante técnicas de Process Mining que analizan la secuencia de actividades. Por ejemplo, si en un mismo caso la 'Actividad A' va seguida de la 'Actividad B' y luego vuelve a aparecer la 'Actividad A', la segunda aparición de la 'Actividad A' se considera reprocesamiento. Ejemplos truefalse | |||
| ID del cliente CustomerId | Identificador único del cliente o la entidad jurídica que se incorpora. | ||
| Descripción El ID del cliente es la referencia única de la entidad del cliente en el sistema de datos maestros. Mientras que el número de solicitud es el ID del caso en el proceso, el ID del cliente vincula la actividad de incorporación con un cliente específico. Este atributo permite analizar el historial de incorporación de un cliente, por ejemplo, si ha pasado por varios procesos de incorporación a lo largo del tiempo. También permite combinar los datos del proceso con otros datos relacionados con el cliente para obtener una visión empresarial más completa. Por qué es importante Vincula el proceso de incorporación con una entidad de cliente única y permite realizar análisis centrados en el cliente y enriquecer los datos. Dónde obtenerlo Este ID se almacena en el registro del cliente o de la entidad jurídica en Fenergo y se asocia al caso de incorporación. Ejemplos CUST-98765CUST-98766CUST-98767 | |||
| Motivo del rechazo RejectionReason | Código o descripción que explica por qué se rechazó una solicitud. | ||
| Descripción Cuando el estado final de una solicitud es 'Rechazado', este atributo indica el motivo específico. Algunos ejemplos son 'Comprobación de antecedentes no superada', 'Documentación incompleta' o 'Perfil de riesgo alto'. Este atributo es esencial para analizar las causas raíz de las solicitudes fallidas. Contribuye directamente al Dashboard 'Reprocesamiento y rechazo de solicitudes', ya que clasifica los fallos y ayuda a identificar problemas habituales y aplicar medidas correctivas para mejorar la tasa de aprobación en el primer intento. Por qué es importante Aporta información clave sobre los motivos por los que fallan las solicitudes y permite analizar las causas raíz para reducir la tasa de rechazo. Dónde obtenerlo Suele encontrarse en un campo de código de motivo o de notas asociado al estado final de rechazo en el flujo de trabajo del caso de Fenergo. Ejemplos Coincidencia con listas de sancionesDocumentos no válidosIncumplimiento de políticasEl cliente retiró la solicitud | |||
| País Country | País de domicilio o jurisdicción de la solicitud del cliente. | ||
| Descripción Este atributo especifica el país asociado al cliente, que suele determinar las normas regulatorias y los factores de riesgo aplicables al proceso de incorporación. El análisis del proceso por país permite comparar los tiempos de ciclo, los niveles de riesgo y la complejidad del proceso según la jurisdicción. Ayuda a entender cómo afectan las diferencias regionales al rendimiento operativo y a garantizar el cumplimiento de las normativas locales. Por qué es importante Permite segmentar el proceso por ubicación geográfica, algo clave para analizar el impacto regulatorio y el rendimiento regional. Dónde obtenerlo Esta información forma parte de los datos básicos del cliente que se recogen durante la solicitud y se almacenan en la entidad del cliente en Fenergo. Ejemplos USAGBRSGPDEU | |||
| Recuento de solicitudes de información adicional AdditionalInfoRequestCount | Número total de veces que se solicitó información adicional para una solicitud. | ||
| Descripción Esta métrica cuenta las veces que aparece la actividad 'Información adicional solicitada' en cada caso. Un recuento más alto indica más intercambios de información, lo que puede retrasar el proceso y perjudicar la experiencia del cliente. Este atributo contribuye directamente al KPI de casos con solicitudes de información adicional. Se utiliza para identificar solicitudes con un número excesivo de requerimientos, lo que puede indicar problemas en la recopilación inicial de datos o requisitos complejos para el caso. Su análisis ayuda a agilizar la recopilación de información. Por qué es importante Cuantifica las dificultades para el cliente y las demoras del proceso causadas por la falta de información inicial, y ayuda a mejorar la recopilación de datos. Dónde obtenerlo Es una métrica calculada que se obtiene contando los eventos 'Información adicional solicitada' para cada ID de 'CustomerApplication'. Ejemplos 013 | |||
| Responsable del caso CaseOwner | Usuario o equipo principal responsable de gestionar la solicitud durante todo su ciclo de vida. | ||
| Descripción El responsable del caso es la persona o el grupo al que se asigna la responsabilidad principal de un caso de incorporación. Por lo general, debe garantizar que el caso se complete a tiempo y correctamente. Este atributo ayuda a analizar la carga de trabajo y el rendimiento de quienes gestionan los casos. Permite comprobar si algunos responsables tienen tiempos de ciclo más largos o tasas de rechazo más altas, lo que podría indicar necesidades de formación o desequilibrios en la asignación de recursos. Por qué es importante Identifica a la persona o al equipo responsable de un caso y permite analizar el rendimiento de quienes lo gestionan. Dónde obtenerlo Suele ser un campo específico de la entidad principal del caso en Fenergo que indica a quién se asignó. Ejemplos s.jonesonboarding_team_am.chen | |||
| Tipo de cliente CustomerType | Clasificación del cliente que se incorpora, por ejemplo, persona física, empresa o fideicomiso. | ||
| Descripción Este atributo clasifica a los clientes según su estructura jurídica o su relación con la entidad financiera. Los distintos tipos de cliente suelen seguir rutas de incorporación diferentes, con distintos niveles de complejidad y requisitos de diligencia debida. El análisis del proceso por tipo de cliente ayuda a identificar diferencias de rendimiento entre segmentos. Es clave para el Dashboard 'Eficiencia por origen y tipo de solicitud', que permite comparar los tiempos de ciclo y las tasas de aprobación para orientar mejoras específicas del proceso. Por qué es importante Permite comparar el rendimiento del proceso entre distintos segmentos de clientes, que suelen tener diferentes niveles de complejidad y SLA. Dónde obtenerlo Esta información suele almacenarse en la entidad del cliente dentro de Fenergo y vincularse al caso de la solicitud. Ejemplos Persona físicaEmpresaFideicomisoSociedad | |||
Actividades de incorporación de clientes KYC
| Actividad | Descripción | ||
|---|---|---|---|
| Caso cerrado | Esta es la actividad final, que indica que el caso de incorporación se cerró administrativamente en Fenergo y que no se esperan más acciones. Se aplica tanto a las solicitudes aprobadas como a las rechazadas y se infiere a partir del estado final 'Cerrado'. | ||
| Por qué es importante Esta actividad marca el final definitivo de todo el proceso. Permite calcular correctamente el tiempo de ciclo de todos los casos, independientemente del resultado, y confirma que el proceso ha concluido. Dónde obtenerlo Se infiere del registro de auditoría del caso en Fenergo al identificar la marca de tiempo en que el estado del caso cambia a 'Cerrado', 'Completado' u otro estado final. Capturar Identifique la marca de tiempo del cambio de estado final a 'Cerrado' o 'Completado'. Tipo de evento inferred | |||
| Caso creado | Esta actividad marca el inicio del proceso de incorporación KYC, cuando se crea formalmente en Fenergo una solicitud para un nuevo cliente. Normalmente, se registra como un evento explícito con una fecha y hora concretas, cuando se guarda por primera vez el registro del caso. | ||
| Por qué es importante Como evento de inicio, esta actividad es esencial para calcular el tiempo de ciclo total de la incorporación y analizar el rendimiento. Establece el punto de partida para todas las mediciones posteriores del proceso y el seguimiento de los SLA. Dónde obtenerlo Normalmente, se obtiene de la fecha y hora de creación de la entidad principal del caso en Fenergo, que suele encontrarse en las tablas relacionadas con los casos o flujos de trabajo de incorporación de clientes. Capturar Utilice la fecha y hora de creación del registro del caso de incorporación. Tipo de evento explicit | |||
| Evaluación de riesgos completada | Representa la finalización del proceso interno de clasificación de riesgos, en el que se asigna una calificación de riesgo al cliente según diversos factores. Se deduce de un cambio de estado o de la cumplimentación de un campo de calificación de riesgo. | ||
| Por qué es importante Este es un hito clave para la toma de decisiones que suele determinar la ruta posterior del flujo de trabajo. Analizar su duración ayuda a agilizar una etapa crítica de cumplimiento y a garantizar la coherencia en la evaluación de riesgos. Dónde obtenerlo Se deduce del registro del historial del caso al identificar cuándo cambia a un estado como «Riesgo evaluado» o cuándo se asigna un valor al campo final «Calificación de riesgo del cliente». Capturar Utilice la fecha y hora en que se finaliza la calificación de riesgo o se establece un estado relacionado. Tipo de evento inferred | |||
| Revisión de cumplimiento completada | Marca la aprobación formal del departamento de cumplimiento e indica que se han satisfecho todos los requisitos normativos. Se deduce de la finalización de una tarea o de un cambio de estado a «Aprobado por cumplimiento». | ||
| Por qué es importante Como hito importante, su finalización es fundamental para el tiempo de ciclo total. Marca el punto final para medir el «Tiempo medio de revisión de cumplimiento» e identificar cuellos de botella en la función de cumplimiento. Dónde obtenerlo Se deduce de la fecha y hora de finalización de la tarea «Revisión de cumplimiento» en el flujo de trabajo de Fenergo o del evento de actualización del estado en el historial del caso. Capturar Utilice la fecha y hora de finalización de la tarea de revisión de cumplimiento o de la actualización del estado. Tipo de evento inferred | |||
| Revisión de cumplimiento iniciada | Esta actividad marca el inicio de la revisión del departamento de cumplimiento, una etapa crítica que suele prolongarse. Se deduce cuando el caso se asigna a la cola de trabajo de cumplimiento o su estado cambia a «Pendiente de revisión de cumplimiento». | ||
| Por qué es importante Esta actividad es el punto de partida para medir el KPI «Tiempo medio de revisión de cumplimiento». Ayuda a determinar cuánto esperan los casos antes de que el equipo de cumplimiento empiece a trabajar en ellos. Dónde obtenerlo Se deduce del registro de auditoría del caso en Fenergo, al capturar la fecha y hora del cambio de estado a «En revisión de cumplimiento» o de la asignación del caso a una persona responsable o a un equipo de cumplimiento. Capturar Identifique la fecha y hora del cambio de estado a «En revisión de cumplimiento» o el evento de asignación. Tipo de evento inferred | |||
| Revisión de documentos completada | Indica que ha finalizado el proceso manual o automatizado de verificación de la autenticidad y exactitud de todos los documentos enviados por el cliente. Normalmente, este evento se deduce de la finalización de una tarea del flujo de trabajo o de un cambio de estado en Fenergo. | ||
| Por qué es importante Este es un hito crítico en el que suelen producirse retrasos. Analizar la duración y los resultados de esta actividad ayuda a localizar cuellos de botella en la tramitación de documentos y a realizar un seguimiento de KPI como «Tasa de aprobación en el primer intento». Dónde obtenerlo Se deduce de la fecha y hora de finalización de la tarea «Verificación de documentos» en el flujo de trabajo del caso o de una actualización del estado a «Documentos aprobados» en el registro del historial del caso. Capturar Utilice la fecha y hora de finalización de la tarea de revisión de documentos o de un cambio de estado relacionado. Tipo de evento inferred | |||
| Solicitud aprobada | Esta actividad representa la decisión final de aprobar la solicitud de incorporación del cliente. Se deduce cuando el estado del caso cambia a un estado final como «Aprobado» o «Incorporación aprobada». | ||
| Por qué es importante Este hito clave indica un resultado satisfactorio antes de los pasos finales de activación de la cuenta. Es esencial para calcular las tasas de aprobación y analizar las características de los clientes incorporados correctamente. Dónde obtenerlo Se deduce del historial del caso o del registro de auditoría al encontrar la fecha y hora del cambio final de estado a «Aprobado» o a otro estado positivo equivalente. Capturar Identifique la fecha y hora del cambio final de estado a «Aprobado». Tipo de evento inferred | |||
| Solicitud rechazada | Esta actividad es un evento final que representa la decisión definitiva de rechazar la solicitud del cliente. Se deduce cuando el estado del caso cambia a un estado final como «Rechazado» o «No aprobado». | ||
| Por qué es importante Como punto final clave del proceso, esta actividad es fundamental para calcular la «Tasa de rechazo de solicitudes» y analizar los motivos de los rechazos. Ayuda a identificar los puntos habituales de rechazo y a mejorar la calidad de las solicitudes. Dónde obtenerlo Se deduce del registro de auditoría del caso al capturar la fecha y hora en que el estado final cambia a «Rechazado». El motivo del rechazo suele guardarse en un campo relacionado. Capturar Identifique la fecha y hora del cambio final de estado a «Rechazado». Tipo de evento inferred | |||
| Comprobaciones de antecedentes iniciadas | Esta actividad marca el momento en que se inician las comprobaciones externas de antecedentes, prevención del blanqueo de capitales (AML) o crédito. A menudo, se registra como un evento explícito cuando se realiza una llamada a un servicio externo integrado. | ||
| Por qué es importante Es fundamental hacer un seguimiento del inicio y la finalización de estas comprobaciones para comprender los retrasos causados por dependencias externas. Esto ayuda a separar el tiempo del proceso interno del tiempo de espera externo. Dónde obtenerlo Normalmente, se obtiene de los registros del sistema que recogen las llamadas a API de proveedores externos de verificación o de la creación de una tarea específica de «Comprobación de antecedentes» en el caso de Fenergo. Capturar Busque registros de integraciones con servicios externos o de creación de una tarea de «Revisión». Tipo de evento explicit | |||
| Cuenta activada | Indica que la cuenta del cliente se creó y activó correctamente en el sistema bancario central o en el sistema posterior correspondiente tras la aprobación. Puede inferirse a partir de una actualización del estado final en Fenergo después de la aprobación. | ||
| Por qué es importante Esta actividad confirma que el proceso de incorporación se transfirió correctamente al estado de cliente activo. Medir el tiempo transcurrido entre la aprobación y la activación puede revelar demoras en la configuración operativa. Dónde obtenerlo Puede inferirse a partir de un estado del caso como 'Cuenta activa' o 'Incorporación completada'. También podría tratarse de un evento explícito registrado por una integración con un sistema posterior. Capturar Busque un cambio de estado posterior a la aprobación o un evento de registro que confirme que la integración se realizó correctamente. Tipo de evento inferred | |||
| Datos y documentos solicitados | Este evento indica que el sistema o una persona encargada de la incorporación ha solicitado formalmente al cliente la información y los documentos necesarios. A menudo, se registra como un evento explícito cuando se envía una plantilla de comunicación estandarizada. | ||
| Por qué es importante Esta actividad marca el inicio de una etapa que depende del cliente. Medir el tiempo transcurrido desde este momento hasta la recepción de los documentos es fundamental para analizar el recorrido del cliente e identificar retrasos en la comunicación. Dónde obtenerlo Se obtiene de un registro de eventos asociado a las comunicaciones con el cliente o del registro de finalización de una tarea como «Solicitar documentos». También puede deducirse de un cambio de estado a «A la espera de información del cliente». Capturar Busque un evento registrado de comunicación con el cliente o de finalización de una tarea. Tipo de evento explicit | |||
| Documentos recibidos | Esta actividad indica que el cliente ha cargado o enviado los documentos requeridos y que ya están disponibles en Fenergo para su revisión. Normalmente, se deduce cuando el estado del caso cambia a «Documentos recibidos» o «Pendiente de revisión». | ||
| Por qué es importante Este momento marca el fin del tiempo de espera del cliente y el inicio del ciclo de revisión interna. Es fundamental para medir los tiempos de respuesta del cliente y los tiempos de espera en las colas de tramitación interna. Dónde obtenerlo Se deduce del registro de auditoría del caso, que recoge la fecha y hora del cambio de estado a «Documentos recibidos» o a un estado similar. También puede relacionarse con los eventos de carga de documentos. Capturar Identifique la fecha y hora del cambio de estado a «Documentos recibidos» o «Listo para revisión». Tipo de evento inferred | |||
| Información adicional solicitada | Representa un ciclo de retrabajo en el que el equipo de incorporación debe volver a contactar con el cliente para aclarar información o solicitar documentos que faltan. Es un evento explícito que normalmente se registra cuando se envía una comunicación al cliente. | ||
| Por qué es importante Esta actividad es un indicador clave de ineficiencia del proceso y de una mala experiencia del cliente. Hacer un seguimiento de su frecuencia ayuda a identificar las causas del retrabajo y a medir el KPI «Tasa de ciclos de retrabajo». Dónde obtenerlo Se obtiene de un registro de eventos de comunicaciones con el cliente o de un cambio de estado a «A la espera de información adicional». La primera opción permite registrar con mayor precisión el momento exacto de la solicitud. Capturar Busque eventos de comunicación registrados o un cambio de estado a «Pendiente de respuesta del cliente». Tipo de evento explicit | |||
| Revisión inicial realizada | Representa la finalización de las comprobaciones preliminares, automatizadas o manuales, como la validación básica de datos o la revisión de listas de sanciones. A menudo, se deduce de un cambio de estado en el flujo de trabajo del caso en Fenergo, por ejemplo, al pasar de «Nuevo» a «Revisión completada». | ||
| Por qué es importante El seguimiento de este primer hito ayuda a identificar problemas iniciales de calidad de los datos y cuellos de botella en la etapa de precalificación. También permite distinguir la fase automatizada inicial de los procesos de revisión manual más exhaustivos. Dónde obtenerlo Se deduce del historial del caso o del registro de auditoría al identificar la fecha y hora en que el estado cambia a uno que indica que la revisión ha finalizado, como «Revisión superada» o «A la espera de documentos». Capturar Identifique en el historial del caso el cambio de estado a «Revisión completada» o a un estado similar. Tipo de evento inferred | |||
Guías de extracción
Pasos
- Acceda al módulo de informes: Inicie sesión en la aplicación Fenergo con una cuenta de usuario que tenga permisos suficientes para el módulo de informes y análisis. Vaya al módulo, que suele encontrarse en el menú principal de la aplicación.
- Cree un informe nuevo: Inicie la creación de un informe personalizado. Elija un nombre y una descripción que indiquen claramente su propósito, por ejemplo, 'Registro de eventos de incorporación KYC para Process Mining'.
- Defina la fuente de datos principal: Seleccione el objeto de datos o la vista principal que registra el ciclo de vida de los casos. Suele tratarse de una vista preconfigurada, como
[CaseWorkflowHistory]o[LifecycleEventsView]. Este objeto debe incluir identificadores de casos, nombres o estados de eventos y marcas de tiempo. - Configure las columnas del informe (atributos): Use la interfaz de creación de informes para añadir columnas. Asigne los campos de origen del modelo de datos de Fenergo a los atributos necesarios del Registro de eventos. Por ejemplo, asigne
CaseIDaCustomerApplication,EventTimestampaEventStartTimeyEventPerformeraInitiatingUser. - Defina la lógica de las actividades: Este es el paso más importante. Configure el informe para que genere una fila independiente por cada una de las 14 actividades requeridas. Para ello, cree bloques lógicos o conjuntos de datos filtrados para cada actividad y combínelos con UNION o una función equivalente en el generador de informes.
- Defina la lógica de 'Caso creado': Cree el primer bloque. Filtre la fuente de datos para seleccionar el evento inicial de creación del caso. A menudo, se identifica por la marca de tiempo más antigua asociada al caso o por un tipo de evento llamado 'Caso creado'. Asigne
CreationDateaEventStartTime. - Defina la lógica de las actividades basadas en el estado: Para las actividades que se deducen de cambios de estado, como 'Documentos recibidos' o 'Solicitud aprobada', cree bloques independientes. Filtre la fuente de datos por el valor específico del campo
Estadoy useStatusChangeDatecomoEventStartTime. - Defina la lógica de las actividades basadas en tareas: Para las actividades vinculadas a tareas del flujo de trabajo, como 'Revisión de cumplimiento completada', cree bloques que filtren por
TaskNameyTaskCompletionDate. Use la fecha de finalización comoEventStartTime. - Establezca filtros globales para el informe: Aplique filtros al informe para delimitar los datos. Defina un
Date Rangeespecífico paraEventStartTimey evitar exportaciones demasiado grandes. Para el análisis inicial, se recomienda un periodo de 3 a 6 meses. Filtre por el tipo de caso correspondiente, como 'Incorporación de clientes KYC'. - Ejecute y previsualice el informe: Ejecute el informe en la interfaz de Fenergo. Revise las primeras 100-200 filas para comprobar que la estructura de los datos sea correcta, que todas las columnas estén completas y que aparezcan distintas actividades.
- Exporte los datos: Exporte todos los resultados del informe a un archivo CSV o Excel. Este será el archivo sin procesar del Registro de eventos.
- Prepare los datos para finalizar: Abra el archivo CSV exportado. Si el informe no pudo generar directamente las columnas
SourceSystemyLastDataUpdate, añádalas manualmente. Asigne 'Fenergo' aSourceSystemen todas las filas y la marca de tiempo de exportación aLastDataUpdate.
Configuración
- Requisitos previos: El usuario necesita acceso al módulo de informes y análisis de Fenergo y permisos para crear y ejecutar informes personalizados.
- Fuentes de datos principales: El informe debe basarse principalmente en los objetos de gestión de casos y el historial del flujo de trabajo de Fenergo. Entre las fuentes habituales se encuentran
[CaseDetails],[CaseStatusHistory]y[WorkflowTaskHistory]. Los nombres exactos pueden variar según la configuración de Fenergo. - Intervalo de fechas: Es fundamental establecer un filtro por intervalo de fechas en la marca de tiempo del evento para controlar el rendimiento. Empiece con un periodo reciente de 3 a 6 meses. Para analizar datos históricos, ejecute el informe por lotes, por ejemplo, por trimestre o por año.
- Filtros clave: Filtre siempre por el proceso o tipo de caso específico, como 'Incorporación de clientes KYC', para excluir datos irrelevantes. Según los objetivos del análisis, quizá también deba filtrar por tipo de entidad jurídica o jurisdicción.
- Definición de actividades: Defina cada actividad mediante criterios de filtrado específicos en campos como
Estado,TaskNameo un campoEventTypeespecífico. Estos campos son esenciales para identificar cada evento del proceso. - Consideraciones de rendimiento: Los informes que combinan muchas fuentes de datos o abarcan un intervalo de fechas amplio pueden tardar en ejecutarse. Si es posible, programe su ejecución fuera de las horas de mayor actividad. Evite incluir columnas innecesarias en la exportación, ya que aumentan el tiempo de procesamiento.
Consulta de ejemplo sql
/*
This is a logical representation of the configuration needed in the Fenergo Reporting & Analytics module.
The module uses a graphical interface, but this query structure illustrates the required data sources, filters, and unions.
Fields like [CaseLifecycleData].[CaseID] are placeholders for actual Fenergo fields selected in the UI.
*/
-- Base data selection for common attributes
WITH CaseAttributes AS (
SELECT
C.CaseID AS CustomerApplication,
C.SlaTargetDate AS SlaTargetDate,
C.FinalRiskScore AS RiskScore,
C.CurrentStatus AS ApplicationStatus
FROM [CaseDetails] C
WHERE C.CaseType = 'KYC Customer Onboarding'
)
-- 1. Case Created
SELECT
A.CustomerApplication,
'Case Created' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
L.CompletionTimestamp AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CASE_CREATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 2. Initial Screening Performed
SELECT
A.CustomerApplication,
'Initial Screening Performed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Initial Screening' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 3. Data & Documents Requested
SELECT
A.CustomerApplication,
'Data & Documents Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Initial Document Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 4. Documents Received
SELECT
A.CustomerApplication,
'Documents Received' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 5. Document Review Completed
SELECT
A.CustomerApplication,
'Document Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Document Verification' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 6. Background Checks Initiated
SELECT
A.CustomerApplication,
'Background Checks Initiated' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'EXTERNAL_CHECK_INITIATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 7. Risk Assessment Completed
SELECT
A.CustomerApplication,
'Risk Assessment Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Risk Assessment' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 8. Compliance Review Initiated
SELECT
A.CustomerApplication,
'Compliance Review Initiated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Compliance Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 9. Additional Information Requested
SELECT
A.CustomerApplication,
'Additional Information Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Additional Information Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 10. Compliance Review Completed
SELECT
A.CustomerApplication,
'Compliance Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Compliance Review' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 11. Application Approved
SELECT
A.CustomerApplication,
'Application Approved' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Approved'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 12. Application Rejected
SELECT
A.CustomerApplication,
'Application Rejected' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Rejected'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 13. Account Activated
SELECT
A.CustomerApplication,
'Account Activated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Active'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 14. Case Closed
SELECT
A.CustomerApplication,
'Case Closed' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Closed'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]' ¿Todo listo para empezar?
Con este Template de datos, podrá detectar ineficiencias y agilizar el proceso de incorporación de clientes KYC en Fenergo. Empiece hoy mismo a optimizar las operaciones y mejorar la satisfacción del cliente.
Agilice la incorporación de clientes KYC y obtenga aprobaciones más rápidas
Únase a las empresas que reducen el tiempo de incorporación a solo 24 horas.
No se requiere tarjeta de crédito. Empiece en cuestión de minutos.