Finance plus data wasn't a pivot. It was the job from day one.

I joined SLB's treasury in January 2024, as an intern. The job was to reconcile, report, close. And what happens to everyone who joins a finance team happened to me: 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.

The question struck me as a good one and the tool at hand didn't answer it.

Then came automating the treasury reporting. That one gave every analyst on the team about ten hours a month back — around sixty a month between all of us. It's the figure that best explains why I kept going: nobody asked me to automate anything. I did it because I see the whole process, not just my task.

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's where I learned something no course had told me: a number nobody can audit is worth nothing, however good it looks. Hold on to that one. It comes back at the end, and not by accident.

At Neoris/EPAM it grew: I came to own the SG&A close and forecast process for more than fifteen countries — the Americas, Europe and Asia: India, Hungary, Spain, the Czech Republic — from HQ. Monthly close, company-wide forecast confirmation, variances against plan and against prior forecast, FX variance in constant currency.

And again, the same thing. Advanced Excel, Power Query, Power BI, MicroStrategy, JD Edwards, SAP — and underneath all of it, code, because the missing piece was always the data, never the presentation.

That's when I stopped reading it as a run of coincidences. In every finance role I ended up building the same thing. And I worked out where the edge actually is, which isn't where people think: it isn't knowing Python. Plenty of people know Python. It's knowing which question is worth answering before you write the first line.

The M.Sc. in Economics at Javeriana is where that habit turned into a method. The thesis asks whether financial inclusion explains regional growth in Colombia.

Answering it needed, once again, data that didn't exist. I pulled nineteen public sources into a dimensional warehouse with dbt and DuckDB, built an inclusion index by dimension, and built an atlas of all 1,123 municipalities in the country.

And the result wasn't there.

Let me tell you what happened, because this is the part that matters. Add time effects and the coefficient collapses to something you can't tell apart from zero. The naive specification — entity effects only — publishes a +0.027 at p < 0.001 that sounds excellent and means nothing. What it's picking up is something else: the whole country rose at once.

That common rise is the finding. It isn't the noise, it's the answer.

I could have published the +0.027 and nobody would have said a word. I published the null, and its power with it: the design rules out effects above 0.55 points per standard deviation of the index and says it cannot see smaller ones. It's a bound, not an absence. It's 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 anyone who can read tells the difference.

The thesis left me with a standard: if the analysis is production-grade, the infrastructure has to be too. 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, currencies — without me touching a thing. It carries a Power BI semantic model on top.

And an honest backtester, which is where it gets interesting. Five classic technical strategies and every combination of them: 1,392 variants, with fees, with slippage and no look-ahead. 1,392 went in. 51 survived.

That number is the product. Not the 51 that made it: the 1,341 that didn't. Almost all the winning strategies were backtest illusions, and the only way to show 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 isn't analysis — it's data dredging with good presentation.

The same discipline produced two more: a lab that forecasts twenty Latin American economies and measures what each forecast is worth, and Kairo, a product with health and money data open to the public without exposing a single row.

The project that carries the most weight here is a credit decisioning system over 1.96 million SBA loans and 62.4 million HMDA applications, US public data.

The first reading gave me AUC 0.9461.

And I'll be honest with you: for a while there, I felt pretty good.

But that isn't a credit model. It's a leak. TermInMonths is overwritten when a loan is liquidated, so that field carried inside it exactly the outcome I claimed to be predicting. Removing it drops the ablation to 0.6621.

The model that ended up in production sits at 0.7005 — +0.0311 over an interpretable WoE scorecard, with a calibration error of 0.0107. Far less impressive than 0.9461. And it's the only thing that holds.

The system has ten promotion gates and one of them is designed to block my own model when it doesn't comply. That's what I wanted to build: not a model that wins, but one that survives an audit. Which is, when you look at it, the same idea I met in SLB's internal audits a year earlier — except back then I was on the other side of the table.

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

The thesis null is published, with its power. The 0.9461 leak is in the README with the exact number, unretouched. Of 1,392 strategies, the headline is how many died. And this very site carries a log of numbered defects, each with its root cause and its fix.

It's an engineering standard, not humility: a portfolio where everything went well can't be verified. 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 it can't be checked, I don't publish it.

The right role pays for financial judgment and data engineering as one capability, not as two halves. Finance Data Analyst, Financial BI Analyst, Analytics Engineer — three different names for the same job, depending on who you ask.

I'm in Bogotá, GMT-5, with full overlap with US hours.

And if you made it this far, the rest is one click away: the code is public, the figures link to their source, and so do the mistakes.