Regulatory requirements are here to stay. Whilst, on one hand they pose a true challenge to be handled efficiently, on the other hand they offer a convenient way to both bolster the quality of your data assets and further develop their ownership. This is no new idea, but still surprisingly topical given the recently reported data governance maturity gaps in financial institutions.
Path from BCBS239 to data mesh
After living a decade with BCBS’ Principles for effective risk data aggregation and risk reporting [1] (commonly known as BCBS239) European financial institutions are still struggling to adopt best practices for data management. This could be seen in ECB’s Thematic Review [2], the following letter [3], and more recently in its public consultation on risk data aggregation and risk reporting [4]. Hence, risk data aggregation remains on the supervisory agenda [5] until the sufficient level has been reached.
Meanwhile, other data driven industries have been marching forward with new approaches for maintaining the competitive edge. Often, they don’t bag as much legacy burden, or regulatory pressure, as financial institutions, but they do have had to adapt as well. These experiences have provided us with useful and practical use cases for the transition in financial services industry.
Currently, the debate has settled in the point of view, that heavily data-reliant industries should treat its data assets as products with proper product management. This is well elaborated in one of the principles in the acutely relevant data mesh [6] methodology: “Ecosystem of data products over centralized data platform”. Furthermore, to bridge the gap between the business lines, technical data experts, and the data consumers the ownership of these data products should remain with business.
Product thinking in the front lines
Regulatory pressure for financial institutions often manifests as regulatory reporting requirements. These requirements remain one of the main drivers for data development in banking. This is very much business as usual, and we’ve noticed it often creates (at least) two separate organizations who practically ‘own’ the data for regulatory purposes. And indeed, it’s truly a challenge to overcome these old ways of working in this area.
Say, business lines own and thoroughly know the business process and customer journey with its systemic quirks, whereas specific regulatory reporting department might hold de facto ownership of the risk weight calculations, collateral allocations, certain risk modelling or such. More than often, not all details that truly affect the financial institution’s capital or liquidity positions (through regulatory requirements) are reflected in the pricing of the products, which is decided and carried out in the business line.
Through our recent projects in the regulatory reporting space, we’ve noticed that if sufficient buy-in from business lines can be achieved, then data intensive regulatory reporting projects can drive a positive change in data product development and ease out the hard task of assuming ownership of the data. Indeed, given how complex and broad current regulatory reporting is, often its data requirements offer a great proxy to develop a business-based data product. Suitably, EBA’s Data Point Model (DPM) [7] supports this data development methodology. Resulting data products naturally depend on the financial institution’s data strategy, but some examples could include data interfaces describing institution’s derivatives business domain (or subset of it), or lending business domain (commercial or mortgage).
Exploring data product model for derivatives business
Let’s explore a bit further with an example of derivatives. A good set of regulatory data requirements for derivatives is laid out in EBA’s Common Reporting (COREP) framework [8]. Specifically, our example draws from Counterparty Credit Risk (CCR), which appears on COREP templates C 34.01 – 34.11 [9]. These requirements already spell out a wide variety of information about derivatives business, including e.g. size of the business, number of transactions, counterparties, collateralization, netting sets, margins, notional amount, market value, credit valuation adjustment risk (CVA), risk categories, and approach for CCR.
Just by superficially glimpsing through these requirements gives us an impression of a conceptual structure. We would need to arrange this information in a way that at least encompasses:
- deal level information (margins, notional amount, market value, collateralization, CVA),
- general referential information (counterparties, risk categories), and
- specific referential information (netting sets, approach for CCR).
Now, it would seem, that categories 1) and 3) represent a typical part of doing business with derivatives and making decisions about them. Thus, the ownership of these data sets should very probably reside within the organization who runs the derivatives business. With category 2) we have seen mixed approaches, for example a centralized reference data service, a dedicated customer/counterparty data interface product, or derivatives business line just owning the counterparty information as well. In addition, depending on the jurisdiction where one operates, collateral management might be complex enough that it should be considered an area of its own.
Taking above three to four information domains into account, we already built ourselves a conceptual model of our derivatives business. This model serves as a great starting point for our data product development. It could be directly used for our regulatory COREP purposes, and on the top of it, it would arguably already provide the most business-critical information for many other potential data consumers. This model is extendable, able to hold the one truth, and can be maintained to facilitate additional use cases.
Restrictions may apply
This approach is especially relevant for business lines for assuming ownership of their data. When working with larger financial organizations, we’ve seen that there are different data domains with different data management maturities. Given both the web-based banking interactions and a bit more recent developments in artificial intelligence, customer data domain often seems to be more mature, and owned and maintained more meticulously. Same applies to ownership of the reference data (zip codes, industry classifications, instrument lists etc.), which usually is one of the first data domains in which the ownership needs to be decided and assigned.
Welcome regulatory requirements; welcome data products
We warmly recommend that when faced with yet another set of regulatory requirements, extend your point of view to strategically important transformation. Rather than tackling them as a standalone challenge, harness them for merging data management into business lines’ thinking. After all, financial services are natively fully digital in nature and properly owned high quality data products translate directly into business value.
Sources
[1] Basel Committee on Banking Supervision (January 2013), Principles for effective risk data aggregation and risk reporting https://www.bis.org/publ/bcbs239.pdf
[2] ECB Banking Supervision (May 2018), Report on the Thematic Review on effective risk data aggregation and risk reporting https://www.bankingsupervision.europa.eu/ecb/pub/pdf/ssm.BCBS_239_report_201805.pdf
[3] ECB Banking Supervision (June 2019), Supervisory expectations on risk data aggregation capabilities and risk reporting practices https://www.bankingsupervision.europa.eu/press/letterstobanks/shared/pdf/2019/ssm.supervisory_expectations_on_risk_data_aggregation_capabilities_and_risk_reporting_practices_201906.en.pdf
[4] ECB Banking Supervision (July 2023), Guide on effective risk data aggregation and risk reporting (draft for public consultation) https://www.bankingsupervision.europa.eu/legalframework/publiccons/pdf/ssm.pubcon230724_draftguide.en.pdf
[5] ECB Banking Supervision (19th Oct 2023), SSM supervisory priorities for 2024-2026 https://www.bankingsupervision.europa.eu/banking/priorities/html/ssm.supervisory_priorities202312~a15d5d36ab.en.html
[6] Zhamak Dehghani, Thoughtworks (2019) How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (martinfowler.com)
[7] EBA, Reporting frameworks, https://www.eba.europa.eu/risk-and-data-analysis/reporting-frameworks
[8] EBA, Reporting framework 3.2, https://www.eba.europa.eu/risk-and-data-analysis/reporting-frameworks/reporting-framework-32
[9] EBA, ITS on supervisory reporting (folder Amended, under Annex 1 and 2 for Solvency), https://www.eba.europa.eu/sites/default/files/2023-11/7ffe0b9b-ae8b-49b1-b808-8ed141ed8afd/ITS%20on%20supervisory%20reporting.zip
Jaa somessa:
