Must all data be traced? What the RDARR Guide really expects of data lineage
Search for the term "data lineage" in the BCBS 239 text: you won't find it. It is a concept the ECB's RDARR Guide introduces and develops in 2024, building on BCBS 239 requirements that had remained more general — the "dictionary" of concepts used, the traceability of manual workarounds, the single authoritative source (BCBS 239, Principle 3). Few topics sparked as contested a debate during the Guide's public consultation as data traceability.
What the RDARR Guide requires
Section 3.4 of the Guide, devoted to integrated data architecture, requires data taxonomy management that includes, in particular, lineage that is "complete and up to date, at the level of the data attribute" — from data capture through to its extraction, transformation and loading — for the risk indicators and their critical data elements identified within the scope of application. (ECB Guide, section 3.4)
"Impossible for large banks," the EBF objected
The European Banking Federation directly challenged the feasibility of this requirement: for a large bank, achieving and maintaining complete, up-to-date lineage for all data, across the entire chain, would simply be impossible — given the number of sources, reports, critical data elements and many-to-many relationships between data and reports — unless that lineage were maintained at the high level of mere "architecture diagrams".
The ECB's response does not give way on the principle, but clarifies a method: data lineage can be achieved through a layered approach. The overview of the data landscape must be clear and up to date at all times — it is always necessary to know which systems are in place, how they are connected, and in what order data flows through the entire chain. When the need arises to trace a critical data element — due to a data quality issue, a period of stress, or any other reason — the bank must be able to describe it based on these architecture diagrams, supplemented by system documentation, interface descriptions and mapping tables — allowing end-to-end traceability to be assembled from the elements available. (ECB consultation feedback statement, May 2024 — Table 4, comment 17 — amendment made)
Lineage created "on demand" is not enough
The ECB does, however, close off a tempting escape route: creating lineage on a case-by-case basis, only when requested, is not sufficient — it consumes time and effort precisely when, during periods of stress or crisis, rapid data aggregation is essential. On substance, the ECB also states that it does not share the view that the exercise would be impossible for large banks: the expected capabilities simply need to be proportionate to the institution's size and the complexity of its data architecture. (ECB consultation feedback statement, May 2024 — Table 4, comment 17)
What granularity, in practice?
KBC Group asked for clarification on the expected level of detail: system-level, attribute-level, technical, table-to-table granularity? The ECB answers that this depends on each institution's internal organisation — the granularity must allow the critical data elements needed to produce reports, including ad hoc ones, to be identified, particularly during periods of stress and crisis. On scope: lineage is required for all the critical data elements needed to calculate the key risk indicators used to steer the institution — not for the entirety of the bank's data. (ECB consultation feedback statement, May 2024 — Table 4, comment 18 — amendment made)
What lineage documentation must actually contain
In response to a request for clarification (ESBG, German Banking Industry Committee, DZ BANK), the ECB details what data lineage documentation must cover: the steps of the data's movement and/or transformation, end to end, from its capture through to reporting, with functional and technical traceability presented at data-attribute-level granularity; the systems that deliver, store, aggregate and transform the data, including end-user-developed (EUC) applications; any manual step; the data quality controls and requirements at each stage of creation, acquisition, movement or transformation; and the business roles, responsibilities and data ownership at each stage, as well as the technical ownership of the systems involved. (ECB consultation feedback statement, May 2024 — Table 5, comment 5)
A never-ending task
Traceability is not a once-and-for-all exercise. For any new initiative, the data taxonomy must be respected, the impact on data architecture assessed, and the necessary links between systems created. In the case of a new product, the taxonomy must be amended to account for it. In the case of a merger, how the taxonomy is implemented, the data lineage itself, and any need to adjust the data architecture in the new entity arising from the consolidation must be assessed during the consolidation process, with the necessary changes made accordingly. (ECB consultation feedback statement, May 2024 — Table 5, comment 5)
Key takeaway
Data lineage does not exist in the founding 2013 text — it is a requirement the ECB built and made operational in 2024, precisely because the thematic reviews and inspections carried out between 2016 and 2023 showed that reliable risk data aggregation requires knowing, at all times, where a piece of data comes from and what transformations it has undergone. The compromise reached during the consultation is clear: not exhaustive traceability of all the bank's data, but complete, proportionate lineage, immediately available for the critical data elements that feed the key risk indicators — built in advance, not at the moment a crisis makes it urgent.
This article is based on three documents: the Basel Committee's 14 BCBS 239 principles (January 2013), the ECB's RDARR Guide (May 2024), and the ECB's feedback statement on the RDARR Guide's public consultation (May 2024).