The CDE Program in Practice: A Reference Implementation From Day One to Year Two

CDE Practitioner’s Guide: Overview | Part 0 | Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6

The Practitioner’s Field Manual

What follows is a reference implementation: populated artifacts, worked examples, and an 18-month timeline showing what the program produces at every milestone. The examples are composites drawn from programs I have built or reviewed, not hypothetical constructs. We start with a CCAR submission, then extend to insurance (Solvency II) and healthcare (USCDI).

The Worked Example: A CCAR Submission

The Federal Reserve’s FR Y-14 report family defines hundreds of specific data fields for stress testing. For this walkthrough, we start from one schedule: FR Y-14Q Schedule H.1, Domestic First Lien Residential Mortgages. This schedule requires banks to report loan-level data on their residential mortgage portfolio each quarter, and the Fed uses it to model credit losses under stress scenarios.

We will trace a single data element through the full CDE lifecycle: from regulatory template to source system, through scoring and registration, into quality rules and monitoring, and finally into the KRI framework that the risk committee sees.

Step 1: Identify the Report Fields

Schedule H.1 prescribes specific fields for each loan in the portfolio. Five of those fields carry the highest downstream impact:

• Current Loan Balance: outstanding principal amount
• Current Interest Rate: the rate at which the loan accrues
• Loan-to-Value Ratio (LTV): current balance divided by property value
• Borrower Credit Score: most recent FICO or equivalent score on file
• Delinquency Status: number of days past due (current, 30, 60, 90, 120+)

Each field appears in the FR Y-14Q template as a defined column with specified data types, allowed values, and reporting conventions. The Federal Reserve does not use the term “Critical Data Element,” but every field in this template functions as one. If the data is missing or inaccurate, the Fed applies conservative assumptions that increase the bank’s projected losses and, consequently, its capital requirements.

Step 2: Trace Lineage Backward

Pick one element: Borrower Credit Score. Trace it backward from the CCAR report to its origin.

The lineage path for Borrower Credit Score in a typical large bank looks like this:

Layer 4: CCAR Report (FR Y-14Q Schedule H.1) The borrower_credit_score field appears in the quarterly submission. It represents the most recent score on file at the reporting date.

Layer 3: Enterprise Data Warehouse The value is sourced from edw.mortgage_portfolio.fico_score, which is refreshed nightly from the staging layer. A business rule selects the most recent score when multiple scores exist for the same borrower (the MAX(score_date) rule).

Layer 2: Staging Layer Two feeds converge here. stg.credit_bureau_scores receives daily batch files from the credit bureau vendor. stg.origination_scores contains the FICO score captured at loan origination from the Loan Origination System. The staging layer maintains both; the warehouse transformation selects the more recent of the two.

Layer 1: Source Systems Three systems provide the raw data:

• Credit Bureau Feed (Experian, Equifax, or TransUnion): daily batch delivery of refreshed scores for the bank’s borrower population
• Loan Origination System (LOS): the score captured during the underwriting process, stored as a point-in-time snapshot
• Loan Servicing System: periodic score refreshes pulled during servicing reviews

Each layer introduces a potential failure point:

• Credit bureau feed delivers late or nulls for a subset of borrowers
• Staging layer fails to load
• Warehouse transformation selects a stale score when a more recent one exists
• Report generation truncates or mismaps the field

Column-level lineage makes each of these failure points visible and monitorable.

Step 3: Score the Element

Using the criticality formula from Part 2 (C = N x I):

Borrower Credit Score feeds:

1. CCAR stress testing (FR Y-14Q Schedule H.1)
2. Fair lending analysis (HMDA overlay reporting)
3. Credit risk pricing model (interest rate assignment)
4. Risk segmentation model (portfolio risk stratification)

N = 4 (four Tier 1 uses)

Impact rating (I) = 8 (regulatory finding risk, enforcement action risk if materially inaccurate; the Freedom Mortgage case carried a $3.95 million penalty for HMDA data errors, compounded by a prior enforcement order violation)

C = N x I = 4 x 8 = 32

With a qualification threshold of C >= 5, Borrower Credit Score qualifies as a CDE with a score of 32. It is not borderline. It is firmly in the top tier.

Step 4: Register Entry

Here is the fully populated CDE register row for Borrower Credit Score, using the 15-field register structure from Part 2:

