SAP White Paper

TECHNICAL
REQUIREMENTS
FOR BASEL II
COMPLIANCE
Produced by Financial Insight

INTRODUCTION
Regulators around the world require the financial institutions

management practices into synch. The BIS has not yet finalised

they supervise to hold capital against potential losses, a practice

its proposals, and any recommendations it issues will need to be

largely designed to protect depositors and investors and to

interpreted by national regulators, so we can only make some

maintain a stable national financial system. The dispute over

guesses based on early statements made by some of the

how much capital is enough to promote safety and soundness

regulators. The regulations themselves will not be fully known

has raged for at least the last 30 years. Since 1988, the capital

until sometime in mid-2004.

ratio required by global regulatory agencies has been fixed at

8 per cent, as set forth by the 1988 Capital Accord. This was
intended less to reflect the level of risk taken as to provide a
cushion according to the institutions size.

Most major financial institutions across the world have

implemented enterprise risk systems to assess and report on
levels of risk exposure across the institution. Few systems,
however, can automatically generate regulatory reporting.

Over the past decade, financial institutions themselves have

Reporting systems, for any purpose, still leave a lot to be desired.

adopted the practice of allocating economic capital internally to

Regulatory reporting has three major components.

assess the performance of the institutions businesses (that is,

Data aggregation tools systems that gather data from the

users of capital). These measures, commonly referred to as risk-

various sources across the institution and transform it into

adjusted return on capital or RAROC, assess the profitability of

uniform or standard formats for further analysis.

the financial institution, given the level of risk taken.

Calculators systems that use the data acquired to calculate

This has led to the development of parallel capital management

ratios or other numbers required for regulatory reporting

practices: one calculated and reported to the regulators, and one

purposes.

by which to manage the business. Over the years, many have

Report formatting and output systems that take the raw

discussed updating the 8 per cent standard so that it more

data and calculated figures and put them in the form required

accurately reflects business practice and to motivate sound risk

by regulators, including both electronic and paper output.

management practices. It was not until 2001, however, that the

Most financial services firms have a team of people who spend

Bank for International Settlements (or BIS, the supranational

the vast majority of their time manually aggregating and

body that set the original 8 per cent) finally got around to

checking the data used to send regular reporting to regulators.

proposing the first draft defining a new capital standard.

Even when they automate some of the aggregation and

In January 2001, the BIS proposed a new standard for capital

formatting, they often need to manually check and amend data

adequacy that would bring regulatory and economic capital

for one reason or another. Much of the report preparation is

often done in spreadsheet software. Paper is also still very much

reporting and, as we have noted earlier, most are not particularly

a part of the data aggregation and report formatting process.

user friendly. Most institutions export the required figures into a

Although some vendors have created regulatory reporting

packages, very few have the ability to perform the required risk
management calculations. Even if the institution has licensed a

spreadsheet and then import the data into whatever reporting

software is used. Sometimes, they can simply format the data in
the spreadsheet and send it directly to the regulatory agency.

package for the actual report formatting, it must internally

Because the systems supporting regulatory reporting today are a

automate or manually perform the aggregation and calculation

rather motley collection of vendor and homegrown

pieces of the solution.

technologies, often held together by a great deal of manual

Credit risk reporting under the new Basle II recommended

amendments will differ greatly from its present form. Today,
regulators focus far more on expected losses and the process
determining the quality of the various parts of the portfolio.
The credit risk capital charge is not difficult to calculate and is
done at such an aggregate level that very little firm-wide data
needs to be assembled to prepare the necessary regulatory
reporting. For this reason, the systems supporting market risk
management reporting garner far more attention.

intervention, any changes to regulatory reporting requirements

are very painful. They require a reconfiguring of the process and
can be time-consuming and costly.

ADAPTING TO THE NEW REGULATIONS

It is difficult to sit down and define a risk architecture that
successfully meets regulators requirements. Because previous
incarnations of regulatory requirements have been relatively
straightforward, institutions have successfully created regulatory
reporting with minimal investment in actual systems or

