Data Lineage Compliance: What Regulators Expect

Most regulators do not use the words "data lineage" in their rules. The practical question is whether your team can explain a number to the SEC, OCC, or an internal model-risk reviewer without reconstructing it by hand.

Short answer: data lineage is rarely mandated by name, but the required evidence is traceability to source data, documented transformations, versioned context, and repeatable reconciliation.

We have worked with teams on both sides of this. Teams with lineage could point to the source of every number in their regulatory reports. Teams without it spent weeks reconstructing how a figure was calculated because the original spreadsheet, feed, or owner was no longer available.

Both groups can pass an exam. The difference is cost, speed, and residual risk. Lineage turns a regulatory question into an evidence lookup instead of a reconstruction project.

What the regulations actually say

Three frameworks matter here. None of them say "you must have data lineage." All of them require things that are practically impossible without it.

BCBS 239: risk data aggregation

BCBS 239, the Basel Committee's principles for effective risk data aggregation, is the closest thing to a lineage mandate in financial regulation.

Principle 3 (Accuracy and Integrity) requires that data used for risk reporting be "accurate, reliable, and produced on a timely basis." Principle 4 (Completeness) requires that it cover "all material risk data." Principle 7 (Accuracy of Risk Management Reports) requires that reports "be reconcilable to source data."

That last requirement matters most. If you cannot trace a number in a risk report back to the data that produced it, through every transformation, aggregation, and calculation step, you cannot reconcile it. If you cannot reconcile it, Principle 7 is not satisfied.

The standard does not say "build a lineage system." The requirement it describes, tracing data from origin to report, is data lineage by definition.

SR 11-7: model risk management

The Fed's SR 11-7 guidance covers model risk management, and it has direct implications for data lineage.

SR 11-7 requires that model documentation include "data inputs, transformations performed on those inputs, and the rationale for those transformations." It requires that model validation include "assessment of data quality and relevance." And it requires ongoing monitoring to ensure that "model performance does not deteriorate as conditions change."

Every one of those requirements gets harder without lineage. If you can't trace a model's inputs to their sources, you can't validate data quality. If you can't document the transformations, you can't explain the rationale. If you can't track how inputs change over time, you can't monitor for deterioration.

SR 11-7 doesn't mandate lineage. It mandates things that lineage makes possible and that are expensive to do any other way.

SEC examination standards

The SEC's examination program looks at whether firms have "policies and procedures reasonably designed to ensure the accuracy and completeness" of data used in client communications, regulatory filings, and investment decisions.

In practice, this means examiners ask questions like: "Where did this number come from?" "How was it calculated?" "Can you show me the source?"

Without lineage, answering those questions requires manual reconstruction: opening files, tracing spreadsheet formulas, and finding the original data pull. With lineage, the answer is already attached to the number.

The practical reality

The question is not only whether lineage is "required." The question is what it costs when you do not have it.

Without lineage, every audit response involves archaeology. Someone has to reconstruct the calculation chain from memory, email threads, and file timestamps. This takes weeks, consumes senior staff time, and introduces risk because reconstructed lineage is less reliable than lineage captured at the time of calculation.

With lineage, audit response is a lookup. The number traces to its source. The methodology is documented. The temporal context is preserved. The examiner gets their answer and moves on.

The cost difference is material. We have seen teams spend more than 400 hours preparing for a single exam that a team with lineage handles in under 40. That gap recurs every exam cycle.

What good data lineage looks like

This is not theoretical for us. We build data lineage for SEC filings, structured finance data, and regulatory reporting. In practice, good lineage includes:

Source attribution: every extracted data point carries its EDGAR accession number, filing date, and document location. When an examiner asks "where did this come from?", the answer is a direct link to the source filing.

Transformation history: when we calculate a metric from raw filing data, the calculation methodology is versioned and timestamped. If the methodology changes, both versions are preserved with their effective dates.

Temporal context: the system captures what was known when. If a filing gets amended, the original and the amendment both exist in the timeline. Decisions made before the amendment can be explained in the context of what was available at the time.

Entity resolution: the same company appearing as "NVIDIA Corp." in one filing and "NVIDIA Corporation" in another resolves to a single canonical entity. This prevents the kind of identity confusion that creates compliance risk.

Known gaps: when data cannot be extracted cleanly because of formatting issues, missing tables, or ambiguous structures, that limitation is captured in the metadata. The system knows what it does not know.

This is what DealCharts does for structured finance data: 1,185 CMBS and ABS deals with source records, filing links, and update context attached. It is the same pattern we apply to regulated datasets.

For AI systems, lineage is non-negotiable

The regulatory dimension gets more interesting when AI enters the picture. If your AI system produces a number that shows up in a regulatory report or client communication, the question "where did that come from?" now has two layers: where did the data come from, and what did the model do with it?

Without data lineage, an AI system is a black box producing numbers that no one can trace. With lineage, the AI output connects to its inputs, the inputs connect to their sources, and the whole chain is auditable.

As regulators increase their focus on AI in financial services, the expectation that firms can explain AI outputs will only get stronger. Data lineage is the foundation of that explainability.

The bottom line

Data lineage is rarely required by name. Everything regulators do require, including tracing data to sources, documenting transformations, reconciling reports, and validating model inputs, is impractical at scale without it.

You can run a compliance process without lineage. You will spend more time, more money, and carry more risk every time someone asks where a number came from.

A better compliance system traces every number to its source, documents every transformation, and preserves the context of every decision in a form an examiner or agent can verify independently.

That is more than a compliance program. It is operating leverage.

---

Related:

• How to Get Your Data Ready for AI - Practical guide to AI data preparation
• AI Audit Trail: Evidence Packs - What evidence looks like when your system gets questioned
• Why Outcome Delivery Isn't Enough - Why evidence has to remain attached to the result
• BCBS 239 Data Lineage - A practical guide to the standard
• AI Provenance & Data Lineage - How CMD+RVL approaches lineage