risk management systems of responsible entities how to develop risk management system and risk management systems approach risk management system benefits
The Promise of Risk
We look at the current state of risk management systems. Installing a risk management system
is critical for the continuing business success of a company. Implementation is such a com-
plex process that it requires a project management methodology. We suggest RAMP as one
possible alternative for imposing management control. We look at some examples of system
Finally, we outline the deﬁnition of the client’s needs for the system. These needs are
translated into reality by an invitation to tender (ITT) process. A risk management project plan
example for implementation of the selected system is presented in the RAMP context at the
CURRENT STATE OF SYSTEMS
Financial institutions will chose their risk management paths and associated IT (information
technology) systems. A real-time online dealing system performs as the eyes and ears of
modern trading. Linked to a risk management nose for trouble, institutions should be able to
trade more securely and more proﬁtably.
There is strong competitive advantage to be derived from a powerful union of business and
IT. We have to look at the varying results and levels of success within the IT of many banks
and funds. There has been a mountain of literature published about the wonders of working
in the new information age. The dot-com craze certainly heightened this sentiment. But, the
resounding crash of the IT sector showed that there are real limits to marketing hype. There are
potential faults on both sides of supplier and client that raise unrealistic business expectations
in IT system delivery. Banking and fund management require skilled coordination between IT
and risk management that is focused on business success.
The complexity of ﬁnancial markets has increased because of the development of newer
products and services in an increasingly global economy. Derivative instruments also require a
higher level of quantitative techniques to cope with them. Back-ofﬁce clearing and settlements
systems do not always keep up with these technological advances, so mismatches will be
frequent with the advent of new trading products.
One of the most prevalent problems is that the antiquity of the major clearing and settlement
systems in the back ofﬁce has meant that they lack the ﬂexibility to be able to handle the welter of
new ﬁnancial products emanating from the front ofﬁce. Because of this, there is frequent recourse
to manual intervention and Excel spreadsheets, with all the attendant potential for error that this
Investor understanding in this respect has declined. Even bank top management has often
shed little light upon this extremely unglamorous failure. A huge ﬁnancial loss arising from
Operational Risk, p. 27, Middle Ofﬁce, spring 1999.
TLFeBOOK102 Investment Risk Management
a rogue trader is much more understandable than a consistent and innocent seepage from the
back ofﬁce and settlements. Risk management must be focused on accurate goals.
Was the IT project conceived in a manner where initial goals were realistic? These have to
be gauged against the bank’s resources and the IT supplier’s own input. When the business
culture of the ﬁnancial institution proves unsuitable to implementing an appropriate system,
this quicksand can sink a project before it is launched. Realistic expectations and a good idea
of project risk-return are essential pictures for top management to formulate before calling in
technology to solve a business problem.
It is advisable to consult RAMP or PRINCE 2 methodologies before plunging into the deep
end of complex risk management systems. Buying solely upon a salesman’s pitch or IT direc-
tor’s recommendation can be a sorry choice. Companies need the guidance of a methodology
such as RAMP. This is a blueprint that is ﬁlled in with data and ﬁnalised at the end.
RISK MANAGEMENT METHODOLOGY – RAMP
Activity A: Analysis and project launch
Deﬁne risk strategy.
Appoint a risk analyst or problem owner.
Outline the objectives and investment project scope.
Estimate people and skills required, investment complexity, budget and timetable.
Establish an investment project plan with baselines.
Estimate the “most likely” outcome, plus alternative pessimistic scenario.
Activity B: Risk review
Identify project risks, both likely and unlikely.
Analyse risks and their frequency plus probable impact.
Generate mitigation options and discuss them brieﬂy.
Create a risk matrix applicable to this project (cf. Basel II Loss Database).
Consult a Delphi group of experts familiar with similar projects.
Spotlight risks needing deeper scenario analysis and mitigation measures.
Pick cost-effective mitigation for each risk.
Deﬁne plan for each mitigation option.
Devise actions for handling residual risks.
Check risk measures with third parties.
Plan ﬁnancing of the risk management measures.
Get approval for commencing the risk management project with key stakeholders.
Activity C: Risk management
Implement the risk management plan.
Check that risk management plan is compatible with current management processes.
Check that contracts, ﬁnancing and insurance are compatible.
PRINCE 2, Central Computer and Telecommunications Agency (CCTA), UK, 1999.
RAMP (Risk Analysis and Management for Projects), Institute of Actuaries, 1999.
TLFeBOOKThe Promise of Risk Management Systems 103
Conﬁrm that that the risk management plan is properly staffed, resourced and funded for
Monitor the expected plan results against realised.
Monitor changing market conditions and the extent of risks present.
Revise plan actions where necessary.
Evaluate whether the investment project should continue.
Activity D: Project close down
Summarise the risk events with impact in relation to risks predicted.
Pick out the residual risks and risks unforeseen.
Conclude how successful the project was in ﬁnancial and risk management terms.
Close down the project with a report for key stakeholders.
Putting this into the RAMP context we can derive a risk management project plan. This is
presented as a brief example at the end of the chapter.
FINANCIAL IT SYSTEM SUPPORT
Financial IT development projects took a massive boost in the mid-1980s following “Big Bang”.
Open systems running on common client-server architecture became the industry standard at
the beginning of the 1990s and system choice for banks and fund managers increased. There
are now numerous vendors, e.g. Algorithmics, Barra, Erisk, Misys, Reuters, Sungard, who
will be happy to entertain you. The hardest job is to select which one (see: Value for Money).
Finding the right supplier can provide real business value-added service at a competitive price.
Technology has enabled a huge number of private investors to take part in whatever invest-
ment at a touch of a button. This has resulted in an unprecedented widening of the clientele
within global exchanges. But, technology increased the potential for IT and systems failures,
commonly lumped into the catch-all “operational risk”. Some banks have met spectacular
failures, or have been taken over by more capable and risk-aware banks.
Choose substance and not style in risk management systems. Many system vendors promise
to provide you with the “best” systems for every business line. We must choose the “best” IT
systems supplier to design and install our speciﬁc business environment.
Good use of IT is not about buying fancier computer boxes and designing jazzier websites.
All computer-based ﬁnancial modelling tools and complex IT systems promise to help you.
The Loss Database for Basel II is one product that holds a lot of potential. The question is
whether it will deliver. The key to success lies in its project implementation.
The Basel II Loss Database project
The new Basel II banking regulations are geared to raising the overall level of risk management
in banking and fund management portfolios. Basel II will enable regulators to request advanced
operational risk-managed ﬁnancial institutions to set up and maintain the Loss Database. It
has two business drivers, one a mandatory requirement and an optional “nice-to-have”.
First – all ﬁnancial institutions wishing to have the status of an “Advanced” risk-managed
company must comply with the Basel II. One of the requirements is the formation of the
TLFeBOOK104 Investment Risk Management
Second – there is the goal of detecting consistent patterns of loss, and extrapolating from
the data to predict the likely level of future business losses.
The ultimate objective is to reduce their level of losses and increase the predictability of the
remaining losses. The downside risk of this project is an expensive business and an IT white
elephant that does not meet business expectations.
A large global bank can have an expensive loss database, both in terms of number and
value of loss items, plus the huge project costs of creating the database. They cannot afford
to get it wrong because to do so would be both costly and embarrassing. Backing out a failed
loss database project from all global branches would also be a high-proﬁle noticeable loss
(compare: Reputational risk).
An operational loss database, driven by the desire for good management or by the regulators,
represents a large investment. An empowered band of ﬁnancial specialists can reap real rewards
for the company, supported by IT systems staff to “drill-down” within the loss database. This
data-mining involves ﬁnding out lines of causality for:
how much was lost
how much could have been lost
why it all happened in the ﬁrst place.
Loss databases will have to prove themselves against resilience-based approaches. These
data will be analysed time and time again under different data-mining angles. The real test will
be that of continual testing and review for cost-beneﬁt analysis.
The loss database is a potentially good corporate risk management tool, but, it is likely to fail
where it attracts little support within the corporation. Loss data are input for risk management
decision making, and it needs a lot of massaging into acceptable reports before it can help
to formulate director-level actions. The initiative stands or falls on whether top management
supports and funds it.
The beneﬁts are easier to predict than the costs. An advanced-certiﬁed operational risk-
managed bank will have lower Basel II regulatory capital charges because its risk management
processes are highly developed and evaluated as a lower overall risk. From previous regulatory
examples within credit risk, a bank could ﬁnd its regulatory capital reserve falling by some
How much this will translate into similar savings for OpRisk is to be decided by the regulators
interpreting the Basel II guidelines.
Risk appetite becomes more directly linked to risk offer, but risk appetite is also covered
by Basel II regulatory capital. Risk support systems alert the danger of capital becoming
inadequate to cover expected losses.
The loss database business rationale may be a search for lower risk ratings and knowledge
data-mining, forced on them by the regulator. The compliance “Big stick” approach of the
regulator may be better at explaining the need for the database, instead of the more complex
business cost-beneﬁt analysis.
Losing money has never been in the interests of a bank, nor of its clients. Yet banks and
investment funds continue to lose money without knowing where or why. There is some hope
Quantitative Impact Study 3, Basel Committee for Banking Supervision, May 2003.
Enterprise Risk Management, Professional Risk Management Association (PRMIA), London, 13 November 2002.
TLFeBOOKThe Promise of Risk Management Systems 105
Table 7.1 Loss data requirements
Loss Business Cause-effect Exposure Relief amount loss
Date (£k) line Result business lines rating party (£k) (£k)
1/3/04 136 Asset Mgmt Client lawsuit 2–4–5 0.4 AON 36 100
2/4/04 43 FX trading Late trade 7 0.9 None 0 43
Gross loss Event Likely casuality Risk transfer Final net loss
that this integrated database, linked to advanced modelling tools, can help make investing less
risky. It will most likely be a complex and expensive project to set up, mainly because of the
complexity and size of the data collected. See Table 7.1.
The formation of a complex loss database is a knowledge management structure that we
are actively constructing. It requires a lot of data and system integration to link the dis-
parate elements in a global bank. Some call this risk management system a “data warehouse”
where information is packaged into one compatible format for analysis (see Enterprise appli-
cation integration – EAI). The beneﬁts are the harnessing of market intelligence to understand:
who, when, how and how much money has been lost. Then, we can reinforce risk manage-
ment procedures to avoid such a loss recurring, or to reduce the loss when the hazard strikes
CASE STUDY: ALGORITHMICS SYSTEM IN A BANK
Bayerische Landesbank uses Algorithmics’ Algo Collateral to manage its current and future
cross-product margining requirements. BayernLB uses Algorithmics to update its trading
limit systems with intra-day collateral balances. A banking regulatory data warehouse is
then updated with capital requirements and collateral trade costs. Algorithmics Collateral
also checks for valuation discrepancies and monitors data changes.
Such systems perform various essential functions, namely:
Getting to the concrete system stage is putting everything from theory into practice. The
IT task sequence is relatively simple in theory, but complex in execution.
1) Deal capture data must be collected in a timely manner from the simple trading ticket
upwards throughout various application systems.
2) Standardise or pre-process the data into an acceptable and usable format. This can be
done using enterprise application integration (EAI).
3) Transfer into another application system – in this case the risk management system.
4) Analyse and distribute output and reports to relevant systems and departments.
Algorithmics, www.algorithmics.com, October 2002.
− − −→
− − −→
− − −→
− − −→
− − −→106 Investment Risk Management
Once the system design is successfully implemented, it has the potential to offer speciﬁc
competitive advantage to the business. These have functional beneﬁts of risk modelling
analysis, risk monitoring, procedural alerts and regulatory compliance. IT systems used by
experienced staff can reduce the risk exposure in bank portfolios successfully and cut down
Integration and straight-through processing (STP)
STP would help us reduce losses where the buy and sell orders are either mismatched or lost.
STP can reconcile trades and place them in accounts automatically by software packages. It
would be admirable to have fast turnaround and cut down mistakes on trades. Trade processing
errors can be costly, and they can be cut out using STP. Exceptions are costly; automating
exceptions when processing trades can reduce costs by 25 %. Yet only 30 % of 500 ﬁnancial
institutions surveyed have fully automated exception reporting. STP will help us detect errors
within our bank or fund, but will STP ever be implemented?
STP is the ideal sold by many systems vendors. But, in the real world where a front of-
ﬁce may have a 100 IT systems and subsystems, STP may be part of the Holy Grail. The
prospect of no accounting errors or orders mismatches is not borne out by reality. If an ac-
counting error creeps in, how are we to ﬂag it or reconcile it? It would be wishful thinking
to wave a magic wand over the risk elements of fraud, mismatched orders and operations
The idea of STP (see Figure 7.1) convey seamless processing between all three stages or
departments, without any hitches or signiﬁcant delays. There is no universal IT package that
will fulﬁl all functions in the front, middle and back ofﬁce.
Reality offers that one system vendor will eventually be called into the bank or fund and be
instructed to connect its new system to all the existing legacy systems. This means that we are
looking at a reduction of the number of IT systems and subsystems instead of an agglomeration
under one “Big Brother” system. A bank may think of buying a “vanilla” IT package, but they
really come in many different ﬂavours.
The systems market is diminishing with the cut-backs in ﬁnancial institution expenditure
and more banking M&A. This means further cuts in the choice of systems suppliers. Choose
one that survives.
Algorithmics, Barra, Sungard, eRisk, Pareto et al. are ﬁnancial system vendors that offer
“risk management” systems in one form or another. A web trawl can reveal a hundred names
or more for systems providers. All systems suppliers write one IT system and hope to resell
office office risk
sales and mgmt +
Figure 7.1 Straight-through processing
Exceptional Progress: STP, Exception Management, Sungard, November 2002.
TLFeBOOKThe Promise of Risk Management Systems 107
it many times. Their proﬁts lie in amending previously written systems, not in tailoring each
one from scratch for each customer. They are the greatest recyclers of our time.
For example, Reuters, Barra or Sungard should stress that there is no bog-standard “one-
size ﬁts all” package. Theirs is an adaptable systems tool-kit backed by a bespoke consultancy
service that includes tailoring to the business and portfolio of the speciﬁc bank or fund manager.
A company may buy a systems package with a ﬁxed price, but have to add 300 % for the
amendments, project implementation and support services. Even then, project success is not
guaranteed in any way.
IT systems project failure
Numerous cases of cancelled or failed IT projects in the ﬁnance industry happen on an alarming
scale. Many within the banking world are unreported because of reputation risk, i.e. risk of
losing clients or looking foolish in front of rivals.
There are four major reasons for IT systems failure:
The risk management system was initially unsuitable for the bank or fund and could not be
successfully tailored for use.
The skills base of the business project implementation was not properly understood or
Organisational politics or budgetary problems hindered progress.
Operational errors or poor systems design ruined chances of success.
CASE STUDY: IT OVERLOAD
Intelligent technology is programmed and managed by people, so there is a lot of room
for human error. IT systems failure (freeze or black-out) is one of the most well-known
disasters under the operational risk category. The London Stock Exchange trading system
fell down in 2000 because it could not cope with the load of processing trafﬁc. Its IT system
facility was managed by Arthur Andersen. The New York Stock Exchange had to install
trading “breaker circuits” to stop the unusually high volume of programmed trades crashing
the dealing system.
Spectacular IT collapses in trafﬁc happened because of human-organised hardware or
software problems. These can be “directed” or “undirected”. The notable hacker or virus
attacks are sent to speciﬁc destinations such as trading rooms. An electricity supply overload,
ﬂooding or short-circuitry in the computer room, or a drill piercing a telecoms cable in the
street – all man-made. From personal experience in banking, all have happened to us – they
could happen to you.
Disasters and system disruption arise from a variety of hazards:
56 % failure in hardware, software, telecoms, power.
24 % natural disaster: ﬁre, ﬂood, earthquake.
20 % malicious intent, including September 11th.
All of these IT threats can be managed or mitigated, not eliminated.
Delivering on your e-Promise: Managing e-Business Projects, Y.Y. Chong, Financial Times Management, 2001.
“White Paper on Sound Practices to Strengthen the US Financial System”, Sungard, December 2002.
TLFeBOOK108 Investment Risk Management
Tying ﬁnancial system functionality to promise
A company’s best move may involve buying in an IT vendor’s outsourced risk management
services. IT systems and services have been outsourced for many years now. Risk management
services in the ﬁnancial sector have generally involved external outsourced vendor systems and
experts. But, value-added services rely upon the deep understanding of the speciﬁc business
in question. The implementation of key risk management systems bought for the bank and
adapted from insurance initially sounds ﬁne; delivery can be something else. Tailoring it for
retail banking uses can spell a disaster, it need not be cost-effective in time or money.
Successful risk management initiatives must come from the directors at the strategic planning
level. Incremental addition of risk management systems or procedures may prop up the business
weaknesses, but they may not cure the structural illness of the organisation. The Barings and
AIB disasters showed that the directors either did not understand the target banking business,
or were not too bothered to monitor real performance.
A global enterprise dealing in several foreign exchanges requires a central resource for
effective internal corporate control. Otherwise, you end up with different divisions in parts of
the world with varying standards of business operation and risk. One of these enterprises could
have a business failure that could bring down the whole corporation.
A survey of US directors revealed:
43 % of company directors cannot identify, plan for, or safeguard against risk.
36 % do not understand major risks facing the company.
Companies that identify, plan and manage risk reap large potential business rewards. A basic
view of corporate wealth formation, and risk horizons, is that it is created by the:
1. Directors’ strategic leadership planning (long term)
2. Traders or fund managers’ proﬁt from tactical market moves (short term)
3. Risk management systems in place and effective (short to medium term)
4. Portfolio or assets of company appreciate in value (long term).
The fundamental ﬂaws of system design in the ﬁnancial company must be addressed before
technology. Errors can come about from undertaking a too short review and analysis of the
company needs before quoting the price for the contract. The immediate need is to estab-
lish a coherent risk management strategy, rather than a hotch-potch buying of fashionable
technologies and top names. It requires a plan and a project methodology.
What we ﬁnd when designing dealing environments for banks and funds is that risk manage-
ment and IT initiatives can be conducted piece-meal. The may be happy to pay 5 million for a
group of star-traders properly kitted out with the latest technology. They are reluctant to shell
out 500 000 for a risk management system that backs up best-of-breed redesigned business
procedures. Fixing the problem after the risk event occurs can cost hundreds of times more
A clear prioritisation with coordinated goal setting is required for mapping and management
of the risk areas and technologies. A risk map of designated business operations areas coded
US Directors Survey, McKinsey, May 2002.
“Delivering on your e-Promise: Managing e-Business Projects”, Y.Y. Chong, Financial Times Management, 2001.
TLFeBOOKThe Promise of Risk Management Systems 109
red, amber and green can demonstrate the project priorities. These can be input into the user’s
needs analysis for creating the design speciﬁcations in the “user system requirements” (URS).
Giving the go-ahead
Bringing the changes required for the desired risk management processes will be an arduous
task in itself. We deal with so different groups of people, crossing departmental boundaries.
All these introduce something novel into the company, and change management skills will be
needed to bring these new business processes to fruition. Deﬁnition of performance criteria,
underperformance penalties and budgeting is likely to be contentious. Securing support from
the directors will be a prerequisite for getting most large-scale projects off the ground.
Various representatives from the major departments and stakeholders involved are invited
to sit in a Delphi group to offer their views on the investment project. Sometimes there are
consultants brought in to present an impartial opinion of the corporate project risk map.
BUILDING RISK MANAGEMENT SYSTEMS
After selecting the desired staff, we have to install the technical elements of risk management.
It has to be emphasised that IT supports the business and not the other way around. The business
department should not go out alone to shop for the “best” risk management system; neither
should the IT department.
Financial risk management has to rely on specialised software. There are relatively small
ﬁrms that usually work with a limited number of clients. An extra customer won can make a
difference between boom and bust. Sales overcommitment can take over the aims of delivering
the most suitable product for the client at the best price. This sales scramble can lead to
Value-added systems rely upon the supplier’s understanding of the business in that situation,
the implementation of adequate security procedures and good quality staff. The business func-
tionality inherent within the risk management system may prove unsuitable for the speciﬁc
bank or fund. You can buy technology and marketing hype instead of system utility. We can
take a subjective view of technology for the sake of demonstration. See Table 7.2.
Finding the “best” risk management system
Searching for the “best” risk management system and service delivery constitutes a major
project in itself. This is known as the ITT (invitation to tender) process where we follow a rigid
methodology to get the best for us. It is likely that a more suitable product and service can be
obtained at a better price once we have gone through all ITT steps.
Table 7.2 Trafﬁc-lights/relative technology maturities
Technology Time to maturity (months)
Limit usage to minimum (red) Original CAPM 0
Proceed with caution (amber) Organic risk management 12
Invest as appropriate (green) Loss database 36
“Sound Practices for Operational Risk”, Basel Committee for Banking Supervision, July 2002.
TLFeBOOK110 Investment Risk Management
The invitation to tender (ITT) process
If you consider creating critical risk management functions within your company, you have
two general choices:
Build in-house, or
Buy from an outside party.
This dictates that your company has the adequate internal resources and scale to undertake
such a major task. With Basel II, this is further complicated by the small pool of talent able to
handle compliance and technical issues for market, credit and operational risk. Given the ex-
treme novelty of the Basel II “Three Pillars”, we will probably face a medium-term shortage of
able personnel to understand and implement the new regulations.
Specialised risk management has a dearth of skills available. Thus, the company is committed
to having the business skills in-house for understanding the risk management issues, and
outsourcing the technical skills for implementing the new system. This entails getting the
cocktail of talent right, i.e. combining ﬁnancial skills, risk management, change management,
project control, mathematical and IT systems experience.
It is more probable that you do not have all or enough of all the resources to carry out this
large project. “Buying in” is the preferred option when companies do not want to “reinvent the
wheel”. Some external personnel will handle part of the risk management, some the IT side.
This can range from speciﬁc technical tasks that require specialist advice, to wholesale design
and implementation of the entire system.
There are security issues at stake here because few banks and funds wish an external party to
know their ﬁnances and risk management status. Conﬁdentiality clauses are written into con-
tracts, and “Chinese walls” emerge to promise non-disclosure of sensitive data to another client.
The trust works both ways and it behoves a client to provide accurate data to the system supplier.
It is likely that the project size and risk management complexity will force a combination
of build and buy-in, with most companies preferring the buy-in route. Once inviting risk
management ﬁrms to design and install the business solution, some methodology must be used
to select the most suitable suitor. It is crucial to select the best long-term business solution
provider, not just for Basel II, but quite possibly for Basel III and all the follow-on work. We
have often gone into banks and fund managers and seen the client allied to the wrong business
solutions provider. The ITT is a bidding process that is worth conducting carefully.
BUSINESS FUNCTIONALITY REQUIREMENTS
The supporting detail of the grid, used for further analysis and line management purposes, is
contained in a risk functional cross-matrix, see for example Table 7.3.
Red warning lights show us the most critical systems to redesign or overhaul. Where de-
partments are already operating well, and currently get the green risk light, then there is no
immediate need to replace that subsystem. Nevertheless, systems engineers will often replace
that subsystem too and install a completely new one that is guaranteed to be compatible with
the rest of the new integrated system.
TLFeBOOKThe Promise of Risk Management Systems 111
Table 7.3 Risk functional cross-matrix
Department Front ofﬁce Middle ofﬁce and accounts
Function Mark-to-market Basel-type monthly Reconciling mismatched
positions compliance reports Forex trades
Performance status 5 3 1
(1 – good; 5 – bad)
Risk code Red Amber Green
A lot of the system satisfaction revolves around the functionality, that is, fulﬁlling the needs
of the users. The needs analysis comes out in the deﬁning document that is usually called
the “user system requirements” (URS). See Table 7.4. Such a vital document, in summary, is
circulated to interested system vendors in a communication ﬂow, initiated by the “request for
information” (RFI). This is a preliminary document that deﬁnes the summary of needs, and
the ﬁrm’s plans for upgrading systems. It gives enough data to inform systems builders if they
can meet the client’s needs, or not.
The ﬁnal URS is analysed in full and sent to short-listed system vendors in a contractual
document, usually called the “request for proposal” (RFP). It contains some data such as the
user’s functional needs.
User’s functional priorities
When you are designing a risk management system, you are searching for best:
time taken to implement
How you prioritise and assign weightings to these criteria is a subjective matter, and it
deﬁnes your company’s exact situation. Even getting the best price–quality ratio and product
involves the client in a calculus that offers more room for abstract judgement, rather than costs
and ﬁgures alone.
You will have to check interfacing and efﬁciency of sharing data with the new programs.
Otherwise, system integration difﬁculties can bring your risk management system that “speaks”
English into a German bank with a French accounts system. The company’s central IT depart-
ment may specify an Esperanto of XML as a mediator language for translating between the
bank’s myriad systems. XML serves as a universal format for translation that also ports well
to the Internet. Shared data can be sent over all the bank’s operational centres world-wide in
this way. The complex design issues and the need for linking many disparate systems grow
ever more insurmountable with a global corporation.
A world-wide ﬁnancial company is likely to have several risk management systems, includ-
ing all the “legacy” systems. This indicates a need for sophisticated integration, with the bank’s
risk management system at the epicentre. The system can sit in the middle, linked by an EAI
intermediary layer or module – see Figure 7.2.
“Delivering on your e-promise: Managing e-Business Projects”, Y.Y. Chong, Financial Times Management, 2001.
TLFeBOOK112 Investment Risk Management
Table 7.4 User system requirements
Department Front ofﬁce: Forex Middle ofﬁce and accounts
Requirements Current system Current system Current system
The new system has to This group includes This groups consists of 24
replace our whole Forex 15 staff, including chief staff including head of
front-ofﬁce dealing risk ofﬁcer. They use accounts. The current
system. This trading Barra and Reuters system is provided by
group has 32 dealers Kondor + systems. Midas-Kapiti (MKI).
(plus 1 FX group head)
using Reuters dealing
They process market There are about 15 000
systems. The treasurer
reports for the front daily trades (equities,
and 5 other users in
ofﬁce and back ofﬁce. bonds, FX) made during
middle ofﬁce and Back
Other destinations are the day (07:00 to 18:00
ofﬁce and accounts
FSA, BoE and our HQ London time). Currently,
must have access to this
in Germany. There are some orders are taking 4
system. All these users
an estimated 25 daily hours to clear the back
have Compaq EVOs
reports processed per ofﬁce. There are
512 Mb RAM under
day. Other reports are requirements to bring
produced weekly, this down to 1 hour
Datafeeds monthly, quarterly and maximum on average.
There are also live price yearly. We are reconciling about
feeds coming in from Dealers require daily 40 mismatched Forex
the Bloomberg system, reports and valuations of trades per day. This may
our afﬁliate bank in their portfolio. These come from unknown
New York and our must be generated for counterparty. The list of
central bank. There are their positions within clients is run in an Oracle
approximately 5000 15 minutes of their DB that is slow to access.
daily trades made request.
during the day (07:00 to
Basel II compliance There are 140 types of
18:00 London time). We
B-II reports are required reports coming from
for FSA. We will require back ofﬁce. This takes a
position reports at
assistance meeting these lot of workload that we
midday and at the close
standards for AMA are trying to cut down.
of business day.
measurement) level. We
We want 99.95 % system will want you to help us
availability during the meet compliance for
business day. further EU regulations
The interfacing and data conversion difﬁculties between the different business programs
and suppliers may tend to work against easy linking of an enterprise-wide risk management
For this reason, the company may take a strategic policy for IT standards, e.g. something
on the lines of:
For all global ofﬁces. To standardise our IT systems, we stipulate that:
All mainframes will be supplied by IBM, all servers by Sun Microsystems or Compaq, all PCs
from Compaq or Dell, all operating systems either IBM-AIX or the latest Windows. Bloomberg
will be our preferred dealing systems supplier and integrator, with MKI for back ofﬁce and Sungard
for risk management. Deviation from these standards will have to be approved by IT department
TLFeBOOKThe Promise of Risk Management Systems 113
Bank’s separate market data
feeds: Reuters, Bloomberg,
Bank’s central risk
Figure 7.2 Risk management systems and EAI
No supplier ever meets 100 % of your needs perfectly. A compromise solution can be devised
to ﬁt your speciﬁc business requirements. Various interpretations surround the notion of “best
system supplier”. Judging rival suppliers is the most complex part of the ITT selection. It
comprises designing and selecting the “best” supplier and then integrating its risk management
system into your company. You select the “best ﬁt” with your performance demands.
The ITT matrix evaluation needs a lot of company raw data to compare with suppliers’
ability to meet these requirements. Use all information to score their likely performance. It
is viewed as an audit of their risk management overall skills. The ITT process reduces the
probability of picking an unsuitable system or supplier.
Business ﬂirting – the user’s system speciﬁcation
Business functionality plus conclusive “value for money” seems to be the conclusion of the
ITT process. Many of the desired business functions can be graded by your team into:
Red – mandatory, this could be a show-stopper.
Amber – medium priority, a function that is nice to have.
Green – low priority, not essential.
Business ﬂirting – the supplier’s reply
Then, the risk management supplier can respond to your functional requests:
Already provided by us.
Can be provided by us (estimate costs and time for this).
Cannot be provided by us.
The deﬁnition of a suitable business function can be done top-down. The risk management
system has to ﬁt your business line, and not the other way around. See Table 7.5.
Then we can deﬁne the function by whether they meet the product lines that you are already
dealing. See Table 7.6.
We can demand the speciﬁc function down to lower detail. See Table 7.7.
TLFeBOOK114 Investment Risk Management
Table 7.5 Supplier’s risk management functions
Supplier A Supplier B Supplier C
Business line complies complies complies
Investment bank X X
Retail bank X X X
Savings bank X X X
Insurance company X X
Life assurance X X
Pension fund X X
Mutual fund X
Table 7.6 Risk management by product line
Supplier A Supplier B Supplier C
Product line complies complies complies
Forex spot X X
Forex futures X X
Commodities (grain) X X
Commodities (oil) X X
Energy derivatives X X
Bonds (sovereign) X X X
Bonds (US corporate) X X X
Judging the ITT beauty show
The screening process of the suppliers can be long drawn-out, but it has to be methodical and
it has to be done well. This mix of weighted-criteria process is sometimes called a beauty
contest. It can be done in secrecy with sealed bids to only invited suppliers. Or it can have all
interested suppliers bidding. The selection process is certainly more objective with the ‘lowest
bid wins’, but it can leave out the user’s needs considerably. Therefore, the argument for user
functionality has to be spelt out for all. You can include the system criteria, or priorities, you
deem important. See Figure 7.3.
Table 7.7 Risk management functionality
Function Speciﬁc Supplier A Supplier B Supplier C
Mark-to-market Delta X X X
(MTM) Gamma X X X
Vega X X X
Theta X X X
Convexity sensitivity analysis X X X
Discontinuous product (Binary option) X
Discontinuous product (Digital option) X
Real-time charting X X
3-D charting X
Export to Excel X X X
E.g. refer “Contractor Qualiﬁcation”, Ron Prichard, www.IRMI.com, August 2000.
TLFeBOOKThe Promise of Risk Management Systems 115
Speed of implementation
Figure 7.3 System priorities
An extract of the selection matrix for your ITT is shown in Table 7.8 with more criteria and
three supplier companies: A, B, C.
The winner, supplier C, can be graphed to determine its relative compliance with the user’s
wishes. Using a radar graph, we see that the winner covers the most area for the major selection
criteria (Figure 7.4).
Once you got this far, the ITT does not in itself guarantee the best system available anywhere,
but it cuts down the chance of being sold an inappropriate risk management system. It was
worth getting this.
Table 7.8 Supplier selection matrix
Criteria Max. marks Supplier A Supplier B Supplier C
Business functionality 30 21 20 24
Price 10 7 7 5
Speed of implementation 10 6 7 6
System integration 5 3 3 4
Reliability 5 3 3 3
Security 5 4 3 4
Scalability and global support 3 2 1 2
FSA certiﬁed risk-compliance 3 1 1 2
Financial strength of supplier 3 1 2 2
Experience in industry 3 1 2 3
Reputation in ﬁnancial sector 3 1 2 3
Presentation skills 10 7 5 7
Our general conﬁdence in them 10 6 5 8
Total max. possible marks 100
Overall marks 63 61 73
Our decision Second Third First
TLFeBOOK116 Investment Risk Management
Figure 7.4 Meeting the user’s system needs
Project life cycle
On the client’s side, the project performance can be anybody’s guess until the software func-
tionalities have been tried in operation on go-live day. Some systems and technologies are on
a life cycle, both in terms of maturity as well as industry acceptance. When you are way ahead
of rivals, then you may be on the bleeding edge phase of the life cycle where there are few
teachers available to learn from. See Figure 7.5.
Innovators / Early Crossing the Early majority Late majority
bleeding edge adoptors / chasm / / early / late late
bleeding edge bowling alley mainstream mainstream
Figure 7.5 Project life-cycle
TLFeBOOKThe Promise of Risk Management Systems 117
Financial software houses seek a bigger market share, so underselling is never likely to be a
ﬂaw. We still ﬁnd some banks wondering whether the software suppliers want to be committed
to delivering service, or was it really just sales spiel?
We should concentrate on justifying the business case and establishing goals before shopping
for systems. Senior executives should then try to meet the deﬁned risk management objectives
ﬁrst. Risk management systems serve to improve overall company performance by meeting
business needs, not to serve as a goal in its own right. Building a strategy for implementing
risk management is as important as creating the risk management systems. Both need a plan.
RISK MANAGEMENT PROJECT PLAN
We can take the RAMP template for risk management to derive the project plan.
A – Our risk strategy
This is to provide effective and timely support for all the banking staff to cope with market
developments over the next 10 years. Meeting challenges for the bank include:
Evaluating and reporting of strategic long-term risks for the board of directors.
Handling new products, particularly securitised assets and equity derivatives.
Online, real-time mark-to-market pricing for front ofﬁce.
Basel II compliance reporting up to AMA (advanced measurement approach) operational
risk level. We will want to meet compliance for further company disclosure policies, which
we believe will tighten with future legislation.
Middle ofﬁce will continue to be led by our chief risk ofﬁcer. We intend to recruit an extra
12 staff over the next three years. We plan for all our new risk management systems to be
online and operational by 1 January 2005. The capital spend on this system is forecast at
€7.5 m spread over three years. Our annual budget is forecast for€15 million, commencing
on that date. Online availability will be 99.95 %. Our customer satisfaction among our users
will rise by 10 % from current benchmarked levels within three years.
B – Risk review
We have analysed the project risks and tabulated their likely frequency with our company
staff and consultants who are familiar with such projects. We have estimated probable impact,
highlighting extremely damaging events in a risk register (Table 7.9). Where such project risks
are critical, i.e. potential show-stoppers, we have outlined likely alternatives for risk mitigation.
The project risk register for this project is outlined for the ﬁrst six risks only. Residual risks
are listed at the end.
C – Risk management
Implementation of the risk management plan (“plan”) is congruent with the strategic aims of
the company to be a competitive investment bank in western Europe. This plan ﬁts in with
current management needs and envisaged development of business processes up to end 2009.
Phil Dinsmore, vice president, ERisk, www.Erisk.com, January 2002.
TLFeBOOK118 Investment Risk Management
Table 7.9 Project risk register
Risk Prob. Impact Mitigation
Project budget 15 % Depends upon overshoot We have signed-off project
overshoots (amber). Contract states budget of€ 7.5 m and a
signiﬁcantly where 100 % vendor’s fault, contingency fund of
then they pay. Our € 900 000. We have contract
contractual contribution to terms to force vendor to pay
them is capped at 12 % of for all their errors.
total budget for force
Bank wants to cancel 10 % This has a major (red) impact. Board has to understand that this
project Will leave our risk systems project is mission-critical. We
5 years behind our main have signed approval for up to
rivals. €12 m and 14 man-years
System supplier goes 18 % This has a major (red) impact. Pick a supplier company that is
bust Modest risk (amber) if large and robust enough to
supplier taken over. Will maintain independence.
probably add 2 months to our
System not up to 22 % Experts believe this has a major There are likely to be some user
users’ expectations (red) impact. Only modest grumbles. Train all staff
or usability impact (amber) if supplier beforehand. Brief all users
taken over quickly. Will long before so expectations
probably add 2 months max are in line with delivery.
to our risk systems
Hardware downtime 5 % This is a modest (amber) We have a service level
1% impact where were are agreement (SLA) with the
talking minutes. Any more vendor. Red impacts are
downtime 45 minutes compensated by vendor at
becomes major (red). 1000/minute downtime.
Hardware lost in 1 % All power appliances have IT centre is locked within
natural disaster shielded electricity supply blast-proof doors with ﬁre and
with backup for 2 hours. We water alarms, manned and
estimate chances of full loss guarded 24 hours/day.
at c. 0.002 % based on Hardware insured by Royal
industry ﬁgures (i.e. so slight Insurance for€10 m
that we have green risk). replacement cost.
The contracts for all stakeholders and suppliers are listed in Appendix A. The contractor IT
system contract is in Appendix A.2.1. Financing terms and conditions from the bank are listed
in Appendix C.1.2. Insurance policies for this project are held in Appendix A.2.1.
The plan is to be staffed by a full-time project manager, resourced with three full-time persons
and two part-time from middle ofﬁce. It is adequately funded for successful completion by the
board who gave the plan full support 1/3/2004. The chairman’s annual speech reiterated this
We will use Primavera Project to monitor the plan progress against realised events.
TLFeBOOKThe Promise of Risk Management Systems 119
The project manager is empowered to make revisions in the Plan. Where actions have amber
to red impact, there will be a meeting of the project steering committee to agree changes. Low
level (green) changes can be agreed where necessary between the project manager, bank line
managers and supplier’s staff.
Periodic evaluation over the investment cost-beneﬁt and the progress of the project will be
D – Project close down
We will summarise the risk events with impact in our risk register for risks recorded. The
residual risks are to be listed together with ad hoc mitigation measures. We estimate very good
chances (82 %) of a successful project.
The project will conclude with a wrap-up meeting, scheduled one month after implemen-
tation. There will be a report for key stakeholders detailing variances and errors recorded.
Recommendations for project amendments and maintenance will be made then.
The project plan is a risk-managed blueprint for success.