A large bank holds millions of data fields. Treating every one with the same rigor is impossible. That is why banks identify critical data elements (CDEs): the small set of data whose accuracy matters most.
A critical data element is a data element that materially affects regulatory reporting, risk management or key business decisions, so its definition, quality and lineage need to be controlled and demonstrable.
Why CDEs matter
Errors in ordinary fields are an annoyance. Errors in critical ones become restated filings, wrong risk numbers or customer harm. Focusing governance effort on CDEs gives a bank the most protection for the effort spent, and gives examiners a clear, defensible scope.
A defined CDE list also settles arguments. When two teams disagree about whether a field deserves a control, the criteria decide, not whoever argues loudest.
How banks identify critical data elements
There is no single regulatory definition, so each bank sets its own criteria. Common starting points include:
- Regulatory reporting use. The element appears in a filing or report where errors have supervisory consequences.
- Risk measurement. It is an input to capital, liquidity, credit or market risk calculations.
- Decision impact. Management, board or customer-facing decisions rely on it.
- Breadth of use. It flows through many systems and reports, so one defect spreads widely.
- Impact if wrong. A defect would cause financial loss, a regulatory finding or reputational damage.
A practical approach is to work backwards. List the reports, calculations and decisions that matter most, then trace which data elements each depends on. Score those elements against your criteria and review the list with business owners.
A simple scoring approach
Rate each candidate element from 1 to 3 on each criterion, add the scores and set a threshold above which an element is treated as critical. The exact numbers matter less than applying the same method to every candidate and writing down the reasoning. Borderline elements can be reviewed by a small group that includes the business owner and a risk or compliance representative.
Examples of critical data elements
The right list depends on your business, but typical examples include:
- Customer identifiers used in know-your-customer and sanctions checks.
- Exposure and collateral values used in credit risk reporting.
- Balance and transaction amounts feeding financial and regulatory reports.
- Counterparty and legal entity identifiers used to aggregate risk.
- Product and account classification codes that drive regulatory treatment.
Treat these as illustrations of the kind of element that qualifies, not as a prescribed list.
From identified to certified
Identification is only the first step. Each CDE then needs:
- A business definition everyone agrees on.
- An owner accountable for quality and change control.
- Controls that check quality and completeness, mapped to policies.
- Evidence that the controls operate.
- An approval recording that requirements are met.
That is the certification workflow described in our guide to what data certification is. CoComply supports it end to end with critical data element certification, from identification through approval.
Document the lineage
A CDE is only as trustworthy as the path it takes to the report. Record where each element originates, how it is transformed and which reports consume it. This is what lets you answer the question "what breaks if this changes?" and what examiners mean when they ask for traceability. See our data lineage solution for how that looks in practice.
Keep the list current
A CDE list that is built once and never revisited goes stale. New products, systems and regulations create new critical elements, and mergers or reorganizations can change who owns them. Review the list on a schedule and whenever a major change occurs, and re-certify affected elements.
Link CDEs to your frameworks
Standards such as BCBS 239 depend on being able to show that risk data is accurate, complete and traceable. Mapping CDEs to those principles shows examiners exactly where your evidence sits. See our BCBS 239 data certification checklist for how that mapping works.
Common pitfalls
- Too many CDEs. If everything is critical, nothing is. Aim for a list a team can realistically govern.
- No owner. An element without a named owner cannot be certified.
- Definitions that differ by team. Two departments using the same term for different things is a classic source of reporting errors.
- One-time exercises. A list produced for an audit and then forgotten will not survive the next one.
Where to start
Begin with the ten to twenty elements behind your most important regulatory report. Define, assign, control and certify them. The pattern you build there can then be repeated across the rest of the bank. To go further, see our critical data inventory for a single place to track certified assets, or contact us to discuss your program.