Tải bản đầy đủ
2 Valuation - validation of end of day prices

2 Valuation - validation of end of day prices

Tải bản đầy đủ


Manzanares, A. and Schwartzlose, H.

simultaneously, but independently, freezes the prices for all instruments by
its own means. The latter consist mainly of an in-house application that
conducts the freezing, i.e. connects to wire services and saves the prices
obtained from them at a time selected by the user. Immediately after
freezing time, the portfolio management system prices are compared to the
prices frozen by RMA. Corrections are only processed if two market sources
converge and both differ from the FinanceKit price by more than a threshold
amount set a priori for each asset type. In such cases, the most reliable market
source is taken for correction of bid-and-ask quotes.
RMA has access to two wire services – Reuters and Bloomberg – that
generally are regarded as good quality sources of market quotes, for the
majority of market sectors. Their prices are filtered by proprietary rules that
aim at ensuring their quality (e.g. Bloomberg Generic Prices or Reuters
composite prices). However, these two wire services may not provide
tradable quotes, since RMA does not have access to tradable quotes from,
for instance, neither the Bloomberg trade platform nor Reuters’ link to the
GovPX quote database, which is the largest electronic trading system for the
US bond market.36 Despite these limitations, Bloomberg still allows to select
a concrete entity as quote source, if the general Bloomberg quote is considered not reliable. To a lesser extent, Reuters may also make several data
feeds which can be tapped, simply by adding a source code to the RIC, after
the ‘¼’ sign. When none of these options is available, the suffix RRPS may
be used. RRPS stands for Reuters Pricing Service and is the Reuters
equivalent of Bloomberg Fair Value, i.e. a synthetic price calculated from
the curve by Reuters for less liquid instruments.37 The quality of sources has
been tested empirically and has improved over time thanks to discussions
with and suggestions received from portfolio managers.
4.3 Validation of prices transacted at
Often deals are completed on the phone or through a system that is not
linked to an institution’s portfolio management system. Hence, the data
associated with a trade often needs to be re-keyed into the portfolio management system.38 To ensure accuracy it is common practice, at least in


Access to GovPX prices to Reuters was considered too expensive if exclusively used as price source.
As illustration, the thirty-year Treasury note with ISIN code US912810FT08 (as of mid November 2006) has the
Reuters code 912810FT0¼RRPS and the Bloomberg code T 4.5 02/15/36 Govt.
In order to be able to ensure limits compliance prior to agreeing a trade a portfolio manager would need to enter the
deal (at least tentatively) in the portfolio management system prior to agreeing it with the counterpart or submitting


Risk control, compliance monitoring and reporting

