Unleashing ORM value

ORM departments need to take a fresh look at their reporting processes to see if they are maximising their value. By Dan McKinney and Osy Harrison

When thinking about operational risk reporting, one key question must be asked and answered: what is an effective risk report for your organisation? By definition, an effective risk report is one that is relevant, provides not only data but also analysis that adds context, and, ultimately, is a report that management uses to make informed business decisions. While this may seem simple enough, getting it right is not always easy.

As the pressure on operational risk management (ORM) departments continues to mount, and the related costs of building out the ORM infrastructure continue to rise, these departments are continually challenged to demonstrate the value they are bringing to an organisation. Looming regulatory deadlines have spurred companies to develop or enhance reporting processes, but their focus on compliance often does not fully incorporate the needs of all stakeholders. So while vast amounts of data are being captured, reports are often produced without an agreed-upon standard, a unifying focus and, in some cases, a clear understanding of the information expected or required. To further complicate the issue, many ORM departments have been mired in process-implementation issues and, as a result, have probably not allocated sufficient time and attention to the review and analysis of the data they are collecting. Too often, the result is that senior management and boards of directors are receiving information that may be purely historical (and perhaps out-of-date), is data-intensive and provides little or no analysis of the key risk issues the organisation is facing. In short, it is not providing management with any forward-looking view of the organisation’s risk profile and emerging risk issues.

Perhaps the time is right for ORM departments to take a fresh look at their reporting processes to see if they are maximising the value to the organisation. Approaching risk reporting as a process unto itself – with a clear set of guidelines and principles – will allow ORM departments to improve today’s current state where, for many, their reports are viewed only as a by-product of a series of risk management activities.

The first step, which is almost universal for any new process being implemented, is to agree on the goals and objectives with the various stakeholders to ensure that efforts are in line with their needs. In these discussions, some reporting guidelines may become apparent that could be used to implement or reinforce a consistent approach for the organisation. This would address an all-too-common problem we at Ernst & Young have witnessed, where different divisions within an institution are producing and circulating their own versions of risk reports in the absence of a standard corporate model. This often results in duplicative and overlapping reporting processes that confuse rather than clarify.

By soliciting the views and opinions of the key stakeholders, an interesting by-product is often achieved. You begin to socialise both the idea of how ORM reporting could be helpful and the often-arduous process of obtaining the organisational buy-in for this effort.

Since any new process results in change, the need to focus on change-management issues becomes important to the overall success of the effort. While it can be a difficult task to accomplish and takes time to complete, it is far more cost-effective to spend the time upfront than it is to produce reports that no-one finds useful or to try to modify or re-engineer the process after it is implemented. This step has become increasingly critical as more involvement is needed from across the organisation to produce effective risk reports. This is especially true given the broad nature of operational risks and the multiple perspectives of risk within the organisation. As we have seen in many organisations, risk reporting is no longer the sole province of risk management, and a lack of institution-wide buy-in has often resulted in confusion regarding roles and responsibilities, duplication of work and, ultimately, wasted resources.

Only after the needs are identified and buy-in is secured can attention shift to the design and content of the risk reports. The reporting process, and the related reports, will differ from organisation to organisation depending on need and culture; each institution must determine the type of data gathered, the level of detail required and the frequency of reporting.

ORM departments should take a step back from current reporting activities, which are likely to centre around collecting and analysing operational incidents, risk assessment information and key indicators, as well as other metric data. While all are important, it is necessary to bring these activities together within a broader operational risk framework to reap the full value of individual initiatives. This includes defining and implementing a common risk and control language, a common organisational hierarchy, and common measurement/prioritisation criteria. By doing so, organisations begin to consolidate other risk and control activities and related issues (such as audit, compliance and SOX) to present a more comprehensive view of business and operational risks. In addition, some organisations have found that providing multiple views of risk gives perspective and a system of checks and balances to support and substantiate their company’s risk profile. It will also facilitate the presentation of thematic issues for management’s focus and attention.

Any good risk report should facilitate data analyses to assist all levels of the organisation to better understand, monitor and prioritise the risks they are facing. To do this requires the data being reported be put into the proper context. As such, we believe an integral part of effective risk reporting is the establishment of a formal risk appetite. In the credit or market risk arena that is typically articulated via risk limits or value-at-risk limits but that is not as easily done for operational risk. While approaches will vary, a balance between qualitative and quantitative measures seems to be the developing standard. Typically, this would include items such as risk assessment scores, internal audit ratings, number of ‘high-risk’ issues, delinquent remediation plans and certain ‘normalised’ metric levels, among other inputs. The articulation of a clear and well-understood operational risk appetite will facilitate the development of a consistent series of benchmarks and threshold levels to assist the reader in putting the data into the proper context. This will enable the report reader to better understand whether the data presented is within acceptable tolerance levels and further allow for the creation of a reporting process that is more exception-based and user-friendly. Unfortunately, for many organisations, risk appetite has not been formally articulated; as a result, we often see reports that provide voluminous amounts of data but do not provide the reader with a sufficient understanding of what is ‘normal’ versus what items need management’s focus and attention.

Over the past few years, we have seen companies make significant investment in implementing new technologies to enhance reporting capabilities, only to discover that the resulting reports do not fully address management’s needs. Once the reporting processes have been defined, technology can, and should, play a significant role in supporting the data needs within an organisation. It is important that the business requirements are first understood and agreed upon so that the organisation can produce the technical requirements needed to make the right decisions regarding the appropriate system architecture. This will result in a more efficient use of investment dollars as the technology can be selected and implemented to support defined and agreed-upon processes.

Remember, technology is not the driver of effective risk reporting but rather the facilitator of the reporting process. Done correctly, technology can streamline data-gathering processes and allow more time for the ORM department to analyse and interpret the information, which is critically important to producing effective reports. A good rule of thumb is that the time spent analysing the data should be roughly twice the amount of time spent collecting and compiling the data. Too often, organisations spend a significant amount of time collecting various data elements but fall short by spending little time interpreting it. Ultimately, the goal of the reporting effort should be to provide a more forward-looking risk view that includes the ORM department’s insights and perspectives, requiring thoughtful analysis to dissect and interpret the data.

While considerable progress has been made in the development of operational risk frameworks and approaches, it is still an evolving risk discipline. Many of these new enterprise-wide risk processes will take time to implement. However, ORM departments can begin to immediately demonstrate increased value by creating risk reporting that compiles and synthesises different types of operational data and provides meaningful analysis. These reports should become a daily input into organisational decision-making and provide demonstrable evidence of the ‘use test’ concept in action. If ORM departments take the time now to critically evaluate the current state of their reporting processes and, where needed, follow the key principles outlined herein, their investment of time and resources will be more easily justified by the benefits ultimately obtained. And, perhaps most importantly, in a tangible way they will demonstrate to executive management and key stakeholders the value they are providing to the organisation. OR&C

Dan McKinney is a partner with Ernst & Young and co-head of the firm’s North America-based operational risk services team. Osy Harrison is a senior manager within the group. Both are based in New York

A. On the path to better risk reporting Have you identified the key stakeholders at all levels within the organisation? Have you met stakeholders to understand their reporting needs? Has buy-in been established for producing more effective reports? Do you have dedicated resources to produce reports? How will you meet the reporting needs? Have you thought about linking the outputs of various risk tools at the business unit and firm level (such as KRI or RCSA) to develop meaningful analyses of your risk environment? Has the organisation developed and communicated its risk appetite? Are you able to translate the risk appetite into appropriate benchmarks/thresholds that will allow the reader to put the data into the proper context?