VAROPS

Value at Risk (VaR)
Organization Guidelines
Software Release 5
Document Title VaR 5 Organization Guidelines
Version 1.4
Status Final
Author Information Isidore Marcus, Glenys Lynn
Date Last Revised December 5, 1997

VaR Release 5 Operation & Organization Guidelines Page 2
VAROPS Version 1.4 December 5, 1997
1. DEFINITIONS 5
1.1. IT Terminology 5
1.2. Business Naming Conventions 7
2. WHAT IS VALUE AT RISK 15
2.1. Components of the Value at Risk System 16
3. JOB DESCRIPTIONS 17
4. DAILY DATA FEED PROCEDURES 18
4.1. Daily VaR Reports 18
4.2. Standard VaR Exception Reports 18
4.2.1. DataFeed Status, Missing ReportIDs, Stale Levels 18
4.2.2. Missing Feed Roll-Over/Notification 18
4.3. Daily Procedures 19
4.3.1. Daily Data Feeds and Calculator Runs 19
4.3.2. Rerunning the Calculator for Stale Dates 19
4.3.3. Getting the VaR Number for UBS 19
4.4. Banking Holiday Procedure 20
4.4.1. Insuring a Complete Set of Trading Positions 20
4.5. Currency Numéraire, Daily FX Rates 21
4.6. Position Data Override 22
4.7. Daily Checks of the Mapping Interface: Example of Core 22
4.8. Definition of a New Feed 23
4.9. Maintenance of the Mapping Interfaces 24
4.9.1. Using the Static Data Extraction Utility 24
4.9.2. Position Risk Codes Naming Conventions 25
4.9.3. Risk Sensitivity Type 25
4.9.4. Currency of the Time Series 25
4.9.5. Maturity 25
4.9.6. Product Code 25
4.9.7. Currency to Which the Position Risk Code Pertains 25
4.9.8. Maturity in Months 25
4.9.9. Rating of the Corporate Issuing the Bond 25
4.9.10. Time to Expiration of the Option 25
4.9.11. Reference Currency in CCY Pair 25
4.10. Additional Functions Performed by the VaR Loader 26
4.10.1. Currency Conversion 26
4.10.2. Enforcing Uniqueness of the Position in the PVT/EQT Table 26
4.10.3. Generation of the Linear P&L Matrix 26

5. DAILY REPORTING 26
5.1. Using the VaR Reports Application 26
5.2. VaR Reporting Engine 27
5.2.1. Reporting Engine Overview 27
5.3. The PC Calculator (“Scratch Pad”) 27
5.3.1. PC Calculator Overview 27
5.3.2. Getting Intraday VaR for a Portfolio of the Core System 27
5.3.3. Viewing the Market Hierarchy with the PC Calculator 27
5.3.4. Browsing for Equities and Betas with the PC Calculator 27
6. MANAGEMENT OF REFERENCE DATA 28
6.1. Data Replication 28
6.2. Updates of Market Volatility and Correlation 29
6.2.1. Time Series Maintenance 29
6.2.2. Data Providers, Frequency of Updates 29
6.2.3. Distribution of Market Data (Volatility and Correlation) 30
6.2.4. Distribution of Correlation Matrix Files for the PC Calculator 30
6.3. Collection of Equity Betas 31
6.3.1. Improved Handling of Equity information 31
6.3.2. Delivering Equity Information to the VaR System 31
6.3.3. Maintaining the List of ISINs and Dummy Codes 31
6.3.4. How Equity Information is Delivered 32
6.3.5. BetaSource Codes 32
6.3.6. Validation Rules 33
6.3.7. Beta Update Frequency 33
6.3.8. Which Countries does Each Location Have Authority Over? 34
6.3.9. Valid combinations of Country Code and Equity Index 34
6.3.10. Setting the Beta FeedIDs and the Beta Datafeed Contacts 34
6.3.11. New Set of Dummy ISINs Using the Country Code 34
6.3.12. Historical Equity Information 34
6.3.13. Equity Sector Breaks 34
6.3.14. Beta/Total Risk Override 35
6.3.15. Beta Override Audit Table 35
6.4. Maintaining the Market Structure 36
6.4.1. New Time Series Codes 36
6.4.2. Renaming the Position Risk Codes 36
6.4.3. Adding New Position Risk Codes 36
6.4.4. Remapping of Old Position Risk Codes 36
6.4.5. Market Hierarchy Updates 36
6.5. Maintaining Static Data 37
6.5.1. Locations 37
6.6. Updating the Organization Structure 38
6.6.1. Local and Global Changes to the Organization Structure 38
6.6.2. Retro-Active and Non Retro-Active Changes 38
6.6.3. Changes to the Org. Structure which Affect the VaR Limits 38
7. MARKET RISK LIMITS 39
7.1. VaR Limits, Why? 39

7.2. Principles of a VaR Limit System 39
7.2.1. Proactive Management 39
7.2.2. Minimum Quality Requirements 39
7.3. Assigning VaR Limits 40
7.3.1. How to Determine Initial VaR Limits 40
7.3.2. Official Limits and Pro-forma limits 40
7.3.3. Aggregation with Official and Pro-Forma Limits 40
7.4. Populating the System with VaR Limits 43
7.5. Controlling VaR Limits 43
7.6. Maintaining VaR Limits with the Org. GUI 44
7.7. Allocation/Re-allocation of VaR Limits 44
7.8. Operational Limits 45
8. DISASTER RECOVERY PROCEDURE 46
9. ARCHIVAL/SNAPSHOT FACILITY 47
9.1. Archiving Functions Overview 47
9.2. Creating a Snapshot of the VaR Org. Structure 47
9.3. Allowing VaR Users Access to ‘varhist’ 47
10. USER AUTHORIZATION AND SECURITY 48
10.1. Principles of Access Control 48
10.2. Principles of User Authorizations 48
10.3. Security Administrators 48
10.4. Data Ownership 49
10.5. Employee Role Definitions 50
10.6. Special User Accounts 50
10.7. Authorization Path 51
10.8. VaR Authorization Form 52
11. WHO’S WHO IN VAR 53
12. LOCAL PC CONTACT PERSONS 54
13. REFERENCES 55

Modification History
The document has been completely reviewed and shortened for Version 5 of the Value-at-Risk System.
Alternatively, it references to more detailed papers addressing the topics mentionned in the following
chapters.
1. Definitions
1.1. IT Terminology
Account Manager: person responsible for organization and application support in a particular business like
authorization, data mapping and user requirement specification.
Client: a process that requests services from another process usually called a server.
crontab: a UNIX file which lists all the programs to be periodically executed and the specific times when they
are to be run.
Data Release: set of SQL (Structured Query Language) scripts used to carry out a major update of Reference
Data; it is installed on the system after having passed through regular acceptance tests.
Domain Name Server (DNS): an application which maps host names, such as man5112.mp.zh.ubs.com, to IP-
Addresses. This makes it possible for users to send files, mails, or initiate terminal sessions without having to
memorize IP-Addresses.
Entity: an object of importance to the organization. It usually corresponds to a table in the relational data base
model.
ftp: stands for file transfer protocol, a TCP/IP protocol (and command) used to transfer files between
computers.
html: stands for Hypertext Markup Language, the language used to create documents on the World-Wide
Web.
IP Address: address assigned to a computer using TCP/IP as a network protocol (dotted decimal address), for
instance: 193.134.107.112
IT Operations: all routine tasks performed by System Operators to keep computers up and running.
IT Support: assistance in the solution of problems when they arise provided by different levels of expertise.
Local VaR System: a local data base/compute server into which the daily PVT and EQT files are sent from
the different trading systems. All positions thus loaded are copied across the network through the Sybase Data
Replication mechanism to the VaR Consolidation System.
Local VaR Test System: a server used by the local IT organization for component integration test.
ODBC: stands for ‘Open Database Connectivity’, a PC-client interface used by, for instance, Access, Excel,
Power Builder to access a database server such as Sybase or Oracle. The OBDC protocol is independent of
the native SQL command set of the database system.
Port: a logical network communication channel. Example: the VaR SQL server listens to Port 2025 for

incoming client communication requests.
Replication Server: an application which synchronizes updates to selected tables across multiple SQL servers.
In the VaR System, Reference Data is replicated from the Consolidation System to the local servers, while
Site Specific Data is replicated from the local to the Consolidation VaR System.
Relational Table: a structure composed of columns and rows containing information about an entity.
Relationship: the description, in a relational data base, of how entities are being related (one-to-one, one-to-
many, many-to-many relationships).
SQL: stands for Structured Query Language, a non-procedural language originally developed by IBM in the
late 1970s to support their mainframe relational database DB2.
Stored Procedure: a group of compiled SQL commands stored under a procedure name. The procedure is
capable of accepting and returning a set of pre-defined parameters. It may also return a set of rows.
TCP/IP: stands for Transmission Control Protocol/Internet Protocol, the most widely used protocol to
interconnect hosts and networks.
Trigger: SQL commands invoked when a modification to a table takes place (insert, update, delete).
Update-related commands may also be invoked on a field-by-field basis.
URL: stands for Uniform Resource Locator, an address used by the html language in the World-Wide Web to
describe the absolute or relative location of information (for instance, a url starting with http means that the
information is retrieved via the HypertText Transfer Protocol, ftp indicates that the File Transfer Protocol is
being used, mailto points to an e-mail address).
VaR Consolidation System: the global data base server which gets the trading positions from all the UBS
locations through data replication; no positions are fed directly into this system.
VaR Consolidation Test System: the counterpart of the Consolidation Production System where system test
for data releases and new versions of the application takes place.
VaR Reports GUI: A PC-based application with a Graphical User Interface (GUI) to view VaR numbers,
Limits, and Position Detail. This application is also used to perform limited data entry, e.g., create adjustment
feeds and preparing Beta overrides.
VaR Org./Limit GUI: A PC-based application to make modifications to the Organization Structure,
consisting of the Risk Delegation Hierarchy and the Major/Minor Business Line Hierarchy. In addition, this
application allows limits associated with entities of the Risk Delegation Hierarchy to be set or modified.
VaR Access Control GUI: A PC-based application to define the entities for which a user is allowed to view
VaR numbers and limits as well as to add supplementary functions such as ‘B’ and ‘C’ Roles. General
personal information about Datafeed Contacts and VaR Limit Holders is also maintained through this GUI.
View: a stored information extract from a relational data base that behaves like a table. In the Core System,
the term ‘View’ is also used to designate a collection of portfolios.

