During an SEC examination, regulators request documentation demonstrating exactly how the NAV for a fixed-income fund was calculated on a specific date six months ago, including the source of each bond's price, any adjustments applied, and the identities of systems that transformed the data before it reached the portfolio accounting system. Which data management capability most directly satisfies this regulatory request?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A data catalog is the menu; lineage is the kitchen footage. Regulators aren't asking what the NAV field means — they're asking where that specific price number came from, who touched it, and what happened to it between the pricing vendor and the fund's books. End-to-end data lineage with field-level provenance and immutable historical snapshots is the only capability that produces that documented chain of custody six months after the fact.
Full explanation below image
Full Explanation
Data lineage in the investment management context refers to the documented, queryable chain of custody for every data value from its original source — a pricing vendor, exchange feed, or internal valuation model — through every transformation, join, enrichment, and loading step until it reaches its consuming system. For NAV calculation, this means being able to answer, at the field level: 'On date X, the price for bond CUSIP Y was $98.45. That value originated from Bloomberg BVAL at 16:00 ET, was passed through the pricing normalization service (version 2.3.1), had a manual override applied by analyst Z at 16:22 (override ID: OVR-20240315-4421), and was loaded into the portfolio accounting system at 16:45.'
This requires three architectural components. First, a lineage capture mechanism — typically instrumented at the pipeline level using tools like Apache Atlas, OpenLineage (the open standard adopted by Airflow, dbt, Spark), or commercial tools such as Alation, Collibra, or Informatica — that records input datasets, transformation logic, output datasets, and execution timestamps for every pipeline run. Second, field-level granularity — column-level lineage rather than dataset-level lineage, because regulators want to know where a specific price field came from, not just which system was involved. Third, immutable historical retention — lineage records must be write-once and retained for the applicable regulatory lookback period (typically three to seven years depending on jurisdiction and instrument type).
A data catalog (option A) is a metadata repository that documents data definitions, ownership, and classifications. It tells you what the NAV field means but not how a specific NAV value was computed — it operates at the conceptual level rather than the operational history level. Data quality monitoring (option C) generates current and historical accuracy scorecards but does not record transformation chains — it tells you whether data was within tolerance, not where it came from. MDM (option D) enforces consistency of master identifiers but does not record the lineage of values derived from those identifiers.
The SEC's Rule 17a-4 electronic records requirements, ESMA's EMIR reporting obligations, and the Basel Committee's BCBS 239 principles for risk data aggregation all require firms to demonstrate data lineage for regulatory reporting. BCBS 239 principle 2 explicitly requires that firms 'be able to capture and aggregate risk data across the group and to distribute that data effectively, with the ability to show the accuracy of the data and its provenance.' Data lineage systems are the direct implementation of this requirement.