BCBS 239

Focus on growing your business by governing and auditing your data to mitigate risk


Effectively Comply with risk data aggregation, data validation, and reconciliation requirements for BCBS 239

While the term BCBS 239 has a wide range of definitions based on who is asked and what principle, requirement or component is referred to. Basically, BCBS 239 can be understood as “risk data aggregation” and management of financial risks. Therefore with BCBS 239 banks’ information technology (IT) and data architectures are required to improve the ability to aggregate risk exposures and identify issues quickly and accurately at almost all levels within a bank and maintain a sound risk management system.

With the BCBS 239 banks will benefit in several ways – the resolvability of a bank will be improved; stronger capability and the status of the risk function to make sound judgments; gains in efficiency; the reduced probability of losses and enhanced strategic decision-making; and eventually increased profitability.

What is at the core of BCBS 239?

The banking industry has seen many regulations like SOX, CCAR, FINRA and even BASEL. But the BCBS 239 is special from a data management perspective. The BCBS 239 is the first document to precisely define data validation and reconciliation requirements. This requires risk teams to introduce new checks and controls for data processes as they relate to data aggregation and risk reporting.

The Basel Committee on Banking Supervision (BCBS), under the principles for effective risk data aggregation and risk reporting, expect banks to consider data accuracy requirements analogous to accounting materiality.

This elevates the data quality requirements from simple concepts like data profiling and customer address fixing to establishing data accounting standards from a business rules point of view.

Validation -The process by which the correctness (or not) of inputs, processing, and outputs is identified and quantified.”

Reconciliation -The process of comparing items or outcomes and explaining the differences.”

BCBS 239 -While there are fourteen (14) principles with several components in the BCBS 239 and no single product or process can fulfill the overreaching requirements. Our aim here is to focus on the data rules engine requirements and provide information and solutions related to data validation and reconciliation requirements.”

Following are some of the BCBS 239 Components related to data validation and reconciliation requirements:

“Controls surrounding risk data should be as robust as those applicable to accounting data.”

“Supervisors expect banks to consider accuracy requirements analogous to accounting materiality.”

“Reports should be reconciled and validated.”

“Risk data should be reconciled with bank’s sources, including accounting data where appropriate, to ensure that the risk data is accurate.”

“Supervisors expect a bank to consider precision requirements based on validationtesting or reconciliation processes and results.”

“A bank’s risk personnel should have sufficient access to risk data to ensure they can appropriately aggregate, validate and reconcile the data to risk reports.”

“Banks do not necessarily need to have one data model; rather, there should be robust automated reconciliation procedures where multiple models are in use.”

“Defined requirements and processes to reconcile reports to risk data”

“Automated and manual edit and reasonableness checks, including an inventory of the validation rules that are applied to quantitative information. The inventory should include explanations of the conventions used to describe any mathematical or logical relationships that should be verified through these validations or checks;”

BCBS 239

Why are we focusing on the Components related to data validation and reconciliation requirements?

We believe the data audit gap has not been effectively tackled or attended. A typical bank will have multiple systems, each system producing its own set of data and storing it in the database. This can also result in duplicate or redundant data in multiple systems. How does the bank know that the two or more systems have consistent data?

There will be thousands of batch –ETL jobs and real-time processes moving or copying data from one system to another. How does the bank know that the data has been transformed and loaded correctly by the ETL processes?

For risk data aggregation data has to be integrated from multiple systems into the aggregate risk data system. How can the bank be sure that the data is accurate?

How iCEDQ can Help?

There will be multiple databases and data models, there will be thousands of processes and so will be the requirement for data integration. We are proposing a data auditing rules engine that runs in parallel to the data processing system and continually provides the feedback on the data exceptions.

Data-audit-and-reconciliation-rules-engine - iCEDQ

Based on the Matrix below it is clear that a Data Audit and Reconciliation Rules Engine is essential for BCBS 239.

Overarching governance and infrastructure
Data Arch and IT InfraP2R19Data taxonomiesX
Data Arch and IT InfraP2R20Responsibilities on ownership, quality of data and informationX
Data Arch and IT InfraP2R21Role of the business ownerX
Data Arch and IT InfraP2R22Adequate controls through the life cycle of dataX
Rist data aggregation capabilities
Accuracy and IntegrityP3R25Controls as to accounting dataX
Accuracy and IntegrityP3R26Mitigants and controls for manual processesX
Accuracy and IntegrityP3R27Reconciliation with different sourcesX
Accuracy and IntegrityP3R29DictionaryX
Accuracy and IntegrityP3R30Balance between automated and manual systemsX
Accuracy and IntegrityP3R32Measurement and monitoring processesX
Accuracy and IntegrityP3R33For all material risksX
Accuracy and IntegrityP3R34Process to rectify poor data qualityX
CompletenessP4R37Process to identify groups to report risksX
CompletenessP4R38All material data includedX
CompletenessP4R39Documentation of approaches to aggregate exposuresX
CompletenessP4R40Measurement and monitoring of all material risk dataX
CompletenessP4R41Exceptions properly identified and explainedX
CompletenessP4R42Process to rectify completeness issuesX
Risk reporting practices
AccuracyP7R56Requirements and processes to reconcile reports to risk dataX
AccuracyP7R57Automated and manual edit and reasonableness checksX
AccuracyP7R58Integrated procedure for identifying and reporting data errorsX
AccuracyP7R59Accuracy and requirements for regular and stress casesX
Clarity and UsefulnessP9R74Inventory and classification of risk data itemsX

“Integrated procedures for identifying, reporting and explaining data errors or weaknesses in data integrity via exceptions reports.” BCBS-239

Use Cases