Field	Value
CDE Name	Borrower Credit Score
Business Definition	The most recent credit bureau score (FICO or equivalent) on file for a borrower at the reporting date, used to assess creditworthiness across lending, risk, and compliance functions
Data Type	Integer
Allowed Values / Format	300 to 850; null not permitted for active loans
Data Owner	Chief Credit Officer
Data Steward	Senior Analyst, Credit Risk Data Management
Source of Record	Credit Bureau Feed (daily batch from Experian)
Quality Rules	Not null; range 300-850; matches credit bureau source within 30 days; consistent value across CCAR and fair lending report extracts
Quality Threshold	99.9% accuracy (Tier 1)
Sensitivity Classification	PII, Confidential
Downstream Uses	CCAR (FR Y-14Q H.1), Fair Lending Analysis, Credit Risk Pricing Model, Risk Segmentation Model
Regulatory Relevance	CCAR/DFAST, ECOA/Fair Lending, SR 11-7 (model inputs), BCBS 239
Lineage Documentation	Credit Bureau Feed > stg.credit_bureau_scores > edw.mortgage_portfolio.fico_score > CCAR Report Extract
Domain Assignment	Credit Risk
Criticality Score	C = 32 (N=4, I=8)

That is what a completed register entry looks like. Every field serves a purpose: the business definition anchors cross-domain alignment, the quality rules are executable, the downstream uses justify the tier assignment, and the lineage path enables impact analysis when anything changes.

Step 5: Assign SLA

Based on the tier structure from Part 3, Borrower Credit Score is classified as Tier 1 (Regulatory) because it directly feeds CCAR submissions and fair lending analysis.

SLA Component	Tier 1 Requirement
Monitoring Cadence	Hourly
Quality Threshold	99.9% accuracy
Remediation SLA	4 hours from detection
Escalation Path	Steward (0-2 hrs) > Domain Owner (2-4 hrs) > Governance Council (same day) > CRO (next business day)

Step 6: Define Quality Rules

The quality rules for Borrower Credit Score span multiple dimensions, as covered in Part 3:

Rule	Dimension	Implementation
borrower_credit_score IS NOT NULL for all active loans	Completeness	Soda check, hourly
borrower_credit_score BETWEEN 300 AND 850	Validity	Soda check, hourly
Score date within 30 days of reporting date	Freshness	Custom SQL, daily
edw.fico_score = stg.credit_bureau_scores.score (reconciliation)	Consistency	dbt test, nightly
Same borrower shows same score in CCAR extract and fair lending extract	Cross-report consistency	Custom reconciliation, pre-submission
No duplicate borrower-score-date combinations	Uniqueness	dbt uniqueness test, nightly

How to build the check. Six rules across four quality dimensions. Not one null check. That distinction separates CDE governance from general Data Quality monitoring.

Step 7: Connect to KRI

The quality scores from Step 6 feed into the risk framework covered in Part 5. Borrower Credit Score contributes to the CCAR Data Reliability KRI, which connects directly to the institution’s risk appetite statement.

The chain:

1. Quality rule fires (hourly Soda check detects 0.2% of Borrower Credit Scores outside 300-850 range)
2. KPI captures it (DQ score for Borrower Credit Score drops to 99.8%, still above 99.9% threshold? No. Breach detected.)
3. KRI reflects it (CCAR Data Reliability KRI moves from Green to Amber because a Tier 1 CDE feeding FR Y-14Q is below threshold)
4. Risk appetite triggered (risk appetite statement requires all Tier 1 CDE scores above 99.9%; breach activates escalation protocol)
5. Governance council notified (if not remediated within 4 hours, exception escalates to CRO per breach protocol)

What this looks like in practice. That is the full loop. One Data Quality failure in one source system propagates through monitoring, measurement, risk classification, and escalation in a traceable, auditable path. When the OCC examiner asks “what happens when Data Quality degrades in your CCAR submission pipeline?”, this is the answer.

Sample CDE Register (Populated)

The single-element walkthrough above shows depth. The register below shows breadth. Here are 12 example CDEs across three regulated sectors, showing the five fields most useful for cross-referencing. Business definitions and quality thresholds live in each element’s detailed register entry (see the Borrower Credit Score example in Step 4 above for the full 15-field format).

Banking CDEs

CDE Name	Source of Record	Owner/Steward	Tier	Key Uses
Borrower Credit Score	Credit Bureau Feed (Experian)	Chief Credit Officer	1	CCAR, Fair Lending, Pricing Model, Risk Segmentation
Loan Balance Outstanding	Loan Servicing System	Head of Mortgage Operations	1	CCAR (FR Y-14Q H.1), Call Report, ALLL Calculation, SOX Financial Close
Current Interest Rate	Loan Origination System	Head of Mortgage Operations	1	CCAR, Net Interest Income Model, Pricing Validation
Delinquency Status	Loan Servicing System	Chief Credit Officer	1	CCAR, ALLL, Early Warning Dashboard, Collections Prioritization
Customer ID	Core Banking System	Chief Data Officer	1	AML/BSA Surveillance, KYC, CCAR, Fair Lending, SOX

Insurance CDEs

