01 May 2006 Features

 

Gearing up for Basel II

Banks don’t want to tie up too much in minimum regulatory capital when Basel II comes into effect next year. Sherree DeCovny looks at systems to monitor and manage operational risk capital.

For nearly two decades, banks have had to set aside 8% of risk-weighted assets to offset credit risk in order to meet the requirements of the Basel Accord. The regulations have been revised a couple of times over the last 10 years to include minimum regulatory capital requirements to offset market risk and, most recently, operational risk. Complying with the revised Basel II Accord is no easy feat, and banks are burning the midnight oil trying to gear up their systems and processes before the new regulations come into effect.

To comply with Basel II, banks need to put in place a systematic process or set of standardised activities across the company to measure, monitor and manage operational risk. They can adopt one of three approaches: the simplest is called the Basic Indicator Approach; the next most complex is the Standardised Approach; and the most rigorous is the Advanced Measurement Approach.

Over and above that, banks will have to calculate their internal capital requirements using their own methodologies. The regulators and supervisors will review each bank’s calculations and determine what their overall capital requirement should be.

In the US, only the top dozen banks will adopt Basel II, and they will use the AMA to calculate their minimum capital requirement. In Europe, all financial institutions regardless of size and complexity must adopt Basel II, but they are free to decide which approach they take. European banks that choose the Standardised Approach need to comply by the end of 2006, while those that go for the AMA have until 2007. The US has delayed implementation.

Deciding which approach to take comes down to a cost-benefit analysis. Going for a more advanced approach gives banks an opportunity to improve their processes, systems and procedures for measuring and managing risk. In addition, banks may be able to reduce their minimum capital requirement. They have to weight those benefits against the cost of revamping systems and rolling out new processes across the group.

The minimum capital requirement using the Basic Indicator Approach is simply 15% of gross annual income bank-wide, so the systems requirement is not very difficult.

Calculating the minimum capital requirement under the Standardised Approach is also relatively straightforward, with one exception. The gross income is allocated to eight business lines as determined by Basel II. Also, the minimum capital requirement varies according to the business line.

“There’s a little bit of complexity there, but probably more of a general ledger type change rather than anything else because it’s still a given percentage of gross income,” says Martin Whiteley, professional services director at SunGard BancWare in the UK. “It is really mapping your internal business allocation to the Basel definitions.”

The AMA is a complete seismic shift from the other two. Banks have to deploy statistical models to measure the probability of operational losses over a one-year time horizon to a 99.9% confidence level.

Many banks do a top down and bottom up risk assessment to identify the material risks they face within their business that are not credit or market related. Then they determine the probability of an event occurring and the loss potential. They do that by inputting their loss history into a model to create a loss distribution for the risks. Using Monte Carlo simulation, they generate tens of thousands of possibilities. From there, they take their overall loss distribution and generate a 99.9 percentile loss.

Having the right historical data is critical to this process. Banks need a minimum of five years of internal loss data to comply with the AMA, which they typically have. The problem is that it may not be broken down into sufficient detail. For instance, some banks have a sundry loss account for a given entity or a part of the business. “That doesn’t really help by trying to analyse where those losses came from,” says Whitely.

He also points out that key risk assessments are not necessarily forward looking, and they do not necessarily have to be what the bank has lost over the last five years. Banks can use their loss history to validate some of their assumptions, but a key risk may be something that has not happened in the last five years.

Moreover, banks are faced with some serious questions regarding the categorisation, materiality and reconciliation of risk. Should a loan fraud that results in a loss to the bank be considered a credit risk or an operational risk? Should the bank record and analyse a payment error that results in a one-dollar loss of interest? How should the bank reconcile sundry losses with the accounting records?

Measuring operational risk is to a large degree subjective, and getting agreement on how to do it consistently across the organisation is a tall order. A large bank could have several different risk assessment processes in place to comply with an array of regulations, including Sarbanes Oxley, Basel II and Know Your Customer.

“From a business line perspective, they feel harassed,” says Patrick O’Brien, director of product management at OpenPages, a Massachusetts-based governance and compliance specialist. “One week the SOX person has been there saying you’ve got to do this for me. The next week the ORM person is in there saying you’ve got to do XYZ, and it’s sort of three-quarters of what you did last week, but you just bend it sideways and do it a little bit different. They’re frustrated and they would really like to just do it once.”

Beyond that, there are many technical issues. Basel II advises banks to use external loss data to better predict their outlook, but sometimes that is a bit like comparing apples with oranges. For instance, a small bank may be reluctant to use external loss data from a large bank. Also, banks have different processes, technology and internal control frameworks that affect the probability of loss.

Basel II is not completely prescriptive. The regulators give banks the freedom to structure processes, data capture and workflow in a way that meets their business needs. But essentially, they need technology to help them do a risk and control self-assessment, and quantify their exposure. They have to track loss events, associated impacts and recoveries over a period of time, and come up with key risk indicators. In addition, all that data must be reported to internal and external constituencies including risk oversight committees within the company, the board of directors and bank supervisors.

Poor data management itself is a source of operational risk, and some argue that this may drive banks to replace aging core systems and disparate platforms. “One of the fundamental challenges for every large bank is how you link all of the client activities together,” says Fred Sommers, a partner at Basis Point Group in Boston.

In addition, important analytics and risk-sensitive data are often held in Microsoft Excel spreadsheets scattered on people’s desks throughout the organisation. For the most part, they are completely uncontrolled and full of errors. “We see this everywhere that we go,” says Yusef Jafry, co-founder and chief technology officer at Risk Integrated, which is located in the Isle of Man. “Every bank that we talk to says: ‘We’d love it if our data was all consistent, and we could solve Sarbanes Oxley, and we could solve our accounting risk, and we could solve operational risk for Basel II. But we’ve got all these spreadsheets’.”

Since operational risk management can conceivably touch every person in the organisation, the ideal solution is for banks to deploy an enterprise system that can reach out to all the different geographies, product lines and functional organisations. Large IT vendors, including IBM and SAP, offer enterprise solutions to help banks mitigate operational risk. But if a bank is not an existing client of one of these vendors, they may not be inclined to replace their infrastructure with their product. Another solution is to leverage secure web services technology from these vendors to build proper, secure, robust data bridges across these disparate platforms.

According to O’Brien, banks should choose technology that is configurable and flexible so that it can adapt to their processes instead of having to change their processes to fit into the constraints of the technology. The more flexible and configurable the technology is, the more likely it is that their constituents in the business lines will adopt and use it. Since it may only be used quarterly, it should to be intuitive for the user. Also, it is useful to be able to tailor it to the individual, so that he or she sees data that is pertinent to them.

Not surprisingly, a significant amount of integration may be required depending on how sophisticated banks want to get in automatically populating internal systems. Generally, the system used for operational risk will have to interface with those that supply external loss data. It will also have to link up with the bank’s capital allocation engine, because calculating risk capital is very specialised and large banks have their own proprietary algorithms for that.

“There’s a lot of moving parts,” O’Brien notes. “That’s why I think most banks now aren’t trying to build this or put it all together themselves.”