¿Puedes confiar en tus datos de KYC? Cómo garantizar la precisión mediante la observabilidad de los datos

Buenos días. Buenos días, buenas tardes, buenas noches. Bienvenidos al seminario en línea. Me alegra ver que algunos de los asistentes se están uniendo. Agradezco a todos los madrugadores que han llegado puntuales, pero vamos a comenzar la sesión dentro de unos dos minutos. Es la hora en punto, pero empezaremos dentro de un par de minutos. Veo que algunas personas que están en la sala de espera se están uniendo poco a poco a la sesión.

Queremos daros a todos tiempo suficiente para conectaros a la sesión. Así que aún tenéis un poco de tiempo para tomaros un café o vuestra bebida favorita. Y, como ya he dicho, nos alegra mucho que os hayáis unido a la sesión. Esperamos que sea muy productiva. Empezaremos en unos momentos. Gracias por vuestra paciencia. Veo que se están uniendo un par de asistentes más.

Bienvenidos a los nuevos participantes que se han unido a la sesión. Vamos a empezar en breve. Veo que hay algunas personas más en la sala de espera. Queremos dar a todo el mundo la oportunidad de escuchar el seminario en línea el principio. No os preocupéis, tendremos tiempo de sobra. Creo que solo hemos programado unos 45 minutos, así que incluso os dejaremos un poco de tiempo libre para el resto del día. Pero empezaremos dentro de un rato.

Una vez más, gracias por uniros a nosotros. Muy bien, Scarlett, ya han pasado unos dos minutos. Veo, creo, que hay una persona más intentando conectarse, así que hablaré despacio y, vale, vamos a empezar. De nuevo, buenos días, buenas tardes o buenas noches, dependiendo de dónde os hayáis conectado. Bienvenidos a nuestro tercer y último seminario en línea esta serie. Hablaremos un poco más sobre eso. Si este es vuestro primer seminario en línea nosotros, me alegro de que estéis aquí.

Para aquellos que vuelven para cerrar la serie, bienvenidos de nuevo. Me llamo John Wisencay. Seré vuestro anfitrión hoy. Antes de ceder la palabra a nuestra ponente, Scarlett, quería comentar un par de cuestiones prácticas para aquellos que se incorporan por primera vez a nuestra seminario en línea . Solo un par de cosas rápidas. Lamentablemente, os tenemos a todos con el micrófono silenciado para poder llevar a cabo un seminario en línea bastante eficaz. Contamos con un buen número de asistentes, por lo que queríamos asegurarnos de comenzar el seminario en línea el micrófono silenciado.

A lo largo del seminario en línea, si tenéis alguna pregunta, no dudéis en utilizar nuestro panel de preguntas y respuestas. Para aquellos que no estén familiarizados con Zoom, el panel de preguntas y respuestas se encuentra en la parte inferior de la pantalla. Probablemente veáis un pequeño círculo con tres botones y un «Más». Si hacéis clic ahí, veréis la opción «Preguntas y respuestas». No dudéis en escribir vuestras preguntas allí. Cuento con un equipo, y Hal está a vuestra disposición para responder a vuestras preguntas. Os lo presentaré en un momento.

Esta sesión se grabará o se está grabando. El equipo se asegurará de que recibáis esta grabación una vez finalizada la sesión. Como he dicho, la sesión durará unos 45 minutos, y todos los recursos que se traten hoy os serán enviados por correo electrónico una vez finalizado el evento. Una última cosa: si tenéis algún problema técnico, no dudéis en poneros en contacto conmigo a través de mi dirección de correo electrónico. Intentaré resolverlas con vosotros para solucionarlas. Bien, muy brevemente, vamos a presentar al equipo de hoy. Como ya he mencionado, me llamo John Wisencay.

Dirijo el equipo de ingeniería de ventas aquí. Yo solo soy una pequeña pieza del engranaje. Nuestra ponente principal y la persona a la que hay que prestar atención hoy es Scarlett Webbe. Ella será nuestra ponente y presentadora. Y, como ya he mencionado, Hal Shriver está aquí para ayudar a gestionar y dar soporte a la sesión de preguntas y respuestas. Así que, si tenéis alguna pregunta, no dudéis, una vez más, en escribirla ahí, y nos aseguraremos de que se responda. Siguiente diapositiva.

Como ya he mencionado al principio de la sesión, este es el tercer seminario en línea una serie de tres partes. Si es la primera vez que nos acompañas, no te preocupes. Hemos diseñado estas sesiones para que sean independientes entre sí. Pero, para que te hagas una idea de las sesiones, también puedes volver atrás, inscribirte en ellas y conseguir la grabación, así que no sientas que te estás perdiendo nada. Hemos estructurado todo esto en torno a tres componentes que encajan perfectamente en nuestra oferta global. Nuestra primera sesión tuvo lugar en junio, donde nos centramos en la capa de activación. Se trataba de una visión general de nuestro analista de IA.

A continuación, pasamos a lo que llamamos nuestra «capa de contexto» con nuestra plataforma de inteligencia de datos. Impartimos esta sesión hace unas tres semanas. Aquí es donde podéis recopilar y obtener contexto sobre vuestra información. Y hoy vamos a cerrar esta sesión con la capa de confianza, y vamos a profundizar en nuestra plataforma de observabilidad de datos. Y con esto, estos son los tres seminarios web que tenemos, y hoy nos centraremos en la observabilidad de datos. Así que le cedo la palabra a nuestra ponente, Scarlett. Scarlett, adelante. Gracias, John.

