BCBS 239 Banking on Data

Introduction

Influenza, or flu, is a dangerous, contagious disease that can be fatal to those whose health is less than perfect. Throughout the world the occurrence of flu is monitored by national and international health agencies and networks. In 2008 Google joined these agencies by launching the Google Flu Trends service. Google claims that certain search terms are good indicators of flu activity, and the Flu Trends service uses aggregated search data to estimate and report on flu activity. Despite initial promising results, Google tripped up in 2013 ([Natu13]). Triangulation with other flu studies showed that Google’s estimates for flu occurrences were almost double those of similar studies. What went wrong? Some researchers blame poor data quality, or data whose origin is beyond the direct control of Google. Whatever the cause, the fact that predictions by the world’s most respected data company may be inaccurate is an important lesson for companies, including banks, whose business and risk models rely on accurate aggregated data and reports.

The High Level Group of Financial Supervision in the EU, chaired by Jacques de Larosière ([Dela09]), was tasked with investigating the cause of the 2007/2008 financial crisis. Their 2009 report also cited the availability and quality of data as one of the underlying causes of both poor macroeconomic surveillance and inadequate crisis prevention. This report and subsequent changes to the international regulatory framework for banks (Basel 2.5 & III) led to the publication of BCBS 239, “The Principles for Effective Risk-Data Aggregation and Risk Reporting,” by the Basel Committee on Banking Supervision (BCBS) in January 2013. These principles are the focus of this article. The purpose of this article is to inform the reader about BCBS 239 and to share current thinking about how banks can integrate this standard into how they aggregate risk data, ensure reporting quality, and maintain effective policies, procedures and systems.

Before exploring the content of BCBS 239, this article surveys the background and objectives of this standard, then presents an overview of its scope and actual requirements. The assessment section identifies essential lessons learned, and ranks banks with respect to compliance with the BCBS 239 principles. The section “Roadmap Towards Compliance” describes special BCBS 239 impact areas and an overall plan how to approach implementation of that standard. Finally, the future of risk-data aggregation and risk reporting is briefly discussed and conclusions presented.

Figure 1. BCBS 239 principles risk-data aggregation and risk reporting.

BCBS 239 – Background and objective

The financial crisis of 2007/2008 had many causes. The conclusions of the “De Larosière” report with respect to risk data and reporting have been reiterated by numerous later studies and surveys. For example, in the same year a study sponsored by KPMG called “Beyond Box-Ticking: A New Era for Risk Governance” ([EIU09]) pointed out that risk-data quality was at that time of great concern to risks managers of the banks surveyed and ranked high on their agendas. However, the 2007 financial crisis can’t be seen in isolation, as managing risk is arguably the most fundamental function of a bank, and data itself is the raw material for all aspects of the banking business model.

Risk management is a key component of every banking model. A bank’s primary purpose is to serve as intermediary in bringing together supply and demand, i.e. providing loans to its customers while at the same time allowing other customers to deposit their money securely. Identifying and managing the risks of this transformation function is what banking is all about. The complexity and growth of the economy, the role of banks in the market, the subsequent innovation in financial products and the financial volume involved have amplified the role of risk management in banks since the introduction of the Glass-Steagall Act in the aftermath of the depression in the early 20th century.

Similarly, the ability to process data either manually or electronically is a pre-requisite for all banking services. Automation in processing this raw material has lead to the introduction of the ATM, credit/debit cards, electronic payments, online/mobile self-service models and high-frequency trading. Data attributes such as accuracy, completeness, confidentiality, integrity and availability are critical when introducing and running these financial services in the market.

From a regulatory perspective, the years immediately preceding the financial crisis required banks to invest heavily in data and reporting quality in order to comply with regulation. Examples of such regulation were: the International Financial Reporting Standards (IFRS) and Sarbanes-Oxley. Basel II  in particular introduced data quality for risk models, specifically for credit risk and operational risk models. However, the data and reporting requirements expressed were tightly coupled and specific to the respective (risk) domains. No overall standard evolved.

The BCBS 239 paper reiterates the following lesson learned from the financial crisis: “banks’ information technology (IT) and data architectures were inadequate to support the broad management of financial risks.” It presents an overarching set of principles merging and detailing related regulations with respect to material risk-data aggregation and risk reports. In the paper the Basel Committee refers to a number of related post-crisis standards: (1) BCBS 158, Enhancements to the Basel II framework (July 2009), (2) BCBS 176, Principles for enhancing corporate governance (October 2010) and (3) FSB’s “Key Attributes of Effective Resolution Regimes for Financial Institutions (October 2011). These standards provide high-level guidance to both risk-data aggregation and reporting in both “going concern” as well “gone concern” situations. However, the level of detail with respect to IT and data architecture in the above mentioned papers is either too general or too specific for the respective risk categories. This silo-based approach didn’t encourage the development of an overall risk-data aggregation reporting standard. BCBS 239 does.

