Laboratorio de analytics engineering sobre delitos financieros

Visión general

Es un proyecto personal de aprendizaje y demostración. Simula, con datos sintéticos, el tipo de entorno analítico que se utiliza para estudiar riesgo de clientes y delitos financieros. No es un despliegue para un cliente real ni contiene información de ninguna empresa.

Problema y objetivo

Quería un lugar donde practicar y enseñar cómo se estructura un proyecto de datos completo: modelado por capas, pruebas de calidad, transformaciones repetibles y ejecución orquestada. Elegí un dominio que conozco por experiencia —clientes, transacciones y señales de riesgo— y datos sintéticos para poder mostrarlo sin comprometer datos de nadie.

Arquitectura técnica

El proyecto sigue una organización por capas:

• Base: carga de las fuentes casi sin transformar, con nombres y tipos homogéneos.
• Core: entidades de negocio —clientes y transacciones— con claves y reglas bien definidas.
• Marts: tablas preparadas para análisis concretos.

Los modelos se escriben en SQL con dbt, que gestiona dependencias, pruebas y documentación. La ejecución se orquesta con Airflow y las comprobaciones automáticas se lanzan con GitHub Actions.

Los detalles de implementación (motores, modelos y parámetros concretos) los explico en una conversación.

Tecnologías

• Python para la generación de datos sintéticos y utilidades.
• SQL y dbt para las transformaciones, las pruebas y la documentación.
• DuckDB y BigQuery como motores analíticos.
• Airflow para la orquestación.
• GitHub Actions para la integración continua.

Implementación

El conjunto de datos contiene más de 250 000 transacciones sintéticas asociadas a clientes. A partir de ellas se construyen las capas descritas y se ejecutan pruebas de calidad: unicidad y no nulos en claves, relaciones entre tablas y reglas de negocio sencillas. El objetivo es que el proceso sea reproducible: la misma ejecución produce siempre los mismos resultados. El código es privado y lo explico en detalle a quien le interese.

Retos y decisiones

• Datos sintéticos en lugar de reales. Permite publicar el proyecto, pero obliga a generar datos con una estructura creíble. Las conclusiones analíticas no deben extrapolarse a datos reales.
• Capas explícitas. Cuesta más al principio, pero separa los cambios en las fuentes de los cambios en las reglas de negocio y facilita probar cada parte.
• Pruebas desde el primer modelo. Detectar un problema en la capa base es mucho más barato que descubrirlo en un informe final.

Resultados y evaluación

Resultado verificable: un entorno reproducible con más de 250 000 transacciones sintéticas, arquitectura de tres capas, pruebas de calidad y flujos de transformación orquestados. No se publican métricas de negocio porque los datos son sintéticos.

Qué sigue

Documentar el catálogo de modelos y añadir más escenarios de pruebas. Si algo de esto te resulta útil para tu caso, el servicio de ingeniería de datos recoge cómo lo aplico.