How to Select a Buy-Side

Risk Management System

While there is a great degree of similarity across commercially available buy-side risk
management systems, all systems are not the same - each has its relative strengths and
unique capabilities. The best solution for a large pension fund primarily focused on
large-cap equities will likely not be
the best solution for a hedge fund Mix of Business by Supplier
Mix of Business by Supplier
focused on fixed income arbitrage.
Varying styles of management
Algorithmics
present different requirements - a Algorithmics
Askari
Other Buy-Side
Other Buy-Side
clear case of “one size fits Askari
Barra
Insurance
Insurance
Corporate
nobody”. Individual suppliers BlackRock
Barra Corporate
Prime Brokers
have focused on different BlackRock
DBRisk
Prime Brokers
Hedge Funds
segments of the market. DBRisk
Measurisk
Hedge Funds
Money Mangers
Measurisk Money Mangers
Plan Sponsors
RiskMetrics Plan Sponsors
While here we will address the RiskMetrics
SunGard
Sell-Side
Sell-Side
macro selection process and SunGard
Wilshire
related key issues that you will Wilshire
0% 10% 20% 30% 40% 50% 60% 70% 80% 90%100%
want to consider, the micro details 0% 10% 20% 30% 40% 50% 60% 70% 80% 90%100%
© CMRA
of how each system satisfies
specific requirements can be found
in the Buy-Side Risk Systems Comparison Matrix found at www.risksystems.info.
The matrix currently covers more than 600 specific factors with detailed notes. For each
specific function, it shows the percentage of systems that either currently support or plan
to support it in the near future. In addition, www.risksystems.info includes further
discussion on how to select a buy-side risk management system and provides links to
leading suppliers’ websites.

What is a risk management system?

A risk management system is a computer application that utilizes statistical analyses to

quantify the risk of a portfolio. The key techniques used are calculating value at risk
(VaR), performing stress tests, and measuring risk sensitivities.

VaR estimates the largest amount that a portfolio is likely to lose over a specified period
of time at a specified level of confidence (literally the dollar value at risk). For example,
a 95% daily VaR of $1 million would mean that the likelihood of that portfolio losing
more than $1 million on the worst day is less than 5%. This in no way means that the
portfolio cannot lose more than $1 million. In fact, over 100 days one would expect the
portfolio to lose more than $1 million approximately 5 times. Furthermore, it does not
mean that one could not cumulatively lose significantly more over a longer horizon. This
calculation is based on the market performance during a specific historical period. The
length of the historical period used by the buy-side typically ranges from two to five
years. Managers with a short-term, trading-orientation might use a one-year historical
period (the typical period of the sell-side) while others have a long-term horizon (Ontario
Teachers, a pioneer in buy-side risk management, uses 14 years and Barra uses an
exponentially weighted 25 year history).

Stress tests help to answer the question of what the impact of extreme move scenarios
could be. We believe that stress testing is as important as VaR, if not more important.
VaR works well under “normal” conditions but fails to measure the potential impact of a
financial crisis. Many financial businesses that only used VaR during the fall of 1998
were very surprised at the significant losses that were sustained in an event that was more
than five standard deviations from the norm.

The greatest strength of VaR and stress testing is that they are statistical techniques that
transcend asset class. They provide a common vocabulary to measure and discuss risk.
Prior to the introduction of VaR, financial companies were “Towers of Babel”, with each
asset class having their own language of risk. These languages worked well within the
asset class but the asset class silos could not talk to each other, making it impossible to
establish the aggregate risk of all the assets classes combined. VaR is a meaningful
measure of risk for each asset class individually and can be used to establish a level of
risk for a portfolio that combines multiple asset classes. VaR explicitly recognizes the
correlation of risks across asset classes and provides an analytically sound basis for
determining the aggregate risk of a multi-asset class portfolio. Consequently, VaR
meaningfully measures the diversifying or concentrating effect of combining multiple
portfolios. VaR and stress testing have been established as the basis of determining
economic capital to cover market risk on the sell-side by the Basel Accord, an
international accord established by the Bank for International Settlement. VaR becomes
the common denominator for determining risk-adjusted returns (a next-generation Sharpe
ratio). A key requirement of the traditional buy-side is to be able to calculate VaR
relative to a benchmark (tracking error).