The BCSB 239 standard sets one clear general objective: “to strengthen banks’ risk-data aggregation capabilities and internal risk-reporting practices (the Principles) (…..) to enhance risk management and decision-making processes at banks.” This key objective is supplemented by providing explicit expected changes within the bank once the bank has implemented the principles. By implementing this standard, a bank should realize notable benefits:

• enhance the infrastructure for reporting key information, particularly that used by the board and senior management to identify, monitor and manage risks;
• enhance the management of information across legal entities, while facilitating a comprehensive assessment of risk exposures at the global consolidated level;
• reduce the probability and severity of losses resulting from risk-management weaknesses;
• improve the speed at which information is available and hence decisions can be made; and
• improve the organization’s quality of strategic planning and the ability to manage the risk of new products and services.

Overall, the BCBS 239 standard is a radical change from other regulatory principles. It focuses on risk aggregation and (internal) risk reports. It is agnostic with respect to specific business activities, business operations, risk categories- and risk reports. As such, the implications for a bank will be broad, deep and not limited to risk management only. The BCBS 239 principles will impact many more regulatory standards other than those mentioned in the BCBS standard itself, such as the revisions to the Capital Requirements Directive (CRD4) and Regulation (CRR),  the European Market Infrastructure Regulation (EMIR), the Recovery and Resolution Directive (RRD) and also important initiatives such as the Legal Entity Identifier.

With the BCBS 239 standard, the Basel Committee aims to improve risk-data architecture and reporting systems as a fundamental prerequisite for strong risk management, and for the first time the regulator sets out specific requirements for IT risk architecture and risk-data management in banks. The following section provides a more detailed overview of the actual scope and requirements involved.

BCBS 239 – Scope and Requirements

The BCBS 239 standard specifies 14 principles distributed across 4 topics in its 28 pages of text. The topics are:

• I. Overarching governance and infrastructure;
• II. Risk-data aggregation capabilities;
• III. Risk-reporting practices;
• IV. Supervisory review, tools and cooperation.

The first three topics address banks; the last topic addresses supervisors. Based purely on the number of requirements, topic III. Risk-reporting practices has the highest priority. However, priority and impact don’t always match. The initial scope is only to address Global and Domestic Systemically Important Banks (SIB). Nevertheless, the standard notes that local supervisors may apply the principles to other banks also. The timeframe to implement the standard is aggressive: G-SIBs must comply by January 1, 2016, D-SIBs three years after their designation as D-SIB.

Figure 2. BCBS 239 areas and principles.

Being principle-based means that BCBS 239 is not a cookbook, not a set of rules that once followed results in compliance. By specifying principles that are bank type, business activity and risk type agnostic and principle based, BCBS 239 must be interpreted carefully. The following text provides an outline of the standard per area:

• I. Overarching governance and infrastructure – A bank should have in place a strong governance framework, risk data architecture and IT infrastructure. This entails that:
  • The responsibility for data quality lies with the management board and senior management, who must be fully cognizant of the limitations of risk reporting;
  • The goal is the correctness of risk data regardless of organizational limitations (such as business units, jurisdictions, etc.);
  • Effective IT support for risk-data aggregations and reporting must also be available in times of crisis and stress.
• II. Risk-data aggregation capabilities – Banks should develop and maintain strong risk-data aggregation capabilities to ensure that risk-management reports reflect the risks in a reliable way. This entails that:
  • Capacity is available to generate correct and complete risk data;
  • Generation of risk data must be automated where possible, in order to reduce errors;
  • Timely risk-data aggregation must be assured;
  • Risk-data aggregation must be flexible and scalable to adapt to ad-hoc reporting and regulatory requirements (in particular, also in crisis scenarios).
• III. Risk reporting practices – Risk reports should be accurate, clear and complete in terms of content, and be presented to the appropriate decision-makers in time to allow for an appropriate response. This entails that:
  • Timely preparation and distribution of validated risk reports must be assured;
  • All material risk areas must be integrated;
  • Risk reports must be understandable by those to whom they are addressed;
  • Weaknesses and limits of risk reporting are transparent, to assist in making decisions based upon the reporting.
