Report by ISITC Europe to demystify BCBS 239
Author: Martin, Sexton, Principal Consultant at London Market Systems
How many financial institutions could identify their aggregated risk to Lehman Brother on D-Day, or even a week after 15th September 2008? This highlighted a common weakness, as financial institutions struggled to discover and roll up exposures to complex bank organisational hierarchies, in a timely manner. To avoid the possibility of a repeat of another systemic meltdown, the FSB initiated an investigation that subsequently resulted in the creation of BCBS 239. Titled “Principles for Effective Risk Data Aggregation and Risk Reporting” this regulation sets out the principles to provide financial institutions with the capability to accurately assess and manage risk. These requirements are to be enforced by the associated regulator where the SIFI resides (e.g. the Bank of England for UK based financial institutions).
The aim was for banks identified as G-SIBs to comply with BCBS 239 by January 2016, whilst D-SIBs should aim to adhere to the principles within three years thereafter. The G-SIB deadline has now passed and it is understood that a number of G-SIBs are still non-compliant and for those a more realistic compliance date to aim for is January 2019, for all the banks operations, globally. For G-SIBs, a federated operating model approach to achieve adherence is a preferred option, based on legal entities in each of the jurisdictions within which the bank operates. Such an approach provides the organisation with opportunity of a phased rollout whilst keeping the regulators onboard.
This paper takes a peek into regulation 239, examining particular areas of focus and possible outcomes resulting from compliance.
BCBS 239 focuses on the governance and ownership of risk and to achieve these goals there is an appreciation that the deployment of the appropriate IT and data architectures is required.
The regulation is not prescriptive and it is up to organisations to carefully interpret the principles to ensure compliance with BCBS 239. The 14 principles (summarised in Annex 2 of BCBS 239) fall under four main topics:
I. Overarching governance and infrastructure,
II. Risk data aggregation capabilities,
III. Risk reporting practices,
IV. Supervisory review, tools and cooperation.
The emphasis of this topic is on a strong governance framework, risk data architecture and IT infrastructure.
Principle 1: Governance – A bank’s risk data aggregation capabilities and risk reporting practices should be subject to strong governance arrangements consistent with other principles and guidance established by the Basel Committee.
Principle 2: Data architecture and IT infrastructure – A bank should design, build and maintain data architecture and IT infrastructure which fully supports its risk data aggregation capabilities and risk reporting practices not only in normal times but also during times of stress or crisis, while still meeting the other Principles.
This principle along with principles specified in the topic ” II. Risk data aggregation capabilities” are considered more onerous than the others, therefore a section titled, “Making effective use of an Enterprise-wide Data Architecture” has been included within this report to examine an appropriate approach.
The focus of this topic is on data aggregation to support the timely creation of ad-hoc risk management reporting support requests for both internal and external supervisory requirements.
Principle 3: Accuracy and Integrity – A bank should be able to generate accurate and reliable risk data to meet normal and stress/crisis reporting accuracy requirements. Data should be aggregated on a largely automated basis so as to minimise the probability of errors.
Principle 4: Completeness – A bank should be able to capture and aggregate all material risk data across the banking group. Data should be available by business line, legal entity, asset type, industry, region and other groupings, as relevant for the risk in question, that permit identifying and reporting risk exposures, concentrations and emerging risks.
Principle 5: Timeliness – A bank should be able to generate aggregate and up-to-date risk data in a timely manner while also meeting the principles relating to accuracy and integrity, completeness and adaptability. The precise timing will depend upon the nature and potential volatility of the risk being measured as well as its criticality to the overall risk profile of the bank. The precise timing will also depend on the bank-specific frequency requirements for risk management reporting, under both normal and stress/crisis situations, set based on the characteristics and overall risk profile of the bank.
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.
Accurate, complete and timely data is a foundation for effective risk management.
Principle 7: Accuracy – Risk management reports should accurately and precisely convey aggregated risk data and reflect risk in an exact manner. Reports should be reconciled and validated.
Principle 8: Comprehensiveness – Risk management reports should cover all material risk areas within the organisation. The depth and scope of these reports should be consistent with the size and complexity of the bank’s operations and risk profile, as well as the requirements of the recipients.
Principle 9: Clarity and usefulness – Risk management reports should communicate information in a clear and concise manner. Reports should be easy to understand yet comprehensive enough to facilitate informed decision-making. Reports should include an appropriate balance between risk data, analysis and interpretation, and qualitative explanations. Reports should include meaningful information tailored to the needs of the recipients.
Principle 10: Frequency – The board and senior management (or other recipients as appropriate) should set the frequency of risk management report production and distribution. Frequency requirements should reflect the needs of the recipients, the nature of the risk reported, and the speed at which the risk can change, as well as the importance of reports in contributing to sound risk management and effective and efficient decision-making across the bank. The frequency of reports should be increased during times of stress/crisis.
Principle 11: Distribution – Risk management reports should be distributed to the relevant parties and while ensuring confidentiality is maintained.
BCBS 239 highlights that supervisors have an important role to play in continuously monitoring, reviewing compliance and managing change to support the principles going forward.
Principle 12: Review – Supervisors should periodically review and evaluate a bank’s compliance with the eleven Principles above.
Principle 13: Remedial actions and supervisory measures – Supervisors should have and use the appropriate tools and resources to require effective and timely remedial action by a bank to address deficiencies in its risk data aggregation capabilities and risk reporting practices. Supervisors should have the ability to use a range of tools, including Pillar 2.
Principle 14: Home/host cooperation – Supervisors should cooperate with relevant supervisors in other jurisdictions regarding the supervision and review of the Principles, and the implementation of any remedial action if necessary.
This regulation puts an organisation’s data architecture under the spotlight and the need to provide the capability to support risk reporting.
It is not uncommon for an organisation to have multiple information silos, either by asset classes, business units or business functions, or a combination of all three. In such scenarios the creation of an overarching enterprise-wide risk data architecture may be appropriate. Most organisations already have the associated documents and models in some form. For example, a number of G-SIBs have database and messaging frameworks based around FpML, FIX or ISO 20022 and corporate-wide data dictionaries. In some instances, organisations have created semantic models, that may be based on FIBO. All of which can form the basis of an enterprise-wide risk data architecture.
A solid Data Architecture forms the backbone of any Data Quality (DQ) framework. Ensuring systems use consistent cleansed data, data formats and naming conventions, however that is not the whole story. The models need to have an appreciation of the lifecycle of data items within a key object. For example, a counterparty’s name, registered address, LEI, BIC, trading eligibility, their position within a corporate hierarchy , all may have different valid start/end dates and are independent of the entity itself. Traceability and provenance should also be supported by the Data Architecture, along with the data lineages. It is worth highlighting that it is not just about effectively modelling party data. For example, for each trade there is a need to identify whether the trade status is open and the bank still has an exposure to the deal.
Is there any light at the end of the tunnel?
If one thinks of the exercise as a complete overhaul of the organisation’s data architecture, then achieving adherence is extremely onerous. Nonetheless, if one focuses on key data elements to support aggregated risk, then compliance should be achievable. It is not uncommon for business owners to supply a list of hundreds of data items which they consider to key for risk management. Nonetheless, with a bit of analysis, a concise set of elements should be sufficient to achieve the end goal.
BCBS 239 provides the principles to create a framework which financial institutions, in all forms, should aim for. It should be considered an important value-add to all organisation’s governance andIT strategies.
Organisations should consider this as an opportunity rather than a regulatory burden. Upon compliance to BCBS 239, financial institutions will be in a strong position to make better strategic decisions, optimise capital and it provides the capability to outsource business units/functions and effectively deploy Distributed Ledger Technologies (for further information on the subject check out, ISITC Europe’s Blockchain DLT Working Group). With the appropriate Data Architecture it should also be able to support the requirements of the likes of MiFID II/MiFIR, General Data Protection Regulation (GDPR), among others. Nonetheless, to achieve BCBS 239 compliance, in a timely manner, it is important to only focus on the key risk data elements, otherwise there is a greater risk of failing to deliver.
Given the complexity and autonomy of business units within a G-SIB, it may be appropriate to adopt a federated operating model approach based on jurisdictions and agree timelines with the local regulator accordingly.
The crash of 2008 saw organisations having difficulties identifying exposures to counterparties in a timely manner, once the principles of BCBS 239 are implemented, SIFIs should be able to identify an exposure to an organisation in distress, at a click of the mouse button.
Glossary
There are a number of terms, abbreviations and acronyms used in the world of BCBS 239:
| BCBS 239 | Basel Committee on Banking Supervision’s regulation number 239. |
| Data Architecture | Or Model Driven Architecture (MDA) is an approach composed of models, policies, rules and standards used to support the governance and dissemination of information in a consistent and unambiguous manner. This would normally comprise semantic, business, logical and physical models (database and message). |
| DLT | Distributed Ledger Technologiesis a framework that allows for the synchronization of information, in a consistent form across multiple applications, sites and institutions without the need to transform and reinterpret. Removing the risk of misunderstandings and breaks in the trading lifecycle requiring manual intervention. |
| D-SIB | Domestic Systemically Important Banks are financial institutions that do not fit within the G-SIB criteria, however they are of sufficient domestic systemic importance making them subject to the stringent annual stress testing. |
| FSB | Financial Stability Board (FSB) is an international body, comprising of global governmental, central banks and regulator representatives, that monitors and makes recommendations about the global financial system. It successfully facilitated the creation of the processes and organisational structure to support the LEI, along with the creation of BCBS 239 regulation. |
| G-SIB | A Global Systemically Important Bank (G-SIB) is a bank that is normally referred to as a tier 1 financial institution. This categorisation is based on a number of criteria: size, cross-jurisdiction activity, complexity, and substitutability. The G-SIB must maintain a higher capital level – capital surcharge – compared to other banks. . The list of G-SIBs is published annually by the Financial Stability Board (FSB). |
| PERDARR | Principles for Effective Risk Data Aggregation and Risk Reporting, the title of BCBS regulation 239. |
| SIFI | A Systemically Important Financial Institution is a bank, insurance company or other financial institution whose failure could trigger a economic financial crisis. Such institutions are broken down in to two main categories (G-SIB and D-SIB). Basically, these are organisations referred to as “Too big to fail”. |
- Introduction
-
Report by ISITC Europe to demystify BCBS 239
Author: Martin, Sexton, Principal Consultant at London Market Systems
How many financial institutions could identify their aggregated risk to Lehman Brother on D-Day, or even a week after 15th September 2008? This highlighted a common weakness, as financial institutions struggled to discover and roll up exposures to complex bank organisational hierarchies, in a timely manner. To avoid the possibility of a repeat of another systemic meltdown, the FSB initiated an investigation that subsequently resulted in the creation of BCBS 239. Titled “Principles for Effective Risk Data Aggregation and Risk Reporting” this regulation sets out the principles to provide financial institutions with the capability to accurately assess and manage risk. These requirements are to be enforced by the associated regulator where the SIFI resides (e.g. the Bank of England for UK based financial institutions).
The aim was for banks identified as G-SIBs to comply with BCBS 239 by January 2016, whilst D-SIBs should aim to adhere to the principles within three years thereafter. The G-SIB deadline has now passed and it is understood that a number of G-SIBs are still non-compliant and for those a more realistic compliance date to aim for is January 2019, for all the banks operations, globally. For G-SIBs, a federated operating model approach to achieve adherence is a preferred option, based on legal entities in each of the jurisdictions within which the bank operates. Such an approach provides the organisation with opportunity of a phased rollout whilst keeping the regulators onboard.
This paper takes a peek into regulation 239, examining particular areas of focus and possible outcomes resulting from compliance.
- BCBS 239 Composition
-
BCBS 239 focuses on the governance and ownership of risk and to achieve these goals there is an appreciation that the deployment of the appropriate IT and data architectures is required.
The regulation is not prescriptive and it is up to organisations to carefully interpret the principles to ensure compliance with BCBS 239. The 14 principles (summarised in Annex 2 of BCBS 239) fall under four main topics:
I. Overarching governance and infrastructure,
II. Risk data aggregation capabilities,
III. Risk reporting practices,
IV. Supervisory review, tools and cooperation.
- I. Overarching governance and infrastructure
-
The emphasis of this topic is on a strong governance framework, risk data architecture and IT infrastructure.
Principle 1: Governance – A bank’s risk data aggregation capabilities and risk reporting practices should be subject to strong governance arrangements consistent with other principles and guidance established by the Basel Committee.
Principle 2: Data architecture and IT infrastructure – A bank should design, build and maintain data architecture and IT infrastructure which fully supports its risk data aggregation capabilities and risk reporting practices not only in normal times but also during times of stress or crisis, while still meeting the other Principles.
This principle along with principles specified in the topic ” II. Risk data aggregation capabilities” are considered more onerous than the others, therefore a section titled, “Making effective use of an Enterprise-wide Data Architecture” has been included within this report to examine an appropriate approach.
- II. Risk data aggregation capabilities
-
The focus of this topic is on data aggregation to support the timely creation of ad-hoc risk management reporting support requests for both internal and external supervisory requirements.
Principle 3: Accuracy and Integrity – A bank should be able to generate accurate and reliable risk data to meet normal and stress/crisis reporting accuracy requirements. Data should be aggregated on a largely automated basis so as to minimise the probability of errors.
Principle 4: Completeness – A bank should be able to capture and aggregate all material risk data across the banking group. Data should be available by business line, legal entity, asset type, industry, region and other groupings, as relevant for the risk in question, that permit identifying and reporting risk exposures, concentrations and emerging risks.
Principle 5: Timeliness – A bank should be able to generate aggregate and up-to-date risk data in a timely manner while also meeting the principles relating to accuracy and integrity, completeness and adaptability. The precise timing will depend upon the nature and potential volatility of the risk being measured as well as its criticality to the overall risk profile of the bank. The precise timing will also depend on the bank-specific frequency requirements for risk management reporting, under both normal and stress/crisis situations, set based on the characteristics and overall risk profile of the bank.
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.
- III. Risk reporting practices
-
Accurate, complete and timely data is a foundation for effective risk management.
Principle 7: Accuracy – Risk management reports should accurately and precisely convey aggregated risk data and reflect risk in an exact manner. Reports should be reconciled and validated.
Principle 8: Comprehensiveness – Risk management reports should cover all material risk areas within the organisation. The depth and scope of these reports should be consistent with the size and complexity of the bank’s operations and risk profile, as well as the requirements of the recipients.
Principle 9: Clarity and usefulness – Risk management reports should communicate information in a clear and concise manner. Reports should be easy to understand yet comprehensive enough to facilitate informed decision-making. Reports should include an appropriate balance between risk data, analysis and interpretation, and qualitative explanations. Reports should include meaningful information tailored to the needs of the recipients.
Principle 10: Frequency – The board and senior management (or other recipients as appropriate) should set the frequency of risk management report production and distribution. Frequency requirements should reflect the needs of the recipients, the nature of the risk reported, and the speed at which the risk can change, as well as the importance of reports in contributing to sound risk management and effective and efficient decision-making across the bank. The frequency of reports should be increased during times of stress/crisis.
Principle 11: Distribution – Risk management reports should be distributed to the relevant parties and while ensuring confidentiality is maintained.
- IV. Supervisory review, tools and cooperation
-
BCBS 239 highlights that supervisors have an important role to play in continuously monitoring, reviewing compliance and managing change to support the principles going forward.
Principle 12: Review – Supervisors should periodically review and evaluate a bank’s compliance with the eleven Principles above.
Principle 13: Remedial actions and supervisory measures – Supervisors should have and use the appropriate tools and resources to require effective and timely remedial action by a bank to address deficiencies in its risk data aggregation capabilities and risk reporting practices. Supervisors should have the ability to use a range of tools, including Pillar 2.
Principle 14: Home/host cooperation – Supervisors should cooperate with relevant supervisors in other jurisdictions regarding the supervision and review of the Principles, and the implementation of any remedial action if necessary.
- Making effective use of an Enterprise-wide Data Architecture
-
This regulation puts an organisation’s data architecture under the spotlight and the need to provide the capability to support risk reporting.
It is not uncommon for an organisation to have multiple information silos, either by asset classes, business units or business functions, or a combination of all three. In such scenarios the creation of an overarching enterprise-wide risk data architecture may be appropriate. Most organisations already have the associated documents and models in some form. For example, a number of G-SIBs have database and messaging frameworks based around FpML, FIX or ISO 20022 and corporate-wide data dictionaries. In some instances, organisations have created semantic models, that may be based on FIBO. All of which can form the basis of an enterprise-wide risk data architecture.
A solid Data Architecture forms the backbone of any Data Quality (DQ) framework. Ensuring systems use consistent cleansed data, data formats and naming conventions, however that is not the whole story. The models need to have an appreciation of the lifecycle of data items within a key object. For example, a counterparty’s name, registered address, LEI, BIC, trading eligibility, their position within a corporate hierarchy , all may have different valid start/end dates and are independent of the entity itself. Traceability and provenance should also be supported by the Data Architecture, along with the data lineages. It is worth highlighting that it is not just about effectively modelling party data. For example, for each trade there is a need to identify whether the trade status is open and the bank still has an exposure to the deal.Is there any light at the end of the tunnel?
If one thinks of the exercise as a complete overhaul of the organisation’s data architecture, then achieving adherence is extremely onerous. Nonetheless, if one focuses on key data elements to support aggregated risk, then compliance should be achievable. It is not uncommon for business owners to supply a list of hundreds of data items which they consider to key for risk management. Nonetheless, with a bit of analysis, a concise set of elements should be sufficient to achieve the end goal.
- Final Thoughts
-
BCBS 239 provides the principles to create a framework which financial institutions, in all forms, should aim for. It should be considered an important value-add to all organisation’s governance andIT strategies.
Organisations should consider this as an opportunity rather than a regulatory burden. Upon compliance to BCBS 239, financial institutions will be in a strong position to make better strategic decisions, optimise capital and it provides the capability to outsource business units/functions and effectively deploy Distributed Ledger Technologies (for further information on the subject check out, ISITC Europe’s Blockchain DLT Working Group). With the appropriate Data Architecture it should also be able to support the requirements of the likes of MiFID II/MiFIR, General Data Protection Regulation (GDPR), among others. Nonetheless, to achieve BCBS 239 compliance, in a timely manner, it is important to only focus on the key risk data elements, otherwise there is a greater risk of failing to deliver.
Given the complexity and autonomy of business units within a G-SIB, it may be appropriate to adopt a federated operating model approach based on jurisdictions and agree timelines with the local regulator accordingly.
The crash of 2008 saw organisations having difficulties identifying exposures to counterparties in a timely manner, once the principles of BCBS 239 are implemented, SIFIs should be able to identify an exposure to an organisation in distress, at a click of the mouse button.
- Glossary
-
Glossary
There are a number of terms, abbreviations and acronyms used in the world of BCBS 239:
BCBS 239 Basel Committee on Banking Supervision’s regulation number 239. Data Architecture Or Model Driven Architecture (MDA) is an approach composed of models, policies, rules and standards used to support the governance and dissemination of information in a consistent and unambiguous manner. This would normally comprise semantic, business, logical and physical models (database and message). DLT Distributed Ledger Technologiesis a framework that allows for the synchronization of information, in a consistent form across multiple applications, sites and institutions without the need to transform and reinterpret. Removing the risk of misunderstandings and breaks in the trading lifecycle requiring manual intervention. D-SIB Domestic Systemically Important Banks are financial institutions that do not fit within the G-SIB criteria, however they are of sufficient domestic systemic importance making them subject to the stringent annual stress testing. FSB Financial Stability Board (FSB) is an international body, comprising of global governmental, central banks and regulator representatives, that monitors and makes recommendations about the global financial system. It successfully facilitated the creation of the processes and organisational structure to support the LEI, along with the creation of BCBS 239 regulation. G-SIB A Global Systemically Important Bank (G-SIB) is a bank that is normally referred to as a tier 1 financial institution. This categorisation is based on a number of criteria: size, cross-jurisdiction activity, complexity, and substitutability. The G-SIB must maintain a higher capital level – capital surcharge – compared to other banks. . The list of G-SIBs is published annually by the Financial Stability Board (FSB). PERDARR Principles for Effective Risk Data Aggregation and Risk Reporting, the title of BCBS regulation 239. SIFI A Systemically Important Financial Institution is a bank, insurance company or other financial institution whose failure could trigger a economic financial crisis. Such institutions are broken down in to two main categories (G-SIB and D-SIB). Basically, these are organisations referred to as “Too big to fail”.
Author: Martin, Sexton, Principal Consultant at London Market Systems