Risk sensitivities provide a causal understanding of the risk related to decisions that
traders and portfolio managers make. Prior to the establishment of VaR and stress testing
as the common denominators of risk, managers of each asset class had their asset-specific
measures of risk. These measures quantified the unique sensitivities of the asset class to
the specific risks to which they were exposed. For example, fixed income managers
used duration, derivative traders used the Greeks, and equity managers traditionally
measured sensitivities to sector exposures and various style factors (e.g., growth versus
value, small cap bias). In addition to providing the globally applicable VaR and stress
test sensitivities, risk management systems typically provide some or all of these asset-
specific risk sensitivities.

Furthermore, VaR provides a unifying framework to holistically combine all forms of

financial leverage. Portfolio managers can create leverage through borrowing,
long/short, selecting securities with high internal leverage (such as MBS inverse floaters
or high beta equities), and employing optionality. Everybody uses a different definition

2
of leverage. As with multiple asset classes, VaR provides a common denominator to
consistently measure all these forms of financial leverage.

Managing risk is not a mechanical process of simply running a risk management system
and with a single answer defining the level of risk. Risk is multidimensional and
constantly changing. The Heisenberg Uncertainty Principle, a key principle in physics,
says “The more precisely the position is determined, the less precisely the momentum is
known”. The corollary of this in the financial markets is
Recommended Set of Analyses
the more precisely risk is measured, the more the markets’
• A short-term VaR (one year history)
behavior change in response. Therefore, one has to be • A long-term VaR (five year history)
attentive in measuring risk requiring multiple viewpoints. • Multiple historical scenario stress tests
For example, we would recommend performing the set of • Multiple stress scenario stress tests
analyses be shown here.

These multiple viewpoints should be simultaneously reviewed and the stability of the risk
measures across analyses evaluated. For example, if three portfolios generated the results
shown here, most investors would prefer the Portfolio C because the results were the
most stable across scenarios, even though it performed the worst against a single
scenario. If Portfolio A used only a 1-year
period or Portfolio B used only a 5-year Annual Standard Deviation

period they would never have recognized 1 Year History 5 Year History

that the results were not robust. We Portfolio A 5% 15%

strongly believe that creating multiple risk Portfolio B 15% 5%

viewpoints is critical to fully understanding Portfolio C 10% 10%

the risk inherent in a portfolio. © CMRA

A risk management system should provide

meaningful management information on Trending VaR Sensitivities
risk (not just data). This should identify 60

causality, be at an appropriate level of 50

Risk Exposure %

summarization, be exception based, be 40

comparative, and be actionable. While the 30

majority of systems do an excellent job at 20

the micro level, they generally do not 10
provide good risk visualization. For
0
example, although all systems retain the
08/99

10/99

12/99

02/00

04/00

06/00

08/00

10/00

12/00

02/01

04/01

06/01

08/01

10/01

12/01

daily snapshot of risk, most do not have a

standard report or capability to trend risk USD/Yen ST Rate Volatility Growth/Value
© CMRA
over time, one of the most important ways
to view risk.

3
What are your unique requirements?

The most important step in selecting a risk management system is defining your unique
requirements. This includes defining the scope of coverage and functionality that the
system will be required to support. This can range from a simple requirement to provide
only risk management to a focused fund in a single asset class in a single geographic
market to a more complex requirement to provide the integrated systems’ functionality
necessary to support risk budgeting across diverse asset classes on a global basis to a
large plan sponsor.

It is also important to consider how your requirements may change over the next several
years. Risk cannot easily be added or consolidated across systems. If you plan to expand
into an asset class not adequately supported by your selected system (e.g., options,
MBS/ABS) or introduce portfolio analytics/performance attribution, it’s likely you may
have to migrate to a different system. While, as we‘ll discuss later, the implementation
cost for a simple portfolio can be relatively small, the investment of time to learn a new
system is costly. It is therefore desirable to select a system that will satisfy your
requirements over the longer-term. Consequently, you should be forward-looking when
defining your objectives in a risk management system. Focusing on defining your
requirements up front will make the selection process more efficient and will ultimately
make you happier with the selected system.

There are so many specific

capabilities supported by User Functionality Technical Business Specific

some, but not all, risk Front End Interface Software Package/ASP FASB 133
management systems that it is Report Writer Interfaces to Data Systems Pension Liabilities
critical to assess the ability of
Portfolio Hierarchy Data Supplier Interfaces Couterparty Credit
particular systems to support
Limits User Defined Fields Fund of Fund Structure
your unique requirements.
Each of these specific Screening Filtering Systems Security Risk Arbitrage
functionality is described in Model API OLE/DB Wrap Real Estate
the remainder of this
document:

