How to make BCBS 239 critical data elements inspection-ready

A data steward at a European bank opens the catalogue on Monday morning. Two filters: classification, BCBS 239 Risk Data Aggregation. Owner, themselves. The glossary collapses to the business concepts she is accountable for: Counterparty Exposure, Expected Credit Loss, Loss Given Default, Probability of Default, Collateral Value, IFRS 9 Stage. The vocabulary of every BCBS 239 audit since 2013.

Each row carries a six-dot column to the right of the description. One dot per data quality dimension: accuracy, completeness, timeliness, validity, consistency, uniqueness. Coloured by current health. Most are green or grey. Her eye lands on Collateral Value. The first dot is red.

One click. The Data quality tab. A 30-day trend on Accuracy. The current score. 1 / 2 fields coverage. A line at the right that names the stakes: Required by BCBS 239 Risk Data Aggregation, IFRS 9 Expected Credit Loss. The remediation conversation can begin in under a minute.

This is what operational compliance looks like at the column level. Most CDE programs cannot do it.

For more than a decade, BCBS 239 has been a documentation exercise. Banks have produced enormous catalogues of critical data elements: spreadsheets, governance artefacts, mapping diagrams, ownership matrices. The work satisfied audits in 2017. It has not kept pace since. The structural reason is simple: the CDE inventory and the data quality measurements have lived in different tools, and the reconciliation cost has been borne manually.

This post argues that the fix is architectural, not procedural. A critical data element should be a contract that carries the data quality dimensions it requires, attached to the same glossary terms and fields where the measurements happen. Coverage becomes a derived signal. The auditor's question and the steward's daily workflow share the same view. The evidence accumulates by default.

Table of contents

• Why every CDE program stalls at the same place
• What a critical data element should be
• The six-dimension contract
• Coverage as a living view
• Where governance meets observability
• One primitive, four use cases
• The question to ask your program

Why every CDE program stalls at the same place

BCBS 239 was published in 2013. More than a decade on, only 13% of banks have achieved full compliance with Principle 2 (Data Architecture and IT Infrastructure), and 77% report that lineage compliance costs remain significant. The numbers come from Deloitte's 2024 BCBS 239 Progress Report. They are not surprising to anyone running a program.

It is not for lack of effort. Banks have produced enormous volumes of CDE documentation. The artefacts go stale within weeks of any pipeline change. The gap between what the inventory says is critical and what the data quality system is actually measuring has to be reconciled by a person, on a recurring basis, indefinitely.

That is the structural mismatch. The CDE inventory is in a governance tool. The data quality measurements are in a different tool. Auditors need both. Stewards spend their time bridging the two. A CDE program that is mostly bridge-work is not a control. It is a permanent reconciliation overhead.

The supervisory expectation has moved. The ECB's 2024 RDARR Guide and the Basel Committee's 2026 newsletter both push in the same direction: not whether documentation exists, but whether it reflects current operational practice. The Fire Drill, the supervisory test where a bank must produce granular, non-standard risk data with complete lineage and quality indicators inside 48 hours, is the most visible symptom of the shift. Programs that pass it are programs whose CDE inventory and quality measurements come from the same view. Programs that fail it are programs where the two have lived apart.

Documentary compliance was the standard for the first twelve years of BCBS 239. The supervisory expectation has moved.

What a critical data element should be

A critical data element has been treated, mostly, as a label. This field is important. That framing was good enough when the obligation was to produce a list. It is not enough when the obligation is to produce a control.

A CDE is a contract. Four parts:

1. Business meaning. A name and a description that say what the data represents and why it matters. Probability of Default. The likelihood that a borrower fails to meet contractual obligations within a 12-month horizon. The CFO and the regulator both know what this is.
2. Regulatory anchor. The framework the data is in scope for: BCBS 239, IFRS 9, GDPR, SOX, DORA, Solvency II. Not freeform text. An explicit reference to the regime that governs the obligation, drawn from a controlled vocabulary so that filtering and reporting work without interpretation.
3. Ownership. A named person accountable for the contract. Not a team mailbox. The person an auditor's question lands on, and the person who is woken up when something breaks.
4. Quality contract. A declaration of the data quality dimensions the data must satisfy: accuracy, completeness, timeliness, and so on. This is the part most tools omit, and it is the part that turns a documentary classification into an operational one.

The Validio classification model carries all four. A CDE classification names the business concept, declares a regulator from a controlled vocabulary, assigns an owner, and lists the required dimensions. It attaches to glossary terms, which attach to schema fields, which carry the validators that measure the data.

The fourth part is the difference. With a dimension contract on the classification itself, every other part of the system can ask the CDE what it requires.

The six-dimension contract

The six DAMA dimensions are well-known: accuracy, completeness, timeliness, validity, consistency, uniqueness. Most data professionals can recite them. Few platforms treat them as first-class operational objects.

In Validio, every validator declares the dimension it serves. A null-values check carries Completeness. A freshness check carries Timeliness. A referential-integrity check carries Consistency. A numeric-distribution check carries Validity. The choice is not a label for reporting purposes. It is an operational property the platform uses to answer coverage questions.

Now the loop closes. A CDE declares (say) that Accuracy and Completeness are required. The system asks: for each field carrying this CDE, is there at least one validator declaring Accuracy? Is there at least one declaring Completeness? The answer is a derived signal. There is no reconciliation. There is no spreadsheet.

The framing question changes with it. The old question was are we covering what the auditor will ask about? That is a question you answer by reading two documents and hoping they agree. The new question is what does the system show as covered, and what does it show as gapped? That is a question you answer by reading the system.

