I did not change careers. I priced what I already did.

I joined SLB's treasury as an intern in January 2024. The job was to reconcile, report, close. And as in every finance team, the report someone actually needed was never the one the system knew how to give.

The first was the FX mismatch across Latin American markets. No view showed it, so I built one in Python. It was not a career decision: the question was good and the tool at hand did not answer it.

Then came automated bank reconciliation in SAP. That one gave every treasury analyst about ten hours a month back — close to sixty a month across the team. It is the figure that best explains why I kept going: nobody asked me to automate anything. I did it because the manual work was the boring part of an interesting question.

Intern to billing specialist for Argentina and Brazil in twenty-six months. Along the way, revenue recognition in SAP under Sarbanes-Oxley and internal audits on technology projects. That is where I learned something that was not on the syllabus: a number nobody can audit is worth nothing, however good it is. That sentence comes back at the end of this page, and not by accident.

At Neoris/EPAM the scope grew: financial management systems for SG&A close and forecast across 15+ countries, in the Americas and the Eastern Hemisphere — India, Hungary, Spain, the Czech Republic. Monthly close, company-wide forecast confirmation, variances against plan and prior forecast, FX variance tracked in constant currency.

And again the same thing: advanced Excel, Power Query, Power BI, MicroStrategy, JD Edwards, SAP — and underneath, code, because the missing piece was always the data, not the presentation.

That is when I stopped reading it as a run of coincidences. In every finance role I ended up building the same thing. The edge is not knowing Python; plenty of people know Python. The edge is knowing which question is worth answering before writing the first line.

The MSc in Economics at Javeriana was where that pattern stopped being a habit and became a method. The thesis asks whether financial inclusion explains regional growth in Colombia.

Answering it needed data that also did not exist: I pulled nineteen public sources into a dimensional warehouse with dbt and DuckDB, built an inclusion index by dimension, and raised an atlas of all 1,123 municipalities in the country.

And then the result did not come.

Adding time effects collapses the coefficient to zero. The naive specification — entity effects only — publishes a +0.0242 at p < 0.001 that means nothing: what it captures is that the whole country rose at once.

That common drift is the finding, not the noise. I published the null: it is on the page, with both maps on the same scale so you can see why. A well-measured null says more about how I work than a pretty coefficient, and the person reading it can tell the difference.

The thesis left me with an uncomfortable question: I knew how to do the analysis, but I had assembled the infrastructure by hand every time. So I built a real one.

market-data-medallion is a PostgreSQL warehouse in medallion architecture, transformations in dbt, eighty-nine automated quality tests and a daily cron that brings in forty-eight assets — crypto, ETFs, US equities, Latin American ADRs and currencies — without me touching anything. It carries a Power BI semantic model on top.

And an honest backtester. Five classic technical strategies and every possible combination of them: 1,392 variants evaluated with fees, slippage and no look-ahead. More than thirteen hundred went in. Fewer than fifty survived out-of-sample validation.

That number is the product. Most of the winning strategies were backtest illusions, and the way to prove it was to split every series into 70% training and 30% the model never saw. Without that blind window, picking the best of 1,392 variants is not analysis: it is data dredging with good presentation.

The most recent project is a credit decisioning system over 1.96 million SBA loans and 93.4 million HMDA applications, US public data.

The first reading was AUC 0.9461.

That is not a credit model. It is a leak. TermInMonths is overwritten when a loan is liquidated, so the field carried inside it the outcome I claimed to be predicting. Removing it drops the ablation to 0.6621.

The production model sits at 0.7005: +0.0311 over an interpretable WoE scorecard, with a calibration error of 0.0107. Far less impressive figures than 0.9461, and the only ones that hold.

The system has ten promotion gates and one of them is designed to block my own model when it does not comply. That is what I wanted to build: not a model that wins, but one that survives an audit — the same idea I met in SLB's internal audits, four years earlier, from the other side of the table.

There is a thread running through all three and it matters more than any of them: I publish what fails.

The thesis null is published. The 0.9461 leak is written in the README with the exact number. Of 1,392 strategies, the headline is how many died. And this very site carries a log of thirty-five numbered defects, each with its root cause and its fix — including the ones I broke this week.

This is not shop-window humility. It is that a portfolio where everything went well cannot be verified, and one where the mistakes are dated can. Every figure on this site links to the artifact that produces it: the repository, the commit, the pipeline. If something cannot be checked, it is not published.

I am looking for a remote role where financial judgment and data engineering are paid as one capability, not two halves. Finance Data Analyst, Financial BI Analyst, Analytics Engineer — the three names job posts give the same position.

Bogotá, GMT-5, full overlap with US hours. The evidence is one click away: the code is public, the figures link to their source, and so do the failures.