1.2. Business Naming Conventions
Agency Bond: bond issued by government agencies, for instance ‘Bundesbahn’ or ‘Bundespost’ in Germany,
and fully backed by the Federal government.
Asset Backed Securities: securities collateralised by assets such as car loans and credit cards receivables.
Authority Location: Location which has the responsibility to sent equity information of one or more countries
to the VaR system. The Authority Location is usually also the Beta Source (owner of the information) but
alternative ways where new Betas supplied from non-authoritative sources are supported. However, the
Authority Location is the ultimate responsible for the Betas and can override information supplied by other
sources.
Base Currency (Reporting Currency): the currency in which Market Risk is measured.
Beta Source: code used to identify the provider of equity information. Each Location may have one or more
Beta Sources (e.g. BAN for Barra NY and BLN for Bloomberg NY). The provider of equity Betas is also the
owner of that information and can delete it from the system, providing that no equity position with that ISIN
Code exists in the system.
Bond Option: an option to buy or sell a bond for a certain price.
Brady Bond: a bond backed by the US Treasury but with actual repayment being made by a sovereign lesser
developed country (proposed by Nicholas Brady, U.S. Treasury Secretary in 1989).
Broad Risk Type: a sub-division of the Risk Class in the Market Structure, specially useful for the Fixed
Income Business where risk is aggregated by currency:
Risk Class Broad Risk Type
Commodities: Base Metal, Energy, Precious Metals
Equity: East Asia Equity, Europe Equity, NorthAMerica Equity, Other Equity
FX: East Asia FX, Europe FX, NorthAMerica FX, Other FX
Fixed Income: AED Interest Rates, ATS Interest Rates, AUD Interest Rates, BEF Interest Rates etc.
Business Unit (BU): level 5 of the Risk Delegation Hierarchy locally defined by the business; it can be a
desk, a trader, a group of trader or a book. Setting a VaR Limit at this level is left at the discretion of the
Section Heads.
Cap: an over-the-counter option which provides insurance against rising floating interest rates.
CAPM: stands for Capital Asset Pricing Model, an approach developed by William Sharpe to describe the
relationship between return and systematic (market) risk. It asserts that the expected excess return on
securities is proportional to their systematic risk coefficient or Beta (market portfolio has a Beta of 1).
Cheapest-to-Deliver (CTD): the security available in the cash market which can be delivered the most
economically against a futures position.
Capture Point: the code of the location where the positions are originated. It is used by the Datafeed Loader
to generate the Synthetic FX Position in the Base Currency of the Location. Virtual Location codes may also
be used for the Capture Point if the Base Currency of the business is different from the local currency.
Collaterals: assets which are guaranteed as security for a loan.
Commodity: a sub-division of the Broad Risk Type in the Market Structure defining the underlying (the

‘Commodity’) originating the risk:
Broad Risk Type: Commodity:
Base Metal: Aluminum, Copper, Lead, Nickel, Tin, Zinc
Energy: Crude Oil, Gasoline, Jet Fuel, High Sulfur, Low Sulfur, Naphtha, Natural Gas
Precious Metal: Gold, Palladium, Platinum, Rhodium, Silver
East Asia Equity: AUD Equity, HKD Equity, JPY Equity etc.
East Asia FX: USD/AUD, USD/HKD, USD/JPY, etc.
AUD Int. Rates: AUD Agency, AUD Asset Backed, AUD Corp., AUD Fut., AUD Gov., AUD Libor
Convertible Bond: a debt instrument with embedded options issued by corporations. The holder has the right
to exchange a convertible bond for equity in the issuing company at certain times in the future according to a
certain exchange ratio.
Correlation Coefficient: a number which describes to what degree two variables move together: +1 or in
opposite direction: -1 (the perfect hedge), zero meaning no tendency at all (perfect diversification of the
portfolio).
Correlation Matrix: the matrix of Correlation CoefficientsAMong all the current time series. For instance,
element rij represents the correlation between the time series i (row i) and the time series j (column j). The
elements on the diagonal are equal to 1 and the matrix is symmetrical. The matrix should ideally be positive
semi definite (meaning that all its eigenvalues are  0), in order to be able to use it for the generation of
correlated random variables (e.g. through the Cholesky decomposition into two triangular matrices).
Therefore, if one data point in one of the Time Series changes, the entire matrix is affected.
Covariance: a statistical term defined as the average of the cross product (after removing the mean) of two
random variables to measure the degree of association. The Covariance and the Correlation Coefficient
provide the same information about the joint distribution of two variables, zero Covariance (or zero
Correlation Coefficient) meaning that the random variables are independent. The Correlation of X and Y is
defined through the Covariance as follows: (sx and sy are estimators of the Standard Deviation of X and Y,
and r an estimator of the Correlation): r X Y
Cov X Y
s sx y
( , )
( , )


Cross Currency Implied Volatility: volatility of one currency against another (non USD) currency. The
relation between the Cross Currency Implied Volatility and the USD expressed volatility used in VaR is given
by the following basic result of statistics:     12
2
1
2
2
2
1 22  
where 12 stands for the cross currency volatility of currency 1 against currency 2
and 1, 2 for the volatility of currency 1, respectively currency 2 against the USD.
Daily Volatility: the Annual Volatility divided by 252 (average number of business days per year).
Data Feed Location Code: a two-character location code of a Primary Location into which a Secondary
Location feeds its position data.
Delta: the ratio of the change in the price of an option to the change in the price of the underlying. It is the
number of units of the underlying (in percentage) to be held for each option shorted to create a riskless hedge.
Derivative: a financial instrument whose value depends on the value of other underlying variables.
Diversification: spreading investment riskAMong different instruments and market in order to reduce the
overall exposure of a portfolio.
Domain: subset of the Organization Structure defined by a range of ReptIDs.

Equity Add-on: exposure created by convertibles uncorrelated with the market; it is aggregated with all the
other exposures as follows:
     VaR VaR VaRtot add on
2 2 2
  
Equity Beta: a factor in the Capital Assets Pricing Model (CAPM) used by the VaR calculator. It represents
the slope of the regression line between the return on equity and the return on the market index. This factor
together with the volatility (‘Total Risk’ in the Beta table) is specific to each equity.
Equity Position Table (EQT): table containing the equity positions (number of shares, market price or delta
equivalent for options, convertibles etc.) together with the corresponding ISIN codes and trade date
information.
Exercise Date: the date, in an option contract, when the right to buy or sell the underlying expires.
Feeder System: a program used in the Middle Office area to run the end-of-day revaluation of the trading
positions. In some cases, it creates a Position Inventory File which is converted into a PVT or an EQT file.
FeedID: an identifier with a minimum length of 4 and a maximum length of 8 characters assigned to each
data feed. The FeedID code is globally unique with the 2 first characters specifying the Location (FM, GE,
HK, LO, NY, LU, PS, SI, SY, TO, TN, TP, ZH).
Financial Element: attribute of the Time Series describing the financial underlying (Commodity Spot,
Commodity Forward, FX Spot, FX Forward, Equity Spot, Equity Add-on, Term Volatility, Par Yield, etc.).
Futures Contract: an agreement between two parties to buy or to sell an asset at a certain time in future for a
certain price; Futures Contracts are normally traded on an exchange.
Gold Leasing Rate: interest rate received by Central banks for gold holdings they lease out to the Gold Mines
companies.
ISIN code: a universal equity identifier.
Level of Aggregation: level to which the VaR figures are consolidated (1 to 5 on the Risk Delegation
Hierarchy starting from GTRM, 1 to 3 for the Major/Minor Business Lines, Risk Class/Broad Risk Type and
Commodity for the Market Structure.
LIBOR: stands for London Interbank Offer Rate, the rate of interest offered by banks on deposits from other
banks in Eurocurrency markets.

Linear Risk: market exposures which can be calculated by a straight multiplication of the sensitivity with 2
standard deviations (neglecting the convexity of the underlying).
Loader: a program used to append data (in the PVT, EQT or FX format) into the VaR database on a daily
basis. The Loader does some plausibility checks (format, date, ReptID, ISIN). It rejects the whole file if one
entry is invalid.
Location: code used to identify a UBS site. In VaR we differentiate between:
Primary Locations: sites running a VaR System with a proper team supporting the application.
Secondary Locations: sites producing positions to be fed into a VaR System at a Primary Location.
Virtual Locations: the global businesses of UBS which are not bound to a geographic location.
Mapping: the process of translating sensitivities and positions delivered by Middle Office systems into a
standardized format called PVT or EQT readable to the VaR system.
Market Structure: the classification of market risks as defined in the VaR system:
Risk Class, Broad Risk Type, Commodity, Risk Sensitivity, Financial Element
Market Break Variable: an element of the Market Structure (instance of the Risk Class, Broad Risk Type,
Commodity, Risk Sensitivity or Financial Element) used to break down the VaR exposure of a particular node
into its market risk components.
Mortgage Backed Security: a security backed by a pool or package of mortgage loans. Monthly payments of
principal and interest from the underlying pool of mortgages is passed along to the holder of the security.
MatrixID: a sequential number (1, 2, 3, 4, 5..) identifying the Correlation Matrix used by the Calculator.
Model: template used by the VaR Calculator to compute the VaR exposures for different levels of
aggregation (1 to 5 for the Risk Delegation Hierarchy and 1 to 3 for the Major/Minor Business Lines) broken
down by categories of market risk. For instance, “Function FUNCADV” is a Model, or presentation of VaR
results, such that there is a VaR number for GTRM, and one for each category of “Functional Advisor”
within GTRM. A Design represents a particular grouping or a vector of positions classified by Time Series
used in the quadratic form to calculate VaR.
Commodities Equities FX
Functional Advisor
GTRM
Function
Fixed Income GTDE
Time
Series K
Time
series 2
Time
Series 1
Time
Series K
Time
series 2
Time
Series 1
.......
MSCI: stands for Morgan Stanley Capital International, a provider of Sector Breaks information.
Monte Carlo Method:
A numeric probability approach to the pricing of options which cannot be valued with closed-form (analytic)
solutions. It is also used in the Value-at-Risk computation of an option portfolio where return doesn’t match a
standardized distribution.

Netting: allowing positions with opposite signs (long and short) to offset. This happens in the VaR system
whenever positions or equities are mapped to the same Time Series (same Volatility and Correlation).
Furthermore, in the case of equities, Market Risk induced by a single index is netted while Specific Risk is not,
as shown by the equation:
   VaR VaR VaRequity market specific
_
2
2 2
  
Non-Linear Risk: VaR calculation for financial instruments such as options where the risk is not normally
distributed, hence requiring a revaluation of the portfolio’s P&L evaluated at random draws.
Notional: principalAMount which is not exchanged (for instance in futures contracts and IR swaps).
Organization Structure: the collection of trading hierarchies along which risk figures are reported.
Operational Limit: key risk exposure that is actually traded and should not be exceeded at trader level.
Portfolio: a collection of financial instruments in the possession of an investor.
Position: balance of purchases and sales in a given financial instruments for a given maturity (in the VaR
System: reported sensitivities).
Position Value Table (PVT): table containing the trading positions together with the corresponding codes
(ReptID, PRC) and the Trade Date. Individual equities are excluded from the PVT.
Position Inventory File (PIF): file containing the positions from the feeder system prior the mapping to VaR
(in feeders such as Core).
Position Risk Code (PRC): the lowest level in the Market Structure used in the VaR System to catalog market
exposures. Position Risk Codes map to a Commodity as well to a Time Series for instance:
Position Risk Code: Commodity Time Series
ATS Libor 6 M ATS Libor ATS Eurocurrency 6M
The link between positions (PVT; EQT/Beta) and market risk (Volatility, Correlation) occurs at this level.
Product Control: staff unit responsible for market risk monitoring and trading P&L reporting.
Repo: stands for Repurchase Agreement, an operation where the dealer is effectively a borrower of funds to
finance further purchases of securities. The dealer collateralises the loan by selling his securities to the
investor and repurchasing them at an agreed price and date . The difference between the sale and repurchase
price represents the interest payable on the loan.
Report ID (ReptID): a numerical identifier used to tie up positions in the Org. Structure. A unique ReptID
code may be assigned to each individual trading book or to a “desk”, depending on what is locally acceptable.
The VaR calculator does not break Value-at-Risk out by ReptID, so it does not make a difference in reporting
whether different ReptID codes are used for different trading books mapping to a particular Business Unit, or
whether the same ReptID is used for these trading books.

ReptID Range: set of numbers to be used as ReptIDs in a Location:
NY (New York) 10001 - 40000
TN (Toronto) 40001 - 50000
LO (London) 50001 - 80000
PS (Paris) 80001 - 85000
JE (Jersey) 85001 - 90000
LU (Luxembourg) 90001 - 95000
FM (Frankfurt) 95001 - 100000
ZH (Zurich) 100001 - 120000
LG (Lugano) 120001 - 125000
BS (Basel) 125001 - 130000
CT (Bank Cantrade) 130001 - 135000
BL (Banco di Lugano) 135001 - 140000
HY (Hyposwiss) 140001 - 145000
SI (Singapore) 150001 - 200000
GFD (Global FI Derivatives) 200001 - 210000
GED (Global Equity Derivatives) 210001 - 220000
GXD (Global FX Derivatives) 220001 - 230000
GCD (Global Commodity Derivatives) 240001 - 250000
TO (Tokyo) 250001 - 300000
GE (Geneva) 300001 - 325000
HK (Hong Kong) 325001 - 350000
SY (Sydney) 350001 - 375000
TP (Taipei) 375001 - 400000
Retro-active, non retro-active change: the first term describes a modification to the data base after which old
and new Calculator results are no longer comparable over time (e.g. changes to a Business Unit Code or a
Section Code, reorganization of the Risk Delegation Hierarchy, extension of the Correlation Matrix
dimension etc.), the second term applies to regular updates of the data like Volatility, Correlation Matrix,
Betas, VaR Limits, Limit Holders, new Sections, Business Units and ReptIDs.
Return: the difference between two consecutive values of a financial parameter, two methods can be used:
Xt - Xt-1 weekly differences (used in interest rates and vegas)
ln (Xt/Xt-1) weekly relative differences (used in FX, commodities and cash equities)
Rho: the rate of change of the value of the portfolio with respect to the interest rate.
Risk (Exposure): loss which may occur on a trading position (various types of risks exist like: Market
(Systematic) Risk, Specific Risk, Credit Risk, Country Risk, Liquidity Risk, Operational Risk etc.).
Risk Aggregation: consolidation of exposures taking into account Market Diversification through the
Correlation Matrix.
Risk Class: a table in the Market Structure describing the main type of financial risks encountered in the
market: Commodities, Equity, FX, Fixed Income.
Risk Factor: the product of the Daily Volatility and the number of Standard Deviations (2.0) chosen for the
Value-at-Risk calculation.
Risk Factor = 2.0 (Annual Volatility / 252 )
Risk Sensitivity: attribute of the Position Risk Code describing what type of sensitivity is reported
(+1 USDVBP, Notional, Principal, Ounces, Vega +1% etc.).
Role: attribute describing the function of the user:
U: User, O: Org. Manager, S: Security Admin.,B: Beta Override Administrator, C: Controller).
Section: level 4 of the Risk Delegation Hierarchy, usually a trading desk holding a VaR Limit.

