Don’t just prove your lineage. Prove your compliance.
SR 26-2: Regulatory Data Lineage Is Only Half the Case
Lineage shows where your data travelled. Regulators want proof it can be trusted. Here’s how to close the gap.
SR 26-2, the new US interagency model risk guidance, makes the point plainly: a model is only as defensible as the data behind it. European and APAC supervisors use different rulebooks, but they converge on the same demand: show your working, for data and for AI, continuously. Automated data lineage gives you the path your data travels. Compliance that proves itself attaches five things to that same path: provenance, meaning, accountability, consequence and proof that controls ran. This article explains each property, how AI raises the bar, and how Alex Solutions turns regulatory evidence into a by-product of everyday operations.
In this article
Can we trust this, from requirement to source?
It’s the question underneath every regulatory review. Not “do you have a policy?” but something sharper. Whether it’s a regulatory report, a dataset holding customers’ personal information, a critical business process or an AI model’s decision, can you show a supervisor exactly why it deserves to be trusted?
For too long, the honest answer has been “give us three weeks.” Teams pull spreadsheets of mappings, screenshot pipelines and interview whoever remembers how the report was built. The evidence is out of date the day it’s finished, and the whole exercise starts again next cycle.
Automated data lineage changed that picture. It gives you the path your data travels, from source to report, application or model, and that path is the foundation of any defensible answer. The next step is to build on it. Attach what the data is supposed to mean, who answers for it, what depends on it and whether the controls around it actually ran, all to that same path.
At Alex Solutions, we call that the step from lineage evidence to compliance that proves itself.
SR 26-2, BCBS 239 and APRA: One Expectation for Regulatory Data Lineage
Look across the major regimes and the vocabulary changes. The demand converges. And in 2026, the sharpest statement of that demand came from the US.
SR 26-2: Model Risk Is Now Data Risk
SR 26-2 at a glance
Issued
April 2026
Issued by
Federal Reserve, OCC, FDIC
Replaces
SR 11-7 and SR 21-8
Focus
Banking organisations over $30B in assets
For more than a decade, SR 11-7 was the reference text for model risk management in US banking. SR 26-2 replaces it, alongside SR 21-8, which covered models supporting BSA/AML compliance. One guidance document now governs the models behind credit decisions, capital planning, fraud detection and anti-money laundering.
Here’s the part data teams should read twice. Model risk is data risk. A model is only as defensible as the inputs you can trace and explain, and an examiner reviewing a model will follow those inputs upstream. If the trail goes cold at a spreadsheet or an undocumented transformation, the model’s validation story goes cold with it.
That makes SR 26-2 data lineage a practical question, not a theoretical one. Which source tables feed this model? Which definitions did those features rely on? Who owns them, and did the controls on them run? Alex Solutions answers those questions on the same lineage, for every model in the inventory.
The Same Expectation in Europe and Asia Pacific
Europe and the UK
BCBS 239 remains the reference point for risk data aggregation and reporting, and the ECB’s May 2024 guide sets out more detailed supervisory expectations, including on data lineage. DORA extends the lens to ICT resilience and third parties, while Article 10 of the EU AI Act sets data governance requirements for high-risk AI systems.
Asia Pacific
APRA’s CPS 230 expects boards to own operational risk management and the resilience of critical operations. APRA’s April 2026 letter to industry on AI signalled that assurance is not keeping pace with AI adoption, and that point-in-time assurance struggles with systems that change over time.
The common thread is simple. Show your working, for data and for AI, continuously rather than once a year.
Data Lineage Is the Backbone of the Compliance Case
Picture the lineage behind a regulatory return. It shows that a field in the report is fed by a column three systems upstream, via two transformations. That’s the spine of your evidence. Every other question a supervisor asks hangs off it.
Is that column the definition the risk committee approved, or a near-duplicate a project team built last year? Who owns it, and which policy governs its use? If an engineer changes the upstream schema next sprint, which reports, models and controls move with it? And when the retention or masking policy says something must happen to that data, did it happen, and where is the record?
Connect the Answers to the Trace
Every one of those answers is anchored to a point on the lineage. The question is whether they’re connected to it. When meaning sits in a glossary, ownership in a spreadsheet, policy in a document and control evidence in a ticketing system, someone has to stitch them back together before every review.
That doesn’t scale to a modern data estate, let alone the pace of AI. Put those answers on the same connected context as the lineage, and the trace becomes the case. That’s the design principle behind Alex Solutions.
The Five Properties of Provable Data
We think about trust as five properties that need to hold at the same time, in one connected context.
1. Provenance: where it came from
Transformation-aware lineage reverse-engineers SQL logic and captures runtime events through frameworks like OpenLineage, mapping dependencies from source to report across databases, ETL tools and BI platforms. Data doesn’t stop at system boundaries, and neither should the trace.
2. Meaning: what it should be
Data without an agreed definition is an argument waiting to happen. Semantic inference suggests links between glossary terms and the columns that implement them, and mapping the SQL behind a metric shows whether you’re looking at the certified version or a draft.
3. Accountability: who answers for it
Observation agents scan new schemas, identify sensitive patterns and assign domain owners based on telemetry. Critical automated actions route to verified owners for one-click approval, so ownership becomes a working fact rather than a column in a spreadsheet.
4. Consequence: what depends on it
Engineers can simulate the downstream reach of a schema change before they push code, with alerts raised in the pull request. When an upstream data quality rule fails, dependent dashboards can be flagged as “Untrusted” before anyone signs off on them.
5. Proof: evidence the controls ran
Policies execute as code, triggered by metadata events, with technical actions such as dynamic data masking delegated to the platforms you already run through OpenMetaHub. Enforcement generates an immutable log of technical controls, so audit evidence becomes a by-product of operating.
Each property is valuable alone. Together, on a context layer that follows dependencies across every system at once, they turn “we believe this data is right” into “here is the proof.” Alex Solutions builds all five into one platform rather than five separate tools.
AI Provenance Raises the Bar
AI models now consume regulated data, and supervisors are treating them that way. The same five properties apply, extended to the model itself.
Model-to-data lineage maps the lifecycle from source tables through feature engineering to the final prediction. Policy-aware agents flag or block models that try to use data breaching sensitivity, privacy or residency rules. A trace of model inputs and policy validations gives you the evidence an SR 26-2 model review or an explainable-AI assessment asks for, without the scramble.
That’s the idea at the centre of Alex Solutions: AI You Can Trust, on Data You Can Prove. You can’t have the first without the second.
From Assembled Evidence to Operationalised Compliance
This is what we mean by Operationalised Compliance. Instead of static policies on a shelf and evidence gathered for the auditor, controls run continuously and produce their own proof. Policy-aware agents monitor active data flows and raise issues such as residency drift with the full lineage path attached, so the people responsible can act straight away.
Built for Enterprise Scale
At a leading Tier-1 bank in APAC, Alex Solutions runs as one deployment, used across divisions every day. That’s the scale Alex operates at inside a regulated bank.
30M+
data assets under management
2,100+
total users across divisions
25
technologies connected
1,900+
applications catalogued
The result is a compliance posture that’s ready for review on any day of the year, not just the week before the examiners arrive.
Start With the Obligation Under Most Pressure
You don’t need to catalogue the whole estate before anything gets better. Start with the business problem.
Verify Regulatory Compliance is one of the seven Alex Business Solutions, and it begins with a single question: can we trust this, from requirement to source? Pick the obligation under the most pressure today, whether that’s a risk report, a privacy or data-residency requirement, a critical operation or an AI model heading into review.
Alex Solutions connects to the systems you already run and traces the data behind that obligation from requirement to source, with its meaning, ownership, downstream impact and controls attached. Then you extend from there.
Frequently Asked Questions
What is regulatory data lineage?
Regulatory data lineage traces the data behind a regulatory report, process or model from the obligation back to its source systems, including every transformation along the way. It’s the evidence that lets a bank or insurer show a supervisor where a number came from and why it can be trusted.
What is SR 26-2, and how does it affect data lineage?
SR 26-2 is the model risk management guidance issued in April 2026 by the Federal Reserve, OCC and FDIC, replacing SR 11-7 and SR 21-8. Because a model is only as defensible as its inputs, banks need lineage that traces every model back to its source data, with definitions, owners and control evidence attached.
What does BCBS 239 expect for data lineage?
BCBS 239 sets principles for accurate, complete and timely risk data aggregation and reporting. Supervisors increasingly look for lineage from risk reports back to source, with the controls along that path documented. The ECB’s 2024 guide on risk data aggregation sets out more detailed expectations on lineage for banks it supervises.
How do I prove data lineage to an auditor or regulator?
Show more than a diagram. Auditors want the path from source to report plus the agreed definition, the owner, the downstream impact and a record that controls ran. When those sit on the same lineage, evidence comes from everyday operations instead of a three-week assembly exercise.
How does the EU AI Act affect data governance?
Article 10 of the EU AI Act sets data governance requirements for the training, validation and testing data used by high-risk AI systems. In practice, that means knowing where model data came from, what it means and which rules applied to it, which is exactly what model-to-data lineage provides.
Can data lineage for compliance be automated?
Yes. An automated data lineage tool reads SQL logic and runtime events to build and refresh lineage without manual mapping. Alex Solutions goes a step further, attaching meaning, ownership, impact and control evidence to that lineage so compliance checks run continuously.
Prove It on Your Own Regulatory Reporting
Bring one report or model that’s facing review. We’ll show you how Alex traces it back to source and produces the evidence examiners ask for.
