Is this the end of an era for NPAP?

The Basel Committee on Banking Supervision (BCBS) recently published a consultative document for the revision to the Principles for the Sound Management of Operational Risk (PSMOR). On a high level, the principles cover the same topics as before but there are some clarifications and some substantial changes. The substantial changes, in the consultative draft, are foremost related to what is commonly known as New Product Approval Process (NPAP) and information and communication technology (ICT). NPAP is replaced by a general change management approach and a new principle requires robust ICT governance. Below, FCG provides our thoughts on the changes to NPAP.

The principle covering NPAP, principle 7, used to require an approval process for all new products, activities, processes and systems and that these were fully assessed from an operational risk perspective. The argument motivating NPAP was that when engaging in changes or development of new products (or activities etc.) a bank exposes itself for increased operational risk and these risks needed to be analysed. A further motivation was that it is better to identify and manage risk during the planning stage of change (proactive), instead of managing the risks when the change has been made (reactive). However, FCG’s experience from the Nordic and northern European market is that NPAP in most cases is implemented in a way where the assessment (in best cases) is performed before launch of the change, and where a high level comparison is made towards the company’s risk appetite. When the change is approved in the NPAP the risk and mitigation actions are in some cases unfortunately forgotten about. Further, FCG’s experience with NPAP is that the processes itself is by the banks, considered cumbersome and administrative in nature and not fit for modern organisations. FCG is frequently engaged in dialogue with our clients (second line of defence) regarding NPAP, and the most common questions are:

• How do we make the business use NPAP as intended and not hate NPAP as an administrative burden?
• How do we uphold NPAP in an Agile environment as NPAP is designed for a traditional (waterfall or IT Service Management) company governance model?

Looking into the revised version of the principles we can see that the waterfall like method of NPAP has been replaced with a change management process. You could argue that there is not much that differs between a NPAP and a change management process. However, the details set the scene for the revised scheme. First of all, the new proposed change management processes is intended not to manage the change from the initiation until the change is launched (as in the case of NPAP), but rather the change management process cover the full life-cycle of a change. From initiation, to launch and further until termination. During this life-cycle risk and controls should be continuously assessed. This will require a lot more effort from the institutions to both reassess risk and controls and to keep track of all changes with associated risks and controls. This is of course a more holistic view of how to manage risks in changes and could be used in an Agile business model as well. FCG suggest that due care is taken by the second line of defense to develop the risk controls in the proposed change processes with minimal unnecessary administration to avoid the NPAP stigma. Lean is the new change.

From FCG’s perspective this change is more than welcome. From what we have seen (from the best examples that we have seen in the market) NPAP delivers significantly more value to the company when integrated with the rest of the risk management process. I.e. when risks are managed from initiation until termination.

Last but not least, the revised version of the principles is very clear around the responsibilities for first and second line. This is, even if it is very clear in GL 11 most welcome as well, since it clarifies that first line should perform and second line should challenge. In the last couple of year this has become less of an issue, but we still today come across institutions that believe that is second lines responsibility to perform the risk and control assessments within NPAP.

If this is a peephole to the future of legislation around operational risk, we feel it’s a positive future.

Two things could however benefit from further guidance. First, if and how is the overall alignment of all ongoing changes (both big and small changes) towards the institution’s current risk limits and appetite going to be managed? This is a crucial activity to understand how the institute’s overall risk exposure when there are several concurring changes being performed.

Second, in an Agile IT development environment many small changes are performed on a regular basis rather than in the traditional way, where there was a big bang. How are the institutions supposed to handle the many small changes that one by one are, on a relative scale too small to manage in a traditional change process but combined might lead to significant change?