Tips to Ensure BCBS 239 Compliance

Meeting BCBS 239 obligations can be daunting. After the Global Financial Crisis of 2007/2008 there was a collective recognition that banks were lacking in capability (and willingness?) to manage their operational risks effectively. The level of this mismanagement is hard to accurately quantify, but we can look at the fundamental flaws that have been identified, and hypothesise & rationalise the (very) likely reasons for the failures, and suggest steps to better understand remedy.

While the heavily siloed structure of the vast majority of financial institutions led to fundamental issues with how risk across all-of-business was seen – it wasn’t – there was also negligence from many organisations in the guise of complete absence of any appreciable risk management framework that pulled risk data together to present for proper decision-making.

This lack of risk data aggregation coupled with poor risk data reporting architecture spurred the Basel Committee on Banking Supervision to develop additional principles injected into Basel II – BCBS 239.

 

“One of the most significant lessons learned from the global financial crisis that began in 2007 was that banks’ information
technology (IT) and data architectures were inadequate to support the broad management of financial risks. Many banks
lacked the ability to aggregate risk exposures and identify concentrations quickly and accurately at the bank group level,
across business lines and between legal entities.”

– BCBS Principles for Effective Risk Data Aggregation & Risk Reporting

 

Like most regulatory measures, BCBS 239 is focused on the net-positive outcome from adhering to such measures being introduced. And as arduous as it may be, with a cohesive and coordinated plan, there are enormous ancillary benefits that in most cases would justify implementation anyway.

 

 

 

 

Major Obstacles

It is incredibly challenging for many organisations to meet the expectations for BCBS 239 due to several key challenges:

• Governance. There must be strong governance procedures in place. Risks to data quality must be addressed at the Board level.

• Verification. Data and reporting on risk must be reconciled and independently validated.

• The data architecture must be documented. Processes, controls, roles and responsibilities, data items, identifiers, and reporting must all be specified and documented completely. Risk data’s lineage across the data lifecycle must be thoroughly comprehended.

• Flexibility in aggregation. The structure of the group should not obstruct the organisation’s ability to aggregate data. At the geographical/regional, legal entity, industry, asset class, and business line levels, data must be able to be aggregated.

• Adaptability. Finance organisations must set up flexible infrastructure and processes to generate timely ad hoc reporting in both stressed and regular situations.

• Efficiency of risk data aggregation activities. Any technological or legal constraints that impair risk data aggregation must be identified and addressed by the Board and senior management. When a bank relies on manual procedures and desktop programmes, adequate safeguards and controls must be in place.

• Patient diligence. The approach to compliance must be sustainable since it requires an enterprise-wide awareness of the data architecture and the ability to adapt to change.

• Adaptability to change. Firms must be able to analyse the impact of regulatory changes, new products, process changes, and IT projects on risk data aggregation and reporting capacity.

 

Considerations for Remedy

NovoFinity recommend several critical consideration in any approach:

Actively Maintain the General Corporate Understanding

• Information is accessible to key stakeholders, such as decision-makers and independent validators.
• All data is still the responsibility of the data and process owners.

 

Create and Evangelise Transparency

• Through collaboration between business and IT owners, information about the data landscape must become corporate understanding that is ingrained and actionable.
• Data items must be contextualised in terms of people, policies, and procedures in order to be useful.
• Throughout the data lifecycle, from data gathering through reporting, data lineage and data aggregation must be transparent and clear to all stakeholders.

 

Gain Visibility over Data Aggregation

• Risk data components, identities, and definitions — both in standard form and as they are represented in specific systems.
• At each point of the data collection and reporting lifecycle, governance identifies the roles & responsibilities for risk data.
• Infrastructure refers to the systems that generate, transform, and store data.
• Processes for data transformation and aggregation, including manual involvement.
• Coverage and substance, as well as dissemination and goal, are all important aspects of reporting.