The requirements for capital adequacy calculations under the

technology dedicated to this purpose. We believe, however, that

proposed internal models method for market risk are much

this latest round of changes in the credit and operational risk

more complicated than the current credit risk calculations.

capital adequacy guidelines will change this for two reasons.

Since the market risk portfolios in question are relatively well

Calculations are complex and specialised enough that

delineated, however, it is not very difficult to aggregate the data

automation will be required, and no existing automation can

and perform the calculations centrally. Many of the enterprise

fit the bill.

risk systems that do manage market risk have the requisite data

Potential reductions in capital will motivate institutions to

and can perform these calculations. In this case, an institution

create not just systems to support the calculations, but also

must frequently manually format and publish reports, because

those required for the testing and backup of internal models.

most of these systems were not designed for regulatory

Institutions may have got away with little or no technology

The internal ratings based approach (IRB) determines the

investment to meet regulatory requirements in the past, but we

credit quality and, therefore, the capital allocated to a holding

assert that these new recommendations will finally make it

using an internal system of credit ratings.

necessary to start to automate. With that in mind, here are our

thoughts as to what will make a risk architecture successful
from the regulatory perspective. We have divided our analysis
into credit and operational risk components because they are
quite different. It is possible, however, that they will share many
of the tools (and some of the actual systems).

CHANGES TO THE CREDIT RISK

REQUIREMENTS
The new Basle proposals on capital allocation for credit risk are
set up with two basic ideas in mind.

Both methods require far more detail on the portfolios of the

institution. The second, however, requires an entire documented
system of credit quality determination and credit decisionmaking based on that system. Table 1 outlines the minimum
recommended requirements an institution must meet to elect
the IRB method of capital adequacy determination.
TABLE 1: BIS-RECOMMENDED MINIMUM
REQUIREMENTS FOR IRB METHOD
IRB Minimum Requirement
1. Meaningful differentiation of credit risk
2. Completeness and integrity of rating assignment

The industry requires more differentiation in capital allocated

3. Oversight of the rating system and processes

to credit risks to better reflect the vast differences in credit

4. Criteria of rating system

quality between assets held.

5. Estimation of probability of default

Regulatory capital arbitrage and the desire to improve credit

6. Data collection and IT systems

decisions overall across the industry require that regulatory

7. Use of internal ratings

8. Internal validation

capital charges for credit more closely mimic market practice.

The BIS has designed two approaches for determining capital

9. Disclosure
Source: Bank for International Settlements

allocated to credit risks such that even smaller institutions can

comply, but they are clearly angled to persuade banks that can

The first four requirements do not imply any particular

use more sophisticated credit practices.

technology. The latter five, however, imply a technology

architecture, which we believe does not currently exist in any

The standard approach determines capital by the type of asset.

For example, bonds are bucketed by issuer and the credit
weighting determined by the credit quality of the issuer
(sovereign, corporate, municipal, etc.).

financial institution, large or small.

BIS II Required Credit Risk Technology

information to perform some type of economic capital

This is the first time that the BIS has explicitly included in its

allocation for internal management purposes. Beyond these core

recommendations a requirement for IT systems. Although the

areas, however, we expect that even the very largest will need to

BIS stops short of detailing exactly what type of systems will be

invest in credit risk technologies over the coming year,

required, Financial Insights thinks that the credit risk

specifically to meet IRB specifications. We expect all institutions

recommendations will need the following technology elements:

will have to make improvements in four areas.

data aggregation tools;

Standardisation of credit definitions The BIS

database for ratings and all inputs;

recommends that the credit ratings buckets be standard and

analytical tool for selecting factors and effectiveness testing;

applied consistently across the firm. This will require that

capital allocation tools; and

similar analytical tools be used across the firm.

regulatory reporting and disclosure documentation.

Historical ratings data The BIS recommends that ratings

Although these five elements will require the greatest change,