Sectors: segments of the economy like Finance & Insurance, Basic Industry, Energy, Transportation, High
Technology, Consumer Goods etc. into which stocks are classified. VaR exposures are not computed
separately for each sector, however, reports displaying market values of the shares by sector are provided.
Sensitivity: the degree of responsiveness of a portfolio to changes in the market defined according to the
financial instrument involved. Positions reported to the VaR system are actually Sensitivities.
Specific Risk: part of the volatility of a stock which is totally uncorrelated with the market according to the
Capital Asset Pricing Model (CAPM). The Total Risk (Stock Volatility) is related to the Market Risk
(Systematic Risk)and the Specific Risk as follows:
     TotalRisk MarketRisk SpecificRiskequity
2 2 2
 
Spread: difference in yield between two fixed income securities.
Standard Deviation (): the most common parametric measure of dispersion. 68.26 % of the observations of
normally distributed data lie within -1 and +1 , 95.44 % lie within  2.
Swap: agreement between two companies to exchange cashflows in the future according to a prearranged
formula.
Swaption: an option which gives the holder the right to enter an interest rate swap.
Term Structure: the pattern of interest rates on default-free debt instruments with various terms to maturity
illustrated by a yield curve.
Term Structure of Volatility: the curve of the relashionship between price volatility and time to maturity.
Time Series: historical data about rates and prices which are used to produce the volatility and the market
correlation needed by the VaR calculator, they are provided by third party vendors like DRI. The VaR model
assumes that proportional changes in price are normally distributed. (lognormal distribution of returns).
Time to Expiration: the period of time between the ‘Value Date’ and the Exercise Date of an option.
Trade Date: the business date to which the position value refers (‘Value Date’).
Value at Risk (VaR): the largest amount of capital that can be lost from day to day based on a specific
portfolio with 97.7 % probability (up to +/- 2 standard deviations move in rates).
FX spot risk Value at Risk (VaR) = (Position Value/FX rate * % Annual Volatility / 252 )*2
All other risks Value at Risk (VaR) = (Position Value * Annual Volatility / 252 )*2
VaR Calculator: the program which calculates the VaR figures using the Correlation Matrix:
VaR RiskVector CorrelationMatrix
Risk
Vector
2


































( )*
Components of the risk vector are individual VaR exposures.
VaR Limit: the Value-at-Risk exposure allocated by the management which must not be exceeded. A

distinction is made here between Official Limits, the fully binding limits, and Pro-Forma Limits, the
provisional limits defined for businesses where the quality of the data used in VaR exposure calculation is not
yet sufficient for controlling purposes.
Vega: the measure of change in the value of an option compared with a 1 % change in volatility.
Volatility: the annualized Standard Deviation of returns expressed in basis points for fixed income, in % of
price for equities, in $/oz. for precious metals, in $/barrel for oil etc.
Warrant: an option attached to a bond with a separate life and value. A warrant is freely transferable and can
be traded separately.
Weighted Volatility: Market Volatility calculated under the assumption that recent observations have to be
more heavily weighted than earlier ones.
Yankee Bond: bond issued in the U.S. by a foreign borrower in U.S. dollar.
Zero-Coupon Sensitivity: the change in value of a portfolio for a 1bp parallel shift of the zero-coupon yield
curve (i.e. bonds with no intermediate payments). Alternatively, the Par Rate Sensitivity is obtained by
shifting separately each Par Rate of the yield curve and calculating the induced change in value of the
portfolio. In the VaR system, sensitivity positions must be expressed against the Par Rate yield curve, since
all Time Series data refers to these rates.

2. What is Value at Risk
VaR, Value at Risk, is a trading market risk information and control tool that is globally implemented in UBS
GTRM. VaR measures only market risk of traded products; other risks such as liquidity risk, credit risk or
operational risk are covered by other UBS systems and procedures. The need for accurate market risk
measurement has been motivated for a number of reasons. First, measuring trading risk consistently across all
traded products allows senior management to set trading limits more fairly. Second, performance across
businesses and products can be better evaluated with valid risk-return comparisons. Finally regulation debate
is currently focusing on VaR methodologies. VaR uses a statistical approach, looking at the statistical
distribution of market movements and from a statistical model asses the magnitude of trading losses of the
current trading portfolio within certain confidence bands. This is defined such that there is only a 2.3%
probability of losing an even larger amount in that same period (a 2 standard deviation move).
Calculating VaR requires an estimate of the risk present in each market, and of the linear sensitivities of
trading portfolios to the risk parameters. Estimation of the risk present in each market requires detailed
analysis of time series of market data. The result of this analysis is a set of volatilities and correlations of
approximately 1000 time series. Linear risks consist of positions in underlying assets, as well as deltas and
volatility risks of option books; e.g. positions in foreign exchange, sensitivities expressed as a present value of
one basis point (henceforth PVBP) rise in interest rates, option vegas, etc. The volatility (or standard
deviation) of the market and the sensitivity of the position to the market together give linear VaR of a single
position. Correlations between markets account for diversification. Thus far, the methodology for linear
risks has required relatively simple computations based on matrix algebra.
When the relationship between return on portfolios and changes in market rates is not constant, for instance in
option portfolios because of the convexity of the return profile, one can no more estimate exposures by
multiplying sensitivities with risk factors. The so-called ‘closed form’ method (assuming a given level of
confidence for each number of standard deviations) does not apply. Simulation methods (reproducing by
numerical methods a distribution of the market underlyings and obtaining the actual change in P&L of the
portfolios) must be used instead.
A detailed description of the Value-at-Risk methodology is provided in reference 1.

2.1. Components of the Value at Risk System
The Value at Risk system consists of a database, a set of UNIX-hosted programs and utilities, and PC-hosted
applications (Graphical User Interfaces or “GUI’s”). The database contains Static Data, which are those data
that are not changing on a daily basis, and Daily Position Data, which reflect end-of-day Market Risk for a
wide variety of UBS businesses. The system has been deployed in five major UBS sites, namely Zurich (ZH),
London (LO), Singapore (SI), Tokyo (TO), and New York (NY). Smaller European sites, such as Paris (PS),
Frankfurt (FM), and Luxembourg (LU), North-American sites such as Toronto (TN), or East-Asian sites such
as Taipei (TP), Sydney (SY), and Hong Kong (HK) feed their information into and report out of the closest
major site. The data in each of the local sites are non-overlapping, that is, daily position data are booked in
one and only one place. Aggregation (“global rollup”) of the Daily Position Data from local sites is
performed at the Consolidation System in Zurich through replication of the local data. In other words, the
Consolidation System has the summary of all Daily Position Data from all sites.
DB Server
Zurich (local)
London
New York
Singapore
Tokyo
Toronto
Taipei
Sydney
Hong
Kong
Geneva
Paris
Frankfurt
Luxembourg
App. Server
Consolidation System
The details of the VaR System installation and operation can be found in references 3, 4.

