Building the Reporting Capability for Operational Risk
Effective management of operational risk is not only a regulatory requirement but also an important performance baseline for most banks. Management of operational risk requires effective flow of diverse information from a variety of sources within and outside the bank and at various levels of granularity. Unlike other risk disciplines the quantum of data is huge, and processing and presenting them to aid management and decision-making is quite challenging. This is made more complex by different sources for data, different target audiences within the bank and different business objectives.
The multitude of sources (including different source systems), target audiences and objectives make operational risk reporting complex. And given the fact that the responsibility of managing operational risk in most banks is spread across the bank and carried out by many people at different levels, having an effective reporting capability becomes very important. It is also important for the banks to have a consistent and uniform reporting framework across the organisation to be able to develop a single risk culture and language.
However, this is easier said than done. Most banks have either developed or purchased operational risk solutions without considering their capability for generating reports. In cases where consideration has been given, not much work is done to implement effective integrated data architecture or for uniform report designs to be used across the bank.
This article discusses the three important components involved in putting in place an effective operational risk reporting capability for a bank:
This is one of the most important steps in developing an effective operational risk reporting capability. This activity can start once a high-level requirement is in place. Banks can use different criteria to analyse and assess the applications available in the market. Some important criteria that can help in this decision-making process are:
Most banks have multiple operational risk applications resulting in multiple data sources. The reporting application should be able to deal with multiple sources and integrate easily. The simplest way to access data from a source system might be direct database query. But most reporting applications separate the data access layer from the business logic. In such scenarios the reporting tool does not make a direct connection to the database though most of them provide that flexibility, too. They should be able to extract data from Java objects, XML data or any other source.
Many banks might look at the reporting application to not only take care of their operational risk reporting but also other functional groups within risk management or even outside. Hence it is important that the application should have easy and flexible integration capability.
Functionality offered is an important criterion for deciding on an operational risk reporting application. Analyse the capability for:
Strong visualisation capability ensures that important and critical information can be conveyed to decision-makers in a powerful way. As operational risk has to deal with a huge quantum of data, an effective visualisation capability can ensure that critical information is communicated and understood effectively.
The user base for any operational risk reporting application can be huge. Hence, the application should be easy to use by business users, enabling end-to-end self service via intuitive interfaces and report workflow. It should also be easy to maintain by IT with comprehensive administration, monitoring and performance tuning features.
Performance of the reporting solution and its scalability are other important criteria in decision-making. To assess this, the current requirement might not be a good benchmark and the bank needs to know whether the solution can also handle its future requirements in terms of data and usage. Also, there will be a need for real time reporting in operational risk, unlike in a purely BI scenario. Hence due consideration has to be given on this capability and the right balance can be set between data freshness and performance.
Cost is an important criterion. While looking at cost, it is important to understand that there can be new operational risk reporting requirements based on internal and regulatory requirements at any point. As a result, there will be a lot of ongoing configuration and maintenance requirements. Hence implementation and maintenance cost should be given due importance in decision-making. Also, future upgrade costs are to be considered, as the landscape for operational risk is changing and banks will find themselves in position where they will need to upgrade to enhanced product versions in future.
There is no single and effective way to understand the operational risk reporting requirements. As a result one might have to resort to multiple sources and methods to understand the reporting requirements. Some of the important ones are:
Since reporting is an important tool for managing operational risk, it is important to understand the objectives set by the management and the operational risk unit which will help to crystallise the reporting requirements. Usually banks have the following objectives:
Operational risk requires regulatory reporting in various countries. Reports are required for submission to regulators and have to be considered while deciding on the reporting requirements. These are must have reports and any reporting solution should be able to support these.
An analysis of the existing reports is always very helpful. Although most banks initiate this exercise to implement a new reporting framework and solution to cover gaps of the existing, it is nevertheless useful to look at the kind of information that the bank has been using. It is important to question and analyse the relevance of the information and whether they will be useful going forward. During this exercise it is also important to group the reports by their subject area and the purpose they serve. It will often become apparent that different business units will be using different reports (in terms of title, format, data content) to address the same need and provide the same information.
It is important to engage with the business users through discussions, interviews and workshops to understand the reporting requirements for their management of operational risk. This exercise will help document the requirements that are driven by their day-to-day needs and also their pain points. It is also important to have exploratory discussion and brain storming to crystallise report requirements which are not currently addressed but which are going to be useful if available. Many banks follow a blue sky approach at this stage without defining any boundaries and the users can come out with any requirement that they can think of. Others define certain boundaries. Nevertheless, it is very important to inform users of potential functionality and possibilities on a high level after analysing the underlying operational risk solution and the potential reporting solution to be used.
It can be counterproductive if participants in workshops are allowed to define their wishlist of functionalities without knowing what is possible in the reporting application to be used. It is also worthwhile assessing the requirements, vis-a-vis the data architecture, to identify potential technical problems in implementing the requested functionality, such as performance problems. It is found that considering the above, it suits to conduct multiple sessions with the participants wherein the first session focuses on the requirements and the subsequent sessions are used to confirm and prioritise them using assessment vis-a-vis application and data architecture.
Once requirements are gathered, it is important to decide which requirements are important from a business perspective and have common utility across the organisation. While documenting the requirements, it is important to group them by functional areas, e.g. incident/loss, risk and control, key indicators, etc, so that it is easy to analyse the coverage. The existing reports and the new requirements have to be prioritised depending on their utility, complexity, effort, etc. It is also important to decide on a single acceptable version of reports where multiple different versions are used across different business units.
It is also important to filter those requirements that are not supported by the available data from the source systems or by the selected application. Stakeholders have to be informed accordingly.
Once the scope is discussed and agreed on, reports are to be designed and specifications are to be prepared. The design will vary depending on the type of report. Most banks will use some or all of the following types of reports:
The pre-built reports are used regularly and have a certain pre-defined objective. These reports are either used internally for monitoring, analysis and decision-making, or are required as part of regulatory requirements. Many of these reports might be required for submission to higher management and reflect the operational risk performance of a business unit. There are different types of standard reports, each with their own focus. They can be formatted type reports or non-formatted data extract type reports.
Profile-type reports: There may be profile reports for specific operational risk objects like risk, control, key indicators (KIs), incidents, issues and actions and there may be profile reports for specific business units. For example, the risk profile report for a business unit might show its different risks with all their attributes and assessments, as well as the linkage of the risks to other objects like control, incidents, KIs, issue and actions, etc. This report should be able to capture the profile of the risks in the context of the environment it exists in. Similarly, a profile report of a business unit will be able to profile the business unit with respect to its risks, controls, assessments, incidents, issue and actions, etc.
Performance and assessment reports: These reports are used to analyse the performance of various risk objects or specific business units over a period of time. They are used to analyse progress, vis-a-vis operational risk target state. Use of graphs makes these reports useful. This type can also cover quantitative reports such as a scorecard for business unit and bank.
Monitoring and tracking reports: There are other reports that can track changes and are more operational in nature. These should be designed in such a way that they focus attention on the highest priority issues. For these reports information should not only be accurate but also timely. Such reports focus on incidents, issue and action tracking, emerging risk, etc.
Analytical reports: These reports are used for analysis and predictions. They use quantitative metrics and use graphs extensively for analysis of trend. Many banks also use different extract reports with export capability to Excel to support their analysis function.
Most of the above report types will contain a large amount of information on the primary object, as well as all linked objects, and hence should have good format and layout to make them easy to read. For formatted reports, it is important to decide on single acceptable format to be used across the organisation. Time should be spent agreeing on templates for all standard reports. Strong attention to detail at this stage (i.e. down to agreed fonts, spacing, page layouts, graphics, etc) will save considerable effort during the remainder of the implementation. It is found that even when formats are decided beforehand, when the reports have been built and are seen with real data in them, they might look different from what is visualised – prompting redesign and rebuild. Therefore, it is worthwhile to populate the templates with data so that they are as close as possible in appearance to the built report. Considerations have to be given to the data type and volume of data that the fields in the underlying application handle so that similar data is put in the report to understand whether the design will be able to handle real world data without losing its integrity. The level of detail in the reports is to be determined by the objective and the target audience. It is also important to decide on uniform parameters and prompts to be used in the report.
Ad-hoc reporting capability allows non-technical users to build reports that they want through free form queries constructed via a graphical user interface. The design of the ad-hoc reporting layer is determined by the database design and structure. Most operational risk data models are complex due to the nature of relationships between the different operational risk objects – most having many-to-many relationships. Moreover, due to their transactional nature, they are highly normalised. Considerable effort might be involved in designing a true ad-hoc layer with capability to report on any object and any possible combination between objects. Hence, it would be prudent to analyse how ‘ad-hoc’ the ad-hoc reporting layer needs to be. And depending on that, the solution can range from a simple design supporting simple queries through to a separate data warehouse.
Thus it makes sense to restrict the scope of queries and design the layer to support only specific scenarios which are expected to be useful to the organisation and which address real operational risk problems. A good effort to understand and design for such important scenarios will go a long way in avoiding unnecessary effort in building ad-hoc layers for scenarios which are never going to be used.
Another issue to consider in the design is whether the bank can risk users constructing runaway ad-hoc queries on their finely tuned operational databases, risking bringing them to their knees. It might be prudent to give ad-hoc layer access to only specific trained users rather than exposing it to all the users. Another consideration is the timeliness of the data and data freshness. Firms also need to consider whether there are hierarchical structures in the data which require unpacking and flattening.
Considering all the above, it is best to work backward from the defined scenarios to decide whether to build ad-hoc on the existing database or to built a separate data warehouse.
A dashboard is a visual display of important information through tables, graphs and charts used to achieve one or more objectives. The two most important objectives for operational risk dashboards are to:
A dashboard can provide a consolidated and high-level summarised view of the operational risk state, while allowing users to drill down to appropriate granular levels of information. Accordingly, the bank can have separate tactical and strategic dashboards to support the management and the operational staff.
A dashboard should be clear, concise and use an intuitive display mechanism. The following points should be kept in mind while designing a dashboard:
Many reporting applications allow alerts to be sent to predefined recipients based on certain conditions being met. This is effective in the monitoring and controlling function of operational risk and can be used effectively to invoke operational response to operational risk events. The design of alerts should focus on the information being concise and actionable.
The requirement and the resulting design are then documented in the report specifications so that reports can be built based on them. The specifications should cover the following at a minimum:
It is important to provide as much detail as possible in the specifications; these should be signed off by the stakeholders confirming their agreement to what is proposed to be built.
The database foundation is a critical component of the reporting capability. The greatest barrier to achieving an effective reporting capability is the complex structure of the physical data model (the complexity is in the relationship between the tables. The actual tables are not complex). Besides, most operational risk reporting solutions are either OLTP, or a mix of OLTP and OLAP. As a result, they have a fair amount of normalisation. Normalisation is good and is required for the transactional system but does not lend itself efficiently to reporting applications. Operational risk reporting requires dealing with a huge range of data and requires joining of numerous tables. It also requires a star schema to enable analytical and dimensional reporting. Thus trying to build reports on the operational risk database is not only complex, but can have adverse performance impacts making the implementation journey difficult.
Therefore, there needs to be a good understanding of how the underlying physical data structure relates to the business data model of the application. In cases where the physical data structure is highly normalised, a decision needs to be made whether to implement a separate data mart with a de-normalised structure or to build a ‘virtual’ data mart (i.e. using a business metadata layer in a reporting tool to provide real-time de-normalising). To make that call, it is important to understand the requirements for data freshness so that an appropriate data source can be applied for reporting. Many banks might decide to use both options considering that some operation risk data needs to be in real time and cannot be supported by a data warehouse.
Data warehouse or data mart: It is important to have the majority of the reporting requirement basing out of a data warehouse or a data mart. A data warehouse can be maintained outside the operational risk system, thus making it immune to the politics of the operational risk database. It will allow reporting requirement to determine the structure of the database and provide greater flexibility. Tables can be built combining different production system tables in a perfectly de-normalised manner and star schema, which will enable advanced analysis and dimensional reporting. These newly created tables can be populated using batches at frequency based on the requirements of the business. Usually most batches can be made to run as nightly jobs except cases justified where the frequency needs to be higher. In case banks do not want to maintain a separate database, they can also use the existing operational risk database to create a warehouse or a data mart. The trade-off in this option is data freshness.
Real-time production operational risk system: This should be a small percentage and has to be justified. Basing reports out of production systems can be complex. One has to understand the business logic within the database and how it relates to the report requirements and then determine the base tables that need to be used and find out how best to join them for the correct data results. The database component might not just be tables but can be views, packages (procedures and functions), grants/synonyms, etc. While building, it is important that the apparent side effects of performance are to be considered, particularly when views are created to cover database complexities. Each view might be built on many tables involving complex queries, which are to be tuned appropriately including using techniques such as indexing.
Considering that operational risk management is very important for banks today, an ability to implement an effective operational risk reporting solution is crucial. And during these difficult times, it is very important that any reporting solution implementation is smooth and efficient so as to save cost and reap the benefits of effective operational risk management in the shortest possible time. Even though the three components mentioned here are not the only areas to focus on to make that happen, they are the most important.