it is important to keep in mind that the BIS recommendations
explicitly state that the entire process must be integrated. That is, the
information used to determine credit worthiness and capital
must be the basis for credit decisions in the front office as well.
This implies a level of automation that flows all the way from
the credit granting/sanctioning operations, through the
origination groups, to portfolio management. Many institutions
that have credit decisioning tools in place will require
enhancements to both their processes and their systems to
comply with this BIS recommendation.

be tracked over time and compared to defaults to determine

the predictive value of the ratings.
Credit reference data The BIS recommends that all data
related to the internal ratings (including who determined the
rating, when it was determined, where, and using which
method) be stored for future use in back-testing the accuracy
of ratings.
Integration with front-office decisioning The ratings
information used for capital allocation must have an
operational role as well, supporting the credit decisioning
process.
In addition to these areas of advanced usage, firms determined

Most of the larger institutions across the world have some

portion of the needed elements already in place. Most have some

to use the IRB that do not currently have an internal ratings

system already will have to invest in the following technologies:

form of internal credit ratings in use. They typically already

have access to (and make some use of) external ratings
information where it exists. Most use this credit portfolio

credit information database to store information related to

customers, including relationships to other corporate entities
to which the bank may have exposures;

credit analysis to determine the rating bucket for each

of advanced management capability. Institutions wanting to

individual credit;

leverage their BIS II infrastructure for this purpose, however,

transaction/portfolio database to track outstanding and

will need to plan in advance to be sure they define hierarchies in

committed credit facilities using a single repository for

a manner consistent with their desired management approach.

transaction information;
default probability estimation to take available credit
information and create default probability by credit grade;
loss and exposure data to estimate future losses by credit
grade; and
capital allocation calculator to convert ratings and exposure
information into capital charges.

In summary, although many firms across the world (primarily in

North America, the United Kingdom and Germany) have credit
risk components in place that could provide the basis for
compliance with the recommendations for the IRB method of
capital determination, we expect that all institutions desiring to
use IRB will still be forced to augment their current systems.
These investments will primarily focus on collecting and storing

These investments in technology could easily add up into the

credit risk information and using that information to test

hundreds of millions of dollars, although some of these

internal ratings models.

functions may already reside in portfolio management or limits

systems and could be leveraged for these purposes. We expect
institutions will need to invest considerable additional amounts
in staffing and in defining internal credit processes before they
can use these rating for decision-making. Those institutions
planning to move toward the advanced IRB approach must also
be prepared to collect loss severity data sufficient to verify that
the severity assessments used in their risk estimates are indeed
accurate based on historical experience.
To prepare for a move toward a more comprehensive riskadjusted management framework, institutions must also
recognise that a finer level of detail would be required to push
capital allocation into each of the business units. The BIS II
recommendations help to provide the foundation for this type

THE ADDITION OF OPERATIONAL

RISK CHARGES
The BISs new proposals on capital are its first attempt to
quantify the cost of the industrys exposures to operational risks.
At its heart, the proposal tries to both standardize definitions of
operational risk and to motivate banks to begin to assess their
own degree of operational risks.
Judging by the clamor created by this first effort at quantifying
operational risk, much remains to be done to create industry
consensus on exactly how to manage operational risk. The BIS
is proposing three approaches to determine the level of risk at
individual institutions.

Basic Indicator Approach Institutions scale risk at the

whether or not the BIS institutes these recommendations,

firm-wide aggregate level using a single factor, such as net

operational risk has finally made it onto the regulators radar,

revenues. A flat percentage (originally 20 per cent, and now

and we believe its here to stay.

proposed at 12 per cent) is then applied.

Standard Approach Institutions, presuming exposures
(and, therefore, capital) differ by business line, choose a
scaling factor for each of a list of predetermined business lines
and hold capital accordingly.
Internal Models Approach Institutions determine key risk
indicators (KRIs) for all areas of operational risk across

Required Operational Risk Technology

A tremendous degree of variability exists in the technology
requirements between the basic indicator approach and the
internal models approach. The BIS primarily emphasises the
collection and analysis of data related to losses and key risk
indicators, which then form the basis for assessing capital
charges.

