Data governance in banking is the discipline of ensuring data is accurate, complete, and reliable enough for every system, human or AI, that depends on it to make a decision, aggregate risk, or generate a regulatory report
More than a decade after the Basel Committee established BCBS 239’s risk data aggregation principles, fewer than 30% of Tier-1 banks report full compliance. BCBS 239 itself formally binds only global and domestic systemically important banks, so a Tier 2 or Tier 3 institution is not directly examined against it. What matters for a smaller bank is that the OCC, the FDIC, and the NCUA have each increasingly folded the same underlying data aggregation and lineage expectations into ordinary safety-and-soundness and model risk examinations, which means the architectural problem described here shows up at community and regional banks even though the named regulation does not technically apply to them. Institutions still working to close that gap are frequently addressing the wrong root cause.
The Gap Is Architectural, Not Merely a Data Quality Issue
The instinct when validation fails is to attribute the failure to the data itself: missing fields, stale records, inconsistent formats. That diagnosis is often accurate as far as it goes. The deeper and more persistent problem, however, is structural: in the pre-AI core, validations are embedded directly in the data mart or the report definition. Adding a new validation rule required re-engineering the report. Removing one that the underlying data could not support required re-engineering the data mart. Neither process was fast, and neither was flexible.
The practical consequence is that validation coverage was determined by what was anticipated when the report was originally built, not by what the data actually required at the moment of query. Banks operate for years with known validation gaps because closing them constitutes a data engineering project rather than a configuration change. This is a validation architecture problem presenting as a data quality issue, and it is the reason more than a decade of BCBS 239 remediation effort has not moved the industry compliance figure nearly as far as it should have.
What Reconciliation Looks Like When Validation Moves to the Query Layer
AI changes where validation logic resides. Rather than being embedded in the data mart, it is applied at the point of data retrieval, layered on top of the existing data mart, without altering its structure or the applications built on it. This architectural shift changes three things directly relevant to a CIO’s regulatory obligations:
- New validations do not require a data mart rebuild. A reporting requirement introduced by a regulatory finding becomes a rule in the intelligence layer, testable and deployable in the time it previously took merely to scope the data engineering work.
- The system reports what it cannot validate, not only what passed. In the predefined model, a validation the underlying data cannot support fails silently or is quietly excluded from the report specification. A query-level validation model flags what it cannot perform, giving governance complete visibility into the coverage gap, not just the output of what ran.
- Validation failures become a feedback loop. Patterns across failures surface either underlying data quality issues or incorrectly specified validation rules and route them for human review, turning governance into a continuous learning process rather than a periodic audit cycle.
This shift is not without cost. Moving validation out of the data mart and into a query-level intelligence layer means that layer now needs its own governance, version control, lineage tracking, exception handling, which is new engineering discipline the institution has to build and staff, not a simplification. The trade-off holds up because the alternative is continuing to pay the re-engineering cost every time a validation requirement changes, which is the pattern that produced the current compliance gap in the first place.
Reconciliation Becomes More Precise, Not Merely Faster
A fourth and more fundamental shift follows from this architecture: AI-generated validations are not aggregated constructs applied uniformly across a segment, product, or period. In the predefined report model, a validation designed for a period, product category, or customer segment functions as a generalized standard that all data in that group must meet. AI-generated, query-level validations operate at an entirely different level of granularity. They are specific to the individual customer or transaction under assessment, informed by patterns relevant to that exact context: behavioral patterns specific to a customer’s history, typological patterns specific to a transaction type, anomaly patterns specific to a particular moment in the market.
The result is a validation that is simultaneously more granular and more intelligent than any predefined rule could be. It indicates not only whether the data meets a general standard, but whether it is consistent with what that specific context should actually look like, a materially higher bar than most legacy reconciliation processes were built to clear.
Lineage to the Sentence, Not Only the Document
In service-oriented architecture, lineage was established at the document or code level: a decision could be traced back to the report from which its logic derived, or the code module in which its validation was implemented. That represented the finest granularity available.
AI-enabled query-level validation extends lineage to the paragraph and sentence level. When a validation rule is informed by a regulatory guidance document, an internal credit policy, or a risk management framework, the system can identify not only which document informed it, but which specific passage. When a compliance determination is challenged, the institution can point to the exact sentence rather than the source document alone. When a policy document is updated, the system can identify precisely which validation rules, and therefore which decisions, those changed sentences affected. The scope of impact assessment narrows from a document to a passage, and examination responses become faster and more defensible, a benefit that matters as much to internal audit and model risk teams as it does to external examiners.
Why This Matters Beyond the Regulatory Reporting Function
Data governance built along these lines does more than close the BCBS 239 gap. It is a prerequisite for every other AI-enabled use case across the institution. A data estate governed only for its structured fields still carries ungoverned content in every text column, content that AI models can now access and reason over for lending, fraud, and AML decisions. Extending the governance framework to cover unstructured data is not an optional addition to a modernization program; it is what makes every downstream AI decision defensible. Institutions that treat data governance as a narrow, report-specific exercise tend to rediscover this gap the difficult way, one AI use case at a time, rather than closing it once at the architectural level.
What This Means for the CIO Agenda
The persistent BCBS 239 compliance deficit is not primarily a data engineering problem that additional headcount will resolve. It is a validation architecture problem that AI-enabled, query-level validation intelligence can close without a data mart rebuild, and it is buildable before the next reporting cycle, rather than only in response to the next examination finding. For a board weighing the investment, the relevant comparison is not this project against no project; it is a fixed, one-time architectural investment against an open-ended, recurring cost of re-engineering the data mart every time a regulatory or examiner expectation shifts. Institutions that treat this as an architectural investment, rather than a recurring remediation exercise, are the ones most likely to close the gap permanently.
Further reading: The CIO’s Guide to AI-Enabled Core Banking Modernisation, part of Maveric Systems’ research on AI-first banking.
FAQ
1. Does BCBS 239 actually apply to a Tier 2 or Tier 3 bank?
Not directly. BCBS 239 formally binds global and domestic systemically important banks. It matters to smaller institutions because the OCC, the FDIC, and the NCUA have increasingly built the same underlying data lineage and aggregation expectations into ordinary examinations, so the architectural gap shows up in practice even where the named regulation does not technically apply.
2. Why is BCBS 239 compliance still so low across the banking industry?
Because the predefined report model cannot accommodate an evolving regulatory standard without continuous re-engineering. Adding or removing a validation historically required rebuilding the data mart or report, an expensive, slow process, so banks operate with known validation gaps rather than data quality failures alone.
3. What is query-level validation intelligence
It is AI-generated validation logic applied at the point of data retrieval, layered on top of an existing data mart, without altering its structure. It provides visibility into three categories: validations passed, validations failed, and validations that could not be performed because the underlying data does not support them.
4. How does AI improve data reconciliation in banking?
AI-generated validations are context-specific, applied to the individual customer or transaction rather than as a uniform, aggregated rule across a whole segment, and informed by behavioral and typological patterns specific to that context. This makes reconciliation both more granular and more accurate than static, rule-based checks.
5. What does “lineage to the sentence level” mean for regulatory reporting?
It means the system can trace a validation rule or decision back to the exact paragraph or sentence in a regulatory guidance document or internal policy that informed it, not just the source document as a whole. This narrows impact assessment when a policy changes and makes examination responses faster to produce.
6. Does improving data governance require rebuilding core banking data infrastructure?
Not necessarily. Query-level validation intelligence can be layered on top of an existing data mart, closing validation gaps and improving reconciliation accuracy without a full data infrastructure rebuild, which is what makes it achievable for banks without a Tier-1 data engineering budget.