Gaps surface as gaps. A CDE that requires Timeliness, but where no validator on the underlying fields carries Timeliness, shows up as a coverage gap on every view that aggregates by dimension. The work item creates itself. The steward does not need to remember to look.

Coverage as a living view

The CDE contract becomes operational through two paired views. Same signal, two levels of zoom.

The first is the glossary list. The opening scenario showed it: filter by Classification = BCBS 239 Risk Data Aggregation, filter by Owner = me. The list collapses to the terms in scope. Each row carries a six-dot Data quality column: one dot per dimension, coloured by current health. Green for covered and healthy, red for an active issue, grey for uncovered. A steward scanning the list spots problems instantly.

Look at what the row carries on top of the dots. Collateral Value is governed by four classifications simultaneously: BCBS 239 Risk Data Aggregation, IFRS 9 Expected Credit Loss, AnaCredit, and a Customer Financial Data sensitivity tag. Multi-regime governance is a real condition, not a corner case. A field that is a CDE under one regulation and subject to a privacy regime under another carries both, with no force-fitting of one regime to the other.

The second view is the per-term Data quality tab. One click takes the steward to the detail. Six dimension cards, one per DAMA dimension. Each shows the current score, a 30-day trend, the field-coverage ratio (1 / 2 fields), and the line that names accountability: Required by BCBS 239 Risk Data Aggregation, IFRS 9 Expected Credit Loss. This is the page a risk lead, a compliance officer, or an auditor can open and read without translation. The data is in the language of the obligation.

Worth dwelling on one design decision. Coverage aggregates over direct glossary-term assignments only, not propagated ones. The reason is operational, not philosophical. A CDE marked on one critical field can propagate via technical lineage to dozens of intermediate fields. If those propagated assignments rolled into coverage, the steward would see false confidence: tens of fields marked "covered" by inheritance, when the steward never intended to govern them. So Validio aggregates over what was directly governed. When a propagated assignment is genuinely the right thing to govern, the steward can promote it to direct with a single action. The escape valve preserves the integrity of the signal.

A coverage view is only as trustworthy as its aggregation rule. The reason most governance dashboards produce dashboard fatigue is that the underlying signals are noisy. False greens. False reds. Drift between the artefact and the obligation. A signal that aggregates over direct intent and exposes a deliberate escape for propagation is a signal you can act on. The dot is red because something is actually wrong. The dot is green because something is actually covered.

Where governance meets observability

The CDE primitive is not a separate governance product. It is a lens on the same substrate as the rest of the platform.

The lineage graph carries the same governance signal inline. Each field on the graph can show a per-dimension data quality dot. CDE classifications appear as chips on the fields they govern. Propagated and direct assignments are visually distinguished. A field-level incident opens in the side panel without leaving the graph.

The consequence: tracing a critical field through the data estate does not require switching tools. The auditor's question (where does this number come from, and how do we know it is correct?) gets answered in one view. The lineage shows the path. The dots show the health. The chips show the regulatory anchor.

This is not a separate observability product bolted to a separate governance product. It is the same data, presented differently. A data engineer asks which validators cover this field? A compliance officer asks which BCBS 239 CDEs flow into this report? Same underlying graph, same coverage signal, two questions, one substrate.

The architectural choice that makes this possible is the topic of a companion post on business lineage derived automatically from the metadata governance teams are already producing. The two views share their data, so they cannot drift apart.

One primitive, four use cases

We can work from four operational use cases: data quality and accuracy, data lineage and traceability, data governance and ownership, auditability and transparency. They are presented as interdependent. Weakness in any one undermines the others.

A CDE classification with a dimension contract serves all four from the same object.

For quality, the dimension contract drives coverage analysis and surfaces gaps. The summary view scans them at a glance. The detail view explains them. Quality is a derived signal on the contract itself, not a separate report someone has to assemble.

For lineage, CDE chips and per-field dots overlay the lineage graph, so the regulatory anchor and the health travel with the field as it flows through the estate. Lineage carries governance, not just topology.

For governance, every classification names an owner and a regulator. Accountability is structural. The question who owns this, and under what regime? is one click on the term.

For auditability, non-destructive reruns preserve the original incident alongside the resolution, so the audit trail is a side effect of the workflow, not a manual export. The evidence accumulates by default. (The audit-trail mechanics are the subject of a companion post on validation execution modes.)

This is what operational compliance means: a system whose normal use produces the evidence that compliance requires. The point of the architecture is not to do more compliance work. It is to make the compliance evidence a free output of the work the team is already doing. The longer strategic case for this shift, alongside the supervisory context that is driving it, is set out in Validio's joint whitepaper with Deloitte on BCBS 239.

The question to ask your program

Back to Monday morning. The steward closes the laptop. The red dot is now an incident with an owner, an audit trail, and a path to resolution. Quarter-end is coming. The conversation about Collateral Value's Accuracy degradation will happen with evidence, not memory.

The question to ask of any CDE program, of any vendor in a procurement review, of any internal roadmap: when an auditor asks tomorrow for accuracy and completeness coverage on every BCBS 239 CDE for the past quarter, where does the answer come from?

If the answer comes from a person reconciling a spreadsheet against a quality tool, the program is a document. If the answer comes from a page someone can open and read, the program is a control.

The first twelve years of BCBS 239 ran on documents. The supervisory expectation has moved. The bar now is operational evidence, produced by the system, available on demand.

A critical data element that knows what it requires, on a platform that measures what was required, on a view that shows the answer in the language of the obligation, is what operational compliance looks like at the column level.

That is what shipped.