Antes de entrar en materia con la plataforma de observabilidad, quiero establecer rápidamente un vínculo entre esta sesión y el anterior seminario en línea sobre el catálogo de datos «Know Your Customer». En esa sesión, nos centramos en la inteligencia de datos de Actian como las capas de contexto que mencionó John. El proceso de incorporación «Know Your Customer» (KYC) se definió como el proceso obligatorio que utilizan las instituciones financieras para verificar la identidad del cliente y evaluar el riesgo antes de permitir que alguien abra una cuenta. Repasamos los cinco pasos de ese proceso: registro de la cuenta, verificación de la identidad, verificación de la dirección, evaluación de riesgos y aprobación e incorporación. Lo importante que nos aportó el catálogo fue el contexto empresarial. Podíamos buscar «incorporación KYC», consultar la jerarquía del glosario, comprender cada subproceso, identificar a los responsables y relacionar el lenguaje empresarial con los activos de datos técnicos subyacentes. Una de las ideas de esa sesión que creo que merece la pena destacar es que el catálogo es un puente entre el lenguaje empresarial y los activos de datos técnicos.

Responde a la pregunta: ¿dónde está representado realmente este proceso empresarial en nuestros datos? También hemos visto la arquitectura «medallón» que subyace al proceso de KYC. La capa de bronce corresponde a los datos brutos de los clientes, donde se registran inicialmente los datos de alta de cuentas, verificación de identidad y verificación de direcciones. La capa de plata corresponde a los datos de clientes en fase de preparación, donde enriquecemos el registro con listas de vigilancia externas e información sobre sanciones, y asignamos un factor de riesgo. La capa de oro reúne los datos de las cuentas y las transacciones de los clientes para que los equipos puedan señalar actividades potencialmente sospechosas. El catálogo también mostraba indicadores de calidad directamente en el linaje. Esto ha sido un adelanto de lo que veremos hoy.

En el catálogo, esos indicadores convierten el linaje de un mapa de datos estático en algo más parecido a un mapa de riesgos dinámico. Y hoy vamos a profundizar en la plataforma de observabilidad de datos de Actian que genera esas señales, detecta esos problemas y ayuda a los equipos a investigarlos y actuar en consecuencia. Así pues, la demostración de hoy gira en torno a una pregunta: ¿podemos confiar en los datos en los que se basan las decisiones de KYC? Para un banco, esa pregunta es importante porque el KYC no es solo un flujo de trabajo de presentación de informes. Determina si se aprueba a un cliente, si se eleva el nivel de riesgo, si se señalan posibles transacciones sospechosas y si los equipos posteriores confían en el perfil de cliente que están utilizando. A medida que avancemos por ese flujo, mostraremos cómo la observabilidad de datos de Actian supervisa los datos de KYC en todas esas capas, detecta problemas de fiabilidad de forma temprana, valida los datos de incorporación en cuanto a actualidad, esquema, exposición de datos de carácter personal y problemas de formato, utiliza la agrupación de datos para separar las poblaciones de clientes de alto riesgo y las aprobadas, y acelera el análisis de la causa raíz a través de Investigator. Ahora bien, antes de pasar al producto, quiero dedicar un minuto a la arquitectura, ya que es importante para este caso de uso.

Los datos de KYC pueden ser sensibles. Pueden incluir identificadores de clientes, datos de direcciones, campos de verificación de identidad e información sobre puntuación de riesgo. Por lo tanto, desde el punto de vista de la arquitectura, la clave es que la observabilidad de datos de Actian se conecta a los datos allí donde se encuentran. En este ejemplo, nuestros activos de KYC están en Snowflake. Antes de pasar a la demostración, quiero dedicar un momento a explicar por qué la arquitectura es importante, ya que se trata de un gran factor diferenciador de la observabilidad de datos de Actian. En el centro de la plataforma se encuentra un motor de procesamiento Spark SQL desacoplado. Esto significa que podemos analizar los datos, aplicar reglas, detectar anomalías y supervisar los KPI de calidad sin trasladar esa carga computacional a la fuente de datos subyacente.

Así pues, tanto si los datos se encuentran en Snowflake, S3, BigQuery, Kafka, Delta Lake o en cualquier otra parte del flujo de datos, Actian puede analizarlos allí mismo y devolver los resultados de observabilidad a la aplicación. Esto cobra gran importancia porque los flujos de datos modernos no se componen únicamente de tablas limpias de almacén de datos. A menudo incluyen datos sin procesar, semiestructurados y no estructurados en las primeras etapas del flujo. Dado que nuestro motor está desacoplado y se basa en Spark, podemos examinar esos diferentes tipos de datos y etapas del flujo, no solo las tablas finales depuradas que ven los usuarios posteriores. Así pues, hoy nuestra demostración se centra en los datos KYC de Snowflake, que pasan a través de una arquitectura Medallion. Pero la conclusión más importante es que Actian está diseñado para detectar problemas mucho antes en el proceso, antes de que se conviertan en problemas mayores más adelante en los flujos de trabajo de cumplimiento normativo. Esto es importante porque podemos supervisar tablas de gran tamaño y datos sin procesar sin obligar a los equipos a copiar datos KYC confidenciales a otro sistema solo para comprobar si son fiables.

Ahora que ya hemos abordado la arquitectura y por qué el motor de procesamiento desacoplado de Spark es importante para la supervisión de los datos a lo largo del proceso, apliquemos esto al flujo de trabajo de KYC que vamos a mostrar hoy. Seguiremos basándonos en el mismo proceso de incorporación de KYC. Así que, de nuevo: registro de la cuenta, verificación de identidad, verificación de dirección, evaluación de riesgos y aprobación. Pero en lugar de centrarnos en el contexto empresarial y el linaje, hoy nos centraremos en la confianza: si los datos que pasan por cada paso de ese proceso están completos, son recientes, válidos y se comportan según lo esperado. En la demostración, supervisaremos los datos de KYC a lo largo de una arquitectura «medallion», datos brutos de clientes, datos de clientes en fase de preparación y capas de transacciones «gold». Veremos cómo Actian Data Observability detecta problemas de fiabilidad antes de que afecten a esos flujos de trabajo, valida campos de incorporación como los datos de identidad y dirección, y señala problemas relacionados con el esquema, la actualidad, el formato y el riesgo. También mostraremos cómo la agrupación de datos puede separar a las poblaciones de clientes de alto riesgo de los registros aprobados y, a continuación, utilizar Investigator para identificar los campos, registros y segmentos exactos que generan riesgo.

