New beginnings

After less than 20 years as an independent state, Slovenia is no stranger to starting something new. Alenka Valher talks us through the implementation of an operational risk framework at one of the country's largest banks: the processes followed, the decisions made and the challenges faced

The bank discussed in this article is one of the top three banks in Slovenia. It has just begun to implement its operational risk system, which will not only comply with regulatory requirements but also add value to the bank.

The bank considers itself to be modern, with 50 years of experience conducting business in Slovenia and abroad.

To comply with Basel II requirements and effectively collect data on operational risk, the bank has prepared several lists of codes, covering business areas, op risk categories and the causes, effects, size and composition of op risks, followed by actions taken.

The top level of op risk categories are defined as: internal fraud; external fraud; employment practices and workplace safety; clients, products and business practices; damage to physical assets; business disruption and system failures; execution, delivery and process management.

Approach

From the beginning, the bank chose a simple approach to operational risk. The decision was based on the fact that it was necessary to develop an op risk system from scratch, while the highest priority was assigned to the obligatory conversion to the euro, and the installation of credit and market risk systems. So few resources were dedicated to the op risk system - the primary goal was regulatory compliance.

The bank planned to first develop an op risk system for the information technology department and then apply that system to other business areas.

At the same time, the management board knew the bank was due to be reorganised, with the prospect of merging with another bank by the end of 2010. So it was not cost effective to develop a sophisticated op risk system that might not be usable in a couple of years.

Development - 2005

In November 2005, the bank first prepared a document in which the strategic development and implementation of op risk management was defined and then confirmed by the management board. The starting point of op risk development in accordance with Basel II was defined.

The bank then outsourced the preparation of a database of potential op risk events, for IT only. The company hired to do this had also been hired to prepare the business continuity plan (BCP) for the bank's IT unit a couple of years earlier. The intention was to add value to the BCP by linking the data it collected with the potential op risk database.

To satisfy BCP requirements, the inventory form circulated was very detailed. The potential op risk events were collected at the organisational unit level, together with a prevention and reaction plan. The bank also attempted to identify the processes affected by op risk events, products and resources.

An important consideration was how to prevent the occurrence of op risk events. The inventory form also queried whether a plan existed to follow in case an op risk event did occur.

Controlling the implementation of operational risk strategy was considered an important issue at the bank level. Therefore, the risk management group prepared the implementation document, which set up adequate control procedures.

Risk management prepared reporting instructions to define the deadlines and structure of reports for the management board and directors.

After the coding system of op risk events was defined, the business areas (apart from IT) had to prepare a list of potential op risk events for their lines of business. To effectively gather the information, an inventory form for potential op risk events was given to managers of business units. The definition of frequency and severity of op risk events was an important element of the form. Unfortunately, objective measures of frequency and severity did not exist, so the self-assessment approach prevailed.

While the inventory of potential op risk events took place, a separate group of external experts had been preparing the business continuity plan for IT. The BCP was completed by 2006.

The external company remained responsible for the BCP. It programmed the application, maintained the database and collected the information necessary for the plan. The bank accepted the external company's suggestion to add extra functionality to the BCP application, providing one application for both BCP and potential op risk events. This allowed the input of potential op risk events and reporting on the potential op risk profile of the bank and its business units.

In 2006, the results of the bank's op risk activities were its strategic framework, its database of potential op risk events, and reports on potential op risk events.

Development - 2007

The following year, the bank focused on actual operational risk events.

Following the recommendations of the Bank of Slovenia, the country's central bank, our subject bank began to cut its ties with the external company in the BCP and op risk areas. The reasons for this move were the bank's high dependency on the outsourcing, the high costs encountered and the external company's slow response to the bank's demands. First, the bank focused on the op risk part of the BCP application. The BCP part of the outsourcing contract could not be easily discontinued, because the bank did not have BCP expertise and the external company had not developed the application as a final product available for sale. So the bank decided to take back control of the BCP in small, gradual steps.

The bank's IT department was tasked with developing an application for collecting and reporting on actual op risk events, as part of an existing application for payment transactions. The rationale was that the payment transaction application and op risk application share most of the same code lists.