3. Job Descriptions
Business Head: the person having the authority over the data covering trading information, exposures and
limits (‘Class 2’, business confidential data) and who can therefore grant system access to the users.
Data Owner: a product controller who has the authority to grant access to users to view positions on a
specific level of the business.
VaR Limit Holder: a manager with trading responsibility (risk taker) holding a Value-at-Risk Limit delegated
to him by the GTRM hierarchy , he further assigns this VaR Limit to the levels beneath him.
VaR Controller: a Product Controller whose commitment is to ensure proper quality and trustworthiness of
reported positions, P&L and exposures. He checks that, at all levels, no VaR Limit is exceeded. He also has
ability to feed position override files to correct erroneous information in the system (‘C’ role).
Org./Mapping Manager: the local ‘VaR Specialist’ reporting to an Account Manager. He maintains the
Organization Structure and the VaR Limits agreed between the Business Head and GTCO on the VaR
system. He is the main contact in the location for all mapping issues in the project (‘O’ role).
Security Administrator: the local user access administrator who defines in the application the nodes and the
level of details allowed to be seen by the user in the Risk Delegation Hierarchy. He reports to an Account
Manager but gets the approvals from the Data Owner (‘S’ role).
Authorization Supervisor: the coordinator, who manages authorizations in the whole system and supervises
the work of the local Security Administrators.
Datafeed Contact: a person working for an Account Manager responsible for position extraction from
outside sources. Each feeder system has a designated person for this function. Datafeed Contacts make
sure that the local position inventory is correctly mapped to the VaR System.
Beta Contact: person in a Location responsible of equity information deliveries (Betas and Sector Breaks).
Beta Override Administrator: Product Controller responsible for the overriding of equity Betas (‘B’ role).
Setting up the different roles for the users is described in references 14, 15.

4. Daily Data Feed Procedures
4.1. Daily VaR Reports
Positions are loaded and VaR exposures calculated where risk ends up (where risk is reported). This applies
also to businesses running on a back-to-back basis: the VaR exposure appears there where risk ends up (the
market maker). It is therefore important to realize that good quality of the position data is vital for the entire
process of VaR exposure calculation and limit allocation.
In particular, the VaR Controller checks:
 VaR including non-linear effects
 Noticeable changes over one trading day
 Non-linear effects (through a comparison between simulated results and those obtained with the variance-
covariance method)
 Possible manual corrections (overrides or re-feeding operations necessary to get the correct figures).
The different VaR reports are described in reference 12.
4.2. Standard VaR Exception Reports
4.2.1. DataFeed Status, Missing ReportIDs, Stale Levels
Datafeed Status: shows which data feeds have arrived for a given date, which one have not arrived yet but are
still expected and which one have been delivered after the last calculator run (stale results). An expected
datafeed is one which is defined as Active, Daily ‘AD’ in the VaRFeeds table (intermittent feeds with the
FeedStatus ‘AI’ are not reported as missing).
Missing Report IDs: for a given date, shows all Report IDs missing in the VaR aggregation (only for those
ReportIDs which had been included in the past 10 days calculations).
Stale Org. Levels: for a given date, shows which org. units have stale VaR Results because of data feeds
delivered after the last calculator run.
4.2.2. Missing Feed Roll-Over/Notification
Every day, early in the morning, a utility determines which feeds are missing for the previous business day
and rolls forward the corresponding positions from the preceding Trade Date. These PVT’s and EQT’s are
labelled with a ‘R’ in the Datafeed Status Exception Report.
Equally, a special utility sends an e-mail notification to the Datafeed Contacts of those missing feeds prior to
the mid-day run of the VaR Calculator.

4.3. Daily Procedures
4.3.1. Daily Data Feeds and Calculator Runs
The following chart shows the daily procedures in the VaR System:
Tokyo
Singapore
Zurich
London
New York
Consolidation ZH
Trade Date + 1
1:00-8:30 a.m.
local time
0:00 ZH time 0:00 ZH time 0:00 ZH time 0:00 ZH time
20:00 pm - 12:00 am
local time
12:00 noon 12:00 noon12:00 noon
20:00 pm - 14:00 pm
local time
20:00 pm - 19:00 pm (next day)
local time
16:00 pm - 16:00 pm (next day)
local time
T-1 Run
(11:00 am)
T-2 Run
(4:00 am)
daily standard VaR computations
(97.5 % level of confidence)
Trade Date + 2Trade Date
local time local feeding time
Close Of Business
Standard VaR calculations are performed 2 times every weekday. There is one run at 11:00 am (T-1 run) and
one run at 4:00 am (T-2 run). The 11:00 am run includes all Tokyo and Singapore datafeeds, most London
and Zurich feeds as well as the New York figures sent overnight. Tokyo and Singapore can view VaR for a
given trade date before the end of the next business day.
The 4:00 am run includes all datafeeds from all locations. This run (completed at 6:00 am ZH time) ensures
that New York can view VaR for a given trade date before the end of the next business day (defining the end-
of-trade time of the globally aggregated portfolio as the end-of-trade in New York). The calculation of the
consolidated VaR figures takes about 2 hours time for an average of 14’000 PVTs, 10’000 EQTs and 440
P&L matrices.
4.3.2. Rerunning the Calculator for Stale Dates
It is frequently requested to rerun the VaR Calculator for historical dates with stale results or wrong figures
(for instance: because of erroneous positions or changes in the Org. Structure/Market Hierarchy).
Runs for historical dates take place at pre-defined time slots:
 Every day (2 runs)
 Saturday (5 runs)
 Sunday (6 runs)
Two daily re-runs are done automatically by the VaR system, using the most recent Trade Dates with stale
VaR results (numbers which have been computed prior to the latest data feed). Alternatively, historical
runs scheduled for the weekend are defined manually in the system by the IT support personnel.
4.3.3. Getting the VaR Number for UBS
The VaR number for the whole of UBS (GTRM and GFIN, all business lines) is calculated. on the
Consolidation System and attached as a comment in the Reports GUI (yellow notepad).

4.4. Banking Holiday Procedure
4.4.1. Insuring a Complete Set of Trading Positions
On Banking Holidays trading positions are automatically duplicated from the previous business day, thus
assuring that GTCO has a complete set of position data for all local systems. The table below lists the
Banking Holidays for all the VaR sites in ‘97:
London Frankfurt Luxemb. Paris Singapore Hong Kong Sydney Taipei Tokyo New York Toronto Zurich Lugano
1-Jan-97 1-Jan-97 1-Jan-97 1-Jan-97 1-Jan-97 1-Jan-97 1-Jan-97 1-Jan-97 1-Jan-97 1-Jan-97 1-Jan-97 1-Jan-97 1-Jan-97
28-Mar-97 28-Mar-97 31-Mar-97 31-Mar-97 2-Jan-97 6-Feb-97 27-Jan-97 2-Jan-97 2-Jan-97 20-Jan-97 28-Mar-97 2-Jan-97 2-Jan-97
31-Mar-97 31-Mar-97 1-May-97 1-May-97 7-Feb-97 7-Feb-97 28-Mar-97 3-Jan-97 3-Jan-97 17-Feb-97 19-May-97 28-Mar-97 6-Jan-97
5-May-97 1-May-97 8-May-97 8-May-97 10-Feb-97 28-Mar-97 31-Mar-97 6-Feb-97 15-Jan-97 28-Mar-97 1-Jul-97 31-Mar-97 19-Mar-97
26-May-97 8-May-97 23-Jun-97 19-May-97 28-Mar-97 31-Mar-97 25-Apr-97 7-Feb-97 11-Feb-97 26-May-97 4-Aug-97 1-May-97 31-Mar-97
25-Aug97 19-May-97 15-Aug-97 14-Jul-97 18-Apr-97 9-Jun-97 9-Jun-97 10-Feb-97 20-Mar-97 4-Jul-97 13-Oct-97 8-May-97 1-May-97
25-Dec-97 3-Oct-97 25-Dec-97 15-Aug-97 1-May-97 30-Jun-97 4-Aug-97 4-Apr-97 29-Apr-97 13-Oct-97 11-Nov-97 19-May-97 8-May-96
26-Dec-97 25-Dec-97 26-Dec-97 10-Nov-97 21-May-97 1-Jul-97 6-Oct-97 9-Jun-97 3-May-97 11-Nov-97 25-Dec-97 1-Aug-97 19-May-97
26-Dec-97 11-Nov-97 9-Aug-97 2-Jul-97 25-Dec-97 1-Jul-97 5-May-97 27-Nov-97 26-Dec-97 25-Dec-97 29-May-97
25-Dec-97 31-Oct-97 18-Aug-97 26-Dec-97 16-Sep-97 20-Jul-97 25-Dec-97 26-Dec-97 1-Aug-97
25-Dec-97 17-Sep-97 10-Oct--97 21-Jul-97 15-Aug-97
1-Oct-97 31-Oct-97 15-Sep-97 8-Dec-97
2-Oct-97 12-Nov-97 23-Sep-97 25-Dec-97
10-Oct-97 25-Dec-97 3-Nov-97 26-Dec-97
25-Dec-97 24-Nov-97
26-Dec-97 23-Dec-97
31-Dec-97
The following procedure allows unattended duplication of positions in the event of a holiday or even several
consecutive holidays:
 On the banking holiday, in the morning, any missing datafeed are rolled over for the previous business
day, they appear with the ‘R’status (rolled over) in the Exception Report.
 On the next business day, the non-automated missing feeds arrive for the previous date replacing those
rolled forward with the ‘R’ status.
 All feeds affected by the banking holiday are rolled over, they appear with the ‘H’ status in the report.
In the example below, June 25 was defined as a banking holiday in Zurich but not in Basel and Lugano:
TradeDate LocationCode FeedID NumRecords LoadTime Description Feed Status
25/06/97 ZH BLBSFX 42 26/06/97 10:45:03:206 Banco di Lugano FX positions R
25/06/97 ZH BSCOFXMM 92 26/06/97 10:45:18:276 Core FX/Money Market (Basel) R
25/06/97 ZH CTGDHFX 32 26/06/97 10:45:07:523 PVT Cantrade from GDH System H
25/06/97 ZH GECOFXMM 184 26/06/97 10:45:21:133 GE Core FX/MM H
25/06/97 ZH GECOPMET 42 26/06/97 10:45:24:083 GE Core PM H
25/06/97 ZH LGCOFXMM 141 26/06/97 10:45:30:733 Lugano Core FX/MM R
How to deliver information about local holidays is explained in reference 2.