the central banking world, to apply the four-eyes principle to deal-entry.
A ‘workflow’ is defined where one trader agrees the deal with a counterparty
and enters it in the portfolio management system and another trader is
responsible for verifying the details of the deal and then finalizing it vis-a`-vis
the portfolio management system. After the commitment the deal will typically ‘flow’ to the back-office for settlement. Even if the four-eyes principle is
applied an additional control may be considered, namely the validation of
the price transacted at (and entered into the portfolio management system)
against the prices prevailing in the market at the time the transaction was
concluded. There may be two reasons for applying such additional checks:
1) it reduces operational risk further, in the sense that it may catch a keying
mistake, that went unnoticed through the first validation control and 2) it
could potentially act as a guard against fraud where a trader intentionally
trades at an off-market price disadvantageous to their own institution.
In the case of the ECB the four-eyes principle is applied to all deals entered
and, the portfolio management system additionally performs a check of the
prices/yields of all transactions entered. Moreover, instrument class specific
and maturity-dependent tolerance bands, determining permissible deviations
from market price at the time a transaction is entered have been configured
in the ECB’s portfolio management system. Whenever a transaction is
committed the price/yield of the transaction is compared with that observed
in the market (i.e. to the latest price/yield for the instrument as seen by the
portfolio management system through its market data services interface).
If the price discrepancy exceeds the pre-defined threshold, the system warns
the trader and a log-entry is generated. If the price is correct the trader may
choose to go ahead anyway. On each business day, RMA inspects the logentries for the previous business day and compares (using market data services) the prices/yields transacted at, with those in the market at the time the
transaction was carried out. If the price can be confirmed, a note is made
against the log-entry with an explanation (stored in the risk data warehouse);
otherwise the trader who carried out the transaction is contacted in order to
obtain an explanation and/or a proof of a contemporaneous market quote,
which then, if plausible, is noted against the trade.
If no plausible explanation can be obtained, a procedure analogous to
that for limit breaches is initiated. The Head of RMA formally requests the

it to an electronic trading system. ECB rules stipulate this to be the case and a deal must be fully finalized in the
portfolio management system within a maximum of 15 minutes after the deal was agreed.


Manzanares, A. and Schwartzlose, H.

head of the NCB Front Office to submit a formal report to RMA on the
business day following the day that the report was requested. The report
should detail why the trade was concluded at this particular price. Should
the explanation given not be satisfactory, procedures analogous to those
defined for limit breaches are followed (see Section 4.1). Checks are performed against mid market rates (price/yield). In case a yield is entered for
an instrument whose reasonability check is price based, the traded yield
is first converted into a price and then the reasonability check is applied
against the price corresponding to the traded yield. Tolerance bands are
symmetric and reasonability warnings may result from both trades concluded above and below market prices. The tolerance bands are calculated
separately for each market (EUR, USD and JPY), for each instrument class
and for each maturity bucket (where applicable). This separation of instruments reflects that price volatility depends on time to maturity.
The market rate prevailing when the deal is entered into FinanceKit is
used as the benchmark rate for the comparison. Updates or modifications
made to the deal later do not change this. For instruments with real-time
and reliable market data in FinanceKit, an hourly data frequency is implicitly assumed as the basis for the tolerance band estimation. The hourly
frequency instead of a lower frequency was chosen in order to account for
the time lag that persists between the time a transaction is made and the
time the transaction is input and compared against the market price. It also
takes into account that independently of any time lags, transaction prices
may deviate slightly from the quoted market prices. All instrument classes
without a reliable intra-day data feed are checked against the frozen 17:00
CET prices of the previous day. The methodology applied to calculate the
rate reasonability tolerance bands is described in Box 4.2.

Box 4.2. Calculation of rate reasonability tolerance bands at the ECB
The tolerance bands are always calculated on the basis of historical market data with a
daily frequency. Hourly tolerance bands are obtained by down-scaling the daily tolerance
bands by the square root of eight. It is assumed that there are 8 trading hours a day, and
that normally, the period between the recording of the price from the price source and the
transaction would not be longer than one hour.
The tolerance bands are re-estimated annually according to the statistical properties of
each instrument class during the last year. The portfolio management system does not
support defining tolerance bands for individual instruments and consequently the instruments
are divided into instrument classes and the same band is applied for each instrument within


Risk control, compliance monitoring and reporting

Box 4.2. (cont.)
the same class. The tolerance band for an instrument class (or maturity bucket) is calculated
as the maximum of all the tolerance bands for the instruments within the class.
The tolerance band is defined in such a way that breaches should occur only in up to 1
per cent of trades, when the trades are completed according to the prevailing market
yield39 and assuming that there is a one-hour time-lag between the time the deal was
completed and the time the current market yield was recorded (a lag of one day is assumed
for instruments for which frozen 17:00 CET prices are used). Estimations of the actual
probability of breaches suggest that in reality the occurrence of breaches is over 5 times
rarer than the 99 per cent confidence level would indicate.
The tolerance bands for single instruments are calculated based on the assumption
that the logarithmic yield changes between the trading yields and the recorded market
yields are normally distributed. The logarithmic yield change for instrument i at time t is
defined as

ri;t ¼ ln


where Yi,t is the observed yield of instrument i at time t. The unit of time is either an hour or
a day. The volatility of logarithmic yield changes ri for instrument i is estimated by
calculating the standard deviation of daily logarithmic yield changes during the last year.
Hourly tolerance bands are obtained by dividing the daily volatility by the square root of
eight, assuming that there are eight trading hours a day. To achieve a 99 per cent
confidence that a given correct yield is within the tolerance band, the lower and upper
bounds for the band are defined as the 0.05 and 99.5 percentiles of the distribution of ri,t,
respectively. Since the logarithmic yield change is assumed to be normally distributed,
ri;t $ N ð0; r2i Þ, the tolerance band for instrument i can be expressed, using the percentiles of the standard normal distribution, as
TB ¼ ðUÀ1 ð0:005Þri ; UÀ1 ð0:995Þri Š ffi ½À2:58ri ; 2:58ri Š
where U denotes the standard normal cumulative distribution function. The tolerance
band for instruments within instrument class J and maturity bucket m¼[lm, um[ is then
calculated as
¼ maxfTBi : i 2 J ; lm

mati < um g

where mati is the time to maturity of instrument i.


Yield is used in the remainder of this section, even if it might actually refer to price for some instruments. Yield is the
preferred quantity for the reasonability check, since the volatility of logarithmic changes is more stable for yields
than for prices in the long end of the maturity spectrum. Prices are only used for comparison if no reliable yield data
is available.


Manzanares, A. and Schwartzlose, H.

4.4 Dealing with backdated transactions
Market values, return, performance and risk figures obviously depend on
the positions maintained in the portfolio management system. However,
occasionally it turns out, for example at the time of trade confirmation
(with the counterparty), that some details of a transaction were incorrect. It
may also happen that a transaction was not entered into the system in a
timely manner or for some reason was not finalized. In such cases it may be
necessary to introduce transactions into the system or alter transactions
already entered in the system retrospectively. Such changes may impact
portfolio valuation, limit compliance and other important factors back in
time, and therefore pose a problem for compliance monitoring and for
reporting already completed. It is therefore important to have processes in
place that capture such events and ensure that 1) they cannot be used to
circumvent compliance controls and 2) any report impacted by such changes
is assessed and, if deemed necessary, re-issued. The ECB defines backdated
deals as transactions entered (or changed) in the portfolio management
system one or more days after their opening date.40 Such changes may
invalidate performance and risk figures in the portfolio management system
and risk data warehouse. Backdated deals could also cause limit breaches to
be missed, as the portfolio management system only keeps track of and
checks the present limit utilization against limits.41
On the morning of each business day, the ECB RMA checks all transactions with an opening date prior to the previous business day which were
entered or changed on the previous business day. The changes are assessed,
and if necessary system processes rerun in order to cause the update of the
relevant systems.42 Special procedures associated with end of period (month,
quarter and year) reporting ensure that only very rarely is it necessary to
re-issue monthly, quarterly or annual reports on risk and performance. The
same applies to end-of-period accounting entries. Similar procedures apply in
case of changes due to incorrect static data or systems problems, which also



The opening date ordinarily being the date the transaction is entered into the system, but in the case of backdated
transactions may be the date the transaction would have been entered into the system, had it not accidentally been
omitted for one reason or another.
A backdated transaction could mask a limit breach on day T, if an offsetting transaction was entered on Tþ1 and the
original (otherwise limit breaching transaction) was entered only at day Tþ1, backdated to day T.
The ECB’s portfolio management system does not automatically update for example return and performance figures
that change due to transactions outside a five-business-day ‘window’. A similar ‘window’ applies to the risk data
warehouse which in normal circumstances is only updated on an overnight basis. Changes that go back less than five
business days do not in general necessitate any action in terms of systems maintenance.


Risk control, compliance monitoring and reporting

occasionally necessitate the re-evaluation of reporting that has already taken
place as well as the potential rerunning of system activities for significant
periods of time.
4.5 Maintenance and regular checks of static and semi-static data
Substantial amounts of static or (semi static) data are required to support a
trading operation. Of particular interest to risk management are details
related to financial instruments, issuers and counterparties as well as market
risk factors. Furthermore there may be a need to maintain data related
to fixings (e.g. to cater for floating rate notes) or deliverable baskets for
futures. All this data needs to be set up and maintained. The incomplete or
erroneous set-up of financial instruments could lead to wrong valuations
and risk exposure calculations and hence have serious consequences.
The distribution of these tasks across the organization varies, from institution to institution. In some, the back office would be the main ‘owner’ of
the majority of this type of data and would be responsible for its maintenance. In other organizations the responsibility may be split between front
office, risk management and back office according to the type of data and the
speed with which it may need to be set up or changed and some organizations
may have a unit specifically responsible for this type of data maintenance.
At the ECB, for the purpose of efficiency, a separate organizational unit
(Market Operations Systems Division) is responsible for the maintenance of
the static data in the portfolio management system. This is the same unit
which is responsible for the running and support of the portfolio management system. To facilitate this setup, the ECB has established the notion
of ‘data ownership’. In other words each different type of static data is
owned by one organizational unit. For example data related to the configuration of financial instruments are owned by the ECB RMA, whereas details
related to settlement instructions are owned by the ECB Back Office Division.
A set of procedures govern the maintenance of the data; with changes typically originating from data-owning business areas being forwarded by formal
channels to the unit responsible for the actual update of the data and updates
taking place by means of the four-eyes principle. For some data e.g. the
maintenance of cheapest-to-deliver baskets for futures contracts,43 processes

The cheapest-to-deliver (CTD) bond determines the modified duration contribution of a bond future contract in the
portfolio management system. Whenever a new bond is included in the deliverable basket, it may become the CTD.
If the basket in the portfolio management is incomplete, a wrong CTD bond may be selected and as a result the
contract’s impact on risk figures may be wrong.


Manzanares, A. and Schwartzlose, H.

have been defined in the data updating which ensures that the data is
maintained on a regular basis. The ECB RMA checks the integrity of the data
at regular intervals.
4.6 Maintenance of strategic benchmarks
For financial institutions using in-house benchmarks there is a need to
ensure that benchmark properties, in particular asset allocation and risk
characteristics (duration and liquidity) stay relatively stable over time. For
example, due to the passing of time the duration of instruments held by the
benchmark shortens from month to month, and instruments may mature
or roll from one maturity bucket to the next, thus impacting asset allocation. In order to permit portfolio managers (and the staff maintaining
potential tactical benchmarks) to anticipate future benchmark changes, it is
best practice to agree on a set of rebalancing rules. As an example, one such
rule could state that ‘US bills in the zero–one year maturity bucket in the
USD strategic benchmark are held until maturity and a maturing bill is
always replaced by the latest issued bill.’
Apart from the need to maintain risk and asset allocation properties,
rebalancing transactions need to be replicable by the actual portfolios. If
the portfolio is large, this may occasionally limit the investment choices of
the strategic benchmark due to liquidity considerations and there may also
be considerations related to the availability of issuer limits.44 For performance
measurement reasons, it is important that the benchmark trades at realistic
market prices with realistic bid–ask spreads.
These represent typical areas of contention between portfolio and risk
managers due to their differing objectives. For example portfolio managers
may argue that they need to be able to replicate the benchmark 100 per cent
to ensure that any positions that they have vis-a`-vis the benchmark are
directly tractable to a decision to deviate from the benchmark. This may for
example lead portfolio managers to argue that the benchmark should not
increase exposure to a certain issuer, if the actual portfolio is already very
close to its limit due to a long position and hence cannot follow the
benchmark, thus forcing the actual portfolio to take another (if similar)
position in another issuer. Another typical topic for discussion is how
closely the benchmark should strive to follow its asset allocation. In other