El objetivo es sencillo: pasar de comprender cómo Actian puede observar los datos a lo largo del proceso a ver cómo eso ayuda a los equipos a determinar si realmente se puede confiar en los datos de KYC. Así que, antes de entrar directamente en Actian y la observabilidad de los datos, quiero empezar por el punto en el que un usuario empresarial, un gestor de datos o un equipo de gobernanza podría detectar el problema por primera vez dentro de Actian y la inteligencia de datos. Aquí estamos analizando el conjunto de datos de resumen de transacciones, que se encuentra en la capa «gold» de vuestro proceso de KYC. Aquí es donde se ha reunido la información de las transacciones de las cuentas de los clientes para facilitar la detección de fraudes y la revisión del cumplimiento normativo en las fases posteriores. En la pestaña «Calidad de los datos», Actian Data Intelligence nos ofrece una vista sencilla de entender para los usuarios empresariales sobre el estado de este conjunto de datos. Podemos ver que hay un total de 12 comprobaciones: 10 han superado la comprobación y dos han fallado.

A simple vista, esto nos indica que este conjunto de datos es, en su mayor parte, fiable, pero que existen algunos problemas específicos de fiabilidad que deben tenerse en cuenta antes de confiar plenamente en él para la toma de decisiones relacionadas con el KYC o el fraude. Lo que me gusta de esta vista es que agrupa las comprobaciones en categorías que son significativas para el negocio: coherencia, integridad, puntualidad, fraude y validez. Así, en lugar de pedir a un analista de cumplimiento normativo o a un gestor de datos que interprete código SQL sin procesar, registros o alertas del proceso de tratamiento de datos, pueden ver de inmediato que la mayoría de mis comprobaciones se superan, pero que tengo una comprobación de fraude fallida y una comprobación de validez fallida. Ese es un punto de partida mucho más útil para actuar. Así pues, la pregunta lógica es: ¿qué está provocando esos controles fallidos? Aquí es donde pasamos del contexto a la investigación. Actian Data Intelligence nos indica qué activo empresarial de confianza se ve afectado y nos proporciona el contexto empresarial en torno a él.

Actian Data Observability nos indica por qué se ha producido el problema, qué registros o campos están afectados y qué medidas debemos tomar a continuación. Además, podemos acceder a Actian Data Observability directamente desde el catálogo de datos. Y ahora nos encontramos en Actian Data Observability. Nos centramos en ese mismo activo de resumen de transacciones. Y lo acabábamos de ver en Actian Data Intelligence. Así que aquí es donde la señal de confianza se convierte en una acción concreta. Esto es Investigator.

Se trata de un espacio de trabajo interactivo que utilizan analistas, ingenieros o usuarios de negocio para explorar, diagnosticar y resolver problemas de observabilidad de datos una vez detectadas las anomalías. Aquí podemos profundizar en los resultados de la monitorización. Podemos ver las tendencias a lo largo del tiempo. Podemos apreciar la magnitud del problema y comprender si se trata de un suceso puntual o de un patrón recurrente. En este caso concreto, el del KYC, eso podría significar qué tipos de transacciones están generando el problema de riesgo, qué bandas de riesgo están sobrerrepresentadas o qué registros de clientes están vinculados a importes de transacciones sospechosos. Lo que ocurre aquí es que se están señalando a personas con un importe de alto riesgo y también con un importe de transacción superior a 10 000 dólares. Así que, en lugar de decir que el resumen de transacciones no ha superado una comprobación de fraude, podemos decir: «Estos son los patrones y registros exactos que provocan ese fallo, y este es un subconjunto de los datos que hay que revisar». Este es, por tanto, el traspaso entre la inteligencia de datos y la observabilidad de datos.

Actian Data Observability nos proporciona la capa de confianza operativa, de modo que los registros sean recientes, completos y válidos, y se comporten según lo esperado; y, cuando no sea así, ¿qué es exactamente lo que está causando el problema? Y para el KYC, esa conexión es fundamental. Significa que los equipos no se limitan a documentar los datos de cumplimiento, sino que validan continuamente los datos que respaldan la incorporación de clientes, la puntuación de riesgos, la detección de fraudes y la revisión normativa. Ahora que hemos utilizado Investigator para profundizar en los registros, valores y patrones específicos que están detrás de este problema, voy a volver a la página de resumen. La razón por la que me gusta ir aquí es que Investigator nos ofrece una visión detallada de la causa raíz, pero la página de resumen nos sirve de centro de control operativo. Nos ayuda a comprender cómo encaja este problema concreto en el estado general del proceso de KYC. ¿Qué otros problemas hay pendientes?

¿Qué se ha cerrado? ¿Qué se ha resuelto? ¿Qué activos se ven afectados y dónde se encuentran los riesgos de mayor prioridad en todo el entorno? Así pues, hemos pasado de la alerta a los detalles y ahora volvemos a la visión general. De este modo, un equipo de datos, un equipo de cumplimiento normativo o un responsable de operaciones puede comprender el panorama general y decidir a qué hay que prestar atención a continuación. Así pues, dentro de esta torre de control para la fiabilidad de los datos, en lugar de empezar por una sola tabla o una sola regla, esto nos ofrece una visión operativa de lo que está ocurriendo en todo el conjunto de datos de KYC. Ahora bien, para esta demostración, nos vamos a centrar únicamente en los activos de KYC en Snowflake.