CDE Name	Source of Record	Owner/Steward	Tier	Key Uses
Policy Effective Date	Policy Administration System	VP of Underwriting	1	Solvency II QRTs, Premium Earned Calculation, IFRS 17 CSM
Loss Development Factor	Actuarial Reserving System	Chief Actuary	1	Statutory Filing, Solvency II (S.12.01), ORSA, Reserve Adequacy
Gross Premium Written	Policy Administration System	Chief Financial Officer	1	Solvency II (S.05.01), Statutory Annual Statement, ORSA
Claims Reserve	Claims Management System	Chief Actuary	1	Solvency II (S.19.01), Statutory Filing, Financial Close

Healthcare CDEs

CDE Name	Source of Record	Owner/Steward	Tier	Key Uses
Patient ID	EHR (Epic/Cerner)	Chief Medical Information Officer	1	USCDI Exchange, CMS Reporting, Clinical Decision Support, HIPAA Designated Record Set
Diagnosis Code (ICD-10)	EHR (Epic/Cerner)	Chief Medical Officer	1	CMS Quality Reporting, HEDIS Measures, Claims Submission, T-MSIS
Medication Dosage	EHR / CPOE System	Chief Pharmacy Officer	1	USCDI Medication Data Class, Clinical Decision Support, Adverse Event Monitoring
Lab Result Value	Laboratory Information System (LIS)	Lab Director	2	USCDI Laboratory Data Class, Clinical Decision Support, Quality Measures

This register is not exhaustive. A mature banking program would have 200 or more entries. The point is structural: every row follows the same schema, every CDE has a named owner, every quality threshold ties to a tier, and every key use traces to a regulatory or business-critical output.

Sample DQ Scorecard: What the Governance Council Sees

The governance council does not need to see 200 individual CDE quality scores. It needs a domain-level view that surfaces the exceptions requiring attention. Here is what a monthly DQ scorecard looks like.

Domain-Level Quality Rollup

Data Domain	CDE Count	Avg. DQ Score	Trend (90 days)	SLA Compliance	CDEs Below Threshold
Customer	38	99.7%	Improving	97.4%	1
Loan / Mortgage	52	99.4%	Stable	98.1%	2
Trading / Markets	34	99.1%	Declining	94.1%	4
Finance / GL	28	99.8%	Improving	100%	0
Compliance / AML	22	98.9%	Declining	91.3%	3
Enterprise Total	174	99.3%	Stable	96.2%	10

DQ Score is a count-weighted average across all CDEs in the domain. SLA Compliance is the percentage of CDEs meeting their tier-specific threshold for the full reporting period.

Top 5 Exceptions Requiring Attention

CDE	Domain	Current Score	Threshold	Days Open	Root Cause	Status
Trade Venue Identifier	Trading	97.8%	99.5%	12	3 new venues not mapped in reference data	Remediation in progress
Transaction Amount (FX)	Trading	98.1%	99.5%	8	Currency conversion logic error for new pairs	Fix deployed, validation pending
SAR Filing Indicator	Compliance	97.2%	99.9%	22	Source system migration left 800 records unmapped	Escalated to governance council
Counterparty LEI	Trading	98.6%	99.5%	5	GLEIF feed delay, bulk update scheduled	On track
Sanctions Screening Flag	Compliance	98.4%	99.9%	15	New screening vendor integration incomplete	Escalated to domain owner

Coverage Metrics

Metric	Current	Target	Gap
% CDEs with active monitoring	89%	100%	19 CDEs unmonitored
% CDEs with assigned steward	96%	100%	7 CDEs without named steward
% CDEs with column-level lineage	72%	95%	49 CDEs without lineage

This scorecard fits on a single page. The governance council can see which domains are healthy, which are deteriorating, which exceptions need escalation, and where coverage gaps remain. It drives decisions, not discussions.

Sample KRI Report: What the Risk Committee Sees

The same underlying data, translated into risk language per the framework in Part 5.

KRI	Metric	Threshold	Current Value	Trend	Status	Action Required
CCAR Data Reliability	% of FR Y-14 CDEs meeting quality threshold	>= 99.5% (aggregate)	99.4%	Declining	Amber	One Tier 1 CDE (LTV Ratio) at 99.3%, below threshold. Remediation on track for Q2.
Fair Lending Data Integrity	% of HMDA/Fair Lending CDEs meeting quality threshold	>= 99.5%	98.8%	Declining	Amber	2 CDEs below threshold (Borrower Race/Ethnicity, Applicant Income). Remediation plan due to governance council by month-end.
SOX Financial Close Data Accuracy	% of SOX-relevant CDEs meeting quality threshold	>= 99.9%	99.9%	Stable	Green	None. All 28 Finance domain CDEs within SLA.
AML/BSA Surveillance Coverage	% of AML surveillance CDEs with complete data feeds	100%	87%	Declining	Red	3 data feeds from acquired entity not connected to surveillance platform. Per the JPMorgan lesson: unsurveilled trading data is an enforcement action waiting to happen. Remediation escalated to CRO.