• IV. Supervisory review, tools and cooperation – Supervisors should determine whether the principles achieve the desired objectives. This entails that:
  • Supervisory bodies must review and monitor compliance with principles;
  • Supervisory bodies use the right tools for reviews and for sanctions;
  • Cross-border cooperation of supervisors must take place.

Close inspection of the BCBS 239 principles results in the identification of interdependencies and several common themes. The principles in the first two areas “I. Overarching governance and infrastructure” and “II. Risk-data aggregation capabilities” form the foundation for a solid implementation of the principles in area “III. Risk-data reporting.” It is reasonable to deduce that a risk report can only present a material risk correctly provided the material risks were aggregated correctly and proper and current entry of data was ensured. The standard stipulates that implementation of all principles in all 3 topics is a pre-requisite for banks to be compliant. Banks can’t pick and choose. Also, banks should be aware of common themes inherent to most of the requirements specified. These common themes must, irrespective of the area or principle in question, always be considered when implementing the standard. They are:

• Data aggregation and reporting principles should be applicable to all “material” risks;
• Data aggregation and reporting principles should be applicable in both “business as usual” as well as “stress” situations;
• Data aggregation capabilities and reporting practices should be adaptable and customizable;
• Data aggregation capabilities and reporting practices should be of the same level of quality as accounting;
• Data aggregation capabilities and reporting practices should be documented and validated;
• Data aggregation capabilities and reporting practices should be automated where possible;
• The usage of “end-user- and desktop computing” should be reduced to an absolute minimum.

In combination with the objectives stated in the previous section, the principles specified require banks to look carefully at both core business activities and supporting (risk management) activities in order to assess the impact of BCBS 239 and define a roadmap towards compliance. The following section provides an initial overview of the impact.

BCBS 239 – Assessment

The first required step for every bank is to assess its current compliance with respect to the standards in order to establish a baseline to draw a roadmap towards compliance. For all 30 global systemically important banks (G-SIBs) that are required to comply with the 239 standard by January 2016, the Basel Committee required a mandatory self-assessment. Every G-SIB had to conduct the self-assessment and report the results by July 1, 2013. The aggregated, anonymized results were published in December 2013 in the BCBS  268 report “Progress in Adopting the Principles for Effective Risk-Data Aggregation and Risk Reporting” ([BCBS268]).

The G-SIBs were given a set of requirements for each of the 11 (banking) principles within the scope of the report. The requirements were, but for a few exceptions, the same requirements specified per principle in the BCBS 239 standard. Each requirement had to be given a rating from 1 (non-compliance) to 4 (fully compliant). In addition, banks were asked to rate their overall assessment for each separate principle and to provide an expected date of full compliance.

Figure 3. Self-assessment 30 G-SIBs, December 2013.

The anonymized results, plus comments and conclusions, give an interesting perspective on the self-assessment by the 30 G-SIBs. First of all, for the aggregate score per principle, none of the 30 G-SIBs rated themselves as “non-compliant.” The principles that scored worst were principle 2 (data architecture/IT infrastructure), principle 3 (accuracy/integrity) and principle 6 (adaptability). For each of these principles more than 10 G-SIBs assessed themselves to be “materially con-compliant,” the second-worst rating. The best ratings were given to principles in the space of “III. Risk-reporting practices.” Principle 8 (comprehensiveness) and principle 9 (clarity/usefulness) were evaluated highly (largely or even fully compliant). Principle 11 (report distribution) received only “largely compliant” or “fully compliant.” What shortcomings or positive capabilities lie behind the bad (or good) assessments?

The second principle “data architecture/IT infrastructure” in area “I. Overarching governance & infrastructure” was ranked lower than any other principle. The main stated reason for this is unavailability of data taxonomies and poor data ownership. In addition, inadequate controls was provided as an additional cause behind the inadequate rating of the self-assessment. The meager rating of principle 3 (accuracy & integrity) is due to an insufficient balance between automated and manual systems and quality or unavailability of documentation of the risk-data aggregation process. With respect to the last of the poorly rated principles, adaptability scored low across most of the specified requirements.

Of the 3 principles that were assessed to be in good health, the rating of principle 11 (report distribution) is due to meeting all of its 2 detailed requirements: timely dissemination and confirmation of timeliness. Similar to principle 11, principle 9 (clarity/usefulness) receives a positive rating for most of its 9 specific requirements. The only exception is a requirement related to the inventory and classification of risk types. Principle 8 (comprehensiveness) received favorable ratings, without exception, for all 4 of its requirements as well.

