Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
Critical data elements: the test for what counts, who approves the list, the controls a CDE gets that a normal column does not, and how it stays current.
Updated on
A critical data element, usually shortened to CDE, is a single field whose value directly drives a number an organization has to report, and which would cause measurable harm if it were wrong, missing or late. Customer identifiers, account balances, transaction amounts, exposure values, product codes and effective dates are the usual examples in financial services. The point of the term is exclusion: an organization holds hundreds of thousands of columns and can only put real controls around a small subset of them, so it names that subset and treats it differently.
The most precise published definition sits in a footnote of the European Central Bank Guide on effective risk data aggregation and risk reporting, dated May 2024. Footnote 19 reads:
In this context, critical data elements are those data elements that are used to calculate the key risk indicators and have a direct or significant impact on the value of the indicator or technical routine of the calculation and the reporting.
That definition does two useful things at once. It ties criticality to a named output rather than to a feeling about importance, and it makes the list finite, because an institution has a countable set of key risk indicators. Section 3.2 of the same guide says the set of indicators is defined by the institution itself and that the critical data elements underlying them should then be explicitly identified. Read the guide in full at the ECB banking supervision site.
The guide is also careful about a distinction most articles blur. Footnote 24 separates a data element, which holds information as an independent field and drives the value of an indicator, from a data attribute, which is the description of that field: its business definition, its type, its format. Attributes are usually stored as columns and used in the technical mapping. Elements move the number. When someone on your team says the CDE list has 4,000 entries, this is often what has gone wrong: they have inventoried attributes and called them elements.
The term itself comes out of bank risk reporting. BCBS 239, the Basel Committee paper Principles for effective risk data aggregation and risk reporting published in January 2013, sets out fourteen principles, eleven for banks and three for supervisors. Paragraph 16 draws the scope line the whole discipline rests on: the principles apply to a bank risk management data, and that includes data that is critical to enabling the bank to manage the risks it faces. Paragraph 30 then makes identification a named duty of senior management. The paper is public at the Bank for International Settlements.
The term travels outside banking, and it should. Any organization that publishes numbers other people act on has elements whose accuracy carries consequence, which is the framing the DATAVERSITY explainer of critical data elements uses. What banking supplies is the vocabulary and the enforcement, which is why the definitions worth quoting come from supervisors rather than from general practice.
Two dates are worth knowing because they explain why the term is everywhere in banking and rare outside it. Paragraph 14 of BCBS 239 required global systemically important banks designated in November 2011 or November 2012 to meet the principles by January 2016, with banks designated later given three years from designation. Paragraph 15 strongly suggests national supervisors apply the same principles to domestic systemically important banks three years after their designation. Everything downstream, including the ECB guide eleven years later, builds on that base.
The most common way a CDE program goes wrong in its first month is that the list turns into a copy of the privacy inventory. The two overlap, but they answer different questions. Sensitive data is defined by the harm caused if the wrong person sees it. A critical data element is defined by the harm caused if the value is wrong. A customer date of birth is sensitive and may also be critical. A market closing price on an internal reference table is rarely sensitive at all and is often critical.
Keeping them separate matters operationally, because the controls differ. Sensitive data is protected with masking, retention limits and data access control, where the question is who may read it. A critical data element is protected with validation, reconciliation and lineage, where the question is whether the value is right. A field can carry both sets of controls, and plenty do, but a program that treats one as a substitute for the other ends up with well protected numbers that nobody can prove are correct. The same distinction runs through data integrity and data security, which are related and not interchangeable.
Definition comes first because every later argument depends on it. Without a written test, the list is decided by whoever argues hardest in the meeting, and it grows every quarter because nobody can justify taking anything off it. The test below is the one we use with regulated teams. It has two questions that decide inclusion and two that decide the tier.
| Question | What you are testing | Answer that counts |
|---|---|---|
| 1. Does this element feed a figure that leaves the building? | Whether the element is used to calculate a number in a board pack, a regulatory return, a published financial statement or a model whose output drives one of those. | Yes. If the element only ever appears on an internal dashboard nobody acts on, stop here. |
| 2. Would a plausible error in it move that figure enough to change a decision? | Materiality. Not whether an error is possible, but whether an error of the size that actually occurs in this source would change what somebody does. | Yes. Both question 1 and question 2 must be yes. That is the whole inclusion test. |
| 3. Is there a named person who would be asked to explain the wrong figure? | Whether ownership already exists in practice. If nobody would be asked, the element is not yet governed by anyone, whatever the policy says. | A name. No name means the first remediation task is finding one, not adding a test. |
| 4. Would an error force a restatement, a resubmission or a notification? | Tiering. This separates the elements that carry regulatory consequence from the ones that carry operational cost. | Yes moves the element to tier 1, which gets the tightest tolerances and the fastest escalation. |
Question 2 is the one people find hardest to answer, and BCBS 239 gives the standard to answer it against. Paragraph 56 says:
Supervisors expect banks to consider accuracy requirements analogous to accounting materiality. For example, if omission or misstatement could influence the risk decisions of users, this may be considered material.
Borrowing accounting materiality is what makes the test usable rather than philosophical. Finance teams already set materiality thresholds and defend them to auditors every year. A data team that adopts the same threshold inherits a number, a method and a precedent, instead of arguing from first principles about whether a customer segment code matters.
The importance half of this practice is easier to state than the definition half. Elements that pass the test carry consequences an ordinary column does not: a wrong exposure value misstates capital, a wrong effective date misstates a maturity profile, a wrong counterparty identifier breaks concentration reporting. Those are the failures the discipline exists to prevent, and they are the reason the paragraph 56 standard is worth more than any general appeal to data quality.
Identification runs backwards, from the report to the field. You start with the reports, models and indicators that are in scope, take each figure in turn, and trace it back through the transformations to the fields it is calculated from. The ECB guide sets the scope explicitly in section 3.2: internal risk reports used in decision making, published financial reports and annual statements, supervisory returns including FINREP and COREP templates, EBA and SREP stress test submissions and Pillar 3 disclosures, plus the key internal risk models such as internal ratings based credit models and value at risk models, and the input data those models are developed on.
Working in that direction is what keeps the list finite. Working the other way, from the warehouse towards the report, produces an inventory of everything you own and no way to stop. The practical rule: the length of a CDE list should be a function of how many indicators you report, not of how many tables you store. If your list grew last quarter because a team migrated a source system, rather than because you started reporting something new, the criteria are too loose.
Two techniques make the tracing tractable. The first is lineage: you cannot trace a figure back to its source fields by reading code, and the ECB guide asks for complete and up to date lineage at the attribute level, starting from data capture and including extraction, transformation and loading. That is exactly what column level lineage produces. The second is data profiling, which tells you what a candidate field actually contains before you commit to governing it, and often removes a field from the list because the source turns out to be derived rather than original.
Classification then answers a different question from identification. Identification says whether an element is on the list. Classification says what kind of element it is and which policy applies to it: which indicator or report it serves, which legal entity and business line it belongs to, which tier it sits in, and whether it also carries a privacy or retention obligation. In a catalog this is a set of labels applied to the field, not a separate spreadsheet, because a label that lives beside the data survives the next reorganization and a spreadsheet does not.
Agreeing the list is a process, not an announcement, and the ECB guide names the roles that have to be in it. Data owners are responsible for the indicators and their underlying critical data elements front to end through the whole aggregation process, and the guide says explicitly that delegating that responsibility is generally adequate. Data owners contribute to the definition of controls and to the classification in alignment with the people who consume the data. A central data governance function issues the policies and oversees implementation. And the management body approves the framework.
| Role | What they do on the CDE list | What they cannot delegate |
|---|---|---|
| Management body | Approves the data governance framework, sets the data quality requirements for accuracy, integrity, completeness and timeliness in normal and stress periods, and names one or two of its own members in the management function as responsible for implementation. | Overall accountability. The ECB guide states that naming those members does not discharge the body from its own responsibility for the framework. |
| Named management body member | Carries responsibility for implementing the framework in practice, with a direct reporting line if the role sits with a senior manager instead. | Being identifiable. The point of the arrangement is that one or two people can be asked. |
| Data owner, business side | Agrees the definition of each element, approves its inclusion, signs the tolerance levels on its quality tests, and owns remediation when the tests break. | The definition. A field with two definitions in two systems has no owner in practice. |
| Data owner, technical side | Maintains the mapping from source to report, keeps lineage current, and reviews any schema change that touches a listed element before it ships. | The mapping. Nobody else can say whether a transformation still matches the definition. |
| Central data governance function | Issues the policy, runs the register, monitors quality across the estate, and takes part in change processes with material impact such as acquisitions, outsourcing, new products and tool upgrades. | Consistency across entities. This is the function that stops two subsidiaries running two lists. |
| Validation function, second line | Independently assesses whether the aggregation and reporting processes work as intended, covering infrastructure, lineage and taxonomy, and reviews change initiatives and acquisitions. | Independence from the teams it reviews, with segregation of duties where it sits inside the risk function. |
| Internal audit, third line | Periodically reviews the validation function, the governance framework and the quality of the data used to quantify risk. | Its own periodicity. An audit that only happens after an incident is not a third line. |
The practical sequence that comes out of those roles is short. Draft the candidate list from the reports. Take each candidate to its business owner and get a written definition they will defend. Agree tolerances with the people who consume the figure. Put the assembled list through the governance forum. Then take it to the body that approves the framework. A list that has not been through the last two steps is a working document, and calling it approved before it has been is how a program loses credibility the first time a supervisor asks who signed it.
This is the practice with the clearest answer and the one most articles leave vague. Most of them argue that data quality matters, which nobody disputes. The useful question is what a column gains, in concrete terms, the day it goes on the list. The table below sets out the difference control by control.
| Control | An ordinary column | A critical data element |
|---|---|---|
| Ownership | Whoever built the table, until they change team. | A named business owner and a named technical owner, recorded, responsible front to end through the aggregation process. |
| Definition | Whatever the table comment says, if there is one. | One agreed definition in the dictionary, with the same meaning in every system that uses it. BCBS 239 paragraph 37 calls a dictionary of the concepts used a precondition. |
| Source of truth | Several copies, no ruling on which is authoritative. | One authoritative source per risk type, which BCBS 239 paragraph 36 tells banks to strive towards, with everything else marked as a copy. |
| Quality tests | Whatever somebody wrote once, if anything. | Tests on accuracy and integrity, completeness and timeliness, with tolerance levels agreed in advance and a documented correction process when a tolerance is breached. |
| Lineage | Best effort, reconstructed by hand when someone asks. | Documented at attribute level from capture through extraction, transformation and loading to the report, kept current. |
| Change control | The schema change ships when the pull request merges. | A change to the definition, the source or the transformation goes through approval before it ships, and the owner is the approver. |
| Reconciliation | None. | Periodic reconciliation against the accounting or finance source and against external sources used, so differences are explained rather than discovered. |
| Evidence | None retained. | Test results, breaches and remediation retained so an independent validation function and internal audit can test the process rather than take it on trust. |
Two rows in that table do more work than the rest. The first is tolerance levels agreed in advance. A quality test with no agreed tolerance produces an alert that somebody decides to ignore, and the decision is invisible. A test with a tolerance signed by the business owner produces a breach, which has a process attached. The ECB guide asks for data quality indicators covering accuracy and integrity, completeness and timeliness, with tolerance levels and correction processes, communicated periodically to the management body alongside an analysis of what the current quality means for risk measurement.
The second is reconciliation. BCBS 239 paragraph 36 tells banks to reconcile risk data with their own sources, including accounting data where appropriate, and defines reconciliation as comparing items or outcomes and explaining the differences. Explaining is the operative word. A reconciliation that reports a variance without an explanation has moved the problem, not solved it.
Standard formats and naming deserve their own line because they are cheap and they prevent a whole class of failure. BCBS 239 paragraph 33 asks for integrated data taxonomies across the banking group, with single identifiers or unified naming conventions for legal entities, counterparties, customers and accounts. Two systems that name the same counterparty differently will pass every quality test individually and still produce a wrong concentration figure when aggregated. The broader discipline is covered in our guide to data quality management best practices, and the foundations in data quality management.
Stewardship is the human part. A steward is the person who is asked when a figure looks wrong, who arbitrates when two teams disagree about a definition, and who chases the remediation nobody wants. The role only works when it is named against specific elements rather than against a domain in the abstract, and when the person holding it can see where the data came from without asking an engineer. That is the practical argument for data lineage being available to stewards rather than only to the platform team.
A governance framework for critical data elements is the set of arrangements that make the first three practices survive a change of personnel. It answers who decides, who checks the deciders, how often, and what evidence exists afterwards. The ECB guide sets out what it expects to see, and the shape is consistent enough to copy.
Start with approval, because that is the part most programs get wrong. The guide says the management body must approve and implement the data governance framework, including the detailed data quality requirements and the indicators used to monitor them, and that it should select one or two of its own members in the management function to carry responsibility for implementation without discharging the body from overall accountability. Where the management function is one or two people, one or two senior managers with a direct reporting line to the body take that role instead. A CDE list approved only by a data governance working group has not met that arrangement.
Then the three lines. The first line is the business and technical owners who run the data. The second is a validation function, independent of the teams doing the governance work, that regularly assesses whether the aggregation and reporting processes function as intended, covering infrastructure, lineage and taxonomy, including outsourced functions, IT change initiatives, mergers and new product launches. BCBS 239 paragraph 29 makes the same point from the other side: the processes should be fully documented and subject to independent validation conducted by staff with specific technology, data and reporting expertise. The third line is internal audit, periodically reviewing the validation function itself.
A committee sits underneath all of that and does the routine work: reviewing proposed additions and removals, arbitrating definition disputes between business lines, and looking at the quality indicators before they go to the management body. Representation from every business line that owns a listed element is the only membership rule that matters, because a committee missing a business line will approve definitions that line has to live with.
Training belongs in the framework rather than beside it. The ECB guide asks that members of the management body and the heads of risk management, compliance and internal audit have sufficient understanding of data management and technology to assess the effect on the business, and that they undertake regular training to keep it. The same holds further down: a business owner who cannot read a lineage diagram cannot meaningfully approve a change to a transformation. Our wider write up of data governance concepts covers the operating model this sits inside.
The last piece is documentation that outlives the people. That means a written policy naming the roles above, a register of listed elements with definitions and owners, a data dictionary holding the agreed business definitions, and retained evidence of test results and remediation. BCBS 239 paragraph 37 treats the dictionary as a precondition rather than an output, which is the right order: agreeing what a term means is what makes the rest of the work possible.
This is the maintenance loop for practice 2 rather than a fifth practice, and it is where most CDE programs quietly fail. The list is agreed, approved and correct on the day it is signed. Six months later a team has migrated a source, a product launch has added twenty columns to the customer table, and an acquisition has brought a second general ledger. The list still reads the same. It is no longer true.
The ECB guide names the change events to watch for, in the description of what the central data governance function has to take part in: mergers or acquisitions of material legal entities, the outsourcing of functions to third parties, the launch of new products, the launch of new tools, upgrades of existing tools and other technology change initiatives. BCBS 239 paragraph 29 says the same thing about new initiatives, and adds that when a bank considers a material acquisition the due diligence should assess the target aggregation and reporting practices, with the impact considered by the board before the decision to proceed.
Turning that into something a data team can operate takes four mechanisms, and only the last of them is a meeting.
The first two of those are the ones worth automating, because they are the ones that happen between reviews. The short walkthrough below shows the mechanism in Decube: a classification policy carries a name, a label, a color, a named owner and a stated purpose, its rules auto tag new columns as they arrive when they match the pattern, the managed asset view lists everything classified under the policy and exports to CSV for audits, and every change to a policy passes through an approval workflow.
Four failures account for most of the programs that stall, and none of them is a tooling problem.
There is also an honest limit worth stating. A CDE program tells you which fields matter and puts controls around them. It does not tell you that a number is right. A perfectly governed exposure field, owned, defined, reconciled and tested, will still report the wrong figure if the calculation applied to it is wrong. Element level governance and model validation are different disciplines, and BCBS 239 treats them separately for that reason: paragraph 17 extends the principles to the key risk models as well as to the data that feeds them.
Decube is a data governance platform built around the four jobs above. Automated crawling keeps metadata current across connected sources, so the register describes what exists today rather than what existed at the last manual refresh. Classification policies carry the labels, owners and approval workflow that turn a list into something enforceable. Machine learning driven tests propose quality checks and thresholds as soon as a source is connected, which shortens the gap between listing an element and actually monitoring it. Monitors then watch for anomalies and raise alerts against the owner rather than a shared inbox.
Lineage is the part that matters most for a CDE program, because both of the hard questions depend on it: which fields does this reported figure come from, and which reported figures does this proposed schema change touch. Decube builds column level lineage across the connected stack so both are a lookup rather than an investigation. Access control and approval on changes keep the register itself governed, which is the part supervisors ask about.
Two published results give a sense of what that changes in a regulated setting. At an Australian financial institution, reconciliation checks became a standing part of the pipeline rather than a manual spot check, mean time to resolution fell 72 percent over nine months, and roughly USD 15,000 a week of manual discovery, glossary upkeep and incident handling was saved. At a Nasdaq listed regional bank reporting under FDIC, Federal Reserve and SOX requirements, automated column level lineage across Spark, Synapse, ADLS, Azure Data Factory and Power BI freed 110 hours a week that had gone into tracing lineage by hand, and gave the governance framework a single metadata layer to build on.
On the assurance side, the Decube security page records SOC 2 and ISO 27001, HIPAA and GDPR compliance, encryption in motion with TLS and at rest with AES-256, and a metadata only architecture in which Decube receives metadata and aggregate statistics rather than the underlying records. For a bank deciding what a governance tool is allowed to see, that last point is usually the first question. If you want to see how the register, the classification policies and the lineage work against your own sources, request a demo.
If you are starting from nothing, do not start with a definition workshop. Take one report, ideally one you already submit externally, and trace every figure on it back to the fields that produce it. That single exercise gives you a first list, exposes the places where lineage does not exist, and produces a specific argument about ownership rather than an abstract one. Most teams find between five and thirty elements behind a single indicator, which is a workable number to take to an owner.
Then apply the two question test to everything on that list, write a definition for each survivor, name an owner, agree tolerances, and take the result through the governance forum to the body that approves the framework. Add the classification rules and the change approval before you extend to the second report, because the mechanism that keeps a small list true is the same one that will keep a large list true, and it is far cheaper to build while the list is small.
The organizations that get value from this are the ones that treat the list as a control with consequences rather than as documentation. A critical data element that has an owner, one definition, an authoritative source, tested tolerances, traced lineage and approval on change is genuinely governed. One that appears on a register and nothing else is a note about an intention.
A critical data element is a single field whose value directly drives a number an organization has to report, and which would cause measurable harm if it were wrong, missing or late. The European Central Bank Guide on effective risk data aggregation and risk reporting, May 2024, defines them in footnote 19 by the job they do: they are the elements used to calculate the key risk indicators, and a wrong value in one of them moves either the indicator itself or the calculation and reporting routine behind it. Common examples in financial services are customer identifiers, account balances, transaction amounts, exposure values, product codes and effective dates.
Critical data elements are the fields that drive the figures a fund or bank reports to its board, its members and its regulator. Manage them in four steps. First, define what makes an element critical using a written test: it feeds a figure that leaves the building, and a plausible error in it would move that figure enough to change a decision. Second, identify the elements by tracing each reported figure back through lineage to the fields that produce it, then classify each one by indicator, entity, tier and privacy obligation. Third, put real controls on them: a named owner, one agreed definition, an authoritative source, quality tests with agreed tolerances, and periodic reconciliation. Fourth, govern the arrangement itself, with approval by the management body, an independent validation function in the second line and internal audit in the third.
The difference is the controls attached to it, not the data type. A critical data element has a named business owner and a named technical owner, one agreed definition used in every system, a designated authoritative source, quality tests on accuracy, completeness and timeliness with tolerance levels agreed in advance, lineage documented at attribute level from capture to report, approval required before a change to its definition or transformation ships, periodic reconciliation against the accounting source, and retained evidence that an auditor can test. An ordinary column has none of those by default.
The ECB Guide on effective risk data aggregation and risk reporting, May 2024, expects the management body to approve and implement the data governance framework that the list sits inside, and to select one or two of its own members in the management function to carry responsibility for implementing it. Naming those members does not discharge the management body from its overall accountability. Where the management function is only one or two people, one or two senior managers with a direct reporting line to the body take that role. Individual elements are owned and their definitions approved by named business and technical data owners, and a central data governance function issues the policy the whole arrangement runs on.
There is no published number, and any figure quoted as a benchmark is invented. The right answer is set by scope rather than by size: the list should be a function of how many reports, models and key risk indicators are in scope, not of how many tables the organization stores. In practice a single indicator usually resolves to between five and thirty elements. A useful warning sign is growth for the wrong reason: if the list grew because a team migrated a source system rather than because the organization started reporting something new, the criteria are too loose and the list has become a column inventory.
No. BCBS 239, the Basel Committee paper Principles for effective risk data aggregation and risk reporting published in January 2013, never uses the phrase critical data element. What it does is set the scope the term grew out of. Paragraph 16 says the principles apply to a bank risk management data, including data that is critical to enabling the bank to manage the risks it faces. Paragraph 30 makes identifying that data a named duty of senior management. Paragraph 56 supplies the materiality standard, telling banks to consider accuracy requirements analogous to accounting materiality. The explicit definition of the term came later, in footnote 19 of the ECB guide of May 2024.
Footnote 24 of the ECB Guide on effective risk data aggregation and risk reporting separates them. A data element contains information as an independent field and affects the value of an indicator. A data attribute is a description of a data element, such as its business definition, type or format, and is typically stored as a column used in the technical mapping. Confusing the two is a common reason a CDE list becomes unmanageably long: the team has inventoried attributes and labeled them elements.
With four mechanisms, only one of which is a meeting. Detection at arrival, using classification rules that evaluate every new column as it appears and tag the ones matching a pattern already on the list. Approval on change, so a change to the definition, source or transformation behind a listed element goes to its owner before it ships. Impact analysis from attribute level lineage, so a proposed schema change can be checked against the reported figures it touches. And a periodic review that asks what should come off the list as well as what should go on it. The ECB guide names the change events to watch for: mergers and acquisitions of material legal entities, outsourcing to third parties, new product launches, new tools, tool upgrades and other technology change initiatives.
Eight, and they can be checked one by one. A named business owner and a named technical owner. One agreed definition held in the data dictionary and used in every system. A designated authoritative source, with all other copies marked as copies. Quality tests covering accuracy and integrity, completeness and timeliness, with tolerance levels agreed in advance and a documented correction process. Lineage documented at attribute level from capture through transformation to the report. Approval required before any change to the definition, source or transformation ships. Periodic reconciliation against the accounting or finance source, with differences explained rather than just reported. And retained evidence of tests, breaches and remediation so an independent validation function and internal audit can test the process.
No, although they overlap. Sensitive data is defined by the harm caused if the wrong person sees it, and is protected with masking, retention limits and access control. A critical data element is defined by the harm caused if the value is wrong, and is protected with validation, reconciliation and lineage. A customer date of birth can be both. A market closing price on an internal reference table is usually critical and rarely sensitive. Treating one program as a substitute for the other leaves an organization with well protected numbers it cannot prove are correct.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Bring lineage, quality, governance, and AI together in one platform—so your teams and AI agents can act with confidence.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)