© 2019 SourceMedia. All rights reserved.

Beyond Governance in Finance: Why BCBS 239 Matters to You

In information technology, in its most general sense, we often see adoption of new paradigms in academia and the intelligence/defense complex first, then in finance, and finally passing into other areas of the economy. Because of this, it is always useful to keep an eye on what is happening in these more innovative sectors. For instance, many years ago relational databases and data modeling followed this pathway to widespread adoption. Today, there is demand for a new level of data governance in finance, which has been expressed in something called BCBS 239. There is a very good chance that BCBS 239 will break out into the rest of the economy. As such, it is worth a close look at what this regulation is and just why it matters to all data management professionals.

Data Governance in Finance

In conversing with Mike Atkin of the Enterprise Data Management Council in the fourth quarter of 2008, he remarked to me how finance professionals interested in data management were treated dismissively by financial regulators before the crisis, but were welcomed with open arms after it had struck. A sea change had occurred in the attitude of the regulators in the U.S., U.K., Europe and elsewhere. They recognized that they had not been able to predict the onset of the crisis because they did not have the right data at the right time in a form they could comprehend.

The regulators have become very serious about data management since. The Dodd-Frank Act in the U.S. had some rather vague language about data governance. However, it did specify the need to unambiguously recognize counterparties in trades. This led to the effort to have global Legal Entity Identifiers. In July 2012 the Bank for International Settlements sponsored a global meeting at the New York Federal Reserve which kicked this effort into high gear and began to involve the private sector in a very meaningful way. But the BIS had plans to go far beyond LEIs.

The BIS is sometimes described as the "central bank of central banks." It is based in Basel, Switzerland, and is made up of the central banks of individual countries from around the world. In the past, the somewhat-checkered record of the BIS sidelined it for a number of years, but it has now emerged as an important player in global financial regulation and as an instrument for operationalizing decisions of the G20 - a forum of 19 nations plus the European Union, that make up 80 percent of world trade.

The BIS works through a number of committees. One is the Basel Committee on Banking Supervision, often known simply as the Basel Committee or BCBS. Its mandate is to enhance the understanding of banking supervisory issues and the quality of banking supervision worldwide.

What is BCBS 239?

To our friends in manufacturing, health care, retail, pharmaceuticals, transportation, hospitality, telecommunications, etc., the point of this summary of global regulation is to show that we are looking at a global regulator that carries enormous weight - quite unlike anything we find in any other sector. And when it speaks about data governance, we should all listen.

In January 2013, the BCBS released a document entitled "Principles for effective risk data aggregation and risk reporting." Behind this rather inscrutable title lies a document of great importance in the history of data governance. The name of the file that contained the document was "bcbs239.pdf," which is why it is now referred to as "BCBS 239" rather than by its official title.

BCBS 239 contains 14 principles about data governance. The first 11 pertain to banks and are of general interest; the final three pertain to supervisors and need not detain us. The first 11 principles are as follows:

  1. Governance – A bank’s risk data aggregation capabilities and risk reporting practices should be subject to strong governance arrangements consistent with other principles and guidance established by the Basel Committee.
  2. Data architecture and IT infrastructure – A bank should design, build and maintain data architecture and IT infrastructure which fully supports its risk data aggregation capabilities and risk reporting practices not only in normal times but also during times of stress or crisis, while still meeting the other Principles.
  3. Accuracy and Integrity – A bank should be able to generate accurate and reliable risk data to meet normal and stress/crisis reporting accuracy requirements. Data should be aggregated on a largely automated basis so as to minimise the probability of errors.
  4. Completeness – A bank should be able to capture and aggregate all material risk data across the banking group. Data should be available by business line, legal entity, asset type, industry, region and other groupings, as relevant for the risk in question, that permit identifying and reporting risk exposures, concentrations and emerging risks.
  5. Timeliness – A bank should be able to generate aggregate and up-to-date risk data in a timely manner while also meeting the principles relating to accuracy and integrity, completeness and adaptability. The precise timing will depend upon the nature and potential volatility of the risk being measured as well as its criticality to the overall risk profile of the bank. The precise timing will also depend on the bank-specific frequency requirements for risk management reporting, under both normal and stress/crisis situations, set based on the characteristics and overall risk profile of the bank.
  6. Adaptability – A bank should be able to generate aggregate risk data to meet a broad range of on-demand, ad hoc risk management reporting requests, including requests during stress/crisis situations, requests due to changing internal needs and requests to meet supervisory queries.
  7. Accuracy - Risk management reports should accurately and precisely convey aggregated risk data and reflect risk in an exact manner. Reports should be reconciled and validated.
  8. Comprehensiveness - Risk management reports should cover all material risk areas within the organisation. The depth and scope of these reports should be consistent with the size and complexity of the bank’s operations and risk profile, as well as the requirements of the recipients.
  9. Clarity and usefulness - Risk management reports should communicate information in a clear and concise manner. Reports should be easy to understand yet comprehensive enough to facilitate informed decision-making. Reports should include meaningful information tailored to the needs of the recipients.
  10. Frequency – The board and senior management (or other recipients as appropriate) should set the frequency of risk management report production and distribution. Frequency requirements should reflect the needs of the recipients, the nature of the risk reported, and the speed, at which the risk can change, as well as the importance of reports in contributing to sound risk management and effective and efficient decision-making across the bank. The frequency of reports should be increased during times of stress/crisis.
  11. Distribution - Risk management reports should be distributed to the relevant parties while ensuring confidentiality is maintained.

The significance of all this is that if a bank operationalizes these principles for risk data, it can just as easily do it for master data, marketing data or any other class of data. And why stop with banks? If we maintain that data governance is commercially beneficial to an enterprise, then the operationalization of BCBS 239 should produce quantifiable benefits in the banks that adopt it. If this happens, then these principles will quickly spread to other sectors. Of course, this will be in a more general form that does not speak of "banks" or "risk," but more generally about "enterprises" and "data."
It is, therefore, a good idea for all data management professionals, whatever sector they are working in, to keep an eye on BCBS 239 and its future development. This global initiative may well have long-term implications far beyond finance.

For reprint and licensing requests for this article, click here.