Complimentary Gartner® Research: Data Lineage Is Essential to Manage the Risks of Agentic AI

Starting point

Data Lineage

Regulatory Compliance

Integrations

AI
What is Data Lineage? Request a Demo
Created with Fabric.js 5.2.4

What is SR 26-2?

The Federal Reserve’s revised model risk management guidance, and what it asks of your data

Prove where every model input came from, predict which models a change will disturb, and protect the decisions your examiners review.

Learn how lineage can help Read the guidance (PDF)

SR 26-2 at a glance

  • Issued April 17, 2026, by the Federal Reserve, the OCC, and the FDIC
  • Supersedes SR 11-7 (2011) and SR 21-8 (2021)
  • Most relevant to banking organizations with more than $30 billion in total assets
  • Parallel publications: OCC Bulletin 2026-13 and an FDIC companion letter
  • Outside its scope: generative AI and agentic AI models

What is SR 26-2?

SR 26-2 is the Federal Reserve’s letter number for “Supervisory Guidance on Model Risk Management,” the first substantial revision to United States model risk guidance in 15 years. It draws a narrower boundary around what counts as a model than SR 11-7 did.

“The term ‘model’ refers to a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates.”

— SR 26-2, Section II

Spreadsheet arithmetic falls outside that definition, as do deterministic rule-based processes and any software with no statistical, economic, or financial theory underpinning it.

Who SR 26-2 applies to

The guidance is expected to be most relevant to banking organizations with more than $30 billion in total assets. Institutions below that threshold are excluded, though the agencies note it may still apply to smaller banks carrying significant model risk exposure from the prevalence and complexity of their models.

SR 26-2 also states that it “does not set forth enforceable standards or prescriptive requirements” and that non-compliance “will not result in supervisory criticism.” Its first footnote qualifies that relief, noting that supervisory action may still follow from violations of law or from unsafe or unsound practices stemming from insufficient management of model risk. Examinations continue, and an examiner now assesses whether your practices fit your risk profile rather than whether you followed a checklist.

What changed from SR 11-7

SR 11-7 (2011) SR 26-2 (2026)
Uniform rigor across the model inventoryRigor scales with model materiality, defined as model purpose combined with model exposure
Prescriptive in tone and structurePrinciples-based, tailored to the bank's risk profile and operational complexity
Vendor products treated as modelsVendor scope reaches "data, parameter values, or complete models"
Silent on artificial intelligenceCovers traditional statistical models and non-generative, non-agentic AI; generative and agentic AI carved out

Under SR 26-2, a bank decides how much oversight a risk model warrants by weighing its exposure and purpose together, and models judged immaterial may need little more than identification and periodic monitoring. That freedom carries an evidentiary cost, because a bank calibrating rigor by materiality has to show what each model consumes and what depends on its output.

Model risk management is now a data problem

SR 26-2 uses the word “data” fourteen times in a document of fewer than 3,000 words, and never uses “data lineage,” “provenance,” or “traceability.” Five passages carry the data obligations, and each names something a bank has to demonstrate about where its numbers originated.

Inherent risk

Section III lists “the quality of inputs for the model, and data constraints” among the factors setting a risk model’s inherent risk. Rating that risk means assessing input quality, which means knowing which systems the inputs came from.

Conceptual soundness

Section V requires validators to document model design, including “key modeling choices, assumptions, qualitative judgments, and data selection.” Recording data selection means naming the sources a developer chose and why.

Ongoing monitoring

Section V asks whether a risk model still performs as expected given changes in “products, exposures, activities, clients, data relevance, or market conditions.” Spotting a change in data relevance means knowing what moved upstream since validation.

Vendor products

Section VII extends validation to vendor “data, parameter values, or complete models,” and asks banks to understand a vendor model’s “development data.” Third-party data needs the same trace as data your own teams produce.

Aggregate risk

Section III defines aggregate risk as arising from “reliance on common assumptions, data, or methodologies” across models, which is the hardest of the five to evidence.

Section VI reinforces that last one, asking that a model inventory hold enough information “to support effective model risk management at the individual and aggregate levels.” A list of risk models and their owners satisfies the individual half, while the aggregate half asks what those models have in common, which is usually their data.

Which risk models draw from the same source

Aggregate risk is the SR 26-2 requirement most model inventories cannot answer today.

“Aggregate risk reflects interactions and dependencies among models; reliance on common assumptions, data, or methodologies; and any other factors that could adversely affect several models and their outputs simultaneously.”

— SR 26-2, Section III

Answering it means naming every risk model that consumes a given data element, then showing what happens to each when that element changes. Most banks attempt this with a spreadsheet of model inputs, refreshed whenever someone remembers. The data lineage bundled with an enterprise data catalog rarely closes the shortfall, for two reasons unrelated to effort.

Catalog lineage often resolves to the table rather than the column, so when a validator asks which models depend on a particular field, it returns every model touching that table and leaves the team to reconstruct the rest by hand. It is also overwritten on each scan, describing your data environment as it stands this morning without reproducing what fed a risk model on the day it was validated.