Four KRIs. Each connects a Data Quality measurement to a regulatory consequence. The risk committee does not need to know that 22 CDEs are below their individual thresholds. It needs to know that AML surveillance has a coverage gap that resembles the same gap JPMorgan Chase left open from 2014 to 2023 before receiving a $348 million penalty.

For practitioners: Notice the progression: the DQ scorecard tells the governance council what is failing. The KRI report tells the risk committee what it means.

The Insurance Parallel: A Solvency II QRT Walkthrough

The banking example above traced Borrower Credit Score from FR Y-14Q through four layers to source systems. The same methodology applies to insurance, with a different regulatory anchor.

Starting Point: S.12.01 Life Technical Provisions

EIOPA’s Solvency II Quantitative Reporting Templates define the reporting obligations for European insurers. Template S.12.01 covers Life Technical Provisions: the reserves an insurer holds against future policy obligations. Populating S.12.01 requires actuarial data elements including policy inception and term data, mortality and morbidity assumptions, discount rates, and loss development factors.

Tracing One Element: Loss Development Factor

The Loss Development Factor (LDF) is an actuarial multiplier applied to incurred losses at a given maturity to estimate ultimate losses. It is foundational to reserve adequacy and directly populates Solvency II technical provisions.

Lineage path:

• QRT Layer: S.12.01 Cell R0010/C0020 (Best Estimate of Technical Provisions, Life excluding health)
• Actuarial Model: The LDF is an output of the chain-ladder reserving model, consuming historical claims triangles
• Data Warehouse: edw.claims_triangle aggregates incurred losses by accident year and development period
• Staging: stg.claims_payments and stg.claims_reserves feed the triangle from two sources
• Source Systems: Claims Management System (paid amounts) and Actuarial Reserving System (case reserves)

Register Entry for Loss Development Factor

Field	Value
CDE Name	Loss Development Factor
Business Definition	Actuarial multiplier estimating the ratio of ultimate losses to currently reported losses for a given accident year and line of business
Data Type	Decimal (4 decimal places)
Allowed Values / Format	>= 1.0000 (ultimate losses are at least equal to reported losses); typical range 1.01 to 3.50 depending on line and maturity
Data Owner	Chief Actuary
Data Steward	Senior Actuarial Analyst, Reserving
Source of Record	Actuarial Reserving System (chain-ladder model output)
Quality Rules	Not null for all active accident years; within historical range +/- 2 standard deviations; reconciles to prior quarter within 5% (unless justified by actuarial judgment); consistent across Solvency II and statutory filings
Quality Threshold	99.9% (Tier 1)
Sensitivity Classification	Confidential
Downstream Uses	Solvency II QRT (S.12.01), Statutory Annual Statement, ORSA, Board Reserve Adequacy Report
Regulatory Relevance	Solvency II, NAIC Model Audit Rule, IFRS 17, ORSA
Lineage Documentation	Claims Mgmt System + Actuarial Reserving System > stg.claims > edw.claims_triangle > Actuarial Model > S.12.01
Domain Assignment	Actuarial / Reserving
Criticality Score	C = 36 (N=4, I=9)

Quality Rules Specific to Actuarial Data

Actuarial CDEs require rules that general Data Quality frameworks often miss:

• Reasonableness checks: an LDF that jumps from 1.15 to 2.80 in a single quarter without a documented actuarial basis is a Data Quality issue, not just an anomaly
• Cross-filing consistency: the LDF applied in the Solvency II submission must reconcile with the LDF in the statutory filing and the ORSA, unless differences are documented with actuarial justification
• Vintage stability: LDFs for mature accident years (10+ development periods) should be close to 1.00; significant deviation suggests data contamination in the claims triangle

Insurance Thought Leadership emphasizes this point: “…a loss development factor in a statutory filing is far more ‘critical’ than a seldom-used rating variable, even if both sit in the same table.” The tier assignment and quality rules must reflect that distinction.

The Healthcare Parallel: USCDI as a Starter CDE Framework

Healthcare has an advantage that neither banking nor insurance enjoys: a federal agency has already built a starter CDE inventory. The ONC’s United States Core Data for Interoperability (USCDI) defines the standardized data elements required for nationwide health information exchange, mandated by the 21st Century Cures Act.

USCDI v6 as Your CDE Starter List

ONC published USCDI v5 in July 2024. USCDI v6 followed in July 2025 and is the current version, with v7 in draft. USCDI v6 organizes data elements into classes: Patient Demographics, Medications, Allergies, Problems (Diagnoses), Laboratory, Procedures, Vital Signs, Social Determinants of Health, and more. Each data class contains specific data elements with defined standards (coding systems, value sets, transport protocols).

For a healthcare organization building a CDE program, the mapping is direct:

