It has now been more than three years since BIS published their paper back in 2013 in response to the financial crisis, with the snappy title of ‘BCBS239: Principles for effective risk data aggregation and risk reporting’ ¹. Since then, the world’s largest banks have worked towards the compliance deadline of 1 January 2016, but with only limited success.
At the recent Handelsblatt conference in Frankfurt, I was asked to present an update on the situation, and as of January 2017 only a single G-SIB out of 20 declared full compliance, with a further one due by March 2017 ². The other 18 are ‘in remediation’ requiring more work to be able to declare full compliance.
GFT have participated in many such regulatory programmes over the years, mostly for G-SIBS with large UK footprints, and based on this hard won experience we have derived approaches to delivering and sustaining compliance for BCBS239 and similar regulatory programmes.
Governance and IT infrastructure
Defining what are the key risks facing the institution (both financial and non-financial), and assigning board level accountability and responsibility for managing them is the starting point. Set at an enterprise level this gives the chief risk officer (CRO) and his supporting IT team the boundary of material risk to measure. This is applied through policies, standards and controls.
With BCBS239, the Enterprise IT infrastructure and architecture needs to support the core principles from front-to-back; including managing the all data, from the first system of record through to producing and delivering the required management reports.
Risk data aggregation
Many banks struggle to achieve the level of automation and straight through data management and control called for by the principles of the regulation – this needs to be integral to the processing of risk data, including measuring completeness, accuracy and timeliness, which in turn has to be reported to the consumers of the risk reports. Where complex analytics and modelling are required, (e.g. risk scenario and stress testing for capital and impairment modelling), this too often takes place outside of any formally supported IT infrastructure.
Maintaining the scope and improving the delivery of risk reports are also major challenges. Many banks produce hundreds of obsolete reports and struggle to adapt them to new and emerging risks. Delivering such reports in an appropriate and intuitive form for the end user is key – taking data and presenting it in a spreadsheet supported presentation is still far too common; adding time (and expense), and the need to quality check the process. Reporting should also include an external risk assessment, and include periodic reviews to ensure the reporting is still relevant.
In addition, many banks who can satisfactorily produce reports under ‘normal’ market conditions, struggle to be able to produce timely and relevant reporting in ‘crisis’ conditions. As such, the processes for reporting in crisis situations should be periodically reviewed and tested.
A better way?
The key to achieving compliance is to clearly define the capabilities, artefacts, processes and components required in order to do so. These should be traceable back to the principles, reviewed by senior management, and agreed. The key to achieving compliance with the principles is to build in automation and flexibility from the start, to allow risk data aggregation and reporting to adapt to new risks, as well as providing long term views of established risks and exposures. This approach must be integrated into all risk IT programmes, especially in multi-business, multi-jurisdictional firms. Tactical remediation (especially manual compensating controls) should be avoided, as such workarounds tend to persist and will prevent full compliance in the longer term. Building best practice into ongoing processes is important – compliance is then part of peoples’ roles, not an additional overhead, making ongoing ‘business-as-usual’ compliance achievable.
Being transparent regarding the state of compliance with the regulator is also important – as is ensuring that planning for compliance is properly resourced and funded, with clear and achievable milestones, where there is still work to be completed.
In essence the key factors in achieving BCBS239 compliance are to do good by:
- treating risk data aggregation and reporting seriously, building sound capabilities
- establishing a solid framework to assess the level of compliance at any point in time – this is the first thing regulators will ask for
- avoiding ‘just enough at the last minute’ approaches and ‘workarounds’
- …and improving from there onwards – continuous improvement!
GFT can and has helped firms at all stages of preparedness for BCBS239, from initial assessment of compliance through to managing remediation programmes. We apply innovative technological approaches for automating data governance, processing, quality assessment and use enterprise architecture tools to provide support, through to dashboard and reporting delivery.
For those firms who take such an approach to BCBS239, it will ultimately be possible to achieve compliance, do good and improve.