4.5. Currency Numéraire, Daily FX Rates
The Base Currency used in a Location to report P&L and Risk is the local unit of money so that all other
currencies are considered against it as commodities like securities, energy, metals, food etc. Consequently,
positions held in local Base Currency have no risk and must not be reported to VaR (in particular P&L).
Alternatively, all FX positions must reported with the opposite equivalent amount in Base Currency so that
VaR can be expressed against the local Base Currency (instead of the USD).
Therefore, a synthetic position in Base Currency offsetting all the FX spot positions of a given ReptID is
generated by the PVT Loader whenever FX spot risk is reported. The position is generated in the Base
Currency of the Location defined by the Capture Point of the position. Its FeedID is made out of 2 characters
for the Location Code plus 3 characters for the Base Currency and finally the suffix ‘SYN’.
Hence the VaR exposure calculated by the system always reflects the risk from the point of view of the local
Base Currency. For instance, the VaR figure calculated for New York is the exposure for a USD based
branch, while the number produced for Hong Kong reflects the risk of a Hong Kong Dollar based branch.
FX conversions take place using a set of spot rates provided locally to the VaR System on a daily basis. For
the sake of simplicity and reliability of operations, the management agreed to use the end-of-day FX mid rates
used for local revaluation, although this procedure introduces an inconsistency between the sites.
More about the delivery of FX rates to the VaR System can be found in reference 2.

4.6. Position Data Override
VaR Controllers (users with the ‘C’ Role) have access to a facility which allows for correction of erroneous
position (PVTs or EQTs) in the Primary Location they are authorized for.
The mechanism called ‘Create Adjustment Feed’ is similar to the regular daily position feed:
 a FeedID must be entered by the user (identical to his VaR UserID) with its valid Capture Point code
 a ReptID with a Position Risk Code must be selected (both accessible through a navigation tool)
 the position value with the ISO Currency code are entered
 for EQTs: the ISIN code, number of shares, market price and ISO Currency code are entered
 finally, a file (with a ‘pvt’ or an ‘eqt’ extension) is created, ready to be sent via a ‘ftp’ procedure to the
datafeed account on the local server.
Notice that the position override facility does not make any change to raw data; it only inserts a corrective
position which can easily be inspected using the Reports GUI.
For instance:
Initial position fed by the feeder ZHCOBOND is -100 but should be +200
The original PVT looks like this:
TradeDate ReptId PRC Value FeedId Capture Point
20/6/96 200002 454 -100 ZHCOBOND ZH
The Controller will send a PVT that looks like this:
TradeDate ReptId PRC Value FeedId Capture Point
20/6/96 200002 454 +300 EZHG1A ZH
The VaR system will recognize that the PV for this Trade Date, ReptId and PRC=454 is (-100+300) = 200.
VaR Controllers who are authorized to override positions (‘C’ Role) have to use their 6-character UserID as
FeedID for the correction feed. This identifier is accepted only in the Primary Location they are responsible
for.
Handling position overrides through the Reports GUI is explained in reference 12.
4.7. Daily Checks of the Mapping Interface: Example of Core
Every day, a set of log files are kept on the Zurich Local VaR system listing all discrepancies between the
Zurich Core portfolios and the ‘VaR Views’. This information has to be checked by the Mapping Managers
who are responsible for the accuracy of the position reporting interface.
The user account where the log file can be viewed is called:
logmgr/pw: 1fiddle
type "viewlog" at the $ prompt,
viewlog will ask for the type of log file and the date:
you are able to view the following types of logfiles:
ZHCOBOND
ZHCOFXMM
ZHCOPMET
fxspot
Enter the type of one of these logfiles: ZHCOPMET
Enter date for which to peruse the logfile (YYYYMMDD): 19961111

4.8. Definition of a New Feed
The decision to define a new feed in the VaR system as well as the identification of risks and positions is the
job of the local VaR Controller in co-ordination with GTCO and the Business Head. The translation of
trading information into VaR format is done by the local Mapping Manager while the design of the Mapping
Interface is under the responsibility of the Datafeed Contact (test procedures as well as start-up date for
production must be agreed with GTCO). The Datafeed Contact’s UserID must be entered as a valid code in
the Employee Table with a correct e-mail address to ensure that data feed notification messages can be sent
during position loading.
The format of a HP Open Mail address is: <firstname>.<lastname>/<org unit>@<mail_server_DNS_name>
for instance (when sent from a UNIX host): Walter.Neuenschwander/zhcity@sv400net.flur.zuerich.ubs.ch (Zurich)
Andrew.Tindle/locity@svscafel.lo.ubs.com (London)
Shuang-Jun.Chen/si@svfaber.raffles.si.ubs.com (Singapore)
Joji.Boyd/to1@svfuji.ub.tyo.ubs.com (Tokyo)
for UBS North America use the internet format:
for instance: nyyue@ny.ubs.com (New York)
VaR Controller
identifies
new positions
Mapping Manager
checks
PVT or EQT ?
Feeder Contact
enters the new
Feed ID
in the Feed Table
on local VaR
System
New feed
starts
on the agreed date
New FeedID is replicated at GTCO
Allocate PRC
Map instrument
to appropriate PRC
Map equities
to
ISIN codes
PVT EQT
Assign the positions
to
exisiting ReptID
or
create new ReptID
Assign new FeediD
Check that all
required fields
are supplied
New Feed
agreed
by Global IT
Support
Test the new feed
in the local
test environment

4.9. Maintenance of the Mapping Interfaces
The Mapping Interface is a program or a script (for instance written in Perl) which converts positions
produced by a Feeder System into records readable by the VaR Loader (PVT or EQT) with:
positions allocated to their Rept ID
markets risks identified by their Position Risk Codes (PRC).
Some Mapping Interfaces use the ‘Position Risk Name’ field defined in the VaR Market Structure to allocate
the correct Position Risk Code. This field should, as far as possible, not be modified in data releases, or if
absolutely necessary, changes must be done in conjunction with the Datafeed Contacts.
4.9.1. Using the Static Data Extraction Utility
Programmers and Datafeed Contacts who maintain mapping programs can use the Static Data Extraction
Utility to synchronize other databases with VaR or to obtain information required by their interface. The tab-
delimited file format facilitates importing the data into applications such as MS Access, MS Excel or Oracle.
The following objects, which are tables, views, or the result of database queries, are included in the daily
extracts (in the varextr HOME directory):
Object File Name Comments
Currencies Currencies.bcp All columns of the underlying table
FXSpotRates FXSpotRates.YYYYMMDD.bcp All columns of the underlying table for TradeDate YYYYMMDD
RiskDelegationHier RiskDelegationHier.bcp All codes and descriptions, from function to ReportID
MajorMinorHier MajorMinorHier.bcp All codes and descriptions, from function to ReportID
MktHier MktHier.bcp Risk Class, Broad Risk, Commodity, PRC, Risk Sensitivity Type
PositionCodes PositionCodes.bcp PRC, PRC Name, Risk Sensitivity Type, Currency of TS, Maturity Code
ReportID ReportID.bcp ReportID, Description
Employees Employees.bcp EmployeeCode, Location Code, First & Last Name, Phone, E-mail, Comments
VaRFeeds VaRFeeds.bcp FeedID, LocationCode, Description, ContactCode
TimeSeriesCodes TimeSeriesCodes.bcp All columns of the underlying table
Extended PRC Attributes PRCattr.bcp All the information about PRCs, including new extended attributes
To facilitate searching for PRCs, for instance, in datafeed preparation programs, a PRC file named
PRCattr.bcp is made available in the varextr HOME directory. This tab-delimited file provides the following
original and derived attributes:
1. Position Risk Code (from the database)
2. Position Risk Name (from the database)
3. Risk Sensitivity Type (from the database)
4. Currency of the Time Series it is mapped to (from the database)
5. Maturity Code (from the database)
6. Product Code (derived from the PRC description)
7. Currency to which the PRC pertains (derived from the PRC description)
8. Maturity (in months)
9. Rating of the corporate which issued the bond (when applicable)
10. Option Expiration (when applicable)
11 Reference Currency of the FX ccy pair (when applicable)
A detailed description of the PRC attributes is provided in reference 2.
PRC Position Risk Name Risk Sensitivity Currency of TS Maturity Product Currency of PRC Mat. in months Rating Option Expir.
1 USD GOVT 1M USDVBP USD 1M GOVT USD 1
69 USD A CORPORATES 1M USDVBP USD 1M CORP USD 1 A
2225 USD/CHF SPOT PRINCPL CHF 0M SPOT CHF 0
6062 DEM SWAPTION 3M OPT 2Y SWAP VOL VEGA1% DEM 2Y SWAPTION DEM 24 3M

4.9.2. Position Risk Codes Naming Conventions
In the Position Risk Name field:
the first descriptor is generally a currency or a currency pair (e.g. USD, USD/DEM)
the second descriptor defines the product (e.g. GOVT, CORPORATES, GOVT OPTIONS)
finally, the third descriptor is the Maturity of the risk.
4.9.3. Risk Sensitivity Type
Precious Metal risks are given in OUNCES.
Interest Rate risks are defined as the value of a basis point ccyVBP (par rate sensitivity).
FX Spot and Equity Index risks are indicated with PRINCPL (principal amounts).
Vega risks are defined as VEGA1% (change in value of the portfolio for a 1% move in volatility).
Future Contracts risks are defined as NOTIONAL (futures on commodities or equity indices).
Convertible sentiment risks have a Risk Sensitivity Type of RSKCAP (reported estimated risk).
4.9.4. Currency of the Time Series
This field is not always equivalent to the currency to which the Position Risk Code pertains. Indeed, many
Position Risk Codes are mapped to Time Series of other currencies due to the lack of historical market
information (for instance for FX OPT volatility). The VaR Loader will convert these positions from the native
currency to the currency of the Time Series.
4.9.5. Maturity
The Maturity is defined according to the standard GTRM Ladder (17 grid points)
4.9.6. Product Code
In order to facilitate the mapping between feeder systems and VaR, 53 products are defined.
4.9.7. Currency to Which the Position Risk Code Pertains
A Position Risk Code is always associated with a currency (except for the Precious Metals which are
expressed in Ounces). In many, but not all cases, the currency of the Time Series to which the Position Risk
Code is mapped is equal to the currency to which the PRC pertains. In other cases, PRCs are mapped to Time
Series with a currency which is different from the original one, due to the lack of historical market
information. In particular, historical volatility for vega risk is not available for many currencies so that the
corresponding risks have to be mapped either to one of the main currencies or to a default Time Series
expressed in USD. Recall that datafeeds must express the sensitivity in the currency of the underlying Time
Series unless an additional field specifying the currency of the position is defined in the PVT or the EQT
record
4.9.8. Maturity in Months
Contains the same information as the Maturity field, just expressed in months.
4.9.9. Rating of the Corporate Issuing the Bond
The credit quality of the corporate issuing the bond (AAA, AA, A, BBB); used only in the USD market.
4.9.10. Time to Expiration of the Option
Applies only for swaptions where the Position Risk Codes are classed by the Maturity of the underlying swap
(2Y, 5Y, 10Y) and Time to Expiration of the option (3M, 6M, 1Y).
4.9.11. Reference Currency in CCY Pair
For cross-currency vegas: reference currency addressed by the PRC.

