A finance data catalog is the index and metadata layer that tells a person or a model which table to use, what each column means, how fresh the data is, where it came from, and whether it can be trusted for a given decision.
For AI, that catalog is the difference between a model that queries the certified general-ledger snapshot and one that quietly joins a staging table someone built for a one-off reconciliation in 2023.
Most finance data platforms fail the discovery test in a specific way. There is no shortage of data; there is a shortage of knowing which copy of it is correct. A single revenue figure lives in the source system, a raw landing zone, two staging models, a certified mart, and three analysts’ personal schemas. All six will answer a query. Five of them will answer it wrong for the question you are actually asking. A model with SQL access and no catalog treats all six as equally valid, and the one it picks is a coin toss weighted by table naming luck.
What the catalog has to record for finance
A generic catalog records table names and column types. That is table stakes and it does nothing to prevent a wrong number. For finance work the metadata that matters is the metadata that encodes correctness and provenance.
- Certification status. Which tables are the source of truth for a domain, who owns them, and what breaks if they are wrong. An uncertified table should be visible in the catalog but flagged, so retrieval can deprioritise or exclude it.
- Point-in-time semantics. Whether a table is as-of (the value as it stood on a date) or latest-known (the current restated value). Confusing the two is how lookahead leakage gets into a training set: you join a feature computed with information that did not exist at the decision date, the backtest looks excellent, and the live model underperforms because it never actually had that information.
- Lineage. The upstream sources and transformations behind each column, pulled from parsing the pipeline’s own query logs rather than typed by hand. When a regulator or an auditor asks where a number came from, lineage is the answer, and it is also what lets you assess blast radius when a source feed changes shape.
- Freshness and load cadence. When the table last loaded and how often it is supposed to. A model producing a liquidity view against a market feed that stopped updating four hours ago is worse than a model that refuses to answer.
- Grain and entity scope. What one row means, and which legal entity, book, or currency it is scoped to. Silent grain mismatches are a leading cause of numbers that are off by a factor nobody can explain.
Active metadata beats a hand-written wiki
The catalogs that die are the ones a data team populates by hand in a burst of enthusiasm and then never touches. By the next restatement the descriptions describe columns that no longer exist. The catalog becomes a liability because it is confidently wrong, which is worse than empty.
Active metadata means the catalog is fed by the platform, not by goodwill. Lineage comes from parsing the warehouse query history. Usage and popularity come from access logs, which is a surprisingly strong trust signal: the table that forty analysts query at quarter-end and reconcile against the board pack is more likely to be right than the one queried twice ever. Freshness comes from load timestamps. Column-level profiling runs on a schedule and surfaces drift in null rates, cardinality, and distributions, so a column that silently changed meaning after a source migration shows up before a model consumes it.
We wire this so the metadata is generated as a byproduct of the data moving. The pipeline that loads a table also writes its lineage, freshness, and profile. Human curation is reserved for the judgement calls a machine cannot infer: certification, ownership, business definitions, and the specific point-in-time caveats that live in someone’s head.
Making the catalog readable by the model, not just the analyst
A catalog built only for a human browsing a web UI is half-built. The retrieval layer that sits in front of a finance model needs the same information in structured form, queried before the model is allowed to touch a table.
In practice the discovery flow for a model looks like this. A request comes in for, say, net exposure to a counterparty. The retrieval layer searches the catalog for candidate tables, filters to certified sources for that domain, checks freshness against the request’s tolerance, reads the point-in-time and grain semantics, and hands the model a small set of qualified tables with their column meanings attached. The model stops guessing at data from table names and works instead from a shortlist that has already passed the checks a careful analyst would run.
This is also where a catalog earns its keep against hallucinated joins. When the model knows from metadata that two tables share a certified entity key, it joins on that. When it knows they do not, the retrieval layer can refuse the join rather than let the model invent a plausible-looking one on matching column names. The audit trail for every answer records which catalog entries were consulted, which tables were used, and their certification and freshness at query time. When someone asks six months later why the model said what it said, that record is the reconstruction.
Discovery quality caps model quality, and most teams underinvest in it. A model reasoning over the wrong table produces a confident wrong number with a clean explanation attached, which is the most expensive kind of error to catch because nothing about the output looks off. The catalog is what stops the model from ever seeing that table in the first place. Building it well is less glamorous and more decisive than most of the modelling that gets the attention.
FAQ
Do we need a data catalog if we already have a data warehouse?
The warehouse stores tables; the catalog tells you which one to trust and why. Without it, an analyst or a model picks a plausible-looking table that is stale, pre-restatement, or scoped to the wrong entity, and nobody notices until the number is wrong.
What is active metadata and how is it different from a wiki of table descriptions?
Active metadata is generated and refreshed by the pipeline itself: lineage from the query logs, freshness from load timestamps, usage from access logs. A wiki is written once by hand and rots by the next quarter-end.
Can an LLM read the catalog directly?
Yes, and that is much of the point. We expose the catalog as structured context the retrieval layer queries before a model touches data, so the model sees column semantics, point-in-time rules and certification status rather than guessing from names.