Los tipos de información que quiero destacar aquí son el número total de incidentes, la gravedad o el impacto, la hora de creación del incidente y, por último, las tendencias a lo largo del tiempo. Esto resulta útil para los equipos de operaciones de datos, ya que responde a preguntas como: «¿Qué falla?», «¿Dónde falla?», «¿Cuánto tiempo lleva abierto?» y «¿Quién debe responder?». Y esto es importante porque no todos los problemas tienen el mismo impacto en el negocio. Un cambio en el esquema de una columna no crítica podría ser una simple advertencia, pero la exposición de datos de carácter personal (PII) con campos de identidad que faltan, una caída inesperada del volumen o valores de factores de riesgo fuera de los rangos aprobados son mucho más graves, ya que pueden afectar a la incorporación de nuevos clientes, al cumplimiento normativo, a las revisiones o a la detección de fraudes.

Así pues, la vista general permite a los equipos comprender rápidamente el estado del flujo de datos de KYC antes de profundizar en un activo concreto. Voy a abrir este incidente aquí para que podamos pasar de la vista general a los detalles de un problema de fiabilidad específico. En este punto, un ingeniero de datos o un analista de operaciones de datos puede saber que algo va mal, pero aún así necesita ayuda para entender por dónde empezar. ¿Se trata de un problema en la fuente de datos? ¿Está relacionado con una transformación? ¿Se limita a un campo, a un segmento de clientes o a una ejecución? Ahí es donde nuestro agente de observabilidad de datos resulta útil.

En lugar de recopilar manualmente los detalles del incidente, las tendencias, los resultados de la monitorización y el contexto de los activos, puedo utilizar el agente de observabilidad de datos para que me ayude a resumir lo que estamos observando y a orientar la investigación. La pregunta que me planteo aquí es: ¿cuál es la causa raíz más probable de este incidente? Y lo que hace aquí el agente de observabilidad de datos es ayudar a traducir las señales de observabilidad en una línea de investigación. Puede resumir el incidente, destacar el activo afectado, señalar los campos o patrones que están contribuyendo al problema y ayudar a los equipos a comprender qué deben validar a continuación. Así, en lugar de partir de una alerta genérica que indique que algo ha fallado, obtenemos una experiencia de análisis de la causa raíz más guiada. Podemos determinar si se trata de un problema de calidad de los datos en la fuente, de un problema de transformación, de un problema en el proceso de tratamiento o de una infracción de las reglas de negocio vinculada a los umbrales de KYC. Y el valor empresarial en este caso es la rapidez y la priorización.

Ask AI ayuda al equipo a pasar más rápidamente de la detección de un incidente a su investigación. Proporciona a los equipos de operaciones de datos un punto de partida, ofrece a los equipos de cumplimiento normativo una explicación clara del impacto en el negocio y reduce las idas y venidas entre equipos que intentan interpretar qué significa realmente la alerta. Claro, todavía podemos profundizar en el propio monitor, pero podemos utilizar Investigator para validar los registros y valores exactos implicados. Pero ahora no partimos de una página en blanco, sino que partimos del contexto. Así que orientémonos rápidamente sobre el resto de los activos que vamos a examinar hoy. Como he mencionado anteriormente, la capa de bronce corresponderá a los datos brutos del cliente, y esto representa los datos recopilados cuando el cliente inicia el registro de la cuenta y proporciona datos de identidad y dirección. En la fase de preparación del cliente, es aquí donde introducimos la puntuación de factores de riesgo en comprobaciones externas como listas de vigilancia, listas de sanciones u otros modelos de riesgo.

Y luego, en el nivel superior, tenemos las transacciones y los resúmenes de transacciones, en los que combinamos el riesgo del cliente con el comportamiento de las transacciones. Esto nos ofrece una visión clara. En primer lugar, ¿confiamos en los datos brutos del cliente que nos llegan? En segundo lugar, ¿confiamos en la puntuación de riesgo y en la lógica de aprobación? Y en tercer lugar, ¿confiamos en las señales de transacción que se utilizan para detectar comportamientos potencialmente sospechosos? Así pues, empezaremos con los datos brutos del cliente en la capa de bronce. Este es el punto más temprano en el recorrido de los datos de KYC, y es también donde se pueden detectar muchos problemas antes de que se extiendan.

En esta fase, los clientes facilitan la información de registro de la cuenta y los datos de verificación de identidad; si los datos sin procesar son erróneos en este punto, todas las decisiones posteriores quedan en entredicho. Desde la página de perfilado, podemos ver el estado de cada activo a nivel de atributo o columna. Esto incluye la integridad, los duplicados, la exactitud, la unicidad, la cardinalidad, los valores distintos, cualquier tipo de campo vacío y otras estadísticas de perfilado. En lugar de decir «Creemos que la tabla de clientes parece estar bien», ahora disponemos de una visión cuantificada del estado de los datos. Para el KYC, algunas de las comprobaciones más importantes en esta capa son que los campos de identidad obligatorios estén rellenados. ¿Están presentes los campos de dirección? ¿Siguen campos como el número de la Seguridad Social y el de la tarjeta de crédito los formatos esperados?

¿Son únicos los ID de los clientes? ¿Ha cambiado el esquema de forma inesperada? ¿Y ha descendido o aumentado el volumen de nuevos registros en comparación con el comportamiento habitual? Aquí es donde la observabilidad activa de los datos ayuda a adelantar los procesos. No esperamos a que un panel de control de fraude o un informe de cumplimiento de fases posteriores muestre anomalías. Detectamos los problemas lo más cerca posible del momento de la ingesta. Ahora, analicemos en profundidad una de las alertas relacionadas con los datos sin procesar de este cliente.