“Retrospectively scanned metadata is documentation, not impact analysis.”

Solidatus stores data lineage bi-temporally, recording both when something was true in your systems and when the model knew it. A validation team can compare two points in time to see what moved under a risk model since its last review, and can test a proposed change in a sandboxed copy of the live model to see which models, reports, and controls it would disturb before production is touched.

Where generative and agentic AI sit

Footnote 3 places the systems drawing the most board-level attention outside the guidance.

“Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance. Nonetheless, a banking organization’s risk management and governance practices should guide the determination of appropriate governance and controls for any tools, processes, or systems not covered in this document.”

— SR 26-2, Footnote 3

Banks are left to build their own frameworks, and the agencies have said they plan to issue a request for information on model risk management that gives particular attention to banks’ use of AI. Until that produces something firmer, SR 26-2’s principles remain the closest sanctioned foundation, and the carve-out changes nothing about the data underneath. A retrieval corpus feeding a generative system is a data source with a provenance question attached, and an agentic workflow reading from production raises the same aggregate risk question as any traditional risk model sharing a source with another.

Proof

Solidatus is a business lineage platform built for complex, regulated, and hybrid data environments, and it supports risk and governance programs at BNY, HSBC, and Deutsche Bank. At one global investment bank, modeling risk data across an Oracle data warehouse fed by 30 source systems cut change impact assessment from months to minutes.

“The security and the privacy and the ethics follow the information regardless of the transformation.”

Eric Hirschhorn, Former Chief Data Officer, BNY

Where to start

Three moves make a model risk data lineage program tractable.

1

Start from the model inventory you already maintain

Attach each risk model to its inputs at column level rather than cataloging the enterprise first. Calibrating rigor by materiality means knowing what each model consumes, and scoping by model produces validation evidence in the first month.

2

Model the systems no scanner reaches

Risk model inputs routinely pass through mainframes, bespoke calculation engines, and spreadsheet adjustments that connector libraries do not read. Pair automated capture with visual modeling so the trace runs to source instead of stopping at the first system a scanner cannot open.

3

Work on a living data lineage model from day one

Attach owners, data quality rules, and model references while you map. The bi-temporal record accumulating underneath becomes the evidence your next validation cycle asks for, and the sandbox where you test a change before it ships.

SR 26-2 is not the only obligation asking these questions. BCBS 239 and the European Central Bank’s May 2024 guide require complete data lineage at attribute level across risk reporting, DORA extends traceability to third-party and technology dependencies, and EU AI Act Article 10 covers the data behind high-risk AI systems. One data lineage model supports regulatory compliance across all of them.

Frequently asked questions

01.

What is SR 26-2?

SR 26-2 is the revised interagency supervisory guidance on model risk management, issued on April 17, 2026 by the Federal Reserve, the OCC, and the FDIC. It supersedes SR 11-7 and is expected to be most relevant to banking organizations with more than $30 billion in total assets. The guidance covers model development, use, validation, monitoring, governance, and vendor products, setting a risk-based approach in which oversight scales with each model’s materiality.

02.

Does SR 26-2 replace SR 11-7?

Yes. SR 26-2 supersedes SR 11-7 from April 2011, along with SR 21-8, the 2021 interagency statement covering Bank Secrecy Act and anti-money laundering systems. The OCC published the same guidance as Bulletin 2026-13, and the FDIC issued a companion letter. SR 26-2 keeps SR 11-7’s framework of development, validation, governance, and vendor oversight, while replacing uniform rigor with rigor tailored to model materiality.

03.

Does SR 26-2 require data lineage?

Not by name. SR 26-2 never uses the phrase, yet it ties model risk to data at five points: input quality in inherent risk, data selection in conceptual soundness, data relevance in ongoing monitoring, development data in vendor validation, and shared data in aggregate risk. Evidencing any of them means tracing a model input back to its authoritative source, which is what data lineage records.

04.

Does SR 26-2 apply to generative AI?

No. Footnote 3 states that generative AI and agentic AI models “are not within the scope of this guidance,” describing them as novel and rapidly evolving. The principles do apply to traditional statistical and quantitative models and to non-generative, non- agentic AI. The agencies have said they plan to issue a request for information addressing banks’ use of AI, so banks deploying generative or agentic systems build governance on their own judgment in the meantime.

05.

How does SR 26-2 compare to BCBS 239?

Both ask banks to evidence where their numbers came from, in different regulatory styles. BCBS 239 and the ECB’s May 2024 guide are prescriptive, naming complete data lineage at the data attribute level as a minimum element of data governance for risk reporting. SR 26-2 is principles-based and reaches model inputs rather than risk reports, asking about data quality, selection, and relevance across the model lifecycle. A single data lineage model serves both.

See column-level lineage against your model inventory

Book a demo to see column-level data lineage modeled against your own model inventory.

Book a demo Explore the data lineage platform