USCDI Data Class	CDE Candidates	Regulatory Driver
Problems	Diagnosis Code (ICD-10-CM), Date of Diagnosis	CMS Quality Reporting, HEDIS, Claims
Medications	Medication Name (RxNorm), Dosage, Frequency	Clinical Decision Support, Adverse Event Monitoring
Laboratory	Lab Test Name (LOINC), Lab Result Value, Units	Quality Measures, Clinical Pathways
Patient Demographics	Patient ID (MRN), Date of Birth, Race, Ethnicity	HIPAA, CMS Reporting, Health Equity Measures

USCDI does not assign quality thresholds, ownership, or monitoring cadence. Those are your CDE program’s job. But the identification step, the step that consumes the most time in banking and insurance programs, is largely pre-built.

Register Entry for Diagnosis Code (ICD-10)

Field	Value
CDE Name	Diagnosis Code (ICD-10-CM)
Business Definition	The ICD-10-CM code assigned to a patient encounter representing the primary or secondary clinical diagnosis, sourced from the clinician’s assessment
Data Type	String (3-7 alphanumeric characters)
Allowed Values / Format	Valid ICD-10-CM code per the current CMS code set (updated annually in October); format: letter + 2 digits + optional decimal + up to 4 additional characters
Data Owner	Chief Medical Officer
Data Steward	Health Information Management Director
Source of Record	EHR (Epic/Cerner), assigned at point of care
Quality Rules	Not null for all billable encounters; valid ICD-10-CM code per current year code set; code specificity meets CMS requirements (no truncated codes where greater specificity exists); consistent between clinical documentation and claims submission
Quality Threshold	99.9% (Tier 1)
Sensitivity Classification	PHI
Downstream Uses	CMS Quality Reporting, HEDIS Measures, Claims Submission, T-MSIS, Clinical Decision Support, Population Health Analytics
Regulatory Relevance	HIPAA, CMS Conditions of Participation, 21st Century Cures Act (USCDI), state reporting mandates
Lineage Documentation	Clinician Entry (EHR) > CDI Review > Final Code Assignment > Claims Engine > Clearinghouse > CMS
Domain Assignment	Clinical / Health Information Management
Criticality Score	C = 42 (N=6, I=7)

Quality Rules Specific to Clinical Data

Clinical CDEs carry requirements that financial data elements do not:

• Code set currency: ICD-10-CM codes are updated annually. A code valid in fiscal year 2025 may be retired or replaced in fiscal year 2026. Quality rules must validate against the current year’s code set, not a static reference table.
• Specificity requirements: CMS requires the most specific code available. Submitting “J18.9” (Pneumonia, unspecified organism) when clinical documentation supports “J13” (Pneumonia due to Streptococcus pneumoniae) is a coding quality failure that triggers claim denials and audit risk.
• Clinical-administrative consistency: the diagnosis code in the clinical record must match the code on the claim. Discrepancies between the EHR and the claims engine introduce compliance risk and revenue integrity exposure.
• Timeliness: diagnosis codes must be assigned within the encounter or within a defined post-encounter window (typically 72 hours for inpatient, same-day for outpatient) to support real-time clinical decision support.

The CDE Program Team

Before the timeline, the team. The artifacts described in this article do not build themselves. Here is how the program team grows with the program, what each role does, and who is accountable for what.

Core Team Composition by Phase

The staffing table below applies to a mid-size organization (e.g., a regional bank, single-line insurer, or mid-size health system). For larger institutions, scale according to the sizing table that follows.

Phase	Core Team	FTE Estimate	Federated Support
Inception (Month 1-3)	Program lead (governance), lineage analyst, business analyst	2-3 FTE	None needed yet
Developing (Month 3-9)	Add DQ engineer, second lineage analyst	4-6 FTE	2-3 domain stewards (part-time, 20% allocation)
Mature (Month 9-18)	Add catalog administrator, reporting analyst	6-8 FTE	5-8 domain stewards (part-time, 20-30% allocation)
Optimized (18+ months)	Stabilize core; shift investment to automation	4-6 FTE (automation reduces manual effort)	10+ domain stewards embedded in business lines

Staffing by Organization Size

Phase	Mid-Size Org	Large Institution	G-SIB / Large Enterprise
Inception (0-3 months)	2-3 FTE	4-6 FTE	6-8 FTE
Developing (3-9 months)	4-6 FTE	8-12 FTE	12-16 FTE
Mature (9-18 months)	6-8 FTE	12-18 FTE	18-25 FTE
Optimized (18+ months)	4-6 FTE (automation reduces load)	8-12 FTE	12-18 FTE

These counts include the core program team (program lead, lineage analysts, DQ engineers, catalog admin, reporting). They do not include federated Domain Stewards, who operate at 20-30% allocation on top of their primary roles. At maturity, a large institution may have 10-15 federated Domain Stewards in addition to the core team.

Smaller programs (under 100 CDEs) can operate with 2-3 core FTEs throughout. Programs at G-SIBs with 1,000+ CDEs may need a dedicated Data Quality engineering team of 3-5 people in addition to the numbers above.

Key Roles Defined