En la página «Tendencias y alertas», podemos ver el historial de este activo y las alertas específicas generadas durante cada análisis. La plataforma supervisa el comportamiento esperado a lo largo del tiempo, por lo que analizamos qué ha cambiado, cuándo ha cambiado y cuál ha sido la magnitud del cambio. Por ejemplo, si nos centramos en la exposición de datos de carácter personal (PII): el problema que la plataforma puede identificar son los patrones sensibles que aparecen en lugares donde no deberían, como las notas de formato libre. Si nos centramos en un problema de formato, como la estructura del número de la Seguridad Social, la dirección, la fecha de nacimiento u otros datos de alta. Si analizamos el volumen o la actualidad de los datos, podemos detectar si los datos de registro de los clientes están retrasados o son incompletos. Y cuando accedemos a Investigator, esto va más allá de un simple estado rojo o verde. Investigator nos ofrece ese espacio de trabajo interactivo para comprender los registros, los campos, los valores y los segmentos que dan lugar a la alerta.

Esta es la diferencia entre una alerta irrelevante y una investigación que permite actuar. El equipo puede ver qué campos se ven afectados, qué valores están causando el problema, cuándo comenzó la anomalía y qué registros están implicados. A partir de ahí, pueden exportar los datos detallados, crear una incidencia o derivarla directamente al equipo de incidencias adecuado. Para un flujo de trabajo de KYC, esto es fundamental, ya que no es deseable que un analista tenga que buscar manualmente en Snowflake para intentar determinar si el problema se debe a los datos sin procesar, a un problema en el canal de datos o a un problema de transformación. Lo que se busca es aislar rápidamente la causa y proteger el proceso posterior. Pasemos ahora del nivel «bronce» al nivel «plata». Aquí es donde el proceso de KYC para los clientes en fase de preparación se orienta más hacia el riesgo.

Ya no comprobamos si el cliente ha rellenado correctamente el formulario. En este punto, el registro del cliente se ha enriquecido con información sobre riesgos procedente de fuentes externas, como listas de vigilancia, listas de sanciones u otros procesos de filtrado. En esta demostración, vamos a analizar la puntuación de factores de alto riesgo. Una puntuación más baja representa un nivel de riesgo aceptable. Una puntuación más alta indica que un cliente puede necesitar una revisión adicional o que no debería ser aprobado automáticamente. Y la realidad es que los datos nunca se quedan estáticos. Están en constante evolución a medida que cambian las solicitudes, los clientes y los procesos empresariales.

Por eso las reglas de calidad estáticas dejan de funcionar tan rápidamente. Se necesitan monitores basados en el aprendizaje automático que se adapten a los propios datos, detectando los cambios en las fases iniciales antes de que se conviertan en problemas costosos en fases posteriores. Se trata de generar confianza que crezca al mismo ritmo que tus datos, no solo de capturar una instantánea en un momento dado. Y aquí disponemos de 16 monitores listos para usar que se aplican automáticamente a su activo desde el primer análisis. Así, los monitores de aprendizaje automático de Actian aprenden los patrones de sus datos automáticamente sin que usted tenga que escribir reglas personalizadas. Analizan los datos en cada análisis para determinar distribuciones normales, relaciones y tendencias. De este modo, una vez entrenado el modelo, comprueba continuamente los datos entrantes en tiempo real o por lotes.

Las comprobaciones automatizadas aportan valor de diversas formas. Si eres ingeniero de datos, esto te ahorra tiempo, ya que ya no tienes que escribir reglas ad hoc. Y si nos fijamos, por ejemplo, en este factor de alto riesgo que está demasiado alto, analicemos y desglosemos las partes de un monitor. Un monitor se compone de tres partes. Está la métrica, es decir, lo que se está midiendo. Está el umbral: ¿cómo se determina cuándo algo se convierte en una anomalía? Y hay tres formas de hacerlo.

Se basa en el aprendizaje automático, por lo que aprende a partir de patrones de datos. Dispones de desviaciones relativas y porcentuales entre periodos, así como de rangos predefinidos y valores mínimos y máximos explícitos. Y la tercera parte es la acción. ¿A quién quieres notificar cuando algo vaya mal o los registros no cumplan con ese monitor? Proporcionan valores de referencia basados en el aprendizaje automático, lo que reduce la necesidad de definir manualmente esos umbrales. Así pues, en este ejemplo que vemos aquí, estamos analizando una regla de validación de registros. Dentro de esta expresión, lo que vemos es que estamos utilizando valores de factor de riesgo del 1 al 11, que se consideran aceptables para la aprobación automática, mientras que los valores superiores a 12 se tratan como de alto riesgo.

Ahora bien, eso no significa que los datos sean erróneos en el sentido tradicional. Significa que los datos nos están indicando algo importante desde el punto de vista operativo. Este grupo de clientes debería separarse, revisarse o bloquearse para que no pase a la fase de aprobación posterior. Y este es un excelente ejemplo de por qué la calidad de los datos y la observabilidad necesitan un contexto empresarial. Una cifra como el 13 no es inválida en sí misma. Es inválida para este flujo de trabajo específico de aprobación de KYC porque supera el umbral de riesgo aceptable del banco. Y si lo abrimos en Investigator, podemos ver la distribución de los valores que están provocando la infracción.

