BCBS 239 Compliance Validation Framework

One of the biggest lessons of the global financial crisis that started in the year 2007 was the need to improve the performance of the banks’ risk IT and data management. One problem was that some financial services firms could not aggregate risks they were accumulating quickly and accurately, and, as a result, they could not manage and mitigate them effectively. Also, the quality of the risk data prevented timely identification of the magnitude of risks.

The Bank for International Settlements, resp. its part, the Basel Committee for Banking Supervision (BCBS), have undertaken a number of actions. The strengthening of the existing Basel II frameworks for the supervision and the management of the banks’ risk, also known as Basel III framework, is one of the BCBS’s most significant arrangements. It is not possible to achieve an effective overall risk management without adequate risk data management and risk IT architectures though. Being well aware of that, the BCBS issued a set of 14 requirements, Principles for effective risk data aggregation and risk reporting.

All G-SIBs should meet these 14 requirements (principles) by January 2016. National supervisors may nevertheless choose to apply the Principles to a wider range of banks. For instance, German regulatory authorities plan to incorporate the BCBS’s principles into the local law “Minimum Requirements for Risk Management“ (MaRisk) in year 2015.

In accordance to the banks’ risk governance guidelines the banks are obliged to provide the validation of their compliance with the Principles. The paragraph 29 of the Principle 1 defines this validation activity in the following way:

“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 Principles in this document. 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 (in particular the so-called “second line of defence” within the bank’s internal control system), 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. Furthermore, validation should be conducted separately from audit work to ensure full adherence to the distinction between the second and third lines of defence, within a bank's internal control system.”

Since the bank’s board is finally responsible for the risk appetite of the bank it should be aware of limitations in the risk data aggregation processes at any time. The paragraph 31 of the Principles defines: “The board should also be aware of the bank’s implementation of, and ongoing compliance with the Principles set out in this document.”

Supervisors will have escalation procedures in place to require more stringent or accelerated remedial action in the event that the bank does not adequately address the deficiencies identified.

This guidance conducts the banks establishing new strong compliance validation function to achieve comprehensive, regular and timely monitoring of the compliance to the Principles. To define the compliance validation function, the banks have to deal with and find the right answer for the following topics:


All above mentioned topics are part of our BCBS 239 compliance validation framework.

First, the banks should devote right stakeholders for the compliance validation function. Which business unit(s) should be responsible for the validation? Risk management unit, compliance department or IT operations? Which roles and which skill-set should the validation team master?

Second, it is important to define the set of topics which are subject of validation. The set of topics has to cover all 14 principles and all components (policies, processes) covered by them.

Different validation methods and procedures will be used for different validation actions. The degree of the automation varies across the portfolio of the validation subjects. The frequency of various validation steps is another important aspect to consider; on one side the timely overall compliance status will be required, on the other hand the efforts (costs) of the validation function have to be kept within given bank’s resources.

The degree of the compliance with the BCBS 239 principles as well as plenty of detailed reports is being expected as the outcome of the validation. While the overall compliance report reflects the preparedness of the bank to keep on the BCBS’s principles, the detailed reports help to better manage the gaps as well to trigger or support further improvement efforts in the domain of risk data processing.

One important decision the banks will have to make is how effectively the IT infrastructure can be mitigated to achieve comprehensive as well as efficient validation and monitoring platform. Is the in-house development always the best and most efficient way?

ADASTRA's set of methodologies together with the powerful validation and reporting engine help the banks to improve their compliance validation capabilities as well as to keep the costs of the validation function as low as possible.