business units, to apply loss frequency and severity

assessments, and to determine capital requirements by scaling
accordingly.

Similar to the technology required in the credit risk guidelines,

the operational risk recommendations fall heavily on the data
aggregation and management capabilities of the firm. Unlike

The operational risk requirements proposed by the BIS are still

very much in a state of flux. Initially, many rumors speculated
whether or not the BIS would persist in its recommendation to
quantify operational risk, but it seems almost certain at this
point that it will require some quantification. A big question
remains: what should the likely recommended level of
operational risk capital be? Originally suggested to be 20 per cent,
it then dropped to 12 per cent. Recent rumors suggest that the
results of the QIS indicate it should be higher again. Issues like

credit risk, however, firms are likely to rely much more heavily
on outside sources of data, and this will weigh heavily on firms
that find this data difficult to come by. Data volumes are also
likely to be a challenge. Four major technology components are
needed to support the BIS recommendations:
loss history data collection;
key risk indicator data collection, tracking and storage;
loss severity and frequency estimation tools; and
capital charge calculators.

these continue to plague operational risk managers trying to

plan for future requirements, and they introduce a destructive
level of doubt into the industry as a whole.

Translating the KRIs and loss severity and frequency estimates

into capital numbers is a relatively trivial exercise that a firm
could likely complete using a spreadsheet without having to

Despite the still somewhat fluid nature of the operational risk

recommendations, we believe that adopting the basic technology
architecture we propose here is a sound course. Regardless of

invest in a sophisticated calculation engine. We expect the

second largest area of investment to be in analytical tools for
the estimation of loss severity and frequency.

Needed Enhancements

some progress in this area, but they will require further

Most large financial institutions across the world have some

investment to create data stores for operational risk data and to

technologies that they can apply to the new credit risk

gather loss information from internal and external sources.

recommendations, but the operational risk recommendations

Much like the credit risk recommendations, we expect that no

will catch many somewhat flatfooted. We believe most

financial institution will be prepared to adopt the internal

institutions have barely gone beyond an internal self-assessment

models approach without some changes to the underlying

of operational risk. Some stopped after defining operational risk

technology architecture.

and assigning responsibility for it, without actually providing

any support or infrastructure with which to build assessments
or management tools.

Timing
The deadline for compliance has been set for year-end 2006.
The BIS has already delayed this deadline, and the potential for

While the basic indicator approach does not imply much in the

further delays exists because the final document has yet to be

way of technology, the internal models approach will certainly

agreed upon (let alone published). Once the BIS publishes its

require quite an investment in infrastructure. For many

final recommendations, each national regulator will have to go

institutions, there is no infrastructure in place to leverage for

through the painful process of determining how to enforce the

operational risk, nor is there even a responsible organisational

document within its local regulatory framework. We expect that

unit to take the lead in creating such a thing. We believe that

it will be mid 2004 before the first of the actual regulatory

before an institution makes any investments, it will need to

requirements can be issued. Many institutions are thinking that

undertake quite a bit of internal work to just create the

21/2 years (between mid 2004 and year-end 2006) sounds like

organisational units and reporting structures needed to build

ample time to implement any required technologies. We believe

a team to tackle the issues.

theyre wrong.

Unlike credit and market risks, operational risks reside in every

A quick glance at the timeline overleaf shows that even if

organisational unit. Therefore, each institution will have to find

institutions were to begin today defining their internal

a way to leverage the business units to get operational risk

architectures and designing the internals systems required for

management data (and certainly in order to mitigate the risks).

compliance, there is barely enough time for them to implement

For the institutions that have already made this effort, the
biggest job is likely to be standardising data collection and KRIs.
Most of the worlds very largest financial institutions have made

a system on the scale that will likely be required. Our experience

indicates that implemented firm-wide data infrastructures
frequently require 11/2 -2 years due to the phased rollouts that are
generally required. Assuming a firm needs only 12 months to

build and validate all of the systems, that leaves barely enough

