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 validation, testing 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;”
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.
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 Infra||P2||R19||Data taxonomies||X|
|Data Arch and IT Infra||P2||R20||Responsibilities on ownership, quality of data and information||X|
|Data Arch and IT Infra||P2||R21||Role of the business owner||X|
|Data Arch and IT Infra||P2||R22||Adequate controls through the life cycle of data||X|
|Rist data aggregation capabilities|
|Accuracy and Integrity||P3||R25||Controls as to accounting data||X|
|Accuracy and Integrity||P3||R26||Mitigants and controls for manual processes||X|
|Accuracy and Integrity||P3||R27||Reconciliation with different sources||X|
|Accuracy and Integrity||P3||R29||Dictionary||X|
|Accuracy and Integrity||P3||R30||Balance between automated and manual systems||X|
|Accuracy and Integrity||P3||R32||Measurement and monitoring processes||X|
|Accuracy and Integrity||P3||R33||For all material risks||X|
|Accuracy and Integrity||P3||R34||Process to rectify poor data quality||X|
|Completeness||P4||R37||Process to identify groups to report risks||X|
|Completeness||P4||R38||All material data included||X|
|Completeness||P4||R39||Documentation of approaches to aggregate exposures||X|
|Completeness||P4||R40||Measurement and monitoring of all material risk data||X|
|Completeness||P4||R41||Exceptions properly identified and explained||X|
|Completeness||P4||R42||Process to rectify completeness issues||X|
|Risk reporting practices|
|Accuracy||P7||R56||Requirements and processes to reconcile reports to risk data||X|
|Accuracy||P7||R57||Automated and manual edit and reasonableness checks||X|
|Accuracy||P7||R58||Integrated procedure for identifying and reporting data errors||X|
|Accuracy||P7||R59||Accuracy and requirements for regular and stress cases||X|
|Clarity and Usefulness||P9||R74||Inventory and classification of risk data items||X|
“Integrated procedures for identifying, reporting and explaining data errors or weaknesses in data integrity via exceptions reports.” BCBS-239