Así que del 1 al 16, y podemos ver el número de registros que se encuentran dentro de esas bandas de riesgo. Aquí es donde Investigator nos ayuda a pasar de la detección a la comprensión. Podemos seleccionar un valor específico, como el factor de riesgo 13, y ver los registros asociados a ese valor. Esto proporciona al equipo de operaciones de KYC un conjunto concreto de registros que revisar, en lugar de una alerta vaga que diga: «Se ha detectado un problema con el factor de riesgo». Otra capacidad importante es la agrupación de datos. En este flujo de trabajo de KYC, podemos separar los registros en función del umbral del factor de riesgo. Los clientes con un rango de riesgo aceptable pueden continuar hasta el umbral de aprobación. Los clientes que se encuentren dentro de un rango no aceptable pueden separarse en una vía de «no válido» o de «alto riesgo» para una revisión adicional.

Y eso es importante porque el proceso no tiene por qué detenerse solo porque algunos registros requieran atención. Los registros válidos pueden seguir avanzando mientras los de alto riesgo se apartan para su revisión. Para un banco, esto ayuda a preservar la continuidad operativa sin pasar por alto el riesgo de cumplimiento normativo. Se trata de un punto de control entre las capas «plata» y «oro». Estamos utilizando la observabilidad no solo para detectar que se ha superado un umbral de riesgo, sino también para aislar los registros afectados y evitar que contaminen silenciosamente la población de clientes aprobados. Así que ahora continuemos con la capa de oro. En este punto, el proceso KYC... Déjame pasar por aquí. El proceso KYC ha contenido...

Lo siento. Mi Magic Mouse se ha vuelto un poco loco por un momento. Contiene información tanto de las transacciones como de su resumen. Así pues, las transacciones representan la actividad a nivel de transacción, y el resumen de transacciones nos ofrece una visión agregada que combina el factor de riesgo del cliente y el comportamiento de las transacciones. Esto resulta útil en casos de fraude y de lucha contra el blanqueo de capitales, ya que la actividad sospechosa rara vez se limita a un solo campo de forma aislada. Suele tratarse de un patrón que abarca el perfil del cliente, la puntuación de riesgo, el tipo de transacción y el importe de la misma. Veamos, pues, la transacción sospechosa o el caso de blanqueo de capitales.

La lógica que estamos aplicando aquí es que determinadas combinaciones deben marcarse para su revisión. Por ejemplo, un cliente con una puntuación de riesgo por encima de un umbral aceptable debería ser remitido a un nivel superior, pero incluso un cliente de menor riesgo puede generar actividad sospechosa si presenta determinados tipos de transacciones o importes que superen un umbral definido, como efectivo, Zelle o transferencias bancarias al extranjero superiores a 10 000 dólares. Y si accedemos a Investigator, podemos ver los valores y las combinaciones que están activando la alerta. Una forma de mostrarlo es agrupando o agregando el factor de riesgo con el importe de la transacción. De este modo, el equipo puede identificar rápidamente si el problema se concentra en una banda de riesgo concreta, un tipo de transacción o un rango de importes. Lo importante es que la observabilidad no se limita a indicarnos que el conjunto de datos «gold» no ha superado una comprobación, sino que nos ayuda a comprender por qué ha fallado.

Cuando hay clientes o transacciones de por medio, y tanto si el problema se originó en una fase anterior del proceso de incorporación del cliente, en el enriquecimiento de datos de riesgo o en el procesamiento de transacciones. Ese es el poder de la supervisión a lo largo de todo el proceso de KYC. Podemos partir del comportamiento sospechoso de una transacción en el nivel «oro» y remontarnos, a través de la investigación, hasta los factores de riesgo subyacentes y el perfil básico del cliente. O bien podemos detectar problemas en una fase más temprana, en los niveles «bronce» o «plata», antes incluso de que aparezcan en el flujo de trabajo de las transacciones. Para el departamento de cumplimiento normativo, esto se traduce en una clasificación más rápida. Para la ingeniería de datos, significa menos investigaciones manuales. Para la empresa, supone una mayor confianza en que los datos utilizados para aprobar a los clientes y señalar actividades sospechosas son fiables.

Así pues, una vez que se ha investigado un problema, la siguiente pregunta es: ¿cómo llega al equipo adecuado para que se ocupe de él? La observabilidad de datos de Actian admite alertas y flujos de trabajo operativos. De este modo, los equipos pueden derivar los problemas según la política, el activo, el responsable, la gravedad o el canal. Este puede ser el correo electrónico, Slack, Teams, JIRA, ServiceNow u otro proceso que utilice la organización. El objetivo no es generar más ruido. El objetivo es que las alertas sean procesables. Un problema de datos personales de alto impacto en los datos brutos de un cliente no debe tratarse de la misma manera que una desviación de perfil de bajo impacto en un campo no crítico.

Cualquier incumplimiento del umbral de factores de alto riesgo en los clientes en fase de evaluación debe remitirse al equipo responsable de la revisión de KYC. Es posible que un patrón de transacciones sospechosas y un resumen de transacciones deban remitirse al departamento de operaciones contra el fraude o al de cumplimiento normativo. Y, tras la corrección, la plataforma puede volver a analizar los datos y actualizar el incidente basándose en los propios datos reales. Esto significa que la resolución depende de si los datos han vuelto a un estado aceptable, y no solo de que alguien haya cerrado un ticket. Recapitulemos lo que hemos visto. En primer lugar, hemos supervisado los datos fiables de KYC a lo largo de todo el proceso: los datos brutos de incorporación de clientes, la puntuación de riesgo de los clientes en la fase de preparación y la supervisión de las transacciones de nivel «oro». En segundo lugar, hemos detectado el riesgo de cumplimiento normativo de forma temprana en el nivel «bronce».

