Banks Struggle with BCBS 239

There is a very sobering thought about risk management capability and its dependency on information technology units in banks that goes along the following lines: If your data, model and reporting systems are lacking, so will your response to risk management. It's that simple or perhaps not as we shall see with BCBS 239 regulations.

Recent Developments

The Basel Committee on Banking Supervision has recently published an update on where banks are at with their BCBS 239 compliance [LINK] noting that only three banks are fully compliant with the principles under the Risk Data Aggregation requirement.

"Banks have found it challenging to comply with the Principles, due mainly to the complexity and interdependence of IT improvement projects. As a result, the expected date of compliance has slipped back for many banks."

BCBS 239 Progress Update | Bank for International Settlements

Given the deadline for completing BCBS 239 was actually in 2016 and the number of banks that are struggling with the requirements is enough to say that troubles are likely to persist.

"Banks should develop clear roadmaps to achieve full compliance with the Principles and comply with them on an ongoing basis."

BCBS 239 Progress Update | Bank for International Settlements

There are fourteen straightforward principles to comply with that should be seen as features across a single functional system. What I find most amazing is that very few Risk IT analysts are able to conceptualize the simplicity or even the importance of this project which is to deliver nothing more than risk management oversight at the end of the day.

Many banks are listing the time needed to address IT legacy issues, as well as the complexity and interdependence of IT improvement projects as being significant hurdles that are preventing them from moving forwards with BCBS 239. Instead of correcting old systems, IT departments would be better off merely porting data to a new service and connecting that to a risk management dashboard. Real technical difficulties around the project should originate from data aggregation modelling, stress testing methods and data reconciliation approaches, not toying with legacy data systems.

The original BCBS 239 requirement [LINK]

What NOT to do with BCBS 239 ~ Try to build new functionality into legacy systems in an effort to be compliant with the standard or worse, just outsource the requirements to an IT vendor.

What to do for BCBS 239 ~ Build a dashboard with drill-down capabilities and focus on integrated factor analysis and forecasting decomposition with confidence bands. Attempting to develop a scenario analysis model that can assess the net risk from the introduction of new products is a worthy but difficult risk analytic endeavour ... trying to cram these capabilities into existing software will probably lead to tomfoolery as we are seeing.