Most AI initiatives in finance begin at the wrong end. A team sees a compelling demo, picks a model, and starts wiring it into a workflow. Then they discover the financial data infrastructure underneath is fragmented, full of point-in-time errors, and impossible to trace back to a source.
In finance that is not a rough edge, it is a blocker. An answer you cannot trace is an answer you cannot put in front of a portfolio manager or an auditor. And a model standing on unreliable data does not just give wrong answers, it gives wrong answers confidently.
The gap is usually invisible at the start. The demo runs on a tidy extract someone pulled by hand, maybe a few thousand rows that look clean because a human cleaned them. Production runs on the live financial data infrastructure, with late-arriving ticks, vendor restatements, mismatched identifiers and half a dozen feeds that each have their own idea of what a fiscal quarter is. The model has not changed. The data underneath it has, and that is where the project quietly falls apart.
Ground the data before the model
We invert the usual order. Before any model selection, the data layer has to be query-ready and correct. That means treating the underlying financial data infrastructure as the actual product, and the model as a thin layer on top of it. The pieces we insist on first:
- Point-in-time data, so a backtest works only from prices and fundamentals that were actually known on the day, and cannot quietly read values that did not exist yet
- Ingestion from market, transactional, filing and alternative-data sources
- Data lineage and validation, so every value can be traced from the model output back to the exact feed, file and timestamp it came from
- Entity resolution, so “the same company” really is the same company across feeds
- Retrieval setup: vector and warehouse stores designed for the questions you will actually ask
None of this is glamorous. It is also the difference between a system that works in the demo and one that works at quarter-end.
Point-in-time data is the part teams most often get wrong, because it fails silently. A pipeline that restates a figure after the fact, or backfills a correction without a vintage, will make a backtest look better than the strategy ever was. By the time anyone notices, the model is already in production and the numbers it produced have been shown to people who acted on them. Getting the point-in-time data right is unglamorous plumbing, and it is also the cheapest insurance you will ever buy.
Then prove it with evaluation
Only once the data is solid do we prototype, and every prototype ships with an evaluation set. That turns “it looks good” into a number you can argue about. If the system cannot beat the process it is replacing on that number, far better to know in week three than after six months of build.
Strong data lineage is what makes that number defensible. When a reviewer asks why the model said what it said, you can walk the answer back through validation checks to the source record, rather than shrugging. The same lineage that satisfies an auditor also tells your own team where a regression came from when the eval score drops. Lineage is not paperwork you add at the end; it is the thing that lets you debug the system at all.
What this looks like in practice
Concretely, a data-layer-first engagement spends its first weeks on things that never show up in a slide deck. We map every feed and write down its quirks: which fields get restated, which arrive late, how corrections are versioned. We build the vintage history so point-in-time data is reconstructable rather than assumed. We reconcile identifiers across sources so an entity match is a decision we can inspect, not an accident of string formatting. Only then does the lineage graph hold together well enough to trust.
It is slower at the start and far faster afterwards. A team that skipped this work spends month four hunting for why a number moved; a team that did it reads the lineage and has an answer in an afternoon. The cost is the same work, paid earlier, when it is cheap.
If your AI roadmap starts with choosing a model, it is starting in the wrong place. Start with the data.