• CDE Program Lead: Owns the program roadmap, chairs the governance council working sessions, reports to the CDO or CRO. This person bridges business and technology; they must be credible with both risk officers and data engineers.
• Lineage Analyst: Traces data flows from regulatory reports to source systems. Requires SQL fluency, familiarity with ETL tools, and the patience to reverse-engineer undocumented pipelines.
• Business Analyst: Facilitates stakeholder validation sessions, documents business definitions, manages the CDE register, and handles cross-domain reconciliation.
• DQ Engineer: Implements and maintains quality rules, configures monitoring tools (Soda, Great Expectations, dbt tests), and builds alerting and remediation workflows.
• Domain Data Steward (federated): The subject matter expert within each business domain. Part-time role (20-30% allocation) responsible for day-to-day quality oversight, issue investigation, and recertification of CDEs within their domain.
• Data Owner (not a program team role): The business executive accountable for CDE quality within their domain. Approves CDE designations, funds remediation, and escalates to the governance council.

RACI Matrix

R = Responsible (does the work), A = Accountable (final decision authority), C = Consulted (provides input), I = Informed (notified of outcome).

Activity	Program Lead	Lineage Analyst	Business Analyst	DQ Engineer	Principal Steward	Domain Steward	Data Owner	Governance Council
Identify Tier 1 uses	R	C	C	I	C	C	A	I
Trace lineage to source	C	R	I	C	I	C	I	I
Score CDE candidates (C = N x I)	R	C	R	I	C	C	I	I
Validate with business stakeholders	R	I	R	I	A	C	I	I
Build CDE register	C	C	R	I	A	C	I	I
Implement quality monitoring	C	I	I	R	I	C	I	I
Investigate and remediate DQ issues	I	C	I	C	C	R	I	I
Escalate unresolved exceptions	R	I	I	I	R	R	I	A
Recertify CDEs (quarterly/annual)	R	C	R	I	R	R	A	I
Report KPIs/KRIs to risk committee	R	I	C	I	C	I	I	A
Prepare examination package	R	R	R	C	C	C	A	I

The Principal Steward is the portfolio-level role introduced in Part 3’s three-tier accountability model. At the Director or Senior Manager level, they bridge the gap between executive Data Owners (who set policy) and Domain Stewards (who execute day-to-day). In the RACI, Principal Stewards are Accountable for stakeholder validation and register accuracy, and Responsible for exception escalation and recertification. They handle the activities that require both business authority and operational knowledge, escalating to Data Owners or the Governance Council only when decisions exceed their mandate.

Governance Council Composition

The governance council should be small (6-10 members), senior, and cross-functional. Typical composition: CDO or deputy (chair), CRO representative, CFO representative, compliance officer, 2-3 domain data owners from the highest-CDE-density domains, internal audit observer (non-voting). The council meets monthly during the Developing phase, quarterly once the program reaches Mature. Its purpose is to approve CDE designations, resolve cross-domain disputes, review the DQ scorecard, and escalate material exceptions to the risk committee.

Where Are You Now?

Quick self-assessment (each “No” maps to a specific part of this series):

• Do you have a CDE register with all 15 metadata fields populated? (Part 2)
• Are 80%+ of your CDEs under automated quality monitoring? (Part 3)
• Can you trace any Tier 1 CDE from regulatory report to source system? (Part 3)
• Does your risk committee receive CDE-related KRI reporting? (Part 5)
• Have you conducted a CDE recertification in the past 12 months? (Part 4)

18-Month Program Timeline

The timeline below is not a project plan. It is a narrative of what the program produces at each milestone, what artifacts exist, who is involved, and what the organization can demonstrate to a regulator or auditor at that point.

Phase	CDE Count	Key Deliverables	Milestone
Month 1	15 candidates	Tier 1 use list, first lineage trace	Sponsor sees first lineage diagram
Months 2-3	50-80	Scored register, catalog deployment	Register populated in catalog
Months 4-6	80-100	Automated monitoring, first DQ scorecard	First council scorecard review
Months 7-9	120-150	Column-level lineage, tiered SLAs	80%+ monitoring coverage
Months 10-12	150-180	Data contracts, KRI reports	First risk committee KRI report
Months 13-18	150-300+ (varies by org size; see Part 2)	Automated discovery, exam package	Exam-ready at all times

Month 1: Anchor to Tier 1 Uses

What happens. The governance lead and executive sponsor select the first three Tier 1 uses for CDE identification. In banking, this might be CCAR (FR Y-14Q Schedule H.1), SOX financial close (revenue recognition), and AML transaction monitoring. In insurance: Solvency II QRT S.05.01 (Premiums, Claims, Expenses), statutory annual statement, and ORSA. In healthcare: USCDI-mandated exchange, CMS quality reporting, and claims submission.

The team traces lineage for one of those three uses end to end: from the regulatory report or submission back through the data warehouse, staging layers, and source systems. This first trace produces the initial 15 CDE candidates.