♦ Front-end interface – Most systems provide a flexible tabular front-end interface.

This generally permits the user to select and control data elements across the columns
while selecting holdings/subportfolios/portfolios down the rows. Some systems
provide the capability to drag and drop this table into Excel and to easily present it
graphically. Some systems have the ability to present several VaR calculations as
multiple columns on the same table. This is useful as no single VaR fully captures
the entire picture. We recommend that a buy-side organization produce both a short-
term VaR (e.g., one-year) and a long-term VaR (e.g., five-years) so that you can
understand how the sensitivities have changed.

♦ Report Writer – Most systems do not have very flexible report writing capabilities.
They generally permit the user to print the table generated through the front-end
interface and some provide some level of automation in printing a series of these

4
 tables. Two solutions are suggested: (1) if the objective is to achieve flexibility with
minimal effort the solution is to create a ".csv" file which can be uploaded into Excel
or some other application (2) if the objective is to achieve a high level of flexibility
with rich reporting functionality (e.g., control of fonts/shading/italics, ability to
perform calculations in the report writing) the solution is to use a general purpose
reporting utility such as Crystal Reports (most large organizations already have such a
reporting utility in-house which can be used at no additional cost). Many systems
cannot easily report VaR over time, which we believe is an important tool in
analyzing the trend and monitoring style drift.

♦ Portfolio Hierarchy – Most systems flexibly support an unlimited hierarchy of

portfolios. The ease with which the front-end can move up and down this hierarchy
varies. Most systems have not developed the ability to use this hierarchy to
automatically drive reporting.

♦ Limits – Several systems provide functionality to establish limits and monitor that the
portfolio does not exceed these limits. The simplest and most effective solution for a
risk management system to report limit exceptions is to have it feed the email system
with messages when limits have been violated. The standard functionality in Office
or GroupWise permits emails to be automatically forwarded on a selective basis when
someone is out of the office.

♦ Screening/Filtering – Systems provide varying levels of capabilities to screen/filter

securities and establish a portfolio satisfying specific criteria. This includes selecting
based on a specific screen (all securities in a specific user defined grouping) to logical
conditions (all equities whose price-to-earnings ratio is less than 20) to complex
combination of conditional statements (all equities in a specific sector whose price-to
earnings-ratio is between 10 and 20 and whose market capitalization is greater than
$5 billion but less than $10 billion). Systems can support this in one or more of three
ways: (1) at loading, (2) statically, which implies that the data is applied once and the
results of the screening/filtering is retained, or (3) dynamically, which implies that
rule is reapplied as the data changes. Finally, some systems can use the results of this
screening to update security specific data (e.g., if the price-to-earnings ratio is greater
than 10 and less than 20 then set a specific user defined field called value-growth to
“medium”).

♦ Model API – Several suppliers provide “open” model APIs. They support either
multiple alternative standard models or permit users to implement their own
proprietary models. While this sounds very flexible, the majority of users will not
require this sophisticated functionality. It is most interesting for sophisticated fixed
income and derivative portfolios. The majority of suppliers have taken the attitude
that if a user requires a new model they will develop it and make it available to all
users. Given the broad instrument coverage supported by most systems and the fact
that most suppliers already have models that they have already developed and have
not yet implemented (e.g., quanto options) because no client has required them, it is
unlikely that this will become a relevant issue to any but the most sophisticated users.

5
♦ Proxy Support – All systems provide a basic ability to proxy equities with other
equities, risk factors, or indices/benchmarks. The majority of systems permit the user
to apply a beta factor to the proxied series (this is particularly useful if the proxy is an
index because the volatility of an index is less than that of an individual security).
Many systems permit the user to proxy using a linear combination of multiple series.
Some systems provide support in determining the appropriate beta and/or coefficients
for the multiple-linear proxy by providing a regression tool.

♦ Software Package/ASP – Risk management systems are generally provided as

software packages which the user operates in-house, “packaged solutions”, or as
applications that are provided over the Internet, “ASP solutions”. From a user’s
perspective, either alternative is equally satisfactory. For anything but the largest
buy-side organizations, the ease of not having to run the software internally
(outsourcing) is attractive. While any supplier will seek to earn a profit on the
operation of the software, there are significant economies of scale in ASP delivery,
and, therefore, the cost of an ASP solution can be very attractive (especially to a
small client).