An overall evaluation of the results as reported begs the following question: “how do banks distribute accurate, comprehensive, clear and useful reports in a timely manner when at the same time they  assess themselves to be materially non-compliant in the areas of ‘II. risk-data aggregation capabilities’ and ‘I. governance and infrastructure’? The report notes that principles related to both topics are preconditions to ensure compliance with other (risk reporting) principles.

Summarizing the report, the Basel Committee states that banks need to “significantly upgrade their risk IT systems and governance arrangements, improve the accuracy of their risk data as well as its completeness, timeliness and adaptability, ensure that data-quality checks are as robust as those supporting their accounting data and improve adaptability.” In addition, the report mentions that the assessment itself was hampered due to non-inclusion of all risk types, all material risk reports and/or material business units or entities within the group. Overall, a third of all G-SIBs reported that they expect not to comply with at least one of the 11 principles by January 2016.

Based on the results of the formal BCBS 239 assessment by G-SIBs, and its own assessment and experience, KPMG derived a number of key impact areas for banks to focus on in mapping their own road towards compliance. These are described in the next section.

BCBS 239 – Road towards compliance

The self-assessment by G-SIBs shows clearly how hard it is to comply with the principles. The variety, complexity and size of the customer base, of the business and operational models, of the financial products and corresponding governance and systems of the G-SIBs certainly plays an important role here. However, other banks do not necessarily comply more easily. For a large segment of the industry risk management is a concern shared throughout the front, mid and back office; plus, products and activities are often driven by national requirements and local supervisors are expected to provide their own interpretation of the BCBS 239 principles. In general terms, BCBS 239 is an overarching regulation and its impact will be significant. Therefore, it’s essential that the principles must be interpreted by the bank and that each bank defines its own BCBS 239 minimum standard.

To facilitate the activity of translating the principles to bank-specific minimum standards, KPMG has identified the following key areas in order to understand and define the impacts: A – Organization and IT management, B – IT architecture, C – Data quality framework and D – Risk reporting. The following section elaborates each area.

A – Organization and IT management

A direct result of the principles is the integration of “risk aggregation and reporting” in the overall IT strategy and implementation roadmap. Compliance to the standard will only be possible when the bank adapts a long term “risk aggregation capability and risk-reporting practice” strategy that sets targets for resilience, scalability and adaptability. Furthermore, the bank must include “risk aggregation and reporting capabilities” in its Business Continuity Management (BCM) policy and add independent validations of company-wide BCBS 239 standards. Overall, it is important that risk aggregation and reporting must not exist in isolation.

B – IT architecture

A key focus is establishing a taxonomy and dictionary of risk data. All models of risk data should be derived from these standards, unified or reconciled across the group or business lines using standard naming conventions leading to maintainable and adaptable logical and physical data models. Risk and accounting data should be aligned and reconciled. The level of detail of data across the organization must be consistent to allow for aggregation and enable flexible reporting. A bank should consolidate data sources and strive towards a single authoritative, golden (data) source per risk type and a high degree of automation. Desktop and end-user computing should be reduced and phased out where possible.

C – Data-quality framework

The bank must establish data-quality management, including data profiling, data lineage, monitoring, reporting and escalation procedures. Comprehensive data governance must be established, including identifying data owners and creating service-level agreements (SLAs) between units within the bank and with external parties regarding processes related to risk data. Risk reporting and reconsolidation should be documented and automatic (or manual) quality checks for risk-reporting practices implemented.

D – Risk reporting

The bank must establish adaptable and ad-hoc reporting capabilities with drill-down in various risk dimensions and stress testing. In addition, banks must create a comprehensive, timely, dependable and adaptable risk-reporting capability across all units and all material risks.

Figure 4. Target / compliant governance & IT architecture, BCBS 239. [Click on the image for a larger image]

Overall, banks can use the key impact areas to identify their own areas where improvements are required. The design and implementation of necessary improvements will follow: a reduced number of data suppliers/sources, a standard implementation for ETL/staging, a standard approach regarding data warehousing (DHW) and an analysis engine, plus a standard risk-data reporting process and supporting infrastructure. Much of this will require substantial IT infrastructure and system projects, while at the same time introducing new process and governance models (see Figure 4 above).

Figure 5. Road towards compliance. [Click on the image for a larger image]

