Digitising risk data architecture reporting

Making reporting consistent

Can applying semantics make BCBS 239 reporting consistent and comparable across all regulatory bodies? Rupert Brown explores the options when best practice isn’t good enough…

Regulatory vagaries and the punitive fines make these tense times for bank risk officers. On the one hand, regulators are asking for a whole lot of architectural work to be done including using standard legal entity identifiers, but haven’t been too specific on what all the tasks should be. There are lots of hoops and moving parts.

This article will discuss how to report using a risk data architecture in a financial services institute that would meet the specifications set by the Basel Committee for Banking Supervision, and allow it to be objectively measured against a peer organisation.

Let’s remind ourselves what the BCBS requirements are:

• A bank should have in place a strong governance framework, risk data architecture and IT infrastructure.
• A bank should establish integrated data taxonomies and architecture across the banking group, which includes information on the characteristics of the data (metadata), as well as use of single identifiers and/or unified naming conventions for data including legal entities, counterparties, customers and accounts.
• A bank’s risk data aggregation capabilities and risk reporting practices should be fully documented and subject to high standards of validation. This validation should be independent and review the bank’s compliance with the BCBS Principles. The primary purpose of the independent validation is to ensure that a bank’s risk data aggregation and reporting processes are functioning as intended and are appropriate for the bank’s risk profile. Independent validation activities should be aligned and integrated with the other independent review activities within the bank’s risk management program, and encompass all components of the bank’s risk data aggregation and reporting processes. Common practices suggest that the independent validation of risk data aggregation and risk reporting practices should be conducted using staff with specific IT, data and reporting expertise.

Note the use of the term “independent validation”…

What is actually happening in practice is that each major institution’s regional banks are lobbying/negotiating with their local/regional regulators to agree on an initial form of compliance – typically as some form of MS Word or PowerPoint presentation to prove that that they have an understanding of their risk data architecture. One organisation might write a 100-page tome to show its understanding – and another might write just ten. The requirement is vague and the interpretation is subjective. Just what is adequate?

XBRL – the eXtensible Business Reporting Language – has become the dominant standard for most of the major regulatory reporting initiatives – behind each of the dialects is what is known as a data point model, i.e. all the key risk and other financial values that comprise the report. What if we could extend XBRL to report BCBS 239 compliance and be able then to compare each of the submissions produced by the banks?

This is an excerpt. The full article is available in the February 2016 edition of Banking Technology. Click here to read the magazine online.

To get your free introductory print copy, please register here.