Reports on actual op risk events were prepared in Microsoft Word with the help of an Excel database. It took more than a year to stabilise the op risk application enough for use by the end users. Meanwhile, the data on actual op risk events was still manually collected and kept in Excel.

The op risk profile of the bank and its organisational units was no longer maintained, due to its poor informative value for op risk decision-making during 2007. However, the bank's code lists were common to potential and actual op risk events.

The number of staff in charge of op risk at the bank's level had not increased. The director of risk management and one employee with three years' experience were responsible for op risk implementation. The central bank issued a warning that the op risk unit was understaffed, so the bank hired an op risk specialist on a consultancy basis.

The bank authorised its asset liability committee to review op risk reports on a monthly basis. The management board made a decision to form an operational risk committee, but this has not been implemented yet. The bank's Basel committee is still the focal point of the implementation and development for all types of risk management.

In 2007, the bank also carried out a reorganisation, which meant a substantial part of the op risk coding list, and the people responsible for collecting and reporting information, was no longer relevant. The op risk unit selected new reporters and organised workshops for them to keep the information flow on op risk events intact. The op risk code lists were adapted.

The bank decided to leave the database for 2006 and part of 2007 intact - no adjustments were made. Then the op risk unit prepared to take an inventory of potential op risk events for the new organisational structure of the bank.

Potential op risk events were not collected at the business unit level this time, in order to better capture the essence of appetite and tolerance. Appetite was defined as the desired profile the bank wanted to achieve in five years. Tolerance was defined as a specific level of frequency and severity of op risk event that does not require any action by the bank. The information was collected through forms circulated to directors of business areas. The added value of this form was that it covered key risk indicators (KRI).

Because the bank's op risk application does not have the functionalities for recording KRIs, appetite and tolerance, all this information is kept in Excel files by the op risk unit. The shift from completely qualitative data to partially quantitative data was considered an added value during the definition of the bank's appetite and tolerance.

The op risk unit often encountered problems in linking its data on the op risk losses with accounting records. Just as in the case of money withdrawals, it is possible to trace the loss back to an op risk event. The IT department considered it too costly to adjust the existing accounting application, so the data on op risk losses was a mixture of actual data and forecast data.

The op risk unit has also found it difficult to distinguish between op risk, and credit or market risk. The bank has adopted the policy that whatever is not credit or market risk should be recorded as operational risk. The asset liability committee also has the right to change the type of the risk, even after it has been recorded and processed.

Another problem the op risk unit encountered was the classification and counting of op risk events. IT op risk events are reported once a month in an IT logbook, which is primarily used for IT purposes. The IT op risk events are most often not valued and present the IT side of an event that is often recorded by another business unit as well. So the amount of op risk events and loss is not accurate. Money withdrawal op risk events are reported once a month and each event is listed by number and value.

The op risk unit issued instructions to the directors of business areas regarding how each should prepare their op risk policy. Each policy had to contain information about employees responsible for recording, confirming and reporting, the internal critical points of control, and the preventive and curative measures. An organisational chart of risk management processes to capture and manage op risk at the bank level was prepared before the instructions were issued, which was a great help to directors.

The op risk management process at the bank level was designed in great detail and well documented. It contains the following sub-processes: recording, measuring, reporting and analysing op risk events, developing the op risk system and managing the whole op risk process. The links with other processes have also been marked: legal, management board, internal audit, accounting and IT departments.

Critical points of control in a particular business area were identified during the preparation of its policy, as well as its appetite and tolerance. So directors got the first look at the critical points, and sometimes the critical paths, of the processes they were responsible for.

The first half of 2008

Collected op risk data was used in the Internal Capital Adequacy Assessment Process (Icaap) under Basel II at the beginning of 2008. The capital requirement for op risk was extremely high, so the management board decided to gradually shift the op risk approach from simple to advanced. It is expected the Icaap requirement for op risk will decrease substantially with the adoption of the advanced approach. The importance of control mechanisms has been highlighted (that is, internal audit and legal control).

At the beginning of 2008, some events essential to the enhancement of the bank's op risk occurred - in particular the linking of op risk with processes and the definition of the role of stress analysis.