To assist banks in becoming compliant, KPMG has defined a roadmap prototype. It consists of 4 phases, each with its own objective(s). The first phase “Analysis & design” requires the bank to conduct a self-assessment, similar to the self-assessment described in the previous section. The objective of the self-assessment is to identify the deficiencies and root causes. The scope of the assessment is based on material reports and related risk type. Therefore, an essential step in this process is the identification and description of all risk reports plus the risk types and related risk metrics included in the reports. To assess the risk-data aggregation capabilities, a key step is to document each risk metric including its related risk data, data lineage, organizational unit(s) responsible, risk process (manual/automatic), systems (end-user/application), control(s), paint-points and root cause. Each separate data item should be assessed for compliance to the principles.

Another important step in the first phase is reviewing and aligning ongoing projects or initiatives within the banking group, such as in-flight programs related to the Target Operating Model (TOM) of risk management units or reporting, data quality, business continuity or large IT infrastructure initiatives. Having identified the programs or projects, these must be reviewed to assess if they either conform to the standard or contradict the objectives of the BCBS 239 standard.

Once the two steps have been carried out, the overall BCBS 239 program can be initiated based on the 4 KPMG impact areas, and program governance can be established. It is important that all of sponsorship, scope and issue management is established and agreed upon prior to the kick-off, especially if related projects were identified in the previous step. Typically, the program consists of two different types of teams: global teams that define and implement overarching policies, frameworks and procedures, and distributed, local teams that define, develop and implement specific solutions for individual risk units / risk types and/or systems.

The short & medium term actions to be defined for phase 2 depend on the results of the gap analysis and the result of the alignment of in-flight projects. Once developed and implemented, it is a requirement that the deliverables are monitored and long-term actions are prepared to remain compliant.

The implementation of BCBS 239 will not guarantee long-term success for the bank, nor will it be the final step. The next section details briefly upcoming and mid-term changes to risk-data aggregation capabilities and risk-reporting practices that will require changes beyond the BCBS 239 principles.

BCBS 239 – The Future

The “Less is More” deregulation attitude towards risk management of the 1980s has been replaced by the “More and more, more is more” attitude of the period following the 2007 financial crisis. Contemporary risk management is in a state of flux, characterized by changing regulation, technical guidelines, requirements, governance, definitions and models. This has resulted in more data and more reports in ever-increasing detail for more supervisors.

Furthermore, continuing developments in connectivity, processing and storage have lead to unlimited access to commodity IT resources. This, in combination with advances in data science, machine learning, data mining, statistics and artificial intelligence, and an emphasis on forward-looking, predictive capabilities, will continue to transform and grow risk management. Ultimately, external and internal models will reduce each piece of data to measurable components, interpreting each data object in terms of numerous financial attributes. High-frequency trading (HFT) already provides a glimpse of the future of risk management. HFT has introduced global, real-time, automated market making/taking and arbitrage opportunities across multiple marketplaces without direct, manual interference.

A more immediate example of what to expect in the domain of risk-data aggregation is the FSB (Financial Stability Board) “data gaps initiative.” It implements a common data template to collect key granular data from G-SIBs about their assets and liabilities, to provide the authorities with a strong framework to assess interconnectedness between the banks themselves and with other institutions. In a recent paper ([Jenk14]), the FSB supported this initiative by introducing the concept of uniform representation and definition of key financial elements (standardization), such as a product, an entity and a contract (see Figure 6). The standardization should be domain agnostic, achieving an overarching standard that should be used across domains, ultimately achieving a single source for all risk types.

Figure 6. FSB standardization.

This initiative and others such as the EBA stress test and the ECB asset-quality review show that (risk) data aggregation and (risk) reporting are here to stay, and that adaptability is an essential characteristic in order to meet the requirements efficiently and effectively.

Conclusion

The story of Google Flu Trends in the introductory section shows the possibilities of applying new technology in combination with domain knowledge. The results may leave room for improvement. However, triangulation of (flu) systems increases the accuracy of all flu registration systems. Furthermore, due to the hiccup, Google Flu Trends has gained visibility and has introduced a new audience to the possibilities of its technology.

The introduction of new regulation and principles for risk-data aggregation impacts the majority of banks. The main difference between the BCBS 239 standard and previous standards is its overarching objective and the fact that compliance is required and assessed by the supervisor. A self-assessment will show the strengths and weaknesses of a bank’s current data aggregation capabilities and risk-reporting practices. By approaching the topic proactively, banks can identify the intersections between the standard and their own business and operating model, and develop an adaptable solution that meets the current regulation while embracing technological advances.