What exists at Month 1. A documented Tier 1 use list. One complete lineage trace. A candidate list of 15 elements in a spreadsheet. An executive sponsor who has seen the first lineage diagram and understands where the gaps are.

Who is involved. Governance lead, 1-2 lineage analysts, executive sponsor, 2-3 business stakeholders from the first traced domain.

Months 2-3: Score, Register, Deploy Catalog

What happens. The team completes lineage tracing for the remaining two Tier 1 uses. All CDE candidates are scored using C = N x I. Business stakeholders validate scores, assign ownership, and resolve the first cross-domain definitional conflicts. The CDE register is built with all 15 metadata fields populated. The team migrates from the spreadsheet to a Data Catalog (Collibra, Alation, Purview, or equivalent).

What exists at Month 3. A CDE register with 50 to 80 elements, each scored, owned, and defined. A Data Catalog deployment with CDE metadata loaded. Initial quality rules documented (though not yet all automated). Lineage maps for three Tier 1 uses.

Who is involved. Governance lead, 2 lineage analysts, 1 business analyst, rotating business stakeholders from 2-3 domains, catalog platform team.

Months 4-6: Automate Monitoring, Build First Scorecard

What happens. Automated quality monitoring goes live for Tier 1 CDEs. The team implements Soda, Great Expectations, or equivalent tooling with hourly checks on Tier 1 elements and daily checks on Tier 2. The first DQ scorecard is built and presented to the governance council. Remediation workflows are formalized: detection routes to steward, SLA tracking in Jira or ServiceNow, escalation on breach.

What exists at Month 6. Automated monitoring for the top 30-40 CDEs. A monthly DQ scorecard showing domain-level rollups, exception lists, and coverage metrics. A functioning remediation workflow with SLA tracking. The first quarterly steward review completed. Governance council has reviewed the scorecard at least twice.

What the organization can demonstrate. If an examiner asks at this point: “Show me the data feeding your CCAR submission and how you monitor its quality,” you can answer with a CDE register, lineage maps, active monitoring dashboards, and remediation records. You cannot yet show KRI integration or risk appetite alignment, but the operational foundation is in place.

Months 7-9: Expand, Implement Column-Level Lineage, Establish Tiered SLAs

What happens. CDE identification expands to a second and third domain (e.g., from Credit Risk to Finance and Compliance). Column-level lineage tooling (Solidatus, Collibra Lineage, or Manta) is deployed for Tier 1 CDEs, satisfying the ECB’s RDARR requirement for lineage “at the data attribute level.” Tiered SLAs are formalized across all three tiers with differentiated monitoring cadences, thresholds, and remediation windows.

What exists at Month 9. 120 to 150 CDEs registered across 3-4 domains. Column-level lineage for all Tier 1 elements. Tiered SLA documentation signed off by domain owners. Quality monitoring expanded to cover 80%+ of registered CDEs. Second-domain stewards trained and active.

Months 10-12: Data Contracts, KRI Reports, Risk Committee Presentation

What happens. Data contracts are established for the highest-traffic CDE pipelines, formalizing schema expectations, quality thresholds, and change notification between producers and consumers. The KRI framework from Part 5 goes live: CDE quality scores roll up into 4-6 Key Risk Indicators tied to regulatory domains. The CDE program makes its first presentation to the risk committee, translating Data Quality metrics into risk language.

What exists at Month 12. Data contracts governing the top 10-15 CDE pipelines. A KRI report showing CCAR Data Reliability, Fair Lending Data Integrity, SOX Financial Close Accuracy, and AML Surveillance Coverage (or their sector equivalents). Governance council operating with a monthly scorecard cadence. Risk committee receiving quarterly KRI reports.

What the organization can demonstrate. The full loop: from Tier 1 use to CDE identification to quality monitoring to KRI reporting to risk appetite alignment. An examiner can trace any CDE from the register through its lineage, quality rules, monitoring history, and risk classification. The examination package exists as a living artifact.

Months 13-18: Scale, Automate Discovery, Prepare Examination Package

What happens. The program scales to 150-300+ CDEs across all major domains, depending on organization size and regulatory complexity (see the sizing guidance in Part 2). Automated CDE discovery supplements manual identification, using query log analysis, profiling, and dependency analysis to surface new candidates as new reports and models are deployed. The CDE register is connected to the enterprise risk appetite statement with measurable thresholds and breach protocols. The examination package is formalized: CDE inventory, 12+ months of quality history, control documentation, lineage maps, exception records, governance minutes, and risk committee materials.

What exists at Month 18. 150 to 300+ CDEs under active governance (mid-size organizations land near 150; large institutions and G-SIBs push well past 250). Automated discovery generating candidate lists quarterly. Risk appetite metrics for Data Quality integrated into enterprise risk reporting. A continuously maintained examination package. Incident trends showing quarter-over-quarter improvement. Stewardship activity metrics demonstrating active governance, not shelf-ware.