4.10. Additional Functions Performed by the VaR Loader
4.10.1. Currency Conversion
For certain positions it is mandatory to specify the currency in the feeder file. The reason is that for some
Risk Position Codes no appropriate Time Series could be found. As a solution, these Risk Position Codes are
for the time being mapped to alternate Time Series that happen to be expressed in a currency different from
that of the position code (e.g. LUF interest rates are mapped to BEF interest rates). The Loader will therefore
automatically translate the position into the currency of the Time Series they are mapped to.
4.10.2. Enforcing Uniqueness of the Position in the PVT/EQT Table
The index of the PVT table is based on the composite key: TradeDate, ReptID, PositionRiskCode, FeedID,
(TradeDate, ReptID, ISINCode, FeedID for the EQTs). Consequently, the VaR Loader will enforce
uniqueness of the rows by aggregating duplicate position entries (same value for ReptID, PositionRiskCode,
Trade Date, FeedID or for EQTs: ReptID, ISINCode, Trade Date, FeedID).
See also in reference 2.
4.10.3. Generation of the Linear P&L Matrix
Linear P&L matrices defined in the datafeed through an equation (for the non-linear VaR calculation) are
generated by the Loader.
5. Daily Reporting
5.1. Using the VaR Reports Application
The VaR System is a risk aggregation and reporting application primarily used in the Product Control area by
the VaR Controllers to monitor market risk. Local business is usually captured ‘on site’, so that reports
produced on the local VaR System can satisfactorily display exposures and limit utilization. Alternatively,
getting the global figures needed by Business Heads may require access to the Consolidation System. Those
users will therefore remotely login to the desired VaR System by selecting the server name in the Reports GUI
(providing access has been granted by the Data Owner).
Following servers can be addressed:
Primary Location SQL Server Name
(all servers use 2025 as listening port number)
IP Address Hostname (DNS name)
GTCO (Consolidation) ZHVAR1CP 193.134.107.112 man5112.mp.zh.ubs.com
Zurich ZHVAR1LP 193.134.107.111 man5111.mp.zh.ubs.com
London LOVAR1 139.149.224.236 s2008.sys.lo.ubs.com
New York NYVAR1LP 161.239.136.57 nyvar1p.ny.ubs.com
Singapore SIVAR1LP 192.238.8.190 svtahan.raffles.si.ubs.com
Tokyo TOVAR1LP 147.60.127.50 svvenus.ub.tyo.ubs.com
A Batch Facility is provided to run a list of daily routine reports for the desired level of consolidation. An
export utility is also available for post-processing purposes in all usual file formats (text comma separated,
Excel, etc.) as well as for output extraction (to send for instance a report by E-Mail). The latter is dumped into
a special format (with the extension .PSR) readable to a program called ‘psrview’.
The export utility provided by the Reports GUI does not accommodate automatic data extraction and report
compilation; it is also not convenient for retrieval of data across a range of dates. A new facility has therefore
been developed to provide better access to data : the VaR Reporting Engine.

5.2. VaR Reporting Engine
5.2.1. Reporting Engine Overview
The VaR Reporting Engine is a facility to extract data from the VaR system for the purpose of including it in
reports or other applications and combining VaR with P/L figures. In particular, the following reporting
functions become possible:
 Displaying historical VaR for a range of dates
 Extracting data for the purpose of creating graphs of VaR over time
 Cross tabulation of VaR/limit usage along a variety of organizational or date dimensions
 Daily FX/interest rate sensitivities over a period of time
 Equity detail on the security level, which includes VaR, market value, market and specific risk.
 Comparison and average reports over a period of time
See also the user guide (reference 17 ).
5.3. The PC Calculator (“Scratch Pad”)
5.3.1. PC Calculator Overview
The PC-based VaR Calculator, known previously as the ”Scratch Pad”, provides a PC-Windows-based front
end for inputting position data and calculating Value-at-Risk (VaR) numbers. Position data may be equity-
based or non-equity-based. These data may originate from the VaR Reporting application via a clipboard
transfer or manually entered. A set of positions entered in the VaR calculator is known as a Scenario.
Multiple scenarios may be used at any given time. Such scenarios may be stored in a text file or retrieved for
further analysis. The PC-based VaR calculator uses the same reference data as other VaR applications. As
such, it requires a login to the VaR SQL Server. The user’s login for running the VaR Reporting application
may be used for running the PC-based VaR calculator. This application may also be used to view and export
subsets of the Correlation Matrices and Volatilities. These correlations and volatilities are exactly the same
as the ones used by the UNIX-system-based VaR calculator.
5.3.2. Getting Intraday VaR for a Portfolio of the Core System
GTRM Core (Version 2.1 or higher) provides a new function to download a file containing the data of a
portfolio, a book or a ‘view’ in the format required to create a VaR scenario. Equally, Release 4.2 of VaR
supports an auto-loading facility which allows to update automatically a scenario in the PC Calculator if the
file changes on disk.
5.3.3. Viewing the Market Hierarchy with the PC Calculator
Scratch Pad also enables the user to navigate through the Market Hierarchy (Risk Class, Broad Risk Type,
Commodity, Position Risk Code) and to view and print all the details about Position Risk Codes or Time
Series such as the description, the Volatility and the Correlation Coefficients. In addition, a subset of the
Correlation Matrix (up to 20x20) can be viewed or exported as a text file.
5.3.4. Browsing for Equities and Betas with the PC Calculator
Accessing the Equity Betas defined in the data base is also possible through an alphanumerical search utility.
The selected stocks can then be dragged into a VaR scenario to simulate a typical trader’s portfolio.

6. Management of Reference Data
6.1. Data Replication
Reference Data is information common to the entire corporation (static data and market information) which is
maintained consistent between the VaR Systems through data replication. A distinction is made between the
‘Primary Site’ where data is generated and the ‘Replicate Site’ where data is replicated (not to be confused
with the Primary Location naming convention used for sites with a VaR System installation). The table below
lists the classes of data of the VaR application together with a description how information is kept consistent
across the bank.
 Positions, feed and calculator status data is generated locally and replicated to the Consolidation site.
 Static data, information on access control and Organization Structure, as well as market data is maintained
centrally and replicated to the local systems.
 Equity Betas provided by the local sites are sent as standard equity information files to the Consolidation
System and loaded centrally, they are replicated to the local systems.
 FX Spot Rates are the exception to the rule: they are loaded locally and may not be consistent across the
sites.
Classification Description How they are maintained
Market Structure Time Series Codes Centrally, replicated from the Consolidation System
Time Series Labels Centrally, replicated from the Consolidation System
Risk Classes Centrally, replicated from the Consolidation System
Broad Risk Types Centrally, replicated from the Consolidation System
Commodity Code Centrally, replicated from the Consolidation System
Position Risk Codes Centrally, replicated from the Consolidation System
Risk Measure Types Centrally, replicated from the Consolidation System
Financial Element Codes Centrally, replicated from the Consolidation System
Equity Information Equity Betas Centrally, replicated from the Consolidation System
Beta Source Location Centrally, replicated from the Consolidation System
Countries Centrally, replicated from the Consolidation System
Equity Index Country Centrally, replicated from the Consolidation System
Location Country Authority Centrally, replicated from the Consolidation System
Spot Rates FX Spot Rates Locally Generated
Positions PVT Locally, replicated to the Consolidation System
Equity Positions Locally, replicated to the Consolidation System
Calculator Results VaR Results Locally Generated
Loader/Calculator Statistics Datafeed Status Locally, replicated to the Consolidation System
Calculator Running Locally, replicated to the Consolidation System
Feeds Locally, replicated to the Consolidation System
Security/Access Control Nodes allowed to be seen Centrally, replicated from the Consolidation System
Employees Centrally, replicated from the Consolidation System
Employee Roles Centrally, replicated from the Consolidation System
Reference Data Currencies Centrally, replicated from the Consolidation System
Regions Centrally, replicated from the Consolidation System
Locations Centrally, replicated from the Consolidation System
Organization Structure Risk Delegation Hierarchy Centrally, replicated from the Consolidation System
Major/Minor Business Lines Centrally, replicated from the Consolidation System
Correlation & Volatility Correlation Matrices Centrally, replicated from the Consolidation System
Matrix Type Centrally, replicated from the Consolidation System
Standard Deviations Centrally, replicated from the Consolidation System
Operational Limits Limits Centrally, replicated from the Consolidation System

6.2. Updates of Market Volatility and Correlation
Market Time Series Data is processed centrally at GTCO using specially developed routines and programs.
The outcome is a set of values for the Market Volatility, reflecting the average annual fluctuation of leading
financial indicators, and a Correlation Matrix translating in mathematical form the mutual interaction
between them.
6.2.1. Time Series Maintenance
The volatility and correlation data derived from time series perform an integral role in the calculation of risk
in the VaR application. Time Series are not loaded every day but on a 1-2 week basis. In all cases the data is
obtained from the individual provider and edited to exclude extraneous data. The edited time series are then
transferred to the server containing the FAME master database where they are further formatted and loaded
into the FAME database. Following the time series integration the correlation matrix is computed for input
into the VaR application.
6.2.2. Data Providers, Frequency of Updates
The two main data providers are DRI and Bloomberg. For a matrix update data must also however be
downloaded from all the following sources:
Source Update Frequency By
 DRI (downloaded twice a month) VaR team
 Bloomberg (downloaded twice a month) VaR team
 UBS London FI Database (downloaded twice a month) VaR team
 GXD (FX implied vols.) (downloaded twice a month) VaR team
 FX correlations used in datafeeds (updated once a quarter) GTRI LO/NY
 Eurobrokers (downloaded twice a month) VaR team
 Datastream. (downloaded twice a month) VaR team
 UBS Commodities Trading (downloaded twice a month) VaR team
 UBS Singapore, UBS Toronto (e-mailed twice a month) VaR team
 Synthetic Time Series
 GED (Global Equity Derivatives) (updated once a quarter) GTRI LO/NY
volatility and covariance matrix of equity implied volatility
 GFD (Global Fixed Income Derivatives) (updated once a quarter) GTRI LO/NY