Obviously the benchmark should respect the same constraints vis-a`-vis issuer and other limits as the actual portfolio.


Risk control, compliance monitoring and reporting

words what amounts of deviation from the asset allocation approved by
the organization’s decision-making bodies in the context of the setting of
the benchmark, are acceptable. Following the asset allocation very strictly
may lead to transactions that portfolio managers would characterize as
superfluous (and costly, if the actual portfolio replicates the transactions).
The ECB applies monthly rebalancing to its strategic benchmarks for both
the own funds as well as for the foreign reserves according to rebalancing
procedures defined by the ECB RMA. For the ECB’s foreign reserves this
rebalancing coincides with monthly meetings of the ECB’s Investment Committee and associated changes to the tactical benchmarks. Virtual transactions
in the benchmark are studied in a template spreadsheet and once deemed
appropriate, simulated in the ECB’s portfolio management system thereby
permitting an evaluation of their market risk characteristics and the viewing
of the new benchmarks by portfolio managers, prior to their implementation.
In addition to the monthly rebalancing the ECB RMA re-invests on a daily
basis the cash holdings of the strategic benchmarks. These holdings are
generally rolled over at money market tom-next rates.

5. Reporting on risk and performance
In commercial as well as central banks, risk and performance reporting
typically occurs at least at three levels: the overall organizational level, the
department (or business unit) level, and the individual portfolio manager or
trading desk level. Often risk management will design risk and performance
reports to suit the specific needs of each organizational level.
For an efficient reporting process, it is important to take into account the
audience and its specific needs. Board members tend to focus on the return
and performance over longer periods, market risk concentrations, and possibly the results from regular stress tests. Board members typically appreciate
brief and concise reports without too much detail at a relatively high frequency (e.g. daily) and in-depth reports with more detail and analysis at a low
frequency (monthly or even less frequently, depending on the type of institution and its lines of business). Business area managers are likely to be more
interested in returns, large exposures and aggregate risk positions. They have
a need for daily or even more frequent reports. Portfolio managers are
interested in detailed return and risk summaries, possibly marginal risk
analysis, and individual risk positions. They have a need for high frequency
reporting available ad hoc and on-line.


Manzanares, A. and Schwartzlose, H.

In addition to internal management reports, financial institutions may be
subject to regulatory risk reporting. There is also a trend toward greater
voluntary disclosure of risks to the general public, as exemplified by the fact
that a number of financial institutions reveal VaR figures in their annual
reports. Central banks are following in the footsteps of their commercial
counterparts at varying pace. Some put a very high emphasis on transparency, while others weigh quite carefully which information to disclose.
5.1 Characteristics of a good reporting framework
A good performance and risk reporting framework should ensure that
reports satisfy a number of properties. They should be:
(i) Timely. Reports must be delivered in time and reflect current positions
and market conditions. What is timely depends on the purpose a
report serves and its audience.
(ii) Accurate (to the level possible) and internally consistent. Within the
time (and resource) constraints given reports should be as accurate as
possible, while internal inconsistencies must be avoided. Occasionally
there may be a need to sacrifice some accuracy for timeliness.
(iii) On target – i.e. fulfill the needs of their intended audience precisely.
Reports should be created with the end-user in mind. They should as
far as possible contain precisely the type of information that is needed
by the recipient presented in a way that maximizes the recipient’s
(iv) Concise. The level of detail should be appropriate. Most management
and staff do not have the time to dig into large amounts of detail.
Reporting serves its purpose best, when it is it to the point and does
not contain superfluous elements.
(v) Objective and fair. Numbers tend to speak for themselves. However, analysis which may pass direct or indirect judgements on the
performance of business units must be objective and unbiased.
(vi) Available on demand (to the extent possible). With the level of
sophistication of today’s IT solutions, it is possible to provide many
risk and performance reports on-line. These types of reports may be
designed and vetted by risk management, but may be made available
to other parts of the organization who may run the reports on demand.
A selection of such reports can in many cases fulfill immediate and ad
hoc needs of department heads and portfolio managers.


Risk control, compliance monitoring and reporting

Furthermore, a good reporting framework also permits analysis of unforeseen
risk and performance issues. For this purpose the availability of flexible and
user-friendly systems, which allow the integration of data from many sources
and allow risk management users to create ad hoc reports themselves are
obviously beneficial.
Once produced, reports need to reach their audience and ideally feedback flows the other way enabling the risk management function to adapt
and improve its output. Another consideration is ensuring confidentiality
of report contents, if necessary. Excluding reports that are available directly
to end users in portfolio management or other line-of-business systems,
reports may reach their audience in the following ways:
(i) Surface mail. Reports may still occasionally be distributed in hardcopy using traditional internal (or external) surface mail. However,
with the technological solutions available these days this is reserved for
reports of particular importance, life-span or perhaps confidentiality.
(ii) Email attachment. The most common mechanism for distributing
reports is as an attachment to an email.
(iii) Intranet based. With the advent of web-based solutions such as for
example Microsoft SharePoint or Business Objects Web Intelligence,
which make it easy for non-technical users to easily manage (parts of)
a website, a third option for distributing reports is by making the
reports available on an intranet or internet site. This may be combined
with ‘advertising emails’ containing links to newly issued reports or a
system permitting end users to subscribe to notifications about reports
The ECB RMA presently distributes most reports using email, however the
intention is to make more use of intranet-based distribution.
5.2 Making sure the necessary data is available
Significant investment in information systems infrastructure typically goes
into establishing a solid risk and performance reporting framework. For
measuring risk and performance, at least the following two basic types of
information are necessary:
(i) Position data. Risk reporting systems require position information for
all portfolio positions. Given the sheer number of different financial
instruments and transactions, the task of gathering these positions is
complex. Coupling this with the fact that positions in the typical


Manzanares, A. and Schwartzlose, H.

financial institutions may be held in a number of different systems,
each with their own data models and interfaces, and perhaps located in
various time zones, does not make the job any easier.
(ii) Market data. Market data consists of time series of market prices and
rates, index levels, benchmark yield curves, spreads, etc. The data must
be clean, complete and available in time. Often, such data must be
collected from several sources and then processed to eliminate obvious
outliers. Furthermore, to ensure a consistent picture the full dataset
should ideally be captured at the same time of the day. Obtaining,
cleaning and organizing appropriate market data is a challenge for most
financial institutions; however, with the advent of third-party providers
that (for a significant fee) take on these tasks, there is also the possibility
to outsource significant parts of this work, in particular if one operates
in the more liquid markets.
Given the associated problems, in practice, for global financial institutions,
it may not be possible to ensure 100 per cent accurate aggregate reporting of
risk (and performance) at a specific point in time. Still, with advances in
technology the problem is no longer insurmountable and global banks will
typically be able to compile a reasonably accurate risk overview, on a daily or
even more frequent basis, thanks to large investments in IT infrastructure.45
Central bank risk managers often have a somewhat easier life in these
respects. Typically they only need to retrieve and consolidate position data
from one or at most a few systems and physical locations, and the markets
they operate in are often quite liquid, hence access to data is less of a
problem. Finally, due to the instruments typically traded by central banks,
the scope of datasets required to value investments and calculate risk figures
also tends to be more manageable.
In the case of the ECB, the RMA has established a data warehouse which
integrates data from the ECB’s portfolio management system as well as from
the agent running the automated securities lending programme of the bank.
This provides the division with all relevant data to perform its risk management tasks vis-a`-vis the ECB’s foreign reserves and own funds. Given
the few sources of data, most risk calculations take place using the infrastructure of the portfolio management system, thus ensuring full correspondence between the data seen by portfolio managers directly in the
portfolio management system with data stored in and reported from the
data warehouse.

See also Section 6.2.