Legacy reporting pressures

Even before the September 2021 “Dear CEO…” letter from the Bank of England that called out the widespread use of end-user computing and poor data quality in some regulatory reporting, one major UK bank knew they had a problem.

The data and processes to generate regulatory reporting were almost entirely divorced from those used to create internal risk reporting.

This meant two sets of data, two sets of processes but also two sets of people, and therefore at least two sets of problems. The data for both internal and regulatory reporting were routinely subjected to “manual adjustments” before publication and use, resulting in an army of people just to keep the lights on.

(Well, two armies, actually).

With pressure to document data flows used in board reporting coming from BCBS239, it quickly became apparent that the internal and external figures were subject to an unacceptable level of adjustment.

With regulatory reporting requirements constantly ratcheting up, it was clear that the legacy reporting process was unsustainable.

That’s when we came in to help.

Transparency creates executive buy-in

The first key decision we took – jointly with the CRO and CFO was to stop making manual adjustments for internal reporting. Whilst this caused some initial upset, it also meant that senior executives could see the actual flaws in the data – resulting in a renewed focus on investments in people, processes and technology to address them during the following financial year.

We agreed that the numbers used for regulatory reporting would still need to be manually adjusted (at least initially) because of upstream data quality issues, data gaps and other deficiencies, which we would seek to close.

Next, we looked at the organisational structures.

Aligning organisational reporting structures

We wanted to understand whether or not formal organisational structures and informal structures (such as user groups) were aligned or whether they contributed to the issue.

We found that in many cases, two different sets of teams with different priorities and reporting lines were each responsible for separate internal reporting and regulatory reporting functions.

Some informal user groups bringing key members of those teams together did exist.

`

Some informal user groups brought key members of each disparate team together. However, they were rarely formally constituted with clear terms of reference and ownership. They also operated at a junior level, meaning that whilst some of the technical work was partially aligned, there was a lack of alignment across governance, prioritisation and budgetary allocation.

Clearly, better alignment would remove the wasted effort and free up resources.

The next important step was creating a plan to align the data infrastructure.

Repurposing legacy infrastructure for consolidated reporting

We identified that the data warehouse used for internal risk reporting was structurally sound for both internal and external reporting, but there were definition differences and a small number of missing data sources.

We then looked at the organisation’s Target Systems Architecture to understand how the natural evolution of systems delivered via other projects would address the definition differences and missing data sources.

It was obvious that whilst there were opportunities to redirect existing approved projects and investments to bring internal and regulatory reporting together, left to their own devices, parallel reporting would continue.

Using this information, a number of these “in flight” regulatory programmes were adjusted so that rather than building new reporting solutions, they would correct the existing data warehouse’s shortcomings and migrate many elements of the regulatory reporting suite to it.

A key principle was that this should be at net zero cost to the programmes, leaving a residual element of regulatory reporting that would still need to be migrated.

Releasing human capital to reduce financial investment and accelerate project time-to-value

In parallel, the people who had previously made manual adjustments for internal reporting purposes were freed up. Their time was reinvested in a data governance programme to document and align the data between internal and regulatory reporting.

By prioritising critical data elements first, we identified where there were differences in definitions or where there were simply differences in the labels for the same data field.

Understanding these differences allowed us to size the effort required to harmonise data definitions between internal and regulatory reporting, reducing data lineage complexity and total migration effort.

The ‘Net-Zero’ reporting transformation

Finally, we helped define a dedicated project to migrate the remaining elements of regulatory reporting to the main risk warehouse.

Whilst some direct costs were required, the earlier steps significantly reduced the overall budget. The cost was partially offset because the old regulatory reporting system could be decommissioned rather than replaced at end of life.

In the final analysis, the work was more than paid for by removing a long-standing capital buffer related to concerns about data quality.

In addition, the bank redeployed a sizeable team of experienced staff away from the non-value-added manual reporting work, onto value-driven data initiatives across the organisation, without hiring and training recruits.