♦ Data Supplier Interfaces – Suppliers have developed interfaces to industry standard

data providers and distributors. Many systems automatically interface to Bloomberg
to obtain necessary information including terms and conditions. Several suppliers
have developed interfaces to IDC and Fame.

♦ User defined fields – Most systems provide the user with the ability to define their
own fields and utilize them equivalently to the standard fields predefined by the
supplier in the front-end interface and the report writer. Of the systems that support
this capability, they generally offer the flexibility to define an unlimited number of
user-defined fields.

♦ System Security – While all systems provide a base level of security, the flexibility
of the solutions vary. Large organizations will want the security to be selective by
application (e.g., exclude a specific user from the limits management functionality),
access mode (e.g., permit a specific user to read but not update data), and portfolio
(e.g., provide a specific user with access to fixed income portfolios but not equity
portfolios).

♦ OLE/DB wrap – This is an industry standard interface that will permit the user to
pull the data into other applications such as Excel. Most systems do not support this
standard.

♦ XML – XML is a general technical standard to permit communication of data

between entities. Many industries have developed specific applications of this broad
technical standard in which all participants accept a standard set of definitions of
specific data elements that are relevant to the industry. This has not yet occurred in
those industries that capture or require portfolio information: custodians, money

6
 manageress prime brokers, hedge funds, institutional investors, pension funds, and
risk management systems industries. Several system specific XML solutions have
been implemented but the value of using an XML technical standard when there is no
accepted industry standard application standard is of limited value.

♦ FASB 133 – Some of the systems have developed specific functionality to support
the FASB 133 requirements. This includes logically linking hedge positions to the
positions they are holding and determining the effectiveness of the related hedge.

♦ Pension Liabilities – Some systems have developed specific functionality to support

pension fund requirements. All systems can accept pension liabilities as cash flows
and integrate them into the risk analysis.

♦ Counterparty Credit – Some suppliers provide support in managing counterparty

credit risk. Credit risk of bonds are treated as market risk by risk management
systems so this represents the credit exposure of the broker/dealer counterparty in
OTC structured trades (e.g., swaps, OTC derivatives). Several systems provide
netting of exposures and calculation of potential future loss.

♦ Fund of Fund Structure – Most systems do not currently support a fund of fund
structure. This is one in which multiple clients share ownership in commingled
accounts. One must explicitly acknowledge this relationship to accurately calculate
the risk profile of each client.

♦ Risk Arbitrage – Analyze the risk of risk arbitrage portfolios.

♦ Real Estate – Analyze the risk of direct investment in real estate. None of systems
currently handle this asset class.

♦ Distressed Debt – Analyze the risk of distressed debt holdings.

Which VaR methodology is appropriate for you?

There are three basic methods in wide use

for calculating VaR and two levels at METHODS
which these methods can be applied. You Historical Monte Carlo
Parametric
should understand the strengths and Simulation Simulation
weaknesses of each approach to make an Security 2 2 2
LEVELS

informed decision. The different methods

Equity Risk
of calculating VaR have varying abilities Factor 2 2 2
to handle optionality (non-linear © CMRA
relations), stress testing, complex fixed
income and derivative structures, risk
causality, fat tails, non-symmetrical distributions, aggregation of risk from multiple

7
systems, etc. Furthermore, some of the solutions are more difficult to understand and
explain. The three methodologies are discussed below:

♦ Parametric – When VaR was first developed by the sell-side over a decade ago, the
parametric approach was the standard because it was computationally extremely
efficient. The efficiency results from the fact that this is an “analytic” approach,
which directly calculates a solution, rather than the alternative approaches that
determine a solution by iteratively simulating potential scenarios. It remains an
excellent approach for a portfolio that contains minimal optionality and holdings in
highly efficient markets where returns can be expected to be normally distributed.
The parametric methodology evaluates options with linear approximations (delta
equivalent). As the sell-side introduced increasing levels of optionality and as
computers became increasingly powerful, the vast majority of sell-side organizations
have migrated to a simulation methodology, which can explicitly model the non-
linear relationships of options.

♦ Historical Simulation – The historical simulation methodology repeatedly values

