How do we move to more value-oriented risk management, rather than compliance-oriented risk management?

This topic seems to be on many lips these days.  At ValueBridge we recommend several actions:  Integrating risk management with other business improvement activities (BPM, QC, BA, PM and more); making balanced improvements in risk management capabilities to avoid stumbling over the weak stops; engaging the organization to get more people invested in success and more resources; understanding how to prepare for and respond to changing conditions; and using measurements and incentives to bring alignment to the various functional areas of the bank around the business processes involved.  Sounds overwhelming. Yet, this is where leveraging cross-industry best practices and a kit bag of solid techniques can makes it faster and easier.

What do I have to know to blend business process and IT-related operational risks together?

If you are already talking about "business processes" and have a view of them, you are well on your way.   Manual processes and the "stack" of IT stuff on which they run are increasingly important, the more that banks become automated and integrated in the rush to cut costs.   The pace of acquisitions just adds to this.  The work you really need to do is very simple in concept:  1) understand what IT stuff is running your business process (and where it located), 2) understand the threats to the business process and that stack of stuff (threats can be malicious, natural, accidental or business, 3) the implications if those threats occur and 4) what you need to do on an end-to-end process basis to manage those threats (and the impact to liquidity as the regulatory guidance states).  Simple in concept, yet you face a number of challenges, including: 1) crossing the organization silos and 2) actually knowing how processes run in your enterprise.  The good news is that there are again cross-industry best practices and a kit bag of solid techniques that can makes your task faster and easier.

Is there more to scenario analysis than "long tail" validation? 

In banking operational risk management, scenario analysis has largely been used to validate "long tail" (that is low probability) events. Yes, it can be used more broadly. In fact, check with your strategic planning or business continuity departments, which might already be using scenario analysis in broader ways to more accurately reflect real threats to real banking operations.  If you have ever worked in foreign exchange, they also use scenarios in broader ways (especially those who work directly with clients providing FX services). Banks have the opportunity to use scenario analysis in the same way that other industries have.  Whether manufacturing plants, beer breweries, oil & gas, delivery trucks or telecommunications; they all have lessons to teach. So the opportunity is to use scenario analysis to move from compliance-driven risk management to performance-driven risk management.  In doing so, it is important to start by measuring maturity in several dimensions and evenly work to improve those areas.
 

Our business continuity program is improving, we have good times for recovery on our services, building evacuation and transfer to alternative work locations.  Is there more we need to do?  

For various historical reasons, including the way that compliance tests were designed, recovery time objectives (RTOs) were emphasized at the level of an individual resource (server, network, moving people). However business operations are simply not conducted at that level of individual resources or assets. To provide service to customers and others users, all aspects of a business process must be running. The relevant tests are the ability to process merchant transactions in total, the ability to stock cash in ATM machines, the ability to put inventory on shelves, the ability to ship parts, the ability to communicate with customers. The opportunity for improvement is to conduct end to end business processes based continuity planning. Two other important considerations are:

1. To evaluate range of threats to the range of operations. Too often "continuity" is thought of only in the limited sense of natural disasters or maybe terrorism. Yet, programming errors, cable cuts and human accidents have also resulted in great loss to organizations.

2. Ensuring that systems management tools are also considered in recovery efforts and recovery cycle time.  This is an often looked but serious consideration. In the 2003 U.S. Northeast Electrical Blackout, failures in the systems management recovery process were a contributing cause.

Especially for financial institutions, learn more about fast-start workshops.