WHAT TO WATCH

time to do the rollout globally before reporting would begin.

As we sit here in 2003 looking at the current areas of investment

Find Data
Define Arch.

and effort, we find big efforts by leading financial institutions in

Build Regulatory
Reporting

Validate
Build db

Back-testing
Integrate with
Business Process

some obvious areas:

finding the data (for both credit and operational risk);
creating data aggregation and storage systems;
testing the predictive nature of internal ratings models; and

2003

2004

2005

2006

looking for ways to supplement missing or internally-

Figure A: Timeline for BIS II Systems Implementations

Source: Financial Insights

A further complication is likely to occur as these projects get

unavailable data (especially in the mid-tier corporate credit

world).

going and firms realise that they do not have the data required

Unfortunately for financial institutions, comparatively little

to do the calculations. These discoveries will require a firm to

help exists in the form of packaged software. Again, this is very

create and test proxies and alternate sources of data. This is

similar to other areas of risk management innovation. Business

likely to occur in both credit and operational risk regulatory

practices are likely to be a source of competitive advantage;

reporting systems.

therefore, the preference for early adopters is likely to be

We believe, therefore, that institutions hoping to be among the

first to adopt the IRB approach to credit risk or the internal
models approach to operational risk must begin work immediately.
Specifically, institutions must complete three early steps:

internal development. Of course, several consulting

organisations stand at the ready for those institutions that need
help to develop either methodologies or technology.
Software vendors have begun to enter the fray with commercial

search for related systems and data, including capturing

software aimed at both regulatory reporting and the internal use

information about source systems and formats, timing of

of capital numbers (for example, risk-adjusted performance).

uploads, and frequency of refresh;

Most of these solutions are still in development and testing and

plan integration technologies (such as extraction,

few are market-tested at the moment. The next six months,

transformation and loading, or ETL, technologies); and

however, should clarify which vendors will truly be supporting

map out data architectures.

fulfillment of the regulatory requirements. We expect that an

Completing these are critical to an institutions ability to move

forward quickly (without the worry of regression later on due to
poor planning).

institution will need more than one solution to get all of the
components covered.

PARTING THOUGHTS

save costs, institutions tend to ignore data transformation and

Before closing this article, we couldnt help but add a few last

upload tools. The more this part of the process is automated, the

thoughts about the state of the industrys risk technology and

better. If an institution truly cannot afford to implement sound

the impact of BIS II. First of all, we have no doubt that BIS II is

data management tools now, we highly recommend setting

a positive step in the right direction with regard to technology

forth a plan to do so as soon as possible. Long term, lack of a

investments. The new regulations will bring internal practice

sound automation strategy for data management will cost the

and regulatory requirements into much closer alignment,

institution dearly in terms of scalability, leverage of current

meaning that a single technology architecture will much more

infrastructure, and good old-fashioned cash.

easily support both purposes.

We fully believe that forward-looking institutions will be able to

Secondly, we applaud the BISs efforts to promote the use of risk

leverage these efforts into better decision-making, more efficient

information by the business line as part of daily decision-

resource allocation, and better overall performance. We are ever

making. Enterprise risk management has been the hobby of far

hopeful that enterprise risk management technologies are

too few business people across the industry. It is time the rest of

beginning to move further away from their beginnings in the

the organisation was forced to determine the value of the

back-office MIS function into a true area of competitive

information being created so that the whole process can evolve

advantage, allowing those banks that are good at risk

into something that can add value to the firm.

management to move ahead of their peers.

There is no question that full compliance with the IRB method

of credit risk or the internal models-based approach to
operational risk will require a large investment in technology.
We are hopeful that this time institutions will plan to stage
their investments in a way that allows them to correct for bad
assumptions or poor resource planning. At most institutions,
market risk management technologies have required at least
two, sometimes three or four, tries before they were successful.
This has led to a lot of wasted time and effort (and careers in
some cases). Lets hope weve learned from these failed efforts.
In an effort to move things quickly into implementation and

www.sap.com/banking