More than a decade after the Basel Committee published its principles for effective risk data aggregation and risk reporting, known as BCBS 239, compliance remains elusive for many banks. What has changed in the last two years is the intensity of supervision. In Europe, the European Central Bank’s guide on effective risk data aggregation and risk reporting, published in May 2024, spelled out detailed expectations, and data lineage sits at the center of them.
This article is a practical companion for data, risk, and technology leaders at banks and other supervised institutions. It summarizes what supervisors now expect from lineage, offers a readiness checklist and a maturity model, and outlines a remediation approach that also prepares the institution for adjacent pressures such as operational resilience and AI governance. It is not legal advice; institutions should work from the supervisory texts and their own regulators’ guidance.
Why Lineage Became the Supervisory Focal Point
BCBS 239 sets out principles covering governance, data architecture and IT infrastructure, accuracy and integrity, completeness, timeliness, adaptability, and reporting. Progress has been slow. As summarized by Forvis Mazars, the Basel Committee’s November 2023 progress report found that only two of 31 global systemically important banks assessed in 2022 were fully compliant, and ECB on-site inspections in 2023 found deficiencies including insufficient management body oversight, weak data architecture, and fragmented IT systems.
The ECB responded with its RDARR guide and made risk data aggregation a supervisory priority. Capco’s analysis notes that from 2025 banks are assessed against the guide in the supervisory review and evaluation process, that dedicated on-site inspections have begun at some banks, and that consequences can include additional capital requirements. Forvis Mazars lists a wider supervisory toolkit, including periodic penalty payments, capital add-ons, and in severe cases reassessing the suitability of responsible members of the management body.
Lineage matters so much because nearly every other principle depends on it. You cannot evidence accuracy, completeness, or adaptability without knowing how data moves and changes. In the ECB’s words, as quoted by Solidatus, without a data lineage “it is impossible to assess data quality effectively.”
What the ECB Expects From Lineage
Based on summaries of the guide and the ECB’s feedback statement by Solidatus and Capco, the expectations can be grouped into six themes. Always verify wording against the ECB’s own documents.
1. Scope: Complete Lineage for Key Risk Indicators
Key risk indicators used to steer the institution should have complete, end-to-end lineage, covering every critical data element that feeds them. Lineage for a sample of metrics, or built ad hoc when a supervisor asks, is not sufficient, because it slows production of metrics during stress and crisis.
2. Starting Point: Data Capture
Lineage should begin at data capture, the point where data first enters business systems, rather than at the data warehouse. Origination is broader and includes market data, external data, and derived data, all of which need to be traceable.
3. Granularity: Attribute Level
System-level lineage, which shows that system A feeds system B, does not meet expectations. According to the Solidatus summary, the ECB states that lineage should be defined at the data attribute level, with enough granularity to identify critical data elements for ad hoc and impact reports, especially under stress.
4. Transformations and Systems
Every movement and transformation should be traceable from capture to report, with functional and technical detail at attribute level. Documentation should cover systems that deliver, store, aggregate, and transform data, explicitly including end-user applications, and manual steps must be recorded.
5. Controls Along the Path
Data quality controls should apply at each step where data is created, acquired, moved, or transformed. Capco highlights expectations for continuous monitoring with indicators and tolerance thresholds, validations along delivery paths, and impact analysis of quality issues. Lineage is what lets institutions pinpoint where corrections should be made at source.
6. Ownership
Business roles and ownership should be documented at each step, alongside technical ownership of the systems involved. The guide anchors overall accountability at the top of the institution, with specific senior members responsible for the data management framework.
For supervised banks, lineage is no longer a documentation exercise. Supervisors expect complete, current, attribute-level lineage for key risk indicators, starting at data capture, covering manual steps, and tied to controls and owners at every hop.
The Readiness Checklist
Use the following checklist to assess where your institution stands. Answer each question for your most important key risk indicators, not for the estate in general:
- Have we formally defined the set of key risk indicators and regulatory metrics in scope for lineage, approved by senior management?
- For each in-scope indicator, have we identified all critical data elements, with business definitions and owners?
- Does lineage for each critical data element start at data capture in the originating business system, including external and market data sources?
- Is lineage recorded at attribute level, showing how each field is transformed, aggregated, filtered, or joined?
- Are end-user computing tools, such as spreadsheets and desktop databases, included in lineage where they touch in-scope data?
- Are manual steps, adjustments, and overrides recorded with owners and controls?
- Is lineage captured or refreshed automatically when pipelines change, or does it depend on periodic manual documentation?
- Are data quality controls mapped to specific points in the lineage, with thresholds and escalation procedures?
- Can we run an impact analysis for a proposed change to a source attribute and produce results within hours rather than weeks?
- Can we produce an ad hoc risk report under stress conditions, using lineage to identify the needed data elements quickly?
- Is business and technical ownership recorded for every system and transformation in the path?
- Has lineage for in-scope indicators been independently validated, for example by internal audit or a second line function?
Questions you cannot answer “yes” for your top indicators deserve a place on the remediation roadmap. Questions where the answer depends on a few experts who know the systems are a warning sign in their own right.
A Five-Level Maturity Model
- Level 1, Fragmented: lineage exists in diagrams, spreadsheets, and expert knowledge; it is system-level and quickly outdated.
- Level 2, Documented: lineage for priority reports is documented in a tool at table level, refreshed periodically, with known gaps around end-user computing.
- Level 3, Attribute-level for priority indicators: critical data elements for key risk indicators have attribute-level lineage from capture to report, including manual steps, with owners recorded.
- Level 4, Automated and controlled: lineage is captured automatically from engines and code wherever possible, kept current with change management, and linked to data quality controls and thresholds.
- Level 5, Operational: lineage drives impact analysis in change processes, incident response, and ad hoc stress reporting, and is routinely validated by second and third lines.
Supervisory expectations described in the ECB guide align broadly with level 3 at minimum for in-scope indicators, and the emphasis on currency, controls, and stress reporting points toward level 4.
Building the Remediation Roadmap
Phase 1: Scope and Govern
Confirm the in-scope indicators with senior management, appoint accountable owners, and establish a lineage standard that defines granularity, naming, required metadata, and how manual steps are documented. Choose the lineage platform or combination of platform catalog and enterprise metadata tool that will hold the authoritative graph.
Phase 2: Automate Where Possible
Enable automated lineage capture in modern platforms, such as runtime capture from Spark and SQL engines through native catalogs or OpenLineage, and code parsing for warehouses and stored procedures. Import metadata from ETL tools. Automation reduces cost and keeps lineage current, which supervisors explicitly expect.
Phase 3: Close Legacy and Manual Gaps
Mainframes, vendor packages, and end-user computing are where lineage programs stall. For each gap, decide whether to decommission, migrate into governed pipelines, instrument, or document manually with owners and review dates. Prioritize gaps that feed the most important indicators.
Phase 4: Connect Controls and Operations
Map data quality controls to lineage nodes, link incidents to the lineage graph, and use lineage in change management so that impact analysis is a standard step for any change touching in-scope data. Run fire drills that simulate stress reporting to prove the lineage supports ad hoc requests.
Phase 5: Validate and Sustain
Have second line and internal audit validate lineage on a sample basis, track coverage and freshness metrics, and report progress to the management body regularly.
Questions the Management Body Should Ask
Because accountability sits with senior leadership, board members and executives need a way to probe lineage readiness without becoming data engineers. These questions tend to reveal the real state of affairs quickly:
- For our top five key risk indicators, what share of critical data elements has attribute-level lineage from data capture today, and how was that figure verified?
- How many manual steps or spreadsheets sit in the path of those indicators, and who owns each one?
- How long would it take to identify every report affected if a core system changed a key field tomorrow?
- When did we last run a stress reporting fire drill, and what did lineage gaps cost us in time?
- Is lineage kept current automatically, or would it be out of date after the next major release?
- What are the top three lineage gaps, what is the remediation plan, and what resources does it need?
Asking these questions regularly, and expecting evidence rather than assurances, is itself a sign of the active oversight that supervisors look for. It also helps leadership prioritize funding toward the gaps that matter most rather than toward broad tooling purchases.
Connecting Lineage to DORA, ESG and AI
Lineage investments rarely serve one purpose for long. Capco notes that supervisors may examine risk data shortcomings in relation to other areas, including governance, the Capital Requirements Regulation, the Digital Operational Resilience Act, digitalization efforts, and potential AI use. The same guide extends expectations to climate and environmental risk data, where lineage across complex value chains is particularly hard.
Practically, a well-built lineage graph helps institutions map dependencies of critical functions on ICT systems and third parties for operational resilience, trace ESG metrics back to source data, and document the provenance of data used in AI models. Designing the lineage program with these uses in mind avoids building three overlapping inventories.
A Hypothetical Example: A Regional Bank’s Liquidity Metrics
Consider a hypothetical regional bank whose liquidity coverage metrics are produced from a core banking system, a treasury platform, market data feeds, and a set of spreadsheets used for manual adjustments. An on-site inspection finds that lineage is documented only at system level and that the spreadsheets are not covered.
The bank scopes eight liquidity indicators and identifies around one hundred and fifty critical data elements. It enables automated lineage on its newer lakehouse pipelines, parses legacy SQL in the risk data mart, and imports metadata from its ETL tool. The spreadsheets are migrated into a controlled adjustments application that records each override with an owner and reason, emitting lineage events. Data quality checks are mapped to lineage nodes with thresholds. After a fire drill in which the bank produces an ad hoc liquidity report under simulated stress, internal audit validates a sample of lineage paths. The bank moves from level 1 to level 3 for the in-scope indicators within its remediation window, with a plan to reach level 4.
Common Pitfalls
- Diagrams instead of data. Static diagrams satisfy no one for long; lineage must be queryable and current.
- Stopping at the warehouse. Supervisors expect lineage from data capture, not from the first staging table.
- Leaving out spreadsheets. End-user computing is explicitly in scope and is often where errors originate.
- Tool-first programs. Buying a lineage tool without scoping, standards, and owners produces large but untrusted graphs.
- One-off projects. Lineage built for an inspection and then left to decay will fail the next review.
Conclusion
Supervisory expectations for lineage are now detailed and enforceable. Banks that treat lineage as a living, attribute-level map of how risk data moves, built through automation where possible, tied to controls and owners, and validated independently, will meet those expectations more efficiently and gain a foundation that supports operational resilience, ESG reporting, and AI governance. The checklist and maturity model above offer a starting point for an honest assessment.
How Hanoi Technology Can Help
Hanoi Technology helps banks and financial institutions build automated, attribute-level lineage for risk and regulatory metrics, from data capture to report.