Written by Sehaj Benipal, Senior Consultant, with support of Hugo Weitz, Principal Consultant.
Introduction
As Banks and Financial Institutions drive towards compliance with BCBS-239 principles, documenting data lineage and mapping process flows for relevant risk metrics forms a big part of the overall requirements. However, we cannot fail to notice that these data transformation and aggregation processes are often needlessly inefficient and complex. This can be pinned down to the increase in the complexity and the sheer number of reporting requirements by regulators over the years. This has in-turn resulted in a buildup of technical debt in the overall architecture and design of the solutions that facilitate the computation of said metrics.
The natural next step in the journey towards more accurate and precise risk reporting is to leverage BCBS-239 features like data lineages, glossaries, reference datasets etc. to create an enterprise-wide integrated data layer that can source, transform, enrich, and store all underlying facts and dimensions in a manner that makes sense to Risk analysts and managers.
What is an Integrated Data Layer?
The idea behind building a new data layer is to introduce a degree of normalisation of data by organising all source information into a standardised format supported by a logical data model that can cater for all downstream calculation and reporting needs. This information can then be further enriched semantically by marrying it to a centralised data glossary and reference data. This is a superior way of organising information in your data warehouse and can eliminate all duplication of transformation rules while also simplifying the control framework required to maintain data integrity across the risk reporting process.
ECB’s Banks’ Integrated Reporting Dictionary (BIRD)
The European Central Bank’s BIRD initiative intends to tackle the same problem. Recognising the increasing complexity and volume of regulatory reporting, the service intends to create an integrated dictionary – completed with an overarching logical data model that Banks and FIs can map their physical data elements to with the objective of standardising their reporting frameworks. The scope of BIRD is not just limited to risk reporting but encompasses the entire breadth of regulatory reporting for Banks.
The BIRD data model also intends to function as an all-encompassing input layer for ECB’s proposed Integrated Reporting Framework (IReF), which will integrate the European regulator’s statistical requirements for Banks into a single standardised reporting framework applicable across the Euro area (e.g.: BSI and MIR statistics, SHS-S, AnaCredit and FinRep). It needs to be noted that BIRD is not a regulatory requirement but merely a free-to-use service. However, as the project itself highlights, the benefits of modelling a data management framework on its design principles are hard to understate. Building an Integrated Data Layer incorporating BIRD’s design principles and data models is a sure-fire way to eliminate redundancies and improve the overall quality and accuracy of your data.
Timelines for IRef Implementation
Unlike BIRD, the IRef is expected to be a mandatory regulatory requirement. The ECB is currently in the process of fine tuning and clarifying additional topics relating to IRef (and BIRD). The latest draft regulation is expected in 2024 and it will be subject to a public consultation before it is finalized and adopted. The regulation will then replace the existing legal provisions on the collection of datasets within IRef, and the relevant existing ECB regulations will be repealed or amended, as applicable.
Benefits
Looking at the features required to solve for BCBS-239 compliance along with the BIRD LDM, it would not be wrong to assume that a lot of the ingredients required for engineering such a solution are already in place. However, building an Integrated Layer that spans across the breadth of the enterprise is not a small undertaking. So why build one?
1.Reduced Redundancies & easier Change Management
Possibly the most important benefit of creating an Integrated Data Layer is the de-duplication of various transformation, validation and/or aggregation steps. Let us say for example an organisation has a dedicated database for capturing and storing Collateral data. In the absence of any shared data layer on top of this raw database, the same data attributes from this Collateral database would be queried for modelling Loss Given Default (LGD), reporting Loan to Value ratios across products and numerous other processes. In order to maintain compliance, each of these processes would have to define and document business transformation and validation rules, and perform reconciliations to source independently. This is a typical example of technical debt that is accumulated across a data management solution’s lifetime, which eventually turns the change management process for any new change upstream into a quagmire.
An Integrated Layer addresses this problem by implementing all possible business transformation and validation logic at the source to Integrated Data Layer level, eliminating redundancies and also making change management a one-step process as long as there is consensus amongst downstream consumers.
2.Controls & Validation
As the requirements around having adequate controls across the lineage of a metric have become more stringent, merely performing additional controls at every data transfer and/or transformation step may not have the intended benefit of improving the accuracy and integrity of the underlying data.
Again, using Collateral as an example, let us say there are two separate processes – the first one intends to use Collateral Value from the underlying database to calculate the Loan to Value of a portfolio. The second process queries the same attribute, albeit independently, but to calculate the Foundation LGD as per the Basel IV requirements. In cases where the collateral values are stale (older than the date of sanctioning of the loan), they can be flagged easily by the first process, by simply having a validation rule that compares the date of sanctioning of the loan with the date of the last valuation capture. However, this might be missed by the second process, as it would not need to fetch the underlying attribute for the loan commencement date in the first place to calculate the Foundation LGD.
Indeed, an Integrated Layer also allows for collating the validation rules and various other controls that have been applied to the same attribute by different processes, to create a more holistic view of data quality and highlight defects for all downstream consumers.
3.Centralized Reference Data and Glossary
Establishing the most reliable version of data used for the core entities of regulatory reporting e.g., Asset Class, Product, etc. allows for consistency across the enterprise data aggregation process. Practically, how one business unit or a portfolio defines an attribute is understood in the same way across the board.
Conclusion
Although building an Integrated Data Layer is not a requirement for BCBS-239 compliance or a mandate by ECB’s BIRD, banks have a unique opportunity to leverage the work that they are currently undertaking in this space as a starting step to build a strategic data warehouse that can cope with the increasingly granular reporting requirements from regulators in a manner that is true to the spirit of the BCBS-239 regulation. BIRD is nevertheless an additional incentive to adopt this best practice, putting additional pressure on the banks choosing to maintain silos of data while having difficulties to justify inconsistencies across reporting streams.
Bringing in depth regulatory reporting understanding to the data world, Finalyse is best positioned to help banks leveraging the most from the data quality improvements and process efficiency gain while engaging in such a journey. Do not hesitate to ask for a free workshop to know more and analyse how building an Integrated Data Layer could solve your particular challenges.