What Data Governance in Banking Must Prove for CCAR and BCBS 239

A bank's internal audit team can sign off on data governance every quarter and still fail a CCAR submission or a BCBS 239 exam, because regulators are asking a more specific question than internal audit typically requires: prove that the numbers in this capital planning submission or risk report can be traced back to their source, with a documented, repeatable path.

That is a materially harder bar than showing a warehouse table is well documented. CCAR requires banks to demonstrate that the data underlying capital planning submissions is accurate and that its lineage can be verified end to end. BCBS 239 goes further, requiring both the risk data aggregation capability itself and the IT architecture that supports it to be provably sound, not just described in a policy document. A bank that can only show where risk data currently sits, not where it originated, is exposed in exactly the review that matters most.

This post covers what CCAR and BCBS 239 actually require from a data governance program, where established banking systems break warehouse-level lineage, and what a defensible evidence trail looks like under examination.

What CCAR and BCBS 239 Actually Require

CCAR requires bank holding companies to show that the data feeding their capital plans is accurate, complete, and traceable back through the systems that produced it, so examiners can verify a submission rather than take it on faith. BCBS 239, formally the Basel Committee's Principles for Effective Risk Data Aggregation and Risk Reporting, sets this expectation explicitly: Principle 3 requires banks to generate accurate and reliable risk data, and Principle 2 requires the governance and IT infrastructure supporting that data to be sound enough to produce it consistently.

Neither standard is satisfied by a data catalog describing what a warehouse table contains. Both require evidence of how a number got there: which system created it, what transformations it passed through, and whether that path can be reproduced on demand for an examiner.

Where Established Banking Systems Break Warehouse-Level Lineage

Bank data estates are built on a mix of core banking platforms, established application systems that have run risk and transaction processing for decades, and newer cloud pipelines layered on top. Risk figures frequently pass through COBOL and Java based core systems, custom ETL jobs, and Python or Spark pipelines before they ever reach a warehouse a catalog tool can read.

A lineage graph built only from warehouse query logs treats that entire established application layer as a black box. It can show that a risk figure arrived at a staging table, but it cannot show which core system produced the original value or what business logic in an established application changed it along the way. That is precisely the gap a CCAR or BCBS 239 examiner is trained to probe.

What Is BCBS 239

BCBS 239 is the Basel Committee on Banking Supervision's set of principles for effective risk data aggregation and risk reporting, adopted in response to banks' inability to aggregate risk exposures quickly and accurately during the 2008 financial crisis. It requires banks to demonstrate that risk data is accurate, complete, timely, and adaptable, and that the governance and infrastructure producing that data can be verified, not merely documented in policy.

For a data governance leader, BCBS 239 compliance is not a one-time checklist. It is an ongoing requirement to prove, on demand, that risk data lineage holds up from the established systems that generate it through every transformation to the final report.

What Good Looks Like: Lineage That Holds Up in a CCAR or BCBS 239 Exam

Meeting CCAR and BCBS 239 expectations requires lineage traced from the source code and systems that generate risk data, not inferred from warehouse metadata after the fact. Foundational is the only data and AI governance platform that analyzes source code directly, including SQL, Python, Java, Scala, and the ORM layer, so a bank can show examiners exactly which system and which line of code produced a given risk figure.

Lemonade used this approach to significantly accelerate regulatory approval for its AI driven underwriting models, a direct example of how tracing model and reporting inputs back to their true origin changes a regulatory review from a lengthy back and forth into a documented, defensible answer. For a bank facing a CCAR submission or a BCBS 239 exam, that same evidence trail is the difference between describing governance and proving it.

Here is what each requirement expects and where warehouse-only lineage falls short:

• Principle 2, governance and infrastructure: BCBS 239 expects IT architecture sound enough to produce reliable risk data, while warehouse-only lineage cannot verify infrastructure below the warehouse boundary.
• Principle 3, accuracy and reliability: BCBS 239 expects risk data to be traceable and reproducible on demand, while warehouse-only lineage shows current location only, not origin.
• CCAR's data integrity expectation: capital planning data must be verifiable end to end, while warehouse-only lineage stops at the most recent system hop.

Frequently Asked Questions

What does data governance in banking require for CCAR and BCBS 239 compliance? It requires lineage that traces risk and capital planning data back to the core systems and application code that produced it, not just documentation of where that data currently sits in a warehouse. CCAR and BCBS 239 both expect banks to demonstrate, with evidence, that reported figures can be reproduced and verified end to end.

What is BCBS 239 in simple terms? BCBS 239 is a Basel Committee standard requiring banks to prove their risk data aggregation and reporting capabilities are accurate, complete, and governed by sound infrastructure, not just described in policy. It was introduced after the 2008 financial crisis exposed banks' inability to aggregate risk exposures reliably.

Why does warehouse-level lineage fail CCAR and BCBS 239 requirements? Warehouse-level lineage is built from query logs and metadata, which only shows where data currently sits, not where it originated. CCAR and BCBS 239 examiners ask for the full path a risk figure traveled, including the core banking systems and application code that produced it, which a warehouse-only view cannot show.

How does source code analysis help with a BCBS 239 exam? Source code analysis traces lineage directly from the code that generates and transforms risk data, including established core banking systems, custom ETL, and current cloud pipelines, producing a documented path examiners can verify. This replaces an inferred, warehouse-only lineage graph with deterministic evidence of exactly how a figure was produced.

Does this require replacing established core banking systems? No. Source code analysis reads the existing code in established core banking systems and application layers rather than requiring a bank to replace them. It adds the lineage and governance evidence those systems were never built to produce on their own, without disrupting systems that already run critical banking operations.

Proving Governance, Not Just Describing It

CCAR and BCBS 239 both reward banks that can show, not just tell, where their risk data came from. That evidence has to trace back through established core systems and application code, not just summarize where the data currently sits in a warehouse. See how Foundational's compliance and regulated industries coverage supports CCAR and BCBS 239 evidence requirements, or request a demo to see risk data lineage mapped against your own banking systems.