Value at Risk (VaR) Mapping to VaR: from Products to PVT/EQT Software Release 5 Document Title Mapping to VaR: from Products to PVT/EQT, Software Release 5 Version 1.0 Status Final Author Information Alexandre Riesch/Isidore Marcus/Michael Heintze/Marc Nunes/Glenys Lynn Date Last Revised December 15, 1997
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Value at Risk (VaR)
Mapping to VaR:
from Products to PVT/EQT Software Release 5
Document Title Mapping to VaR: from Products to PVT/EQT, Software Release 5
Version 1.0
Status Final
Author Information Alexandre Riesch/Isidore Marcus/Michael Heintze/Marc Nunes/Glenys Lynn
Date Last Revised December 15, 1997
Mapping to VaR: from Products to PVT/EQT Page 2
MAPPING Version 1.0 December 15, 1997
I. INTRODUCTION 6
I.1 THE EQUITY POSITIONS FILE (EQT) 6
I.2 THE POSITION VALUES FILE (PVT) 6
I.3 POSITION RISK CODE AND POSITION VALUE 7
I.4 SPLITTING 8
I.5 THE P&L MATRIX (LOOKUP TABLE) 9
II. FOREIGN EXCHANGE 10
II.1 CURRENCY SPOT 10
II.2 CURRENCY FORWARD/FUTURE 12
II.3 CURRENCY OPTION 14
III. INTEREST RATE 16
III.1 GOVERNMENT BOND 17
III.2 CORPORATE BOND 19
III.3 BOND FUTURES 20
III.4 SWAP 21
III.5 EMERGING MARKET BOND 22
III.6 OPTION 23
III.6.1 CAP/FLOOR 23
III.6.2 SWAPTION 24
III.6.3 OPTION ON GOVERNMENT BOND 25
III.7 MORTGAGE BACKED SECURITIES 26
IV. EQUITY 28
IV.1 EQUITY BETAS 28
IV.1.1 Beta Source 29
IV.2 CASH PRODUCTS 29
IV.2.1 CASH EQUITY 29
IV.2.2 SWISS CERTIFICATES, ADRs, GDRs 30
IV.2.3 EQUITY INDEX SPOT 32
IV.3 FORWARD/FUTURE 33
IV.3.1 STOCK FORWARD/FUTURE 33
IV.3.2 STOCK INDEX FORWARD/FUTURE 34
IV.4 OPTION 35
Mapping to VaR: from Products to PVT/EQT Page 3
MAPPING Version 1.0 December 15, 1997
IV.4.1 STOCK OPTION 35
IV.4.2 STOCK INDEX OPTION 36
IV.5 CONVERTIBLE 37
V. COMMODITY 38
V.1 PRECIOUS METAL 39
V.1.1 PRECIOUS METAL SPOT 39
V.1.2 PRECIOUS METAL FORWARD / FUTURE 40
V.1.3 PRECIOUS METAL OPTION 42
V.2 BASE METAL AND ENERGY 43
V.2.1 BASE METAL AND ENERGY FORWARD / FUTURE 43
V.2.2 BASE METAL and ENERGY OPTION 46
VI. SIMULATION BASED VALUE-AT-RISK AND NON-LINEAR RISK 47
VI.1 REPORTING P&L MATRICES FOR VALUE-AT-RISK CALCULATION 48
VI.1.1 WHO REPORTS P&L MATRICES ? 48
VI.1.2 AVOIDING DOUBLE COUNTING OF LINEAR POSITIONS 48
VI.1.3 LEVEL OF CALCULATION/ORGANIZATION 48
VI.1.4 THETA (TIME DECAY) 48
VI.1.5 GUIDELINES FOR MARKET SHOCKS (GRID SPACING) 48
VI.1.6 TERM STRUCTURE OF IMPLIED VOLATILITY 48
VI.1.7 SPECIFICATION OF THE LOOKUP TABLE BY PRODUCT GROUP 49
VII. GENERATING THE FEEDER FILE 50
VII.1 USING THE STATIC DATA EXTRACTION UTILITY 50
VII.1.1 POSITION RISK CODES NAMING CONVENTIONS 51
VII.1.2 RISK SENSITIVITY TYPE 53
VII.1.3 CURRENCY OF THE TIME SERIES 53
VII.1.4 MATURITY OF THE POSITION RISK CODE 53
VII.1.5 PRODUCT 54
VII.1.6 CURRENCY TO WHICH THE POSITION RISK CODE PERTAINS 56
VII.1.7 MATURITY IN MONTHS 56
VII.1.8 RATING OF THE CORPORATE ISSUING THE BOND 56
VII.1.9 TIME TO EXPIRATION OF THE OPTION 56
VII.1.10 REFERENCE CURRENCY IN CCY PAIR 56
VIII. GENERAL PRINCIPLES OF THE DATA FEED LOADERS 57
VIII.1 ENFORCING UNIQUENESS OF THE PVT/EQT POSITION 57
IX. SPECIFICATION FOR LOADING DATA INTO THE PVT TABLE 58
IX.1 DETAILED INFORMATION ABOUT THE PVT FILE 58
IX.2 POSITION VALUE CURRENCY CONVENTIONS 59
X. SPECIFICATION FOR LOADING DATA INTO THE EQT TABLE 60
X.1 DUMMY ISIN CODES 61
Mapping to VaR: from Products to PVT/EQT Page 4
MAPPING Version 1.0 December 15, 1997
X.2 DEFAULT ISIN CODES FOR THE LOCATIONS 62
X.3 DETAILED INFORMATION ABOUT THE EQUITY POSITIONS FILE 63
X.4 AGGREGATION OF INPUT RECORDS 63
X.5 EQUITYBETAS AND EQUITY INDICES 63
XI. THE FX RATES FILE 64
XI.1 FILE LAYOUT 64
XI.2 ADDITIONAL SOURCE FOR EXOTIC FX RATES IN ZURICH 64
XI.3 SUMMARY OF THE “UNDERLYING CURRENCY” CONCEPT 64
XII. COLLECTION OF EQUITY BETAS 65
XII.1 DELIVERING EQUITY INFORMATION TO THE VAR SYSTEM 65
XII.2 MAINTAINING THE LIST OF ISINS AND DUMMY CODES 65
XII.3 HOW EQUITY INFORMATION IS DELIVERED 65
XII.4 FILE FORMAT FOR NEW RECORDS OR UPDATES 66
XII.5 FILE NAME SPECIFICATIONS 66
XII.6 BETA SOURCE CODES 67
XII.7 VALIDATION RULES 67
XII.8 BETA UPDATE FREQUENCY 67
XII.9 WHICH COUNTRIES DOES EACH LOCATION HAVE AUTHORITY OVER ? 68
XII.10 VALID COMBINATIONS OF COUNTRY CODE AND EQUITY INDEX 69
XII.11 SETTING THE BETA FEEDIDS AND THE BETA FEEDER CONTACTS 70
XII.12 NEW SET OF DUMMY ISINS USING THE COUNTRY CODE 70
XII.13 EQUITY SECTOR BREAKS 71
XII.14 FILE FORMAT FOR NEW SECTOR BREAK UPDATES 71
XII.15 SECTOR BREAK FILE FORMAT 71
XII.16 VALIDATION RULES FOR THE SECTOR BREAKS 71
XII.17 VALID MSCI EQUITY SECTORS CODES FROM BARRA 72
XIII. BANKING HOLIDAY PROCEDURE 73
XIII.1 INSURING A COMPLETE SET OF TRADING POSITIONS 73
XIII.2 DELIVERING HOLIDAY INFORMATION TO THE VAR SYSTEM 73
Mapping to VaR: from Products to PVT/EQT Page 5
MAPPING Version 1.0 December 15, 1997
XIII.3 EXAMPLE OF GENERATING A HOLIDAYS INPUT FILE USING EXCEL 74
XIV. TESTING A NEW FEED 74
XV. REMOTE BANK DATAFEED 75
XVI. ADJUSTMENT (VAR CONTROLLER) FEED 75
XVII. WHO’S WHO IN VAR 76
XVIII. VAR FEEDS 77
XIX. IT TERMINOLOGY 82
XX. BUSINESS NAMING CONVENTIONS 83
XXI. REFERENCES 90
Mapping to VaR: from Products to PVT/EQT Page 6
MAPPING Version 1.0 December 15, 1997
Modification History
Version 1.0 of the ‘Mapping to VaR’ document includes the non-linear part of the Value-at-Risk System (P&L matrices
delivery) which was introduced with Release 5.0 on November 4, 1997.
I. INTRODUCTION
The VaR calculator needs as input the sensitivity of all positions involving market risks. This sensitivity is expressed
for instance as the value of a basis point for interest rate products or as the number of shares for the equity business. This
manual explains what information is required by VaR (examples of what has to be sent to VaR is given for each product).
The methodology used in VaR involves the daily production of two files containing all market exposures. The first
one, which we call the “Equity positions Table” or “EQT” file will contain the list of all exposures to specific stocks. The
second one, the “Position Values Table” or “PVT” file, will contain all remaining exposures (interest rate, foreign exchange,
equity index, commodity and volatility). The format of these files is described in the chapters VIII and IX of this document.
Starting with Release 5.0, the standard non-linear risk matrices (the so-called P/L matrices) used by the Bank for
reporting options risks must be delivered to the VaR system with a sufficient level of granularity.
The simulation based framework introduced with Release 5.0 covers both the first order delta and vega risks, also referred as
linear risk, as well as the second order non-linear risks due to optionality in the portfolio.
I.1 THE EQUITY POSITIONS FILE (EQT)
This file contains records of all risks resulting from exposures to specific stocks at a level of aggregation determined by the
organization structure. A record in this file corresponds to the end-of-day inventory (number of shares) of a given equity as
indicated by its ISIN code and its ReptID (“Report ID”), which can be a trading portfolio or a desk. ReptIDs map to Business
Units in the Risk Delegation Hierarchy and to the Minor Business Lines. These risks are derived from positions taken in:
stocks
futures on a stock
options/warrants on a stock
convertible bonds
Example of an EQT record:
TradeDate RepID ISINcode FeedID # of shares MktPrice CaptPt Currency
(the full description of these field can be found in chapter IX).
In the case of an option/warrant on a stock, a future on a stock, or a convertible bond, only the delta expressed as an
equivalent number of stocks should be included into the EQT file. The interest rate and volatility sensitivity resulting from
these positions must be included in the PVT file.
I.2 THE POSITION VALUES FILE (PVT) The PVT file holds all interest rate, foreign exchange, equity index, commodity and volatility sensitivity at a level of
aggregation determined by the organization structure and the granularity of the GTRM reporting ladders. In short, this file
contains all risks coming from all exposures except those reported in the EQT file. The current PVT holds only linear
sensitivity.
The positions that have to be included in the PVT file are due to exposure in:
interest rate (bonds, convertible bonds, futures on interest rate, swaps, options on interest rate,...)
foreign exchange
stock index
commodity
implied volatility
The following figure shows the structure of the PVT file:
Non Linear NONLINEAR Special Code for Non-Linear Risk
Mapping to VaR: from Products to PVT/EQT Page 56
MAPPING Version 1.0 December 15, 1997
VII.1.6 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).
For instance, ‘USD/ATS SPOT’ is clearly associated with the Austrian Shilling. 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 (which enables a proper conversion of the
amount by the Loader).
VII.1.7 MATURITY IN MONTHS
Contains the same information as the Maturity field, just expressed in months.
VII.1.8 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.
VII.1.9 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).
VII.1.10 REFERENCE CURRENCY IN CCY PAIR
For cross-currency vega risk: defines the reference currency addressed by the PRC.
Mapping to VaR: from Products to PVT/EQT Page 57
MAPPING Version 1.0 December 15, 1997
VIII. GENERAL PRINCIPLES OF THE DATA FEED LOADERS
The schematic overview of the VaR system suggested that Daily Position Data are fed into the system and processed by
loaders. To facilitate the interfaces, three standard file formats have been specified, namely, one for PVT data, one for EQT
data, and one for Foreign Currency Exchange rates (FX Rates). By having standard file formats, the loaders can enforce
integrity rules on the target tables in the database. The next sections specify the file formats for the three types of daily data.
It is up to the local sites to generate these files and ensure that all required data is present prior to running the calculator.
Utilities, such as fdm, are available to the system manager to check data feeds without having to delve into the database.
To understand the general principles of the loaders, first an overview.
1. PVT, EQT, and FX data are delivered to the VaR system in a designated UNIX account (datafeed) via file transfer (ftp).
2. Each data feed is identified by a FeedID code, which consists of a location code followed by additional alphanumeric
characters. Only one FeedID per data file is allowed. The FeedID also serves to tie delivery of a file to a “person” with
an e-mail address for diagnostic messages.
3. Each data feed file has a “Trade Date” (also known as “Value Date”) in each record. Only data for a single Trade Date
is allowed per file.
4. The Consolidation system accepts only FX feeds. All PVT and EQT data are delivered to the Consolidation system via
replication from the “local” sites.
5. A process on the local VaR system (move_feeds) copies the files from the datafeed account to a secure directory
structure under the feedmstr account. All files with the same FeedID go into a directory with the same name as the
FeedID (these directories are automatically created when the first FeedID is encountered). The suggested file name
convention for the files coming to the datafeed account is:
PVT file: FeedIDYYYYMMDD.pvt
EQT file: FeedIDYYYYMMDD.eqt
FX rate file: FeedIDYYYYMMDD.fx
however, shorter file names due to MS-DOS restrictions are also accepted by the system as long as they are unique and
use the right file extension.
These files are renamed according to a standard naming convention, consisting of a prefix that consists of the FeedID and
a date suffix in the format YYYYMMDD, reflecting the Trade Date (not the delivery date) of the file.
PVT file: FeedID_YYYYMMDD.pvt
EQT file: FeedID_YYYYMMDD.eqt
FX rate file: FeedID_YYYYMMDD.fx
6. Another process (process_feeds) scans the FeedID-specific directory structure for new files and performs input checking
and loading into the database. Successfully loaded files are compressed and archived in the “Used” directory that is
present under each FeedID-specific directory.
7. Only if the entire file is valid are data loaded into the database. The senders of data files are notified of the loading status
via e-mail. E-mail concerning successful loads may be turned off on a system-wide basis, though a log entry is always
made into a file. Errors in the file are reported with as much detail as available to help the senders debug their programs.
8. Prior to a successful load, the loader erases all rows with the same TradeDate and the same FeedID. This mechanism
allows a new file to overwrite a previous file containing incorrect or incomplete values. Because the delete and the insert
operations are replicated to the Consolidation system, the PVT or EQT tables stay automatically in synch.
VIII.1 ENFORCING UNIQUENESS OF THE PVT/EQT POSITION
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).
Mapping to VaR: from Products to PVT/EQT Page 58
MAPPING Version 1.0 December 15, 1997
IX. SPECIFICATION FOR LOADING DATA INTO THE PVT TABLE
The PVT holds all interest rate, foreign exchange, commodity and volatility risk sensitivities at a level of aggregation
determined by the organization structure and by the granularity of the GTRM reporting ladders. The current PVT holds
linear sensitivities, below we will explain this in more detail. First the layout.
Column Sybase DataType Comments
TradeDate SYBDATETIME “time” field currently ignored
ReptID SYBINT4 Organization Structure Identifier
PositionRiskCode SYBINT4 Refers to the position in the market hierarchy
FeedID SYBCHAR 8 <Location><System><suffix>
PositionValue SYBFLT8 Sensitivity
CapturePoint SYBCHAR 2 LO, NY, ZH, SI, TO
In addition to these six fields defined in the PVT table, a seventh field is accepted in the data file by the loader, indicating the
Currency in which the Position Value is expressed.
The loader performs an automatic conversion prior to loading. Once loaded into the PVT, the PositionValue’s currency is
determined by the rule stating that this is the currency of the underlying time series. A unique index for this table is based on
the composite key (TradeDate, ReptID, PositionRiskCode, FeedID). The PVT loader enforces uniqueness of the rows by
aggregating if necessary. All columns must be filled with values, that is, no NULL values are allowed in the table or in the
data files. PVT data are delivered in an ASCII file consisting of tab-delimited values (TDV) for the six fields defined above
in the order given above. Character-valued fields should not be quoted with single (‘) or double (“) quotes. Such quotes are
not necessary, since the tab-character cannot legally occur in any of these fields.
IX.1 DETAILED INFORMATION ABOUT THE PVT FILE 1. TradeDate refers to the Business Date to which the Position Value refers (“Value Date”), not the date of data delivery.
The date should be in a format acceptable to Sybase for conversion from character into the internal type “datetime”. See
the section on “Datatypes” in the “Sybase SQLserver Commands Reference Manual” for valid Sybase date formats.
Examples include:
“Mon dd yyyy”
“mm/dd/yyyy”
“mm.dd.yyyy”
“dd-mon-yyyy”.
With the year 2000 being less than five years away, the two century digits are very strongly recommended. The Trade
Date is stored in Sybase as a date/time field, with the time not currently filled in. This allows intra-day positions to be
added in the future.
2. ReptID is a numeric code to tie a position into the organization 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 the same Business Unit, or whether the same ReptID is used for these trading books.
3. PositionRiskCodes constitute the lowest level of the market structure hierarchy. The actual Position Codes are
maintained as part of the Market Structure by the “Clearing House”. For instance, Position Codes map to “Commodity
Codes”, and so on. Position Risk Codes map also (many-to-one) to time series, which determine correlations and
volatilities. If “Currency” is an appropriate dimension for a given Time Series, that currency is recorded in the table that
is part of the market structure.
4. FeedID is an identifier with a minimum length of four and a maximum length of eight, assigned to data sources. The
FeedID codes are structured so that they are globally unique as long as the third to the last character are locally unique.
The first two characters specify the location (LO, ZH, NY, TO, SI), the next two specify the type of system (for example,
“BN” for a bond-related system), and the final four optional characters specify more detail about the data feed. The
FeedID column serves to identify the source system generating the Position Value.
5. PositionValue is the actual sensitivity, which can be an interest rate delta, a net delta position in either a currency, a
commodity, or a stock index future. The PVT entry can also be a vega.
Mapping to VaR: from Products to PVT/EQT Page 59
MAPPING Version 1.0 December 15, 1997
6. CapturePoint must be equal to the first two characters of the FeedID column, indicating the originating location of the
data feed, such as LO, TO, SI, NY, FM, GE, HK, LU, PS, SY, TP, TN, or ZH. Capture Point determines the Base
Currency of the location originating the position (used in the generation of synthetic Base Currency positions
offsetting the FX exposures). 7. (Optional/Mandatory) Currency in which the Position Value (sensitivity) is expressed. Must be a valid (ISO) currency
code. The reason for requiring a source currency field is that due to lack of a better time series for these classes of
positions the “underlying” currency of the time series is not the currency expected for the position code, but the currency
of the time series into which these position codes were mapped.
An example of a PVT file: the symbol indicates the TAB character.
3/31/1995100102270ZHBN01-37853.7ZH
IX.2 POSITION VALUE CURRENCY CONVENTIONS A Position Value must be expressed in the currency of the underlying time series. The “underlying” time series is the time
series to which the Position Code is mapped via the mapping table “Mkt_TimeSeries_PosRisk “. As the currency conversion
may impose extra work on the local data feed providers, an extra field may be used on the input record, containing the
currency that the PVT record is expressed in. If the PVT loader detects a discrepancy between the supplied currency and the
currency of the underlying time series, a conversion at the day’s spot rate is automatically performed.
In order to more effectively accommodate a multi-currency application in which positions are aggregated globally into CHF,
the following guidelines must be followed.
1. Interest rate deltas are to be expressed in their original currency, not the location’s local currency. Thus, a DEM bond
traded in LO will have a delta entered into the PVT as DEM, and the same bond traded in TO will also have a delta in
DEM.
2. The interest rate Vegas for the same instrument must follow the same currency convention.
3. All commodity Vegas are to be expressed in USD since the price of most commodities is given in USD.
4. Although equity positions are contained in the Equities table, their Vegas will be contained in the PVT. Equity Vegas
are to be quoted in the currency of the underlying index; thus the vega of a UK stock linked to the FTSE250 will be
quoted in GBP, and that of a Japanese stock will be quoted in JPY.
5. Also contained in the PVT are delta equivalents of equity index futures and options. Because the corresponding time
series consists of the underlying equity index, it is easiest to put these positions directly into the PVT, mapping to a
position code corresponding to this index.
6. For FX businesses, each location needs to produce a “synthetic net position in its local currency”.
The procedure that runs the position Loader in the daily production mode automatically generates
such synthetic FX positions without requiring any effort from the local datafeed operations.
Mapping to VaR: from Products to PVT/EQT Page 60
MAPPING Version 1.0 December 15, 1997
X. SPECIFICATION FOR LOADING DATA INTO THE EQT TABLE
The EquityPositions (EQT) table is designed to store equity positions and delta-equivalents for options, convertibles, etc., on
a day-to-day basis. A row in this table corresponds to the end-of-day inventory (number of shares) for a given equity, as
indicated by its ISIN code, by ReptID, which can be a trading account or a desk. The following figure shows this table’s
structure.
Column DataType Comments
TradeDate SYBDATETIME “time” field currently ignored
ReptID SYBINT4 Organization Structure Identifier
ISINcode SYBCHAR(12) Universal Equity Code
FeedID SYBCHAR(8) <Location><System><Suffix>
NumberofShares SYBFLT8 Fractional value if delta-equivalent
MarkPrice SYBFLT8
CapturePoint SYBCHAR(2) LO, NY, ZH, SI, TO,...
In addition to these seven fields defined in the EquityPositions table, an eighth field is accepted in the data file by the loader,
indicating the Currency in which the Mark Price is expressed. The loader performs an automatic conversion prior to
loading. Once loaded into the EQT, the Mark Price’s currency is determined by the rule stating that this is the currency of the
underlying equity index.
A unique index for this table is based on the composite key (TradeDate, ReptID, ISINcode, FeedID). In the table itself, all
fields are populated, that is, no null values are allowed
Mapping to VaR: from Products to PVT/EQT Page 61
MAPPING Version 1.0 December 15, 1997
X.1 DUMMY ISIN CODES In the data delivered to the EQT interface, a “NULL” (empty) ISIN code is allowed, causing the loader to use a location-
specific “dummy” ISIN Code. This behavior may not always be desirable. For instance, when Paris sends an EQT file to
London for loading, a “NULL” ISIN Code field causes the London default ISIN code to be used! Thus, every effort should
be made to find the correct ISIN code, and if one cannot be found, the datafeed generating program should impute a well-
defined dummy code from the list below (up to 70 codes allocated to an index).
CountryName Country
Code
Equity Index Description PRC Start Dummy ISIN End Dummy ISIN Argentina AR ARS GENL EQT 4765 ARDI00000001 ARDI00000070 Australia AU AUD ALL ORD 3673 AUDI00000001 AUDI00000010 Austria AT ATS TRADED 4766 ATDI00000001 ATDI00000070 Bangladesh BD BANGLADESH 4778 BDDI00000001 BDDI00000070 Belgium BE BEF BEL-20 3676 BEDI00000001 BEDI00000010 Brazil BR BRZL BOVESPA 4767 BRDI00000001 BRDI00000070 Canada CA CAD TSE INDX 3677 CADI00000001 CADI00000010 Chile CL CHILE GENL 4768 CLDI00000001 CLDI00000070 China CN CHINA 4780 CNDI00000001 CNDI00000070 Croatia HR HRK CROATIA 7457 HRDI00000001 HRDI00000010 Czech Republic CZ CZECH PX50 4769 CZDI00000001 CZDI00000070 Denmark DK DNMRK KFX20 3679 DKDI00000001 DKDI00000010 Egypt EG EGP EGYPT 7462 EGDI00000001 EGDI00000010 Finland FI FIM FOX25 3680 FIDI000000001 FIDI000000010 France FR FRF CAC40 2277 FRDI00000001 FRDI00000010 Germany DE DEM DAX EQTY 2275 DEDI00000001 DEDI00000010 Greece GR GREECE ASE 4770 GRDI00000001 GRDI00000070 Hong Kong HK HKD HANG SNG 3681 HKDI00000001 HKDI00000070 Hungary HU HUF HUNGARY 7460 HUDI00000001 HUDI00000010 India IN INR BOMBAY 4771 INDI00000001 INDI00000070 Indonesia ID IDR JAKARTA 4779 IDDI00000001 IDDI00000070 Ireland IE IEP IRELAND 7507 IEDI00000001 IEDI00000010 Israel IL ISRL MAOF25 4772 ILDI00000001 ILDI00000070 Italy IT ITL MIB 30 3682 ITDI00000001 ITDI00000010 Japan JP JPY TOPIX 4023 JPTO00000001 JPTO00000070 Japan JP NIKKEI 225 2271 JPNI00000001 JPNI00000001 Jordan JO JOD JORDAN 7458 JODI00000001 JODI00000010 Korea, Republic of KR S KOREA COMP 4773 KRDI00000001 KRDI00000070 Lebanon LB LBP LEBANON 7464 LBDI00000001 LBDI00000010 Malaysia MY MLYSIA INDX 3683 MYDI00000001 MYDI00000070 Mexico MX MEXICO BOLSA 3684 MXDI00000001 MXDI00000070 Morocco MA MAD MOROCCO 7463 MADI00000001 MADI00000010 Netherlands NL NLG AEX 25 3685 NLDI00000001 NLDI00000010 New Zealand NZ NZD SE 40 4774 NZDI00000001 NZDI00000070 Norway NO NOK OSLO OBX 3686 NODI00000001 NODI00000010 Pakistan PK PAKISTAN 4781 PKDI00000001 PKDI00000070 Peru PE PERUVIAN SOL 6933 PEDI00000001 PEDI00000010 Philippines PH PHILIPPINES 4782 PHDI00000001 PHDI00000070 Poland PL PLZ POLAND 7461 PLDI00000001 PLDI00000010 Portugal PT PORTUGAL 4783 PTDI00000001 PTDI00000070 Singapore SG SGD STRAITS 3689 SGDI00000001 SGDI00000070 Slovenia SI SIT SOLVENIA 7459 SIDI00000001 SIDI00000010 South Africa ZA S AFR ALLMKT 4775 ZADI00000001 ZADI00000070 Spain ES ESP IBEX35 3687 ESDI00000001 ESDI00000010 Sweden SE SWEDEN OMX 3688 SEDI00000001 SEDI00000010 Switzerland CH CHF CS GENL 2276 CHCS00000001 CHCS00000001 Switzerland CH CHF SMI 3678 CHSM00000001 CHSM00000010 Taiwan, Republic of China TW TWD WEIGHTED 3690 TWDI00000001 TWDI00000070 Thailand TH THB BKOK SET 3691 THDI00000001 THDI00000070 Turkey TR TURKEY COMP 4776 TRDI00000001 TRDI00000070 United Kingdom GB GBP ALL SHR 3675 GBAL00000001 GBAL00000070 United Kingdom GB GBP FTSE100 2273 GBF100000001 GBF100000010 United Kingdom GB GBP FTSE250 3674 GBF200000001 GBF200000010 United States US USD S&P 500 2269 USDI00000001 USDI00000060 XEU DE XEU 7508 XEDI00000001 XEDI00000010
The betas for such “default” ISIN codes are generally agreed to be equal to one. The total risk for the equity in such cases
was agreed upon to be 5/3 times the volatility of the index. Since that index’s volatility varies from one MatrixID to the next,
the total risk for such codes cannot be stored and is instead obtained by the calculator from the “StandardDeviations” table at
run-time.
Mapping to VaR: from Products to PVT/EQT Page 62
MAPPING Version 1.0 December 15, 1997
X.2 DEFAULT ISIN CODES FOR THE LOCATIONS
The default ISIN codes are defined in the Locations table as part of the static data maintained by GTCO. They are allocated
by the system in the case of a missing ISIN in the EQT feed according to the list below:
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
CT S B. Cantrade Secondary ZH CHF 130,001 135,000 CHSM00000001
BL S B. di Lugano Secondary ZH CHF 135,001 140,000 CHSM00000001
HY 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 CHF 240,001 250,000 n/a
Mapping to VaR: from Products to PVT/EQT Page 63
MAPPING Version 1.0 December 15, 1997
X.3 DETAILED INFORMATION ABOUT THE EQUITY POSITIONS FILE The data feeder systems supplying equities information are doing so by delivering an ASCII file at the “EQT-interface”. This
file consists of a set of tab-delimited values (TDV) for these seven (or eight) fields in the order given above (EQT table
spec).
TradeDate refers to the business date on which this position is held, not the capture date. For this date, any date in a
format acceptable to Sybase may be presented at the EQT interface (See the PVT specification above).
ReptID is a location-specific numeric code to tie a position into the organization structure.
ISINcode is a globally acceptable way to identify an equity. Since ISIN Codes are not universally used, those producing
an EQT file from “local” equity books may require a mapping from the local code (e.g., CUSIP in the U.S.) to ISIN
code. Equity specialists within GTCO can assist in obtaining files to map “local” Equity codes to ISIN codes. Special
“dummy” ISIN Codes (see previous list) must be used to capture the beta and total risk for equities with unknown ISIN
codes. These ISIN Codes map to a table with Betas and Total Risk values for a large number of securities
FeedID is an eight-character code, consisting of the two-character location code (LO, ZH, NY, SI, TO), a two-character
feeder system identifier (for example, “OP” for OPTAS, “QV” for QV in NY), and the remaining four characters
available to subclassify a source within the feeder system. FeedID values can be locally assigned, because the first two
characters make the code globally unique. Each file delivered to the EQT interface should have the same value for
FeedID.
NumberofShares (the number of shares held of that security) has a double precision data type, because some systems,
such as equity Options, provide a “delta-equivalent” which is a fractional value.
MarkPrice is the current price of the equity security as of the Trade Date. The calculator itself is only concerned with
the Market Value = (NumberofShares * MarkPrice). The MarkPrice must be in the currency of the equity index time
series. Thus, UK stocks will have a MarkPrice in GBP, German stocks will have a MarkPrice in DEM, and so on.
CapturePoint plays a role in identifying the equity data from each location in the global system. The value generally
corresponds to the first two characters of FeedID (see the Note about “CapturePoint” in the PVT section)
(Optional/Mandatory) Currency. The MarkPrice of each EQT record is assumed to be expressed in the currency of the
underlying time series. Thus, German stocks are quoted in DEM, UK stocks in GBP, and so on. To find out what that
currency is, the ISIN code of a record in an EQT file is used to search the EquityBetas table for the corresponding
EquityIndex. That index, which is a Position Risk Code, maps to a Time Series, characterized by a currency code.
If a currency code is specified in the EQT file, the loader performs an automatic currency conversion from the user-
specified currency to the “underlying” currency.
The following positions, for instance, require a Source Currency field to be specified as the (last) field in a PVT record:
all volatility risk
the following interest rate deltas: AED, CZK, KRW, TWD, CYP, THB
in general, equities from emerging markets
The reason for requiring a source currency field is that due to lack of a better time series for these classes of positions the
“underlying” currency of the time series is not the currency expected for the position code, but the currency of the time
series into which these position codes were mapped.
X.4 AGGREGATION OF INPUT RECORDS In the process of maintaining the Equity Positions table, the EQT loader may have to perform aggregation. Aggregation is
performed to make each row for a given TradeDate and FeedID unique with respect to ReptID and ISINcode. Thus, even if
the same ReptID is used to classify a number of different records, they’ll end up as one aggregated EquityPositions record.
Aggregation is such that aggregate Market Value is preserved. Two positions, one 20 long and one 5 short (with the same
MarkPrice) are aggregated (netted) into one record with NumberofShares equal to 15. In the unlikely event (unlikely for cash
equity positions) that the MarkPrice differs for the same ISIN code and the same ReptID, the weighted average mark price
will be used, preserving the aggregate market value. If netting is for some reason not desirable, the local Interface Systems
should ensure uniqueness by choosing key combinations that make the rows unique, for instance, by using more detailed
ReptID codes, or do their own netting.
X.5 EQUITYBETAS AND EQUITY INDICES The Value at Risk Calculator uses the Capital Assets Pricing Model (CAPM) to assess the risk associated with equities
portfolios, using i for the ith
stock, and its associated specific risk,
i
2. The “EquityBetas” table stores the betas and total
risk numbers for a large number of equities (see also Chapter XI: Collection of Equity Betas).
Mapping to VaR: from Products to PVT/EQT Page 64
MAPPING Version 1.0 December 15, 1997
XI. THE FX RATES FILE
In order to accommodate multi-currency reporting in the VaR application, individual exposures in the Equities (EQT) and
Position Values (PVT) data files must be reported in (or converted into) the “underlying” currency. If instructed to do so by
adding an optional “currency” field to the PVT or EQT records, the respective loaders perform the conversions automatically.
The VaR calculator converts these exposures to USD, computes value at risk, and then translates the result to the user’s
choice of currency. Because of this design, each VaR site needs to maintain its own set of foreign currency exchange rates.
XI.1 FILE LAYOUT The Currency Exchange Rate Loader expects the following fields:
TradeDate Date to which this exchange rate applies
Currency Three-letter ISO code for foreign currency (See list below)
SpotRate The exchange rate in amount of foreign currency per US dollar (USD)
Please note the following rules.
The file format is ASCII text with Comma-Separated Values. Please refer to the PVT or EQT specification for valid
formats of “TradeDate”.
The FX file must be loaded into the local systems and the Consolidation system. This is the only file type that the loader
will process at the the Consolidation system site.
The file must be delivered to the same UNIX account on the local VaR system as is used for delivery of PVT and EQT
files (datafeed). The file name must end with “.fx”. The recommended syntax of the file name is
fxspotCCYYMMDD.fx (for example, fxspot19950501.fx).
Each business day, the PVT/EQT Loader and the Calculator expect a table to be present with spot exchange rates for the
following currencies:
Currencies in which Time Series, and, consequently, Volatilities are expressed
Currencies occurring in the optional extra column in files processed by the EQT/PVT loaders
A sample record of an FX file is shown next. Suppose the rate for the French Franc is 5.23 FFR per USD on May 1, 1995.
1-May-1995,FFR,5.23
XI.2 ADDITIONAL SOURCE FOR EXOTIC FX RATES IN ZURICH FX rates for exotic currencies which are not defined in the Core system (and therefore not delivered with the FXRT feed) are
downloaded from the Bloomberg PC at GTCO onto an Excel spreadsheet (NOSYRATE.XLS) and exported in a tab-delimited
text file (NOSYRATE.TXT) to the ZHGTCO3 server. A special script located in the feedmaster home directory
(get_nosyrate.sh) fetches the file from the Novell server using the vmatdist account, whilst another procedure (clubmed.sh)
inserts the rates directly into the FXSpotRates table (these steps are logged in a file called nosyrate.log).
O p en B lo o m b erg
rea l tim e fe e d
Z H G T C O 3
N o v e l l S e rv e r
N O S Y R A T E .X L S
spre a dsh ee t
N O S Y R A T E .T X T
res id e n t in
Z H G T C O 3 /S Y 2 :G R O U P S :V A R D O C /F E E D S
V a R S y s t e m
F ile is re tr ie ve d e ve ry
m o rn ing a t 6 :5 0 a .m .
b y ftp from :
zh g tco 3 .b a h nh o f.u bs .ch
XI.3 SUMMARY OF THE “UNDERLYING CURRENCY” CONCEPT Recall from the PVT and EQT specifications that the PositionValue in PVT files must be specified in the currency of the
underlying time series and that the MarkPrice (EQT) must be expressed in the currency of the underlying Equity Index. The
target currency in the case of the PVT entry is found by mapping the position code to the corresponding time series. For
equities, the ISIN code corresponding to the entry is mapped to the EquityBetas table, and the latter table’s EquityIndex
(which is really a type of Position Code) is mapped to the Time Series table via the PositionCode-to-TimeSeries table. In
In practice, one would use the PC Calculator, to display the currency of the PRCe via the Times Series it is mapped to.
Mapping to VaR: from Products to PVT/EQT Page 65
MAPPING Version 1.0 December 15, 1997
XII. COLLECTION OF EQUITY BETAS
XII.1 DELIVERING EQUITY INFORMATION TO THE VAR SYSTEM Equity controllers have often expressed the need to enter equity information quickly for new stocks. Starting with VaR
Release 3.0, 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).
XII.2 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.
XII.3 HOW EQUITY INFORMATION IS DELIVERED The following diagram shows how equity information is maintained.
C o n s o l id a tio n
s y s te m V a R
d a ta b a s e
V a l id a tio n
a n d lo a d in g
S ta n d a rd " e q tin fo " fi le lo c a l V a R
s y s te m
re p lic a t io n
lo c a l V a R
s y s te mre p lic a t io n
U p d a te s ?
Y e s
N o
S a v e u p d a te s in
h o ld in g a re a fo r fu tu re
e x e c u tio n
.
.
.
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.
Mapping to VaR: from Products to PVT/EQT Page 66
MAPPING Version 1.0 December 15, 1997
XII.4 FILE FORMAT FOR NEW RECORDS OR UPDATES The eqtinfo file format is backward-compatible with the previously used "EquityBetas File Specification". An alternate
format is now used for consistency with other VaR loaders. It differs as follows:
Tab-delimited values format is now supported in addition to the previously used comma-separated values format
The header is optional. Absence of the header implies the tab-delimited values format.
Files written in the old format (comma separated with a title) must be converted through the ‘cvt_eqtinfo.sh’ filter on the
Consolidation System (in the betafeed account; syntax: cvt_eqtinfo.sh <old_file> <new_file>).
The following fields are included in the eqtinfo file. For each of the six fields, the table below shows the data type and
validation rules. Each record must contain six fields, though an empty (NULL) field is allowed for the TotalRisk column.
Column DataType Rules
ISINcode 12 characters Exactly twelve alpha-numeric characters, starting with two letters. The first two letters
must be a valid Country Code. ISIN codes are unique.
Beta Floating point number Cannot be zero or NULL. Initially, the range is -3 to +3. Valid range may be modified by
changing a parameter..
EquityIndex Integer PositionRiskCode (PRC) of the equity index. Must be a PRC with RiskSensType equal to
"PRINCPL", and mapping to a Time Series with FinancialElementCode equal to
"EQTSPT"
TotalRisk double precision floating point
number
Expressed as a percentage. May be NULL, in which case it is assumed to be equal to 5/3
times the volatility of the Equity Index. The range is 5 to 100. Valid range may be
modified by changing a parameter
SecurityName 50 characters Description (any text, but no tab character). If the old comma-delimited file format is
used and the description contains a comma, the text must be enclosed in double quotes (").
BetaSource 3 characters To indicate the provider of equity information. Each location may have one or more
BetaSource codes. The codes, which are globally unique, are allocated by GTCO. The
BetaSource code must be unique within each file.
XII.5 FILE NAME SPECIFICATIONS All eqtinfo files, copied by the local sites to the HOME directory of the betafeed account, must use the following file name
syntax:
LLYYYYMMDD.bet
where:
LL is the location code
YYYY the year
MM the month
DD the day
and for deletions:
This file lists simply the ISIN codes of the stocks for which information should be retired. The BetaSource column serves to
identify the origin of the request. Both fields are required.
Column Data Type Rules
ISINcode 12 characters Must be in the database.
BetaSource 3 characters Location Code (see table)
The equityinfo deletion file has the following file name syntax:
LLYYYYMMDD.del
Mapping to VaR: from Products to PVT/EQT Page 67
MAPPING Version 1.0 December 15, 1997
XII.6 BETA SOURCE 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 NY NY
BAL Barra LO LO
BAS Singapore SI
BAT Tokyo TO
ZHO Zurich ZH
UBS GTCO (dummy ISIN codes) GZ
XII.7 VALIDATION RULES
The Location code imbedded 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’ imbedded in the file name is
the same as the Location code implied by 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.
XII.8 BETA UPDATE FREQUENCY
Recall that the Betas provided by the Barra system are the predicted systematic risk coefficients for a time horizon of 3
months.
Therefore, it is a requirement from GTCO in Zurich to get these figures updated once a month in the VaR Consolidation
System (send the new Betas before the last Friday of the month, in order to get them processed over the weekend).
Mapping to VaR: from Products to PVT/EQT Page 68
MAPPING Version 1.0 December 15, 1997
XII.9 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.
Location Country Code Country Name
LO AR Argentina
LO AT Austria
LO AU Australia
LO BD Bangladesh
LO BE Belgium
LO BR Brazil
LO CL Chile
LO CN China
LO CZ Czech Republic
LO DE Germany
LO DK Denmark
LO EG Egypt
LO ES Spain
LO FI Finland
LO FR France
LO GB United Kingdom
LO GR Greece
LO HR Croatia
LO HU Hungary
LO IE Irland
LO IL Israel
LO IN India
LO IT Italy
LO JO Jordan
LO LB Lebanon
LO MA Morocco
LO MX Mexico
LO MY Malaysia
LO NL Netherlands
LO NO Norway
LO NZ New Zealand
LO PE Peru
LO PK Pakistan
LO PL Poland
LO PT Portugal
LO SE Sweden
LO SI Slovenia
LO TR Turkey
LO ZA South Africa
NY CA Canada
NY US United States
SI HK Hong Kong
SI ID Indonesia
SI KR Korea, Republic of
SI PH Philippines
SI SG Singapore
SI TH Thailand
SI TW Taiwan, Republic of China
TO JP Japan
ZH CH Switzerland
Mapping to VaR: from Products to PVT/EQT Page 69
MAPPING Version 1.0 December 15, 1997
XII.10 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).
ARS GENL EQT 4765 AR Argentina ATS TRADED 4766 AT Austria AUD ALL ORD 3673 AU Australia BANGLADESH 4778 BD Bengladesh BEF BEL-20 3676 BE Belgium BEF BEL-20 3676 LU Luxembourg BRZL BOVESPA 4767 BR Brazil CAD TSE INDX 3677 CA Canada CHF CS GENL 2276 CH Switzerland CHF SMI 3678 XS International Equity Funds CHF SMI 3678 LU Luxembourg CHF SMI 3678 CH Switzerland CHILE GENL 4768 CL Chile CHINA 4780 CN China CZECH PX50 4769 CZ Czech Republic CZECH PX50 4769 PL Poland DEM DAX EQTY 2275 DE Germany DNMRK KFX20 3679 DK Denmark EGP EGYPT 7462 EG Egypt EGP EGYPT 7462 US United States ESP IBEX35 3687 ES Spain FIM FOX25 3680 FI Finland FRF CAC40 2277 FR France GBP ALL SHR 3675 IE Ireland GBP ALL SHR 3675 JE Jersey
GBP ALL SHR 3675 GB United Kingdom GBP FTSE100 2273 GB United Kingdom GBP FTSE250 3674 GB United Kingdom GREECE ASE 4770 GR Greece HKD HANG SNG 3681 HK Hong Kong HRK CROATIA 7457 HR Croatia HUF HUNGARY 7460 HU Hungary HUF HUNGARY 7460 RU Russia IDR JAKARTA 4779 ID Indonesia IEP IRELAND 7507 IE Ireland INR BOMBAY 4771 IN India ISRL MAOF25 4772 IL Israel ITL MIB 30 3682 IT Italy JOD JORDAN 7458 JO Jordan JPY TOPIX 4023 JP Japan LBP LEBANON 7464 LB Lebanon MAD MOROCCO 7463 MA Morocco MEXICO BOLSA 3684 BZ Belize MEXICO BOLSA 3684 MX Mexico MLYSIA INDX 3683 MY Malaysia NIKKEI 225 2271 JP Japan NLG AEX 25 3685 NL Netherlands NLG AEX 25 3685 AN Netherlands Antilles NOK OSLO OBX 3686 NO Norway NZD SE 40 4774 NZ New Zealand PAKISTAN 4781 PK Pakistan PERUVIAN SOL 6933 PE Peru PHILIPPINES 4782 PH Philippines PLZ POLAND 7461 PL Poland PORTUGAL 4783 PT Portugal S AFR ALLMKT 4775 GA Gabon S AFR ALLMKT 4775 ZA South Africa S AFR ALLMKT 4775 ZM South Africa S AFR ALLMKT 4775 ZW South Africa S KOREA COMP 4773 KR Korea, Republic of SGD STRAITS 3689 SG Singapore SIT SLOVENIA 7459 SI Slovenia SWEDEN OMX 3688 SE Sweden THB BKOK SET 3691 TH Thailand TURKEY COMP 4776 TR Turkey TWD WEIGHTED 3690 TW Taiwan USD S&P 500 2269 BM Bermuda USD S&P 501 2269 BS Bahamas USD S&P 502 2269 US United States XEU CASH 7508 DE Germany
Mapping to VaR: from Products to PVT/EQT Page 70
MAPPING Version 1.0 December 15, 1997
XII.11 SETTING THE BETA FEEDIDS AND THE BETA FEEDER CONTACTS E-Mail notification is provided to the Beta Contact for a particular BetaSource, defined as a feed in the VaRFeeds table (like
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 Adress) must be
entered in the ‘Employee’ table by the Security Admin.
XII.12 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 missing ISINs) will be updated.
CountryName Country Code Equity Index Description PRC Start Dummy ISIN End Dummy ISIN
Argentina AR ARS GENL EQT 4765 ARDI00000001 ARDI00000070 Australia AU AUD ALL ORD 3673 AUDI00000001 AUDI00000010 Austria AT ATS TRADED 4766 ATDI00000001 ATDI00000070 Bangladesh BD BANGLADESH 4778 BDDI00000001 BDDI00000070 Belgium BE BEF BEL-20 3676 BEDI00000001 BEDI00000010 Brazil BR BRZL BOVESPA 4767 BRDI00000001 BRDI00000070 Canada CA CAD TSE INDX 3677 CADI00000001 CADI00000010 Chile CL CHILE GENL 4768 CLDI00000001 CLDI00000070 China CN CHINA 4780 CNDI00000001 CNDI00000070 Czech Republic CZ CZECH PX50 4769 CZDI00000001 CZDI00000070 Denmark DK DNMRK KFX20 3679 DKDI00000001 DKDI00000010 Finland FI FIM FOX25 3680 FIDI000000001 FIDI000000010 France FR FRF CAC40 2277 FRDI00000001 FRDI00000010 Germany DE DEM DAX EQTY 2275 DEDI00000001 DEDI00000010 Greece GR GREECE ASE 4770 GRDI00000001 GRDI00000070 Hong Kong HK HKD HANG SNG 3681 HKDI00000001 HKDI00000070 India IN INR BOMBAY 4771 INDI00000001 INDI00000070 Indonesia ID IDR JAKARTA 4779 IDDI00000001 IDDI00000070 Israel IL ISRL MAOF25 4772 ILDI00000001 ILDI00000070 Italy IT ITL MIB 30 3682 ITDI00000001 ITDI00000010 Japan JP JPY TOPIX 4023 JPTO00000001 JPTO00000070 Japan JP NIKKEI 225 2271 JPNI00000001 JPNI00000001 Korea, Republic of KR S KOREA COMP 4773 KRDI00000001 KRDI00000070 Malaysia MY MLYSIA INDX 3683 MYDI00000001 MYDI00000070 Mexico MX MEXICO BOLSA 3684 MXDI00000001 MXDI00000070 Netherlands NL NLG AEX 25 3685 NLDI00000001 NLDI00000010 New Zealand NZ NZD SE 40 4774 NZDI00000001 NZDI00000070 Norway NO NOK OSLO OBX 3686 NODI00000001 NODI00000010 Pakistan PK PAKISTAN 4781 PKDI00000001 PKDI00000070 Philippines PH PHILIPPINES 4782 PHDI00000001 PHDI00000070 Portugal PT PORTUGAL 4783 PTDI00000001 PTDI00000070 Singapore SG SGD STRAITS 3689 SGDI00000001 SGDI00000070 South Africa ZA S AFR ALLMKT 4775 ZADI00000001 ZADI00000070 Spain ES ESP IBEX35 3687 ESDI00000001 ESDI00000010 Sweden SE SWEDEN OMX 3688 SEDI00000001 SEDI00000010 Switzerland CH CHF CS GENL 2276 CHCS00000001 CHCS00000001 Switzerland CH CHF SMI 3678 CHSM00000001 CHSM00000010 Taiwan, Republic of China TW TWD WEIGHTED 3690 TWDI00000001 TWDI00000070 Thailand TH THB BKOK SET 3691 THDI00000001 THDI00000070 Turkey TR TURKEY COMP 4776 TRDI00000001 TRDI00000070 United Kingdom GB GBP ALL SHR 3675 GBAL00000001 GBAL00000070 United Kingdom GB GBP FTSE100 2273 GBF100000001 GBF100000010 United Kingdom GB GBP FTSE250 3674 GBF200000001 GBF200000010 United States US USD S&P 500 2269 USDI00000001 USDI00000060
Note:
The betas for such “default” ISIN codes are generally agreed to be equal to one. The total risk for the equity in such cases
was agreed upon to be 5/3 times the volatility of the index.
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.
Mapping to VaR: from Products to PVT/EQT Page 71
MAPPING Version 1.0 December 15, 1997
XII.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 in VaR Release 4.0. These tables are maintained at the Consolidation Site and replicated to Local Sites (as with all
market tables). Initially, the table mapping equities to sectors will be populated with the full set of ISINcodes as found in the
EquityBetas table, with a special SectorCode indicating “Unassigned” sector. Assignment to true sectors will be performed
by the Equity Sector Loader. Addition or deletion of EquityBetas records by the existing equity info loaders will
correspondingly insert or delete records into the ISIN_Sector_Map table.
XII.14 FILE FORMAT FOR NEW SECTOR BREAK UPDATES A file format consisting of tab-delimited values (no header) is defined. This format is consistent with that of other VaR
loaders. The ISIN_Sector_Map table will be initialized with a full set of ISIN codes found in the EquityBetas table with a
special “unassigned” sector code. Because all of the ISIN codes will already be in the EquityBetas table, Sector Break files
will only consist of updates.
The following fields must be included in the sector break file. For each of the three fields, the table below shows the data
type and validation rules. Each record must contain three fields.
Column Data Type Rules
ISINcode char(12) Exactly twelve alpha-numeric characters, starting with two letters. The first two letters must be
a valid Country Code in LocationCountryAuth table..
SectorCode int The field will be validated for existence in the EquitySectors table.
BetaSource char(3) To indicate the provider of equity information
XII.15 SECTOR BREAK FILE FORMAT All sector break files, copied by the local sites to the HOME directory of the betafeed account, must use the following file
name syntax:
LLYYYYMMDD.sec
where
LL is the location code
YYYY the year
MM the month
DD the day
XII.16 VALIDATION RULES FOR THE SECTOR BREAKS The rules for Beta deliveries apply also for the equity Sector Breaks, in particular:
The Location code imbedded 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.
Mapping to VaR: from Products to PVT/EQT Page 72
MAPPING Version 1.0 December 15, 1997
XII.17 VALID MSCI EQUITY SECTORS CODES FROM BARRA The EquitySectors table provided by VaR Release 4.0 is as follows:
SectorCode SectorName
0 Unassigned
1 Energy Sources
2 Utilities - Electric & Gas
3 Building Materials & Component
4 Chemicals
5 Forestry & Paper Products
6 Metals - Nonferrous
7 Metals - Steel
8 Misc. Materials & Commodities
9 Aerospace & Military Technology
10 Construction & Housing
11 Data Processing & Reproduction
12 Electrical & Electronics
13 Electronic Components & Instruments
14 Energy Equipment & Services
15 Industrial Components
16 Machinery & Engineering
17 Appliances & Household Durable
18 Automobiles
19 Beverages & Tobacco
20 Food & Household Products
21 Health & Personal Care
22 Recreation & Other Consumer Goods
23 Textiles & Apparel
24 Broadcasting & Publishing
25 Business & Public Services
26 Leisure & Tourism
27 Merchandising
28 Telecommunications
29 Transportation-Airlines
30 Transportation-Road & Rail
31 Transportation-Shipping
32 Wholesale & International Trading
33 Banking
34 Financial Services
35 Insurance
36 Real Estate
37 Multi-Industry
38 Gold Mines
Mapping to VaR: from Products to PVT/EQT Page 73
MAPPING Version 1.0 December 15, 1997
XIII. BANKING HOLIDAY PROCEDURE
XIII.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
XIII.2 DELIVERING HOLIDAY INFORMATION TO THE VAR SYSTEM Information about holidays is kept locally on each VaR system (no central repository with data replication mechanism). It is
therefore the duty of the local Org./Mapping Manager to provide one year at a time the list of holidays applying to his
Locations in a tab-delimited text file. This file must be loaded into the Local VaR System by the System Operator (the
Holiday Table is not replicated to the other VaR sites). The format of the holiday file is as follows:
1. HolidayDate in one of the following formats:
Mon dd yyyy
mm/dd/yyyy
mm.dd.yyyy
dd-mon-yyyy
2. LocationCode indicating the UBS location to which the HolidayDate pertains.
3. FX flag (which may be NULL) indicating whether FX spot rates should be duplicated or not. If the FX flag field should
be NULL, an empty field must be provided in the input file.
A sample text file might appear as follows (where indicates a TAB):
Apr 5 1996 NY FX
Apr 5 1996 TN
Jul 1 1996 TN
Jul 4 1996 NY FX
Mapping to VaR: from Products to PVT/EQT Page 74
MAPPING Version 1.0 December 15, 1997
XIII.3 EXAMPLE OF GENERATING A HOLIDAYS INPUT FILE USING EXCEL The tab-delimited input file for loading the Holidays table may be generated by first creating the table in Microsoft Excel and
then exporting the worksheet as a tab-delimited file. An outline of these steps is as follows:
Create worksheet as follows:
A B C
1 04/05/1996 TN
2 04/05/1996 NY FX
3 07/01/1996 TN
4 07/04/1996 NY FX
5 . . .
Note that if the 3rd column (Flags) is completely blank, you should enter a blank text string into the cells to have some
data value in this column (otherwise the subsequent export will omit this column). A blank text string can be entered by
typing a single-quote (‘) followed by <Enter>.
The first column should also have its format set to Date | mm/dd/yyyy in order to display the dates in this Sybase-
recognized format.
Select Save As... from the File menu. For Save File as Type, choose Text (Tab delimited). Enter a file name for the
text file (e.g., HOL1996.TXT).
XIV. TESTING A NEW FEED
Whenever a new feed is ready for delivery to VaR following procedure must take place:
Define a new FeedID on a local system test machine (through the VaR Team or IT Support)
Define a Feeder Contact in the Employee table of the system test machine including an e-mail address