current holdings based on the market conditions that existed over a specific historical
period of time. This has the advantage of being very intuitive. Unlike the parametric
and Monte Carlo simulation methodologies, no assumption on the distribution of
changes in market factors is required (the other two assume normally distributed
market returns and therefore historical simulation better handles fat tails (kurtosis),
i.e., extreme event risk, and asymmetric distributions (skewness), as are experienced
in relatively illiquid markets such as emerging markets. Furthermore, the historical
simulation methodology explicitly understands the characteristics of instruments with
non-linear behavior and analyzes based on historic market performance. Most sell-
side organizations have moved to historical simulation because it has the advantage
that in a complex organization each business can perform its own VaR calculation
and the results for each historical period (normally daily for one to three years) can be
simply summed and the aggregate risk (with correlations embedded based on history)
determined.

♦ Monte Carlo Simulation – Monte Carlo simulation can be viewed as a hybrid of the
parametric approach and the historical simulation approach (it is technically a
parametric approach). It uses the variance/covariance matrix that the parametric
approach uses to calculate an analytic solution to drive a simulation. The simulation
works similar to the historical simulation, but rather than simply using history as it
unfolded, Monte Carlo creates the history (called the path) based on the
variance/covariance matrix derived from the actual historic market data. For linear
instruments, the results of the Monte Carlo will be almost exactly the same as those of
the historical simulation if the variance/covariance matrix driving the Monte Carlo
was created from the same historical period that is used in the historical simulation.
However, for instruments that display non-linear behavior (optionality), the Monte
Carlo approach will appropriate measure the imbedded risk while the parametric
approach will not. We would generally favor the historical simulation methodology
over the Monte Carlo simulation (because it is simple and intuitive) for the basic

8
 calculation of VaR. However, when you are performing stress tests, Monte Carlo
simulation has the advantage that the parameterized history is significantly easier to
modify (e.g., a 10% decline in the S&P with all other risks moving based on their
historical correlation to the S&P) than the actual price and rate histories used in
historical simulation.

In addition to which VaR methodology to use, for equities there is a question of whether
the VaR analysis should be performed at the “security” or “risk factor” level. Even in a
data-rich market such as the US, equity factor models can explain only 40% of the
performance of individual equities (based on Barra research). The debate is whether the
calculation of the risk of equities should be driven by the equity factor model and all
other behavior should be viewed as non-structural specific risk or whether the risk
analysis should be performed at the security level and, subsequently, attributed to the
equity risk factors.

Supporters of driving the analysis based on risk factors will argue that using actual
history is “data mining”, a statistician’s term for looking for statistical relationships
where there is no reason for a relationship to exist, resulting in the misinterpretation of
spurious relationships as structural ones. Proponents of security level VaR would counter
that the equity factor models are too rigid and limited and that restricting the analysis of
risk to these relationships misses important “signal”. The debate is a classic one in any
information processing system between “signal” and “noise” - - if you filter out noise you
end up losing signal. There is no “right” answer - - each user should decide based on the
unique characteristics of their portfolio.

For long-only portfolios without

significant optionality all of the
Algorithmics

RiskMetrics
BlackRock

Measurisk
GlobeOp

SunGard
above solutions will work well.

Wilshire
DBRisk
Askari

Barra

This covers the majority of Method Level

“traditional” portfolios. If you Security

Parametric
are not a member of this Risk
Factor
majority, more in-depth
consideration of the alternatives Historic
Security

Simulation
is required. We would favor the Risk
Factor
security level approach for Security
portfolios that are explicitly Monte Carlo
Simulation Risk
playing spreads between Factor

equities. In some cases the No Yes Limited Planned

amount of optionality in a © CMRA

portfolio may be small in

aggregate, yet, if you are Excerpt from Comparison Matrix – Suppliers’ VaR Methodolgy
planning to hold individual
portfolio managers accountable for their risk and their risk-adjusted return, it may be
necessary to more accurately measure the risk of options at a level below the portfolio
level and the limitation of the parametric approach may be a relevant concern to you.

9
Will coverage be an issue?

Over the last several years

the coverage of the leading

Algorithmics

RiskMetrics
BlackRock

Measurisk
GlobeOp

SunGard
risk management systems

Wilshire
DBRisk
Askari

Barra
has grown to be relatively
comprehensive. However, Derivative Solutions

several systems do not

provide data. The major MBS Pricing
Engine
Davidson

systems support fixed Chasen

income, equities and Proprietary

financial derivatives. Except
for one, suppliers have Derivative Solutions

successfully integrated their ABS Pricing

Engine
Davidson
packages across asset
Proprietary
classes. Some of the
systems do not support Intex

physical commodities but Chasen

this has not been a common MBS Cash
Flow
requirement. All suppliers Trepp (CMBS)

have added credit spreads Proprietary

since the fall of 1998. All
Intex
suppliers are in the process ABS Cash
Flow
of adding or plan to add Davidson

implied volatilities. Davidson

Suppliers have added or plan
to add coverage of MBS Espiel

and/or ABS securities. Prepayment

Model
Derivative Solutions

Coverage has become quite

Bond Market Assoc
comprehensive and suppliers
are often willing to extend it Proprietary

even further to satisfy a

© CMRA
customer (if the data is No Yes Planned

available). For example,

Excerpt from Comparison Matrix – Suppliers’ MBS & ABS Solutions
suppliers will add a
government yield curve for an additional emerging market or create a provincial curve in
Canada.

What stress testing do you need?

There are two types of stress tests that risk management systems normally perform. The
first is actual crisis “historic scenarios”, which has the benefit that it preserves the
embedded historical correlation effects between markets and instruments when the crisis
happened. These represent such events as the 1987 stock market crisis, the 1994 ERM
crisis, the 1998 Russia/LTCM crisis, the 2000/01-technology meltdown, and the effects

10
of the September 11th terrorist attacks. “Unexpected” Financial Shocks
While all risk management systems do
a good job of calculating VaR, their 1987 1990 1992 1994 1995 1997 1998 1999 2000 2001

ability to adequately stress test historic

scenarios is limited. The limitation is
1987 Stock 1994 US
generally not a system functionality Market Crash Interest
1999 Brazil
Crisis
Rate Hike
problem but rather a data availability 1997 Asian 2000 Tech
1990 Nikkei
problem. Most systems don’t have Crash
Crisis Meltdown

adequate data to appropriately analyze 1994-95 1998 2001 Tech

the potential impact of a recurrence of Mexican Peso
Crisis
Russian Meltdown
1990 High Crisis
one of these historic events can have Yield Tumbles
on a portfolio. Systems that use a
1995 Latin 9/11 Terrorist
variance/covariance matrix as the American Crisis 1998 LTCM Attacks
basis of a parametric or Monte Carlo 1992 European
Currency Crisis
simulation VaR must prepackage these © CMRA
historic scenarios. Thus, a user’s
ability to select a specific scenario
depends on whether the supplier has included that event in its system. In particular,
correlations across risk factors tend to converge to one (become highly correlated) in
times of stress. Data that replicates these phenomena is critical. Other relationships that
should be captured in the data are spreads between on-the-run and off-the-run bonds and
credit spreads.

The second type of stress testing is “stress scenarios”. These are defined by the user and
generally represent significant step moves in the market such as a 100 bps shift in the
yield curve, a 10% decline in the S&P or a 100 bps increase in corporate credit spreads.
Some systems are flexible, others are not. Some systems provide the capability to move
all other risk factors based on the historical correlation between the factor explicitly being
stressed and the other risk factors. We believe strongly that one needs to stress test non-
parallel moves, correlations, volatilities, changes in liquidity, etc.

CMRA is currently in the process of establishing a standard set of scenarios that would
be available to all risk management systems. This would not only solve the data
availability problem but, more importantly, it would make the results from multiple
systems comparable and aggregatable.

Is comprehensive functionality important to you?

Two key trends on the buy-side have resulted in the increasing integration of historically
separate systems. The first is a move toward “front-to-back office” integration that has
resulted in increasing integration between trading, portfolio accounting, and analytic
systems. The second is a move toward greater integration of pre-trade analytics (asset
allocation and security selection), risk management, and performance attribution. Before
selecting a risk management system, you should assess your organization’s long-term
interest in cross-functional compatibility/integration.

11
Risk budgeting is a
comprehensive management
process that is being

Algorithmics

BlackRock *

RiskMetrics
Measurisk
GlobeOp

SunGard

Wilshire
DBRisk
implemented by the most

Askari

Barra
sophisticated plan sponsors. It Trading
ultimately results in assets being
allocated to managers on the Portfolio Accounting

basis of risk-adjusted returns. Portfolio Analytics

This is attractive because it fully
aligns the objectives of Market Risk Management

investment management with Credit Risk Management

those of the investors. However,
Performance Attribution
a strong and integrated set of
systems is required to support Performance Measurement

such a disciplined process. * Fixed Income Only

“Investors have begun to focus No Yes Limited Planned
on risk dollars spent to achieve
© CMRA
return. The increasing trend to
focus on reward and risk at the
instrument, manager and overall portfolio level has resulted in a need to ensure that
compensation and fees encourage the type of risk-taking that the primary fiduciary
desires.”1

A move to risk budgeting makes it desirable, if not necessary, to construct portfolios,

measure risk and measure performance using a common set of risk factors. For example,
if a portfolio manager takes a small-cap bet, the risk management system should
consistently identify this bet and analyze whether other portfolio managers are making
similar bets and whether this strategy is diversifying or concentrating the strategies of
other portfolio managers. The performance measurement system should consistently
measure whether this small-cap bet paid off. It would be difficult to have portfolio
managers developing portfolios based on one set of analytics, reporting risk on another,
and measuring performance on a third. If portfolio managers are ultimately compensated
based on the risk-adjusted return, then not reconciling the multiple measurements of risk
will result in energy being wasted on debating which measurement of risk is right rather
than focused on jointly analyzing how to most efficiently deploy “scarce” risk appetite.
It is this progression to risk budgeting, which is still in its early stages even with the
leading money managers, that has been the catalyst for the integration of portfolio
analytics, risk management and performance attribution. While most buy-side
organizations are probably some years away from introducing such a process, you should
assess whether this might be a direction in which you may want to migrate. If the answer
is “yes” you should consider alternative suppliers’ commitments to support such an
integrated solution.

1
Risk Budgeting: A New Approach to Investing. Risk Books-Leslie Rahl, Capital Market Risk Advisors

12
Should you select a package or an ASP solution?

Risk management systems are generally provided as software packages which the user
operates in-house or as applications provided over the Internet by an Application Service
Provider (ASP). From a user’s perspective, either alternative is equally suitable.
However, for any but the largest buy-side organizations, the simplicity of outsourcing is
attractive. Do you want to be awakened by a call at three in the morning to learn that
your in-house risk management system has a problem? While any supplier will seek to
earn a profit on the operation of the software, there are significant economies of scale in
ASP delivery and, therefore, the cost of an ASP solution can be very attractive, especially
to a small client. We anticipate that over the next few years suppliers currently selling
only software packages will also provide ASP solutions.

What support should you expect?

Risk management systems are extremely complex and sophisticated. The analytics
applied are inherently complicated, but when implemented in a system that provides
extensive user flexibility, as quality risk management systems do, the resulting system is
a challenge to learn. The objective should not be to sit down and learn the entire system
up-front (you’ll never get past the first step if you try this!) but to begin using the system
on a limited basis and to learn and grow through usage. This will not only keep your
frustration to a minimum, more importantly, it will ultimately focus your effort on the
functionality that provides the greatest value to you.

Suppliers recognize the inherent complexity of their product and therefore provide
extensive support. All suppliers include unlimited telephone support. Most suppliers
provide classes at their offices (the number and frequency of courses vary). In general,
suppliers provide limited free training at the client’s site and then charge for additional
support. Suppliers will often structure packages of additional support. These ultimately
end up being equivalent to a time and material relationship with an up-front commitment
(and potentially a discount). While the system suppliers are the best source of support on
the mechanics of operating the risk management systems, other consultants, such as
CMRA, regularly provide support on the interpretation, analysis, and presentation of the
risk information.

How should you evaluate price?

The prices of risk management systems vary significantly. The minimum price is
approximately $50,000 annually for a simple portfolio processed by an ASP. In contrast,
a very comprehensive in-house system for a large organization can cost over a $1 million
dollars annually. Given that the majority of the suppliers’ cost structure is fixed (e.g.,
development) there can be flexibility in pricing. Suppliers sometimes provide related
applications that are not included in the base system. Make sure you identify all the
additional applications that you might ultimately require.

13
In selecting a system you should look for functionality first and only after assessing
potential systems’ ability to satisfy your requirements you should negotiate price.
Remember, changing suppliers is costly and, therefore, your negotiating leverage
declines dramatically once you have committed yourself to a particular solution. You
should take advantage of the window before you commit to negotiate all implementation
costs and the prices of any additional applications that you may require in the future.
Furthermore, you and the supplier should jointly specify the level of on-going support
included in the standard package. Finally, as the cost of converting to a different system
is significant, you should seek to lock in pricing on a long-term basis. Given the
significant up-front cost of a new client for a supplier and the generally declining prices
for application software, suppliers should be willing to commit to a price that does not
escalate. However, as a hedge against inflation, linking pricing to an inflation index will
probably provide a greater level of comfort to the supplier. You should make sure you
and the supplier understand what future functionality is included in the package. For
example, if the supplier develops a portfolio analytics application, is that included in the
package or is that a different product?

How difficult is the system to implement?

The cost of implementation varies dramatically. We know of a large money manager that
spent over $5 million implementing off-the-shelf packages which required a significant
amount of custom integration to combine an equity and fixed income package and
ultimately created a massive data warehouse to consolidate input data and stage output
data. On the other extreme we know of simple hedge funds that have implemented ASP
solutions within hours and at a minimal cost.

Some suppliers provide significant

implementation support which is charged Key factors driving the implementation cost

on a time and materials basis, negotiated • Amount of customization

separately as a fixed cost contract or • Number of positions without unique identifiers
bundled into the annual price of the • Number of positions requiring proxying or special handling
• Number of system feeds
system. Other suppliers will refer their
• Complexity of reporting
client to a third party consultant. We • Legacy Issues
recommend that you push hard to make
the system supplier responsible for the
implementation with the expense bundled into the cost of the package. These factors are
discussed in detail below:

♦ Amount of customization – The most significant potential implementation cost is

customization. As the systems have matured, the likelihood of requiring
customization has declined dramatically. We would strongly recommend that you
attempt to avoid customization. If you have unique requirements that are not
adequately satisfied by any of the off-the-shelf packages, you should work with one
of the systems suppliers to incorporate this functionality as a standard part of their
system (even if you have to individually finance the development). The cost of
diverging from the standard package is prohibitive and can only be justified if you are

14
 truly a leader in the industry and can achieve significant competitive advantage from
a proprietary solution.

♦ Number of positions without unique identifiers (Sedols, CUSIPS) – The

implementation of holdings for which unique identifiers can be established is a highly
automated process and, as such, high volumes of these can be implemented at a
relatively small cost once the bridge has been developed. The implementation of
positions without unique identifiers (e.g., structured transactions) can be a highly
manual and costly process.

♦ Number of positions requiring proxying or special handling – Implementing

holdings such a private equity or real estate that require proxying or other special
handling (creating unique benchmarks) can be very time consuming.

♦ Number of system feeds – The greater the number of systems from which holdings
must be downloaded, the larger the implementation effort. If the entire portfolio can
be downloaded from a single source (e.g., a single middle or back office system, a
custodian, or a prime broker) the effort is relative simple. As additional sources are
added the effort increases non-linearly because of the difficulty of maintaining
multiple database in sync. Some very large and complex plan sponsors have spent in
excess of $1 million to develop data warehouses to consolidate and synchronize the
many feeds.

♦ Complexity of reporting – All of the suppliers provide basic reporting capabilities.

If the standard reports do not satisfy your requirements, all of the suppliers will
custom develop additional reports on a fee basis. Users who are interested in flexible
and sophisticated reporting generally utilize a report writing utility (e.g., Crystal
Reports).

♦ Legacy Issues – For firms that have existing systems and reports, these have to be
migrated to the new system. Depending on your willingness to rethink your
processes and formats, this effort can range from being relatively easy to quite
challenging.

Conclusions

The process of comparing these risk management systems emphasized how difficult it is
to understand what a specific risk management system does and how it does it. They are
incredibly complex, highly engineered systems. The differences are very difficult to
identify and evaluate. We tried to fully capture the differences by becoming increasingly
granular in our comparison, but we kept discovering new subtleties. Beyond comparing
specific functionality, the user interfaces are highly sophisticated decision support
systems with different approaches that look and feel significantly different.

15
Given this backdrop, there is no right answer - - it is a process of compromise and
tradeoff. The key to selecting the system that will best satisfy your needs is spending a
significant amount of time identifying those features and capabilities that are critical to
you. The suppliers will gladly show you all the unique “bells and whistles” that they
have implemented in their system. Don’t get seduced by them but focus on validating
that the system which satisfies your unique set of critical features/requirements.

16