El cruce entre finanzas y datos no fue un giro. Fue el trabajo desde el primer día.

Entré a la tesorería de SLB en enero de 2024, de practicante. El trabajo era conciliar, reportar, cerrar. Y me pasó lo que le pasa a todo el que entra a un equipo de finanzas: el reporte que de verdad hacía falta nunca era el que el sistema sabía dar.

El primero fue el descalce cambiario de los mercados latinoamericanos. No existía una vista que lo mostrara. Así que la hice en Python.

La pregunta me pareció buena y la herramienta que tenía a mano no la respondía.

Después vino la automatización del reporting de tesorería. Esa le devolvió unas diez horas al mes a cada analista del equipo — como sesenta al mes entre todos. Es la cifra que mejor explica por qué seguí: nadie me pidió que automatizara nada. Lo hice porque veo el proceso completo, no solo mi tarea.

De practicante a especialista de facturación para Argentina y Brasil en veintiséis meses. En el camino, reconocimiento de ingresos en SAP bajo Sarbanes-Oxley y auditorías internas sobre proyectos de tecnología. Ahí aprendí algo que ningún curso me había dicho: un número que nadie puede auditar no sirve, por bonito que se vea. Guarda esa frase. Vuelve al final, y no por casualidad.

En Neoris/EPAM la cosa creció: pasé a ser dueño del proceso de cierre y forecast de SG&A de más de quince países —América, Europa y Asia: India, Hungría, España, República Checa—, desde HQ. Cierre mensual, confirmación del forecast de toda la compañía, variaciones contra plan y contra el forecast anterior, la variación cambiaria en moneda constante.

Y otra vez lo mismo. Excel avanzado, Power Query, Power BI, MicroStrategy, JD Edwards, SAP — y debajo de todo eso, código, porque la pieza que faltaba siempre era el dato, nunca la presentación.

Fue ahí que dejé de verlo como una serie de casualidades. En todos los roles de finanzas terminé construyendo lo mismo. Y entendí cuál era la ventaja, que no es la que uno cree: no es saber Python. Python lo sabe muchísima gente. Es saber qué pregunta vale la pena responder antes de escribir la primera línea.

La maestría en Economía en la Javeriana fue donde ese hábito se volvió método. La tesis pregunta si la inclusión financiera explica el crecimiento regional en Colombia.

Para responderla hacía falta, otra vez, un dato que no existía. Junté diecinueve fuentes públicas en un warehouse dimensional con dbt y DuckDB, armé un índice de inclusión por dimensiones y levanté un atlas de los 1.123 municipios del país.

Y el resultado no salió.

Te cuento qué pasó, porque es la parte que importa. Al meter efectos de tiempo, el coeficiente se cae a algo que no se distingue de cero. La especificación ingenua —solo efectos de entidad— publica un +0,027 con p < 0,001 que suena muy bien y no significa nada. Lo que está recogiendo es otra cosa: que todo el país subió al tiempo.

Esa subida común es el hallazgo. No es el ruido, es la respuesta.

Podía haber publicado el +0,027 y nadie me habría dicho nada. Publiqué el nulo, y con él su potencia: el diseño descarta efectos mayores a 0,55 puntos por desviación del índice y dice que no puede ver los menores. Es un límite, no una ausencia. Está en la página, con los dos mapas en la misma escala para que se vea por qué. Un resultado nulo bien medido dice más de cómo trabajo que un coeficiente bonito, y el que sabe leer nota la diferencia.

La tesis me dejó una exigencia: si el análisis es de producción, la infraestructura también tiene que serlo. Así que construí una de verdad.

market-data-medallion es un warehouse en PostgreSQL con arquitectura medallion, transformaciones en dbt, ochenta y nueve pruebas automáticas de calidad y un cron diario que trae cuarenta y ocho activos —cripto, ETFs, acciones gringas, ADR latinoamericanos, divisas— sin que yo toque absolutamente nada. Encima lleva un modelo semántico de Power BI.

Y un backtester honesto, que es donde se pone interesante. Cinco estrategias técnicas clásicas y todas sus combinaciones posibles: 1.392 variantes, con comisiones, con slippage y sin look-ahead. Entraron 1.392. Sobrevivieron 51.

Ese número es el producto. No las 51 que quedaron: las 1.341 que no. Casi todas las estrategias ganadoras eran ilusiones del backtest, y la única forma de demostrarlo fue partir cada serie en 70% de entrenamiento y 30% que el modelo nunca vio. Sin esa ventana ciega, escoger la mejor de 1.392 no es análisis — es dragado de datos con buena presentación.

Sobre esa misma disciplina vinieron dos más: un laboratorio que pronostica veinte economías de América Latina y mide cuánto vale cada pronóstico, y Kairo, un producto con datos de salud y de dinero abierto al público sin exponer una sola fila.

El proyecto que más pesa en este recorrido es un sistema de decisión crediticia sobre 1,96 millones de préstamos SBA y 62,4 millones de solicitudes HMDA, datos públicos de Estados Unidos.

La primera medición me dio AUC 0,9461.

Y te voy a ser honesto: por un rato me sentí muy bien.

Pero eso no es un modelo de crédito. Es una fuga. «TermInMonths» se sobrescribe cuando el préstamo se liquida, así que ese campo llevaba adentro exactamente el resultado que yo decía estar prediciendo. Quitarlo derrumba la ablación a 0,6621.

El modelo que quedó en producción está en 0,7005 — +0,0311 sobre una scorecard WoE interpretable, con error de calibración de 0,0107. Mucho menos vistoso que 0,9461. Y es lo único que se sostiene.

El sistema tiene diez gates de promoción y uno está diseñado para bloquear mi propio modelo cuando no cumple. Eso era lo que quería construir: no un modelo que gane, sino uno que aguante una auditoría. Que es, mirándolo bien, la misma idea que me encontré en las auditorías internas de SLB un año antes — solo que entonces yo estaba del otro lado de la mesa.

Hay un hilo que atraviesa las tres cosas y me importa más que cualquiera de ellas: publico lo que falla.

El nulo de la tesis está publicado, con su potencia. La fuga del 0,9461 está en el README con el número exacto, sin maquillar. De 1.392 estrategias, el titular es cuántas se murieron. Y este mismo sitio carga una bitácora de fallos numerados, cada uno con su causa raíz y su corrección.

Es un criterio de ingeniería, no de humildad: un portafolio donde todo salió bien no se puede verificar. Uno donde los errores están fechados, sí. Cada cifra de este sitio enlaza al artefacto que la produce — el repositorio, el commit, el pipeline. Si algo no se puede comprobar, no lo publico.

El rol que encaja paga el criterio financiero y la ingeniería de datos como una sola capacidad, no como dos mitades. Finance Data Analyst, Financial BI Analyst, Analytics Engineer — tres nombres distintos para el mismo puesto, según a quién le preguntes.

Estoy en Bogotá, GMT-5, con solapamiento completo con el horario de Estados Unidos.

Y si llegaste hasta acá, lo demás está a un clic: el código es público, las cifras enlazan a su fuente, y los errores también.