volatilty and covariance matrix of interest rate spreads
The methodology used in the generation of synthetic time series is explained in references 6 ,7, the
procedures for time series downloading are described in reference 8.

6.2.3. Distribution of Market Data (Volatility and Correlation)
Once the correlation matrices and the standard deviations have been generated, they can then be sent to the
test and production machines in the different VaR sites. Each site has a test and a production server and the
matrix is sent to both. During a matrix update the matrix can be sent to both sites at once, however new
market hierarchy matrices must first be tested fully on the test servers before they can be installed on the
production machines
6.2.4. Distribution of Correlation Matrix Files for the PC Calculator
While the VaR PC Calculator uses the volatility factors stored in the Sybase database, the Correlation Matrix
which is kept on a binary file is distributed around UBS to the PC servers via the Bank Wide Web by the
Group IT Support Organization. The matrices are available on each PC-server running the VaR application in
J:VARDATAMATDIR (users must have read access to this directory).
They can be found on the Bank Wide Web under the following url (this is a secure page, password required):
https://svcheck.flur.zuerich.ubs.ch/var_data/var_matrix.html
UBS subsidiaries who can’t access the BWW get the matrices via ftp using the ‘var’ account on their server.
Banco di Lugano ftp 192.168.134.20 as user var
binary mode tranfer
cd /sys2/groups/vardata/matdir
put matrix file(s)
Cantrade ftp 194.38.197.250
binary mode tranfer
cd /sys2/groups/vardata/matdir
put matrix file(s).
In GTCO, the matrix files are copied automatically from the UNIX environment to the PC servers (defined in
the .netrc file of the cormgr home directory) through the CmatDist.sh shell script and the vmatdist account.
The procedures to be followed in the distribution of new Correlation Matrices are described in reference 9.

6.3. Collection of Equity Betas
6.3.1. Improved Handling of Equity information
Starting with Release 3.0, considerable improvements have been made in dealing with equity related
information. The collection and distribution of equity information has been simplified to the point that local
sites have the facility to send new or updated equity information to the Consolidation System for processing at
any time, not just prior to data releases. GTCO will assume the responsibility for scheduling and running the
loader that updates the Equity Betas table. This table is of course replicated to all local systems.
6.3.2. Delivering Equity Information to the VaR System
Equity controllers have often expressed the need to enter equity information quickly for new stocks.
Therefore, local sites are able to send small (low-volume) eqtinfo files, containing information about new
stocks and urgent updates of parameters of existing stocks.
An insert can be performed on a “live” system without affecting other VaR programs (Loaders, Calculators),
because by definition, such an operation implies that no record with this ISIN code previously existed.
Therefore, an insert will not disrupt a running calculator or someone viewing VaR reports or using the PC-
based VaR calculator. Replication of inserts from the Consolidation System to all local systems will ensure a
quick turn-around time.
Updates are another matter. An incoming update to equity information during a Calculator run will yield
inconsistent results if the Calculator uses equity positions with the updated ISIN code. For that reason,
updates must be filtered out of the eqtinfo files and transferred to a holding area for processing during “quiet
times”. In particular monthly, high-volume updates must be postponed until a time during which no
interruption of other applications is likely.
Differences between inserts and updates are summarized in the table below.
Insert Update
Nature of transactions Equity information inserted into the
EquityBetas table with new ISIN
codes.
Replace values for beta, total risk, or equity
index in the EquityBetas table
Impact on the VaR systems None, except that the sender of the
inserts is able to load new equity
positions using the new ISIN codes.
Potentially disruptive at all VaR sites
When executed Continuously and automatic Scheduled weekly on Sunday evening
Note: high volumes of Beta inserts (> 2500) are also treated in deferred mode (on Sunday evening).
6.3.3. Maintaining the List of ISINs and Dummy Codes
In addition to the updates described above, GTCO personnel will also be able to schedule deletions of
obsolete or incorrect equity records, as long as the codes are not used in the EquityPositions table. Similarly,
the dummy equity codes and their associated parameters are maintained by GTCO only. This conforms to a
practice in the past of rejecting dummy codes when sent by local sites in equity files.

6.3.4. How Equity Information is Delivered
The following diagram shows how equity information is maintained.
Consolidation
system VaR
database
Validation
and loading
Standard "eqtinfo" file local VaR
system
replication
local VaR
systemreplication
Updates?
Yes
No
Save updates in
holding area for future
execution
.
.
.
As the diagram shows, a standard equity information file (eqtinfo) is sent to the Consolidation system, where
it is processed. Processing includes an elaborate validation process, in which the supplied values for equity
parameters are verified against reference data and rules. Examples of such rules are
 Ensure that the combination of Equity Index and Country code (first two characters of the ISIN) is valid
 Whether a sending location (“Beta Source”) is allowed to modify the data, i.e., whether it is the
“Authority” on the equity information
 Enforce valid ranges for beta and total risk.
6.3.5. BetaSource Codes
BetaSource is a globally unique identifier maintained by GTCO and intended to identify the Location, and
within location, the source supplying the Betas. A table (BetaSourceLocation) is maintained for this purpose.
The currently assigned codes are shown below.
BetaSource Description Location
BAN Barra NY NY
BLN Bloomberg NY NY
CNN Controllers New York NY
BAL Barra LO LO
BLL Bloomberg London LO
BAS Singapore SI
BAT Tokyo TO
ZHO Zurich ZH
UBS GTCO (dummy ISIN codes) GZ

6.3.6. Validation Rules
 The Location code embedded in the file name ‘LL’ must correspond to the Location implied by the
BetaSource field, this, in order to identify the Owner of the equity record as the Authority.
 The sender is recognized as being the Authority for an equity Beta if the Location code ‘LL’ embedded in
the file name is the same as the Location code in the LocationCountryAuth table for the affected ISIN.
 Locations may send Betas for countries they have no authority on, providing that this is a new record
(insert) in the Beta table, they become consequently the Owner of the information.
 A Location may send Betas only with the BetaSource codes allocated to it.
 All records in the eqtinfo file must have the same BetaSource code.
 Only the Owner of an equity information record may delete it (if the Authority wants to do it, it must first
become the Owner through an update of the record).
 Only the Location who is the Authority for a specific equity may override the Beta information.
 A check is made whether the specific risk is negative, given the values for Total Risk and volatility implied
by the Equity Index for the applicable MatrixID, that is, the one that the calculator would use for today
(default matrix type is read from the loader’s parameter file). Values that cause the specific risk to be
negative are accepted but logged. Accepting these is no problem, because the calculator and other
applications set the specific risk to zero when negative. However, further action may be taken to update
the equity index volatility and/or total risk to avoid this condition.
Example:
New York (‘LL’ code = NY) sends a Beta record with BetaSource BAN for a NA equity
New York is the Authority over this Beta: inserts and updates are allowed in any case
New York (‘LL’ code = NY) sends a Beta record with BetaSource BAN for a European equity
New York is the Owner of this Beta: inserts are allowed, updates only if it was not
previously changed by London.
6.3.7. Beta Update Frequency
Recall that the Betas provided by the Barra or the Bloomberg system are the predicted systematic risk
coefficients for a time horizon of 3 months and must be consistent with the volatility levels computed by the
VaR team for equity indices.
It is therefore the responsibility of the local Controllers to get the Equity Betas updated twice a month
through the Beta Contacts.

6.3.8. Which Countries does Each Location Have Authority Over?
A table (LocationCountryAuth) is maintained in the database with the Location code and Country code that a
Location is the Authority over. This table is printed below with the full text of the country name.
6.3.9. Valid combinations of Country Code and Equity Index
The Country code of an eqtinfo record is derived from the first two characters of the ISIN code. A table is
used to maintain the valid combinations of Equity Index and Country code. A Country may have several
indices assigned to it (e.g. U.K.), so may an index be assigned to several Countries (e.g. stock with US ISIN
prefix mapped to the Egyptian index).
6.3.10. Setting the Beta FeedIDs and the Beta Datafeed Contacts
E-Mail notification is provided to the Beta Contact for a particular BetaSource, defined as a feed in the
VaRFeeds table on the Consolidation System (in a similar way as for PVTs and EQTs).
The FeedID is defined by the system through the “EQT”prefix plus the BetaSource code (for instance: EQT +
BAN for NY). The personal record of the Beta Contact (UserID, First name, Last Name, E-Mail Address)
must be entered in the ‘Employee’ table by the Security Administrator.
6.3.11. New Set of Dummy ISINs Using the Country Code
The strict validation rules for equity information discussed before also affects the Dummy ISINs. The latter
will be redefined by GTCO and inserted into the Equity Beta Table.
Time will be given to the local sites to amend their Feeder Interfaces according to a new list of Dummies.
After the completion of the conversion by the sites, the old Dummy codes will be deleted from the Beta Table
and the Default ISIN codes associated to the Locations (for the case of missing ISINs) will be updated
accordingly.
Rule for the usage of Dummy ISINs:
Dummy ISINs should be used only in exception cases when no Beta or ISIN information is available.
Whenever new equity information is provided by the market, user should take benefit of the Beta insert
facility in order to avoid unnecessary allocation of Dummy ISIN codes.
6.3.12. Historical Equity Information
All the changes (insert/update/delete) applied to the EquityBetas table are kept in a historical information
table (EquityInfoHistory) for auditing purpose.
6.3.13. Equity Sector Breaks
In order to accommodate equity sector break reports in the VaR system, a set of tables mapping equities to
industry sectors is provided. These tables are maintained at the Consolidation Site and replicated to Local
Sites (as with all market tables).
The full description of the Beta files specification is provided in reference 2.

6.3.14. Beta/Total Risk Override
VaR provides a GUI mechanism for overriding Beta and Total Risk at the Report ID level. The scheme
provided is flexible enough to allow a controller to set an override on any stock, regardless of geographical
considerations. The rationale for this is that the purpose of the override is largely business-driven. Some
critical aspects of the functionality are as follows.
 Ability to accommodate a range of dates for which a particular override is applicable. Thus, a start date
and end date will be stored in the system.
 Ability to resolve cases where two businesses set overrides on the same stock for a given date. If this
occurs, the overrides associated with the largest position (in absolute value) are applied to all businesses
at that and higher level of the hierarchy. In the unlikely event that two separate businesses set overrides
on positions of the same size, then differences will be resolved by taking the first override in the list.
 A graphical user interface which provides controllers with a mechanism to update and maintain the