The Bank of Slovenia required the bank to have two processes reviewed in the form of an 'as-is' situation. It asked the bank to focus on the entire process chosen and its critical points, not the rationale of the process and its outputs.

The electronic banking process and the process of lending to individuals were selected, and the as-is analysis was prepared by an external company. The results were compared with the information collected by the op risk unit. The comparison showed there was a large overlap of critical points listed by both analyses. The list of critical points helped internal audit to perform a more effective audit of Basel II compliance.

At the same time, the management board expected the process research and revision department to perform an as-is analysis of all the bank's processes. The external company has been hired to do this, with the help of the bank's employees. The analysis is not yet complete, so we can not give any opinion on its effectiveness and usefulness. The purpose of the analysis is to take an inventory of all the processes in the bank, document them (with the help of software) and keep them updated. Only after the process analysis is completed will the bank then consider the evaluation of the processes.

The management board and asset liability commission accepted that the data on actual op risk events was not accurate and complete, no matter how much effort the op risk unit put into improvement. The op risk culture in the bank has slowly begun to shift from analysing all data to analysing only data at the tail of the distribution. Based on a recommendation from the central bank, the management board asked the op risk unit to prepare a stress analysis scenario.

The operational risk unit chose one op risk event (the theft of safety boxes) that was likely to occur once in 25 years. The behaviour approach was used, whereby the op risk unit organised a workshop for the directors, working in groups. In the end, the consensus of the most acceptable analysis, consequences and action plan was prepared. The scenario emphasised that an op risk event has both positive and negative consequences, which occur over a longer period of time. Scenario and analysis were documented and archived.

Conclusion

The Bank of Slovenia is the Basel trend-setter. It sets the general tone of op risk development in banks. Its lack of detailed regulatory guidance is considered a potential risk area for the bank.

Regulatory compliance still prevails, but focus is slowly shifting to adding the value to the bank.

The process of Basel II op risk compliance was the last of the types of risks to be addressed. Op risk development received the least resources.

The bank faces the following challenges:

- the cost and time of implementation;

- lack of buy-in from business units;

- difficulty in getting quality loss data; and

- problems aligning its capital with op risk.

The operational risk unit falls within the risk management unit and it is still understaffed. Operational resources are enhanced slowly, and programmes are maturing at a slow pace.

The op risk committee has not yet been organised, so the asset liability committee performs some of the committee's tasks. The op risk committee is supposed to be responsible for IT, business protection, human resources, business standards and compliance aspects of the op risk system.

An op risk framework is in place to comply with regulatory requirements. Compliance was the primary reason for the development of this framework.

Risk control self-assessment and loss data collection are still major focus areas of the bank. Loss data collection is the most mature aspect of the operational risk system, scenario analysis and economic capital modelling initiatives are the least mature areas.

The database of op risk potential and actual events is modest. It does not receive enough IT support. The quantity of loss data is increasing, but its quality is still questionable. A link between the databases of potential and actual op risk does not exist.

The measurement of op risk is immature, so the op risk executive finds it difficult to demonstrate cost/benefit and added value to the business lines.

Operational risk modelling has to deal with the issue of data quality and incorporation of qualitative factors together with the lack of experienced staff with quantitative backgrounds.

An effective link between business continuity and op risk was not established for several reasons: the systems were too detailed, the organisational levels were too 'Balkanised', and there was no link between potential and actual op risk events, which were often recorded in duplicate.

The potential of scenario analysis has not been fully recognised, although the first steps towards its use have been taken.

Icaap for op risk was first calculated in 2007. It was overvalued because the bank did not take into account the fact business areas must have enough 'self-profit' to pay for the normal part of op risk event loss distribution. Reporting in general was not focused on the extreme parts of op risk loss distribution. Adoption of the advanced measurment approach is considered to be an answer to high Icaap op risk requirements.

The awareness of business processes and op risk interdependence has been slowly improving, but has not been formalised yet.

The development of an op risk system has only just begun. The bank still places more emphasis on the regulatory and control issues than the rationalisation and prevention aspects of operational risk.

Alenka Valher is a consultant specialising in operational risk management for the financial industry at systems integration company SRC.SI in Ljubljana, Slovenia.

Email: [e-mail].