How to limit the endless number of CDE in your bank and follow a prioritization approach to fit your needs

CDEs earn their status through interdependence, not declaration. "Collateral Value" demands a single definition reconciled across Basel IRB LGD, IFRS 9 impairment staging, and LCR outflow calculations -because ambiguity there isn't a documentation gap, it's a capital adequacy gap. A counterparty identifier's path from trade booking to RWA aggregation becomes a priority lineage path not because the technology is complex, but because a break in that chain moves a regulatory capital number. A Probability of Default flagged outside validated model ranges needs immediate escalation - not a daily batch report. These aren't isolated data quality concerns; they are the points where poor governance translates directly into model risk, misstatement, or regulatory censure.

What makes CDEs operationally powerful is that they force each discipline to deliver precisely. Lineage without CDE prioritisation produces comprehensive maps nobody acts on. DQ controls without CDE materiality thresholds generate noise rather than signal. Stewardship without named accountability for specific elements -an identified owner for Exposure at Default, a defined remediation SLA, board-level visibility when thresholds breach- remains a governance policy on paper. CDEs convert each discipline from a programme of record into a working control. That is why they sit at the centre of the diagram: not as an artefact to be catalogued, but as the intersection where definition, traceability, quality, and accountability become mutually reinforcing

This integration creates a virtuous cycle:

1. Dictionary provides precise CDE definitions
2. Lineage confirms end-to-end traceability for those definitions
3. DQ controls enforce thresholds specific to CDE materiality
4. Ownership ensures accountability for the full lifecycle

By the time institutions reach a mature stage in their RDARR programmes, most foundational capabilities are already in place. Data dictionaries have been built, lineage has been documented, and data‑quality controls operate across key COREP, FINREP and liquidity reporting pipelines. The question governance teams now face is much more targeted: out of thousands of attributes, which ones genuinely warrant enhanced CDE‑level oversight?

Regulatory guidance offers an initial anchor. The European Banking Authority defines Critical Data Elements as data used to calculate key risk indicators that have a direct or significant impact on the value of the indicator or on the technical routine of calculation and reporting. On paper, this is clear. In practice, when applied across complex reporting landscapes, it can be disarmingly broad. Most capital, liquidity and financial reporting frameworks rely on large sets of attributes sourced from multiple systems and transformation layers. Many of these influence regulatory metrics in some way. If the definition is interpreted too generously, institutions can quickly find themselves with hundreds or even thousands of “critical” candidates, overwhelming governance capacity.

This is exactly what many banks see in their first CDE identification passes. Once template cells are mapped back through staging layers to source systems, it becomes obvious that a significant share of the dataset contributes, directly or indirectly-to the calculation of metrics such as total RWA, LCR, NSFR or Stage 3 ratios. Without additional guardrails, the CDE universe expands rapidly, making proportional coverage and sustainable control design almost impossible.

Mature RDARR programmes therefore supplement the regulatory definition with a structured CDE evaluation framework: a scoring model that determines whether a data element truly warrants critical classification. The goal is to move beyond the binary question “does this attribute appear in a regulatory calculation?” and instead assess how materially it influences outcomes and how intensively it should be governed.

A practical framework typically evaluates each candidate data element along five dimensions, each with defined weights and scoring logic:

• Regulatory Materiality (35%)
  How directly and visibly does the element feed into EBA‑defined metrics or validation rules?
  • Score 1: Not referenced in ITS/DPM.
  • Score 3: Used only in internal aggregation feeding management overlays.
  • Score 5: Appears directly in an EBA template cell or in a formal validation rule (for example, a FINREP non‑performing exposure field reconciled across F 04.03, F 07.00 and F 18.00).
• Impact Sensitivity (25%)
  How strongly does variation in the element affect the metric?
  • Score 1: Negligible effect on the final figure (for example, a descriptive tagging field whose misclassification changes portfolio labelling but hardly moves RWA).
  • Score 3: Alters the metric but remains within internal thresholds.
  • Score 5: Reasonable shifts in the value can trigger a limit or regulatory breach,for instance, behavioural maturity assumptions on a large retail deposit book that move LCR by several percentage points.
• Cross‑Domain Reusability (15%)
  How extensively is the attribute reused across domains, templates or metrics?
  • Score 1: Single‑use attribute in a local report.
  • Score 5: Attribute reused across multiple EBA templates and risk types-for example, post‑haircut collateral value feeding IRB LGD in COREP, impairment coverage in FINREP, and secured outflows in LCR/NSFR.
• Control Dependency (15%)
  How robust is the existing control and lineage environment around the element?
  • Score 1: Sourced from a golden system with fully automated interfaces, reconciled to the general ledger and covered by strong, automated DQ controls.
  • Score 5: Maintained through manual processes with weak or sampling‑based checks—such as a forbearance flag updated in spreadsheets and only loosely reconciled to FINREP forborne exposure disclosures.
• Operational Volatility (10%)
  How frequently and unpredictably does the attribute change in business‑as‑usual?
  • Score 1: Highly static data (for example, legal entity country of incorporation).
  • Score 5: High‑frequency attributes, such as intraday cash balances at central banks or rolling secured funding positions used in LCR and intraday liquidity monitoring, where timing and cut‑off assumptions materially affect reported liquidity buffers.

Each dimension is scored from 1 to 5 and combined into a weighted criticality score, typically along the lines of:

CDE Score = 0.35× Regulatory Materiality +0.25 × Impact Sensitivity +0.15× Cross-Domain Reusability +0.15×Control Dependency+0.10×Operational Volatility
 

Attributes above a calibrated threshold—often resulting in roughly 10–15% of attributes within a given domain—enter the CDE inventory, while the remainder are governed with standard, but less intensive, controls.

Note: These proportional scoring weights are not regulator-prescribed; rather, they represent practitioner-informed benchmarks developed through extensive experience delivering BCBS 239 compliance across banks.

These guardrails turn CDE identification from a one‑off mapping exercise into a repeatable, evidence‑driven process. They prevent uncontrolled expansion of the CDE list, focus enhanced governance on elements that genuinely drive capital and liquidity outcomes, and provide a defensible rationale during supervisory reviews. Most importantly, they reinforce the central theme of BCBS 239: in a world of ever‑growing data, what ultimately matters is not how much you govern, but whether you can prove that you have identified and protected what is truly critical.

Result: Score 4.65/5 → Tier 1: Top Critical CDE

This tiered structure delivers BCBS 239 proportionality at scale:

• Tier 1 receives executive stewardship and real-time controls
• Tier 2 gets targeted enhancement without over‑governance
• Tier 3 runs on industrialised, low‑touch automation

The result: Sustainable RDARR governance that withstands supervisory scrutiny while remaining operationally viable, a true evolution from BCBS 239 compliance to demonstrable risk data resilience. This proportionality exercise also helps in identifying the real Critical Data elements which will be 15 % to 20 % of the total attribute population identified within the domains.

This scoring‑to‑tiering mechanism transforms CDE identification from a static exercise into a dynamic governance engine, continuously recalibrating controls to match evolving regulatory templates, product sets and system architecture.