override table. A loader mechanism is avoided here. The maintenance is performed through a special
utility in the VaR Reports application; only users with a ‘B’ (Beta Override Administrator) role can
access this utility.
The assignment of ‘B’ roles to appropriate Local Site users is performed by the User Authorization
application. This allows the Security Administrator of a given VaR site to define certain users as Beta
Override Administrators for any UBS locations which feed data into that VaR site.
Entering and maintaining beta overrides in the system is a job done by the Beta Override Administrator of
each site for the Rept ID Domains they are responsible for. Data capture takes place on the Local System and
are replicated to the Consolidation System. An additional utility has been developed as part of the existing
VaR Reports application to enable adding, modifying and deleting beta override records.
New or modified records are tested for the following validation conditions:
 Valid ISINcode (i.e., exists in the EquityBetas table).
 Check that EndDate  StartDate (or NULL for open-ended. EndDate = StartDate for a 1 day override)
 Valid ReportID
 Check that the User has proper authority for selected ReportID. Authority rules will be based on user’s
location code. This user will be only allowed to add/modify BetaOverrides for ReptIDs of his Location
 Check whether Beta and Total Risk are valid- i.e. that they fall within pre-defined bounds (-3 Beta 3)
 Test for negative specific risk - warning will be issued but record will still be accepted.
 Check for duplicate overrides for same or overlapping ISINcode/ReptID/Date Range.
Once the new or modified record has passed the validation tests, the GUI will modify the BetaOverrides
table accordingly. The changes will then be replicated to the Consolidation Site in Zurich.
6.3.15. Beta Override Audit Table
An Audit Trail facility is also available to track any changes to the BetaOverride table. Changes to the
BetaOverride table will be recorded in the BetaOverrideAudit table. This table will include all the fields
from the BetaOverride table along with an additional action field indicating the type of change, Insert,
Delete, or Modify.

6.4. Maintaining the Market Structure
6.4.1. New Time Series Codes
Introducing new Time Series in the System directly affects the Correlation Matrix (its dimension and its
addresses). This implies that a substantial revision to the Time Series requires the regeneration of correlation
and volatility for all existing MatrixIDs. Equally, changes in the Time Series affect the mapping of the
Position Risk Codes, either through the introduction of new PRCs or through the remapping of existing risk
codes.
6.4.2. Renaming the Position Risk Codes
Occasionally, the description of the Position Risk Codes may be changed in order to define the instrument
more accurately like for the example below (add the rating of USD corporates in the description field). This
kind of changes which may affect local Mapping Interfaces must be made in conjunction with the Datafeed
Contacts.
PositionRiskCode Old PositionRiskName New PositionRiskName
69 USD CORPORATES 1M USD A CORPORATES 1M
74 USD CORPORATES 12M USD A CORPORATES 12M
75 USD CORPORATES 2Y USD A CORPORATES 2Y
83 USD CORPORATES 10Y USD A CORPORATES 10Y
6.4.3. Adding New Position Risk Codes
Quite often, new Position Risk Codes are added to the Market Structure. This update is not retro-active
meaning that it does not affect historical runs.
6.4.4. Remapping of Old Position Risk Codes
This change may also occur occasionally in order to improve the accuracy of system (better estimate of the
volatility). Although this must be considered as a retro-active change, it does not prevent the user from
running historical calculations.
Important: whenever the currency of the underlying Time Series of a Position Risk Code is changed (for
instance, because of better market data information), all historical positions (EQTs and PVTs) stored in the
data base must be converted, since they are expressed in the old currency. This can be done either by re-
feeding the files or running an ad-hoc SQL-script on the local VaR systems.
6.4.5. Market Hierarchy Updates
The Market Hierarchy gets continuously improved through the addition of new PRCs and Time Series
(currently one update every 4-6 weeks). Local Controllers can bring up their requirements using the e-mail
address of the VaR Business Support group in Zurich.
The procedures in place for Market Hierarchy updates are described in reference 10.

6.5. Maintaining Static Data
Static Data is information not qualified by Trade Date and most often defined by UBS or international
standards such as ISO, it is centrally maintained on the Consolidation System and replicated to the local sites.
6.5.1. Locations
The VaR System distinguishes between the Primary Locations where a VaR System is installed and
Secondary Locations which are remotely connected to a Primary Location. Both of them deliver feeds to the
VaR System and have access to the Reports GUI. Each Location has a Rept ID Domain and a Default ISIN (if
applicable) defined in the table.
Location
Code
Region Name Location
Type
Datafeed
Location
Base Currency Rept ID
lower
bound
Rept ID
upper
bound
Default ISIN
GZ G GTCO Primary N/A CHF 0 999,999 n/a
SI A Singapore Primary SI SGD 150,001 200,000 SGDI00000001
HK A Hong Kong Secondary SI HKD 325,001 350,000 HKDI00000001
SY A Sydney Secondary SI AUD 350,001 375,000 AUDI00000001
TP A Taipei Secondary SI TWD 375,001 400,000 TWDI00000001
LO E London Primary LO GBP 50,001 80,000 GBAL00000001
PS E Paris Secondary LO FRF 80,001 85,000 FRDI00000001
JE E Jersey Secondary LO CHF 85,001 90,000 n/a
LU E Luxembourg Secondary LO CHF 90,001 95,000 BEDI00000001
FM E Frankfurt Secondary LO DEM 95,001 100,000 DEDI00000001
ZH E Zurich Primary ZH CHF 100,001 120,000 CHSM00000001
LG S Lugano Secondary ZH CHF 120,001 125,000 CHSM00000001
BS S Basel Secondary ZH CHF 125,001 130,000 CHSM00000001
CA S B. Cantrade Secondary ZH CHF 130,001 135,000 CHSM00000001
BL S B. di Lugano Secondary ZH CHF 135,001 140,000 CHSM00000001
HS S Hyposwiss Secondary ZH CHF 140,001 145,000 CHSM00000001
GE S Geneva Secondary ZH CHF 300,001 325,000 CHSM00000001
TO J Tokyo Primary TO JPY 250,001 300,000 JPTO00000001
NY N New York Primary NY USD 10,001 40,000 USDI00000001
TN N Toronto Secondary NY CAD 40,001 50,000 CADI00000001
F_ F GFDE Virtual LO USD 200,001 210,000 n/a
Q_ Q GEDE Virtual NY USD 210,001 220,000 n/a
X_ X GXDE Virtual ZH USD 220,001 230,000 n/a
C_ C GBCD/GECD Virtual ZH USD 240,001 250,000 n/a

6.6. Updating the Organization Structure
The Organization Structure is maintained on-line by the Org./Mapping Managers by logging in remotely to
the VaR Consolidation System. All modifications that pass verification are replicated to the local sites. This
avoids the need for data releases and makes coordination of cumulative changes between the sites possible.
6.6.1. Local and Global Changes to the Organization Structure
The competence to maintain the Organization Structure via the Org. GUI is shared between the local and the
global responsible in the following way:
Organization units in the Risk Delegation Hierarchy on level 5 (Business Units) are maintained by the
local Org./Mapping Manager in so far the Rept IDs under that node fall within his local range.
Employee records for VaR Limit Holders as well as VaR Limits are updated by the local
Org./Mapping Manager for persons (up to level 3) from Locations under his authority.
Major/Minor Business Lines as well as levels 1, 2, 3 & 4 of the Risk Delegation Hierarchy and of the
Legal Entity Hierarchy (LEH) are maintained by global Org./Mapping Managers. The latter have the
right, in addition, to update any part of the Organization Structure for all Locations.
6.6.2. Retro-Active and Non Retro-Active Changes
The VaR System does not keep track of past structures; therefore users should avoid as much as possible to
make a retro-active change to the data base, that is a modification which makes comparison of historical VaR
results impossible over time. Alternatively, non retro-active changes like the addition of new Rept IDs,
Business Units and Sections or corrections to description fields which do not affect results from the past can
be done without restriction.
DO:
Retro-active changes required by the business (to reflect the changes in the organization) like moving Rept
IDs from one unit to another.
DON’T:
change Business Unit or Section codes because they have direct impact on the Sybase Look-up Table used to
retrieve the VaR results (old results are not accessible anymore through the front-end GUI).
If a Rept ID deletion is attempted , a check is made against the entire PVT and EQT content of the data base to
determine whether this Rept ID has ever been used to identify a risk. If so, the deletion is canceled.
6.6.3. Changes to the Org. Structure which Affect the VaR Limits
Changes which affect the VaR Limits must be done cautiously and only after approval by Product Control and
Business Heads.

7. Market Risk Limits
7.1. VaR Limits, Why?
Limits have always existed in the past as a self-regulatory mechanism to ensure the stability of an institution.
Current GTRM trading limits are typically based on product and risk type specific methodologies (i.e. delta or
net position). This means, for fixed income products, that limits are based on interest rate deltas (in CHF), and
for currencies, commodities and equities they are based on a net CHF position (or equivalent underlying
position in the case of equities and equity options). In this type of system it is almost impossible to compare
exposures in one product to exposure figures in a second product because of different volatilities as well as
the offset effects of correlation. A limits system based on Value at Risk (VaR) is desirable because it allows
business managers to compare risk usage using figures that are essentially in the same units- a potential loss
figure in CHF. Furthermore, position offsets and business diversification are taken into account giving new
incentives for sensible trading decisions. The Bank has reached a stage where the implementation of a VaR
based limits system is not only possible but critically needed.
7.2. Principles of a VaR Limit System
Limit setting and limit delegation has to adhere to the following set of principles:
 Limit delegation follows the risk delegation hierarchy. This hierarchy contains the functional (and partially
the line) management structure in the risk management of GTRM.
 A VaR limit is delegated to every node of the risk delegation hierarchy. The manager responsible for the
node (for the organizational entity represented by the node) has to make sure that VaR exposures do not
exceed the limit.
 By delegating limits to more than one organizational unit (i.e. the child nodes) potential offsets in positions
and diversification between the positions of the units can be exploited. The simple sum of limits delegated
may exceed the original limit received (excess allocation).
7.2.1. Proactive Management
By using current market volatilities and correlations in the calculation of VaR numbers, these numbers change
even if the underlying exposure may not; thus more frequent updates in market data will cause VaR to
fluctuate vis-a-vis any limit. VaR can also increase because the underlying position grows or because a new
composition leads to less diversification. The three sources of change in potential VaR usage require
proactive limit management and monitoring with these in mind.
Each manager responsible for limit setting and exposure management will have access to the VaR system and
be authorized to access the positions of the units reporting to him. A set of VaR usage vs. limits reports will
aid managers in the monitoring and allocation process.
7.2.2. Minimum Quality Requirements
Quality of VaR data is affected by three main factors:
 Market data: availability of time series, methods of volatility & correlation calculation, update frequency
 Position details: accuracy and completeness
 Methodologies used to cover the individual businesses as well as the individual risk categories.
For VaR limit setting purposes the key questions are whether VaR quantifies risk more accurately than
existing approaches and whether VaR is consistent with historical P/L volatility.

VAROPS

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (16)

Similar a VAROPS

Similar a VAROPS (20)

Más de Israel Marcus

Más de Israel Marcus (6)

VAROPS