The publication, which is 28 pages long is available here:
If you work in a large bank and are not familiar with BCBS 239, it may behoove you to read it. If you work in risk management, data warehousing or compliance, you're probably already familiar with it. But if you work in the back office, middle office, or a business line and are struggling with the challenge of unavailable, incomplete, or undocumented data, BCBS 239 can be an important tool in getting your requests taken seriously by your institution's executive management, or data management and IT bureaucracy.
Who wrote BCBS 239?
BCBS 239 was written by a committee of representatives from the financial regulators in 13 countries. That includes the FRB and OCC in the US, the FSA in UK, and the JFSA and BOJ in Japan. If you work in a large financial institution, you probably already know the influence these groups have over the project portfolio and purse-strings of your bank.
What does BCBS 239 say?
BCBS 239 lays out 14 principles about risk data, summarized in 4 groups, and further subdivided into 89 paragraphs. There is a summary of the principles in annex 2 of the document. But I found that some of the most interesting and useful language is in the detail itself.
BCBS 239 is surprisingly direct in saying what many line-level practitioners have been saying and thinking for years: it shouldn't be so damned hard to get the information I need from my bank's systems on a daily basis. And I should be able to depend on the accuracy and completeness of that information. Unfortunately, in today's world of split-second searches over billions of websites and self-driving cars, that is not the reality in most large financial institutions.
BCBS spells out principles that should be no-brainers. But they are often not followed today. It's good that the authorities have spelled them out, so that they can be used as ammunition by business users who actually need good data to get a job done.
Here are some of my favorite "no-brainers" that I'm glad to see confirmed by the committee:
- "Controls surrounding risk data should be as robust as those applicable to accounting data."(Principle 3 Accuracy and Integrity, paragraph 36a).
- "Risk data should be reconciled with bank's sources, including accounting data where appropriate, to ensure that the risk data is accurate." (Principle 3 Accuracy and Integrity, paragraph 36c).
- "Supervisors expect banks' data to be materially complete, with any exceptions identified and explained." (Principle 4 Completeness, paragraph 43).
To me this means a bank must allocate and hold accountable actual staff to make sure the data in the data warehouse is correct and reconciled. Plenty of staff. Think how many people are dedicated to making sure the accounting data is correct: Comptrollers, Sarbanes-Oxley compliance people, internal auditors, etc. And the "risk data" is arguably more varied and complex than accounting data.
- "A bank should establish integrated data taxonomies and architecture across the banking group...." (Principle 2 Data architecture and IT infrastructure, paragraph 33)
- "A bank should develop an inventory and classification of risk data items which includes a reference to the concepts used to elaborate the reports." (Principle 9 Clarity & Usefulness, paragraph 67)
In other words, the data in the warehouse needs to be well-organized and documented--not just a mish-mash of incompatible records from different source systems.
- Principle 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.
- "A bank should routinely test its ability to produce accurate reports within established timeframes, particularly in a stress/crisis situation." (Principle 10, Frequency, paragraph 70)
- "Some position / exposure information may be needed immediately (intraday)...." (Principle 10, Frequency, paragraph 70)
In other words, it's not acceptable for IT to demand a project and special budget just to produce some reports for the business. The data must be available and usable in advance.
For years, those of us who work on the ground in financial institutions have heard statements from data practitioners about the strategic importance of data, and read vague statements of policy and principle from our data and IT organizations. But at the same time the actual data we see is often incomplete, poorly organized, or inaccurate, and the day to day tasks needed to clean up the mess are never prioritized.
BCBS 239 is a clear and straightforward document that tells G-SIBs and other financial institutions to actually use 21st century technology to deliver practical results. While it may be a challenge to implement at most banks, it is a challenge whose time has come.