Esto implica detectar problemas relacionados con la actualidad, el esquema, la información de carácter personal, la integridad y el formato antes de que se propaguen a fases posteriores. En el nivel «plata», esto significa identificar a los clientes que superan los umbrales de riesgo antes de que sean aprobados. Y en el nivel «oro», implica señalar patrones de transacciones sospechosos que combinen el riesgo del cliente con el comportamiento de la transacción. En tercer lugar, aceleramos la investigación. Investigator ayuda a los equipos a pasar de «algo ha fallado» a «estos son los campos, valores, registros y segmentos que provocan el problema». Eso es lo que convierte la observabilidad de un panel de control en un flujo de trabajo operativo. Así pues, la principal conclusión es sencilla.

El catálogo proporciona contexto a los equipos de KYC. La observabilidad de datos de Actian les ofrece confianza continua. Y, juntos, ayudan a las organizaciones a comprender no solo por dónde fluyen los datos de KYC, sino también si se puede confiar en esos datos en cada paso. Enhorabuena, Scarlett. Bien hecho. Muy informativo y una forma perfecta de cerrar la serie. Así que, para quienes nos acompañáis en directo, si tenéis alguna pregunta, no dudéis en escribirla en el panel de preguntas y respuestas, y nos aseguraremos de responderla aquí en un santiamén.

Quería facilitaros nuestros datos de contacto. Sé que muchos de vosotros veis estas grabaciones después del evento. Además, para aquellos que estéis viendo la grabación, si tenéis alguna pregunta o necesitáis información adicional, quería facilitaros nuestros datos de contacto. No solo los míos, sino también los de Scarlett, que fue nuestra ponente, y los de Hal. Una vez más, si tenéis alguna pregunta, necesitáis información adicional o cualquier otro tipo de contenido, no dudéis en poneros en contacto con nosotros. Una pequeña llamada a la acción tanto para quienes han asistido a la sesión como para quienes están viendo la grabación. Como mencionamos durante nuestra primera sesión, ofrecemos una prueba gratuita de 14 días de nuestro Actian AI Analyst.

Es una forma estupenda de adentrarte en el tema y empezar a familiarizarte un poco con nuestra tecnología. Es muy fácil de aprender, y muchos de nuestros clientes obtienen un beneficio inmediato con esta prueba de 14 días. Acceso completo a la plataforma, sin restricciones. Y si es la primera vez que te unes a nosotros, como he mencionado antes, esto forma parte de una serie de tres sesiones. Aquí la cerramos con la capa de confianza. Pero si te interesa registrarte, puedes hacerlo y ver los seminarios web anteriores bajo demanda. Solo tienes que entrar en nuestra página web y hacer clic en la sección «Eventos», registrarte en esas sesiones y acceder a las dos grabaciones anteriores sobre KYC.

Y con esto, creo que vamos a pasar a la ronda de preguntas. De nuevo, para quienes estén participando en la sesión, si tenéis alguna pregunta, no dudéis en escribirla. Genial. Creo que acabamos de recibir una pregunta. Scarlett, espero que puedas responder a esta en directo. Parece que tenemos: «¿En qué se diferencia Actian Data Observability de, por ejemplo, las herramientas tradicionales de calidad de datos o de supervisión de flujos de datos?». Muy buena pregunta. Una de las principales diferencias de Actian Data Observability es que no nos limitamos a situarnos al final del flujo de datos para comprobar si los datos cumplen o incumplen una regla predefinida.

Como mencioné anteriormente en la presentación, la plataforma utiliza un motor de procesamiento Spark desacoplado para perfilar y analizar datos a gran escala, lo que permite a las organizaciones supervisar los datos en diferentes fuentes y etapas del ciclo de vida de los datos sin limitarse a un único almacén ni depender de comprobaciones basadas en SQL. Esto también respalda un enfoque de «shift left» para la observabilidad de los datos. Así, en lugar de esperar a que esos datos erróneos lleguen a un informe del panel de control o a un modelo de IA, los equipos pueden supervisar los datos mucho antes en el proceso. Por ejemplo, si los datos llegan a una capa «cruda» o «bronce» y se siguen supervisando a medida que avanzan por las capas de transformación y consumo, eso brinda al equipo la oportunidad de identificar los problemas más cerca del punto en el que se produjeron. Además, combinamos la supervisión automatizada —como la actualidad, el volumen, el esquema, las desviaciones más importantes, los ID de registro y los cambios de distribución— con una lógica de negocio específica, además de las reglas de calidad de los datos. De este modo, podemos detectar tanto cambios de comportamiento inesperados en los datos como condiciones de negocio conocidas que deben cumplirse. Así pues, la diferencia práctica, diría yo, es que un proceso puede seguir completándose con éxito desde... Hmm...

desde una perspectiva de infraestructura y, aun así, proporcionar datos incompletos, retrasados o incorrectos. Y Actian Data Observability se centra en validar la fiabilidad de los datos que circulan por ese canal y en hacerlo con la suficiente antelación para que los equipos puedan investigar y resolver los problemas antes de que tengan repercusiones en las fases posteriores. Genial. Gracias, Scarlett. Mm-hmm. Nos llega otra pregunta. Creo que ya lo has mencionado un poco.

Recuerdo, obviamente, las alertas y el análisis de la causa raíz, pero esta pregunta concreta gira en torno a cómo ayuda realmente Actian a los equipos a pasar de las simples alertas al análisis de la causa raíz. Esa es otra buena pregunta, y suele surgir con frecuencia cuando hablo con los clientes. La clave es que Actian Data Observability está diseñado para proporcionar a los equipos el contexto que hay detrás de un problema, no solo para indicarles que un monitor se ha puesto en rojo. Así, cuando se detecta una anomalía, los equipos pueden empezar por el monitor que ha activado la alerta y, a continuación, examinar la información de perfilado subyacente y el comportamiento histórico para comprender exactamente qué ha cambiado. ¿Se ha producido una caída repentina en los volúmenes de registros? ¿Se ha observado un aumento inesperado de valores nulos en un atributo concreto? Como Actian, una vez más, cuenta con ese motor de procesamiento Spark para perfilar los datos, podemos profundizar más allá de la simple consulta de los registros de ejecución del pipeline.

Además, los equipos pueden investigar los problemas a nivel de activos y atributos utilizando Investigator para profundizar aún más en los registros que contribuyen al problema. Y si necesitas aún más contexto, o quizá no tengas tantos conocimientos técnicos, puedes aprovechar nuestro agente de observabilidad de datos para que te ofrezca esa experiencia guiada de análisis de la causa raíz. Por eso, no definiría el análisis de la causa raíz como el botón mágico que te dice automáticamente quién ha estropeado qué. El verdadero valor reside en que Actian Data Observability es capaz de combinar la detección de anomalías, el contexto en torno a los datos mediante la elaboración de perfiles, la investigación de datos y la supervisión a lo largo de todo el ciclo de vida. Y proporciona a los equipos las pruebas que necesitan para pasar rápidamente de «algo ha fallado» a «esto es lo que ha cambiado, dónde ha cambiado y qué datos se ven realmente afectados». Genial. Parece que nos quedan dos preguntas más.

De nuevo, equipo, si hay alguna otra pregunta, no dudéis en escribirla. Las iremos respondiendo en directo. Esta se refiere a las iniciativas relacionadas con datos críticos para el negocio y, en concreto, ¿cómo apoya Actian Data Observability aspectos como las iniciativas relacionadas con datos críticos para el negocio? Sí. Muy buena pregunta. Lo que realmente queremos hacer es vincular la observabilidad de los datos a las iniciativas que ya son importantes para la empresa. Permíteme poner otro ejemplo, aparte del KYC, que sería el sector de los seguros.

Así pues, en el sector de los seguros, esto podría referirse a la suscripción, la tramitación de siniestros, la fijación de precios, la presentación de informes reglamentarios o la mejora de la experiencia del cliente. Todos esos procesos dependen de disponer de datos precisos, completos y oportunos. Por ejemplo, pensemos en la suscripción. Una aseguradora puede estar combinando información de la póliza, el historial de siniestros, los datos del cliente, los detalles de los bienes y los datos de terceros relacionados con el riesgo para tomar una decisión. Y si uno de esos conjuntos de datos está incompleto, retrasado o cambia de forma repentina e inesperada, eso puede afectar directamente a cómo se evalúa el riesgo y cómo se fija el precio de una póliza. Por eso, Actian Data Observability ayuda a los equipos a vigilar más de cerca los datos que hay detrás de esos procesos e identificar problemas antes de que se conviertan en un problema empresarial. Así, en lugar de descubrir un problema porque se ha calculado incorrectamente una prima, se ha retrasado una reclamación o ha habido que reelaborar un informe regulatorio, los equipos disponen de una indicación temprana de que algo en los datos subyacentes requiere atención.

Así pues, el valor reside realmente en ayudar a la empresa a funcionar con mayor confianza. Y el equipo de datos puede detectar los problemas antes, y la empresa tiene mayor confianza en los datos que respaldan decisiones críticas como, en el caso de los seguros, la valoración del riesgo, el pago de las indemnizaciones y la atención al cliente. Genial. Gracias. Mm-hmm. Tengo otra pregunta para ti. Parece que esta va a versar sobre las migraciones de ERP.

En concreto, ¿puede Actian Data Observability ayudar en una migración de ERP y, potencialmente, detectar asignaciones erróneas? Sí. La observabilidad de datos —y esto es válido, diría yo, para cualquier solución de observabilidad— está configurada y diseñada para supervisar almacenes de datos, bases de datos y almacenamiento de objetos, pero no necesariamente aplicaciones, y hay toda una serie de razones que explican por qué es así. Lo que veo con frecuencia cuando hay una migración de ERP es que, por lo general, nos fijamos en dónde van a parar los datos dentro de un entorno no estructurado, como el almacenamiento de objetos. Ya sea S3, Google Cloud Storage, Blob o cualquier otro lugar. Quizás los estés trasladando a un almacén en la nube como Databricks o Snowflake. Empezaríamos a supervisar los datos en ese momento.

Y a partir de ahí, diría que, a menudo, el componente de perfilado de nuestra plataforma es donde muchos clientes que están llevando a cabo procesos de migración encuentran un valor inmenso. Poder realizar un perfil completo de datos estructurados, semiestructurados o no estructurados y disponer simplemente de una comprensión básica de cuál es la realidad de tus datos. Muchas veces ni siquiera cuentan con esas herramientas implantadas. A partir de ahí, puedes identificar cuáles son tus elementos de datos críticos y, a continuación, seguir adelante, incorporando datos de calidad a tus nuevos sistemas. Así pues, poder aprovechar ese perfilado completo a través de nuestro motor de procesamiento Spark, con el objetivo de comprender realmente la realidad de tus datos como primer paso en una migración, es realmente un componente clave, diría yo, dentro de ese tipo de iniciativas. Estupendo. Gracias, Scarlet.

Sí. Y con esto, estas son las últimas preguntas que veo ahora mismo en nuestro panel. Para terminar, gracias a todos por asistir. Hablaré despacio por si acaso hay alguna otra pregunta. Solo para que lo sepáis, esta grabación, junto con otros materiales, se enviará tanto a los participantes como a todas las personas que se hayan inscrito. Una vez más, si tenéis alguna pregunta, no dudéis en poneros en contacto con el equipo. Estamos aquí para ayudaros.

Y con esto, os agradecemos vuestra participación. Scarlet, has hecho un gran trabajo hoy. Al, gracias por tu apoyo. Cuidaos todos.