The Pressure Is Real and It Is Not Coming Down
Let us be clear about something. The Basel Committee published its Principles for Effective Risk Data Aggregation and Risk Reporting in 3233. Over a decade later, the principles are not suggestions. They are expectations. And for Tier 2 banks, those expectations are becoming harder to ignore.
The OCC has been increasingly direct in its examination focus on data quality and risk reporting. Its guidance on model risk management, stress testing, and data governance all trace back to the same core demand: can you produce accurate, complete, and timely risk data when it matters? Not when things are calm. Not when your star data architect is at their desk. When it matters.
The FDIC has followed a similar trajectory. Its examinations now routinely probe whether banks can demonstrate that risk data flows are reliable, that aggregation is accurate, and that reporting can withstand scrutiny. The days of waving a hand at "we have a data warehouse" are over.
And then there is the Federal Reserve, whose SR 11-7 on model risk management and subsequent supervisory expectations have made clear that governance of data feeding into models is not optional. If your risk models run on data you cannot verify, your models are opinions dressed up as mathematics.
Why Tier 2 Banks Are Especially Exposed
The largest global systemically important banks, the G-SIBs, have had no choice but to invest heavily in BCBS 239 compliance. They were named explicitly. They had deadlines. They had regulators breathing down their necks with public scorecards.
Tier 2 banks watched from a distance. Many concluded that because they were not on the G-SIB list, the pressure did not apply to them. That was a miscalculation.
Here is the reality. Regulators expect all banks with systemic relevance or significant risk profiles to meet the same principles. The language in BCBS 239 itself says the principles should apply to banks "as appropriate" based on their nature, size, and complexity. "As appropriate" is not a loophole. It is a scalpel. And examiners are using it with increasing precision.
Tier 2 banks face a particular set of challenges that make this harder. They often have legacy systems that were never designed for enterprise-level risk aggregation. They have smaller teams, which means governance often rests on a handful of individuals who hold the institutional knowledge in their heads. They have fewer resources to throw at data infrastructure projects. And they have a tendency to view governance as a cost center rather than a capability.
Each of these is a problem. Together, they are a vulnerability.
The Wrong Approach: Documentation as Compliance
The most common mistake Tier 2 banks make is confusing documentation with compliance. Here is how it plays out.
A regulator raises a finding about risk data aggregation. The bank responds by producing a policy document. The policy document says all the right things. Data must be accurate. Reports must be timely. Definitions must be consistent. It gets signed, filed, and presented at the next examination.
But the policy was written by the governance team in isolation. The risk teams did not change how they aggregate data. The technology teams did not reconfigure their pipelines. The front office did not start using standardized identifiers. The policy exists on paper. The data still flows the way it always did.
This is governance theater, and regulators are getting better at spotting it. An examiner who asks "show me how this data element is defined and aggregated across your risk systems" is not looking for a PDF. They are looking for evidence that the system works. If the answer requires someone named Dave to explain it, you have a problem. If the answer requires three different spreadsheets and a manual reconciliation, you have a bigger problem.
The Right Approach: Systems That Prove Themselves
The banks that handle BCBS 239 well, regardless of their tier, share a common trait. Their compliance lives in their systems, not in their documents.
What does that mean in practice?
First, data definitions are enforced by technology, not by policy. If a critical data element is defined a certain way, the system should reject or flag data that does not conform. A policy that says "all risk data must use the same counterparty identifier" is worthless if the system accepts whatever the front office enters.
Second, data lineage is observable. You should be able to trace any number in a risk report back to its source without calling a meeting. If your data lineage exists in someone's head or in a Visio diagram that was last updated two years ago, you do not have lineage. You have a story.
Third, attestation means something. When someone attests to the accuracy of risk data, that attestation should be backed by evidence the system generated, not by good intentions. An attestation that says "I reviewed the data and it looks correct" is not attestation. It is a feeling.
Fourth, governance scales without headcount. If your governance model requires adding people every time you add a data source, you are building a bureaucracy, not a capability. The right systems allow you to certify more data, cover more risk types, and handle more regulatory requests without proportionally adding staff.
This last point matters disproportionately for Tier 2 banks. You cannot outspend the G-SIBs on governance headcount. You have to outsystem them. That means investing in automation, certification workflows, and data observability tools that do the heavy lifting that large banks do with armies of analysts.
The CoComply Angle
This is precisely the problem CoComply was built to solve. Not by adding another layer of documentation. Not by creating another committee. But by making certification a system property.
When risk data is certified through CoComply, the certification is repeatable, transferable, and auditable. It does not depend on who is in the room. It does not require a human to remember what the rules were. The system enforces the definitions, tracks the lineage, and produces the evidence.
For Tier 2 banks facing increasing regulatory scrutiny with limited resources, this is not a nice-to-have. It is the difference between governance that holds up under examination and governance that holds up until someone asks a hard question.
The Closing Test
Here is a simple test. Pick any critical risk report your bank produces. Now ask: if the person who normally explains this report left tomorrow, could someone else reproduce it, verify its accuracy, and attest to it within a week?
If the answer is no, you do not have a compliance problem. You have a resilience problem. And BCBS 239, however you feel about it, is designed to surface exactly that.
The regulators are not asking whether you have a policy. They are asking whether your governance works when the comfortable assumptions fall away. If your answer depends on specific people, specific spreadsheets, or specific interpretations that live in specific meetings, the answer is no.
Fix the system. Not the documentation.