The EDMC DCAM framework benchmarks place a program at this stage between “Defined” and “Achieved” maturity. That is not the endpoint. It is the point where the program becomes self-sustaining: new CDEs are identified through automated discovery, quality is maintained through operational workflows, and risk integration ensures continued executive sponsorship.

Common Objections and Responses

Every CDE program faces resistance. The objections are predictable, and they have answers.

Objection	One-Line Response	Evidence
”We need to define all our terms first.”	Usage-first tells you which 250 terms to define first.	Defining 50,000 terms before identifying CDEs produces a glossary nobody uses to govern anything.
”Our data is too messy to start.”	The CDE program identifies which messy data matters and cleans it in priority order.	Waiting for clean data before starting governance is waiting for the outcome before building the mechanism.
”We do not have lineage tooling.”	Your first lineage trace can be manual: one engineer, one report, one week.	APRA asked banks to identify 100 CDEs. Tools accelerate scale; they do not enable the concept.
”Everything is critical to someone.”	Criticality is scored (C = N x I), not voted on.	An element feeding one Tier 3 report scores C = 3; one feeding four Tier 1 submissions scores C = 32. The formula replaces committee debate.
”We tried governance before and it failed.”	Was it anchored to Tier 1 uses with measurable quality, or a glossary project?	Gartner predicts 80% of governance initiatives will fail because they lack the crisis anchor Tier 1 uses provide.
”We cannot get executive sponsorship.”	Show the CRO the Citigroup and JPMorgan fines alongside your latest audit finding.	Citigroup: $400M + $135.6M (OCC $75M plus a Federal Reserve $60.6M penalty). JPMorgan: $348M (OCC $250M plus a Federal Reserve $98.2M penalty). The business case is not abstract.

Update, September 2026. The enforcement backdrop above has moved. The OCC closed its JPMorgan trade-surveillance order on March 30, 2026, made public April 17, 2026; the Federal Reserve’s companion $98.2 million order stays open (Banking Dive). CFPB staff fell from 1,750 toward a proposed 556, per an April 2026 court filing (PYMNTS). Bank of America disclosed in August 2026 it is still negotiating an OCC resolution over AML program deficiencies (AML Intelligence): enforcement risk persists.

Do Next

Priority	Action	Why It Matters
Start here	Select your first 3 Tier 1 uses and trace lineage for one of them end to end this week, using the CCAR/Solvency II/USCDI examples above as templates	The first lineage trace surfaces gaps, produces CDE candidates, and demonstrates the methodology in one deliverable.
Start here	Build your first 10 CDE register entries using the 15-field template from this article, fully populating every field including owner, steward, quality rules, and criticality score	A half-populated register is a suggestion; a fully populated one is an artifact auditors can examine.
Then	Deploy automated quality monitoring for your Tier 1 CDEs within 60 days, even if the initial implementation is a simple Soda or Great Expectations check on completeness and validity	Monitoring is what separates a governed CDE from a documented CDE.
Then	Build a one-page DQ scorecard for your governance council showing domain-level rollups, SLA compliance, top exceptions, and coverage metrics	The governance council needs a decision-making tool, not a data dump.
Next	Translate your top 3 DQ metrics into KRIs using the CCAR Data Reliability / Fair Lending Data Integrity / AML Surveillance Coverage pattern from this article	KRIs keep the risk committee engaged; raw DQ percentages mean nothing to the CRO.
Advanced	Prepare a draft examination package containing your CDE register, 6 months of quality history, lineage maps, and remediation records before your next regulatory exam cycle	Assembling documentation under time pressure produces incomplete packages; maintain it continuously.

Series Closing

This is the final article in the Critical Data Element Practitioner’s Guide. Six parts, one argument.

The purpose of a CDE program is not to document data. It is not to build a glossary, populate a catalog, achieve a maturity score, or produce a framework that sits in a shared drive. The purpose is to ensure that the data feeding your highest-stakes decisions is accurate, traceable, and controlled.

Start with uses. Identify the regulatory submissions, risk models, and financial reports that carry the severest consequences when data is wrong. Trace backward from those uses to the source data elements that feed them. Build the vocabulary around what you find, not the other way around. Operationalize with tiered controls that match monitoring intensity to business impact. Scale with automation, not with headcount. Measure in risk language that connects the CDO’s metrics to the CRO’s accountability.

And when the examiner asks “can you show me the data feeding this report, prove it is accurate, and trace it back to its source?”, answer with evidence. Not artifacts. Not frameworks. Not slide decks describing what you plan to do. Evidence: a populated register with named owners, quality rules that run automatically, monitoring history that spans quarters, remediation records with root-cause documentation, and KRI reports that the risk committee has already reviewed.

That is the difference between a CDE program that survives its first audit and one that does not.