[ This is the first supporting document, an excel spread sheet, that was attached with mid-year rebuttal ]
No
MRT Issue
Issue Date
Reported by
EMMI Comments
Status
1
Wrong spelling in Label fields, expected names are : quantity, cleanPrice, cusip
1/30/08
BrownMan
Fixed by EMMI
Closed
2
emts_pos_Murex has 10/23 COB date instead of 10/29 date.
2/1/08
BrownMan
Fixed by EMMI
Closed
3
emts_pos_Murex did not generate any IFIBPV* XPs since there are no sensitivity based positions ( none sensitivityValuationFlag set to 1, only 0s ). If this was not intended please provide the right feed with sensitivity based positions.
2/1/08
BrownMan
sensitivityValuationFlag set to 1
Closed
4
Columns AN and AO corresponding to creditSpread emts_pos isn't setup correctly, We are expecting numeric values. At least 0.
2/5/08
BrownMan
we fixed the AO column for the MP record, now is defaulted to '0', no change is required for the column AN for BP record as we already defaulted to '0'.
Closed
5
No Price based positions generated, thus RISKEXP2.XP file was empty since the file has sensitivityValuationFlag always set to 1. This is the opposite situation of earlier when sensitivityValuationFlag was always set to 0, then no IFIBPV*XP but RISKEXP2.XP was created. Looking at the latest production file (2/5) the flag can have either value (0,1) in both BP/MP records.
2/6/08
BrownMan
we will investigate the logic ahead of delivering the SIT files. In general the expectation is that Murex will provide the majority of instruments with correct sensitivity values and therefore sensitivity flag set to 1.
Closed
6
The extension is wrong - EMTSSPRD_Murex.TXT should actually be EMTSSPRD_Murex.out
2/6/08
BrownMan
Fixed by EMMI
Closed
7
EXPORTRM_Murex.DAT failed to load. But when I changed to COB date to 20080124 it loaded. This was due to gap days in our database, if this were a recent file it would load.
2/8/08
BrownMan
1/29 file loaded
Closed
8
RISKLDC_Murex.TXT had extra spaces for every record which caused our generic loader script to fail.
2/11/08
BrownMan
Fixed by EMMI
Closed
9
we are observing nominal differences between the MX and EMTS exportrm reports. The EMTS file appears to be showing double expected nominal value for USD repos. Are you aware of any issue on the nominal of this file?
2/19/08
Christian
Fixed by EMMI
Closed
10
Identified 3 jil jobs that are obsolete as the 3 files associated with them are being directly loaded by Market Data
2/15/08
BrownMan
Verified with Prod that these are not being used and there are Mkt Data jobs instead
Closed
11
In exportrm AE and AL columns are used to populate Quantity and RecVal fields in XP. The Calculator used for MarginFwd positions use Calc 244 that make use of Quantity value to arrive at BPV and Delta Market Value figures. So, Yes, they are critical and halved value does not sound good.
2/19/08
BrownMan
Same as Issue No.9 -- PRODUCTION issue
Closed
12
quantity in RISKEXP2 is a derived field and it's derived based on Calculators being used. Here's a sample list from code as is. As you can see lastMarketValue, parAmount are being used. This is not the complete list.
2/20/08
Alik
Could you please clarify which of emts_pos.Id fields is being used to populate the quantity field of the RISKEXP2.XP file
Closed
13
Replied to EMMI - If the instrument is present either in EMTS or EMMI feed then mkt data is required.
2/21/08
Christian
Independent of the current SIT files, are you able confirm the mkt data requirements for VARs, i.e. whether VARs requires mkt data for active positions only or every instrument that has been setup. The information is key to determine the feasibility of the pilot go live, using Murex mkt data.
Closed
14
Question regarding the portfolio mappings sent by Hok Yee - Are the portfolios highlighted in red ( rows 26, 30, 35 etc., ) to be included during UAT phase and after , not during SIT testing? What about portfolios in blue ..rows 47, 80, 81 etc.,
2/27/08
BrownMan
New Mappings to be sent / updated prior to UAT
Open
15
BOND Positions: Sign Convention – The quantity field, reconciliationValue, notional and lastMarketValue has a revers sign. Does this mean the absolute value of quantity is taken assuming the traded position (Short/Long) shows up in the sign of value?
2/27/08
Hrachia
Fixed by EMMI
Closed
16
Different Field Name – Field name appears differently for b_asw, b_default_yld, and b_stw. The prefix “b” and “_” are missing from EMMI feed. Because of this, the value for these fields show a zero
2/27/08
Hrachia
Fixed by EMMI
Closed
17
Flag Reversal– The flags for listed fields have reversed their values– is it expected and legitimate? distressedFlagpriceValuationFlagsensitivityValuationFlagcashFlowProvidedisFixed
2/27/08
Hrachia
Differences explained by EMMI as expected. isFixed will be fixed
Closed
18
Rating changed for a same issuer – The Chase rating is different – is it expected and legitimate?
2/27/08
Hrachia
Differences expected. To be reviewed by EMMI - The instrument setup in Murex is in line with Bloomberg for the majority of bonds and will not match EMTS for all instruments. On that basis differences vs the current emts pos ld file are expected. For instrument configuration details plse refer to the attached xls.
19
Issuer and countryOfIssuer–Uses different convention in Murex – is it expected and legitimate?
2/27/08
Hrachia
Differences expected due to change in reference data
20
Missing Information – In the new EMMI feed, information is missing for Counterparty, Industry, curveId and traderinitials fields
2/27/08
Hrachia
Differences expected
21
0 value/Missing Information – There are at least 24 cases where the values show a zero. It includes basisPointValue, Yield, and the Spread.
2/27/08
Hrachia
Details wanted
22
Different Definition – “daycountconvention” field has a different definition for its value in the feed. It shows 30E/360 as against the same without “E”
2/27/08
Hrachia
Explained
23
Different Value – There are at least 10 cases where the values are in conflict with EMTS feed. Portfolio, Issuer, and Position Id being the prominent ones
2/27/08
Hrachia
Details wanted
24
Value differing by a $mm – Par Amount shows a value which is million times over the value from EMTS
2/27/08
Hrachia
Will be fixed
25
Miscellaneous position: Sign Convention – Same issue as in BP record. The quantity field, reconciliationValue, notional and lastMarketValue has a revers sign.
2/27/08
Hrachia
Fixed by EMMI
26
Different Product type Classification – The productType appears F in EMTS and O in EMMI
2/27/08
Hrachia
GCRM feedback, signed off by Adrien Campbell
27
Missing Information – In the new EMMI feed, information is missing for book, branch, location fields
2/27/08
Hrachia
Details wanted. Reply: "book" is set to either book or instrument field. "Location" is set to location. It's OK to be blank.
28
Different Value – There are several cases where the values are in conflict with EMTS feed. Significant among them are Currency (earlier it was USD, now it is ARS), and Rating
2/27/08
Hrachia
Production issue - Xccy issue will be fixed and will now come in local CCY and all others will be in USD
29
Flag Reversal– The distressedFlag has reversed it’s value– is it expected and legitimate?
2/27/08
Hrachia
Explained
30
A small error: I believe when the file was regenerated the src system was reset to EMTS in murex file ..it should be EMMX
2/29/08
BrownMan
Fixed by EMMI
31
1. These two are portfolios have positons in the new feed but there are no positions for the corresponding old portfolio in the production feed - BRL STRUCT CBLBRL STRUCT SL
2/28/08
Siddharth
Fixed by EMMI
32
2. Further there are new instruments in the new feed which do not exist in old feed.
2/28/08
Siddharth
Fixed by EMMI
33
3. Further in the new feed if the last market value is populated in local currency we will have an impact and we will have to make code changes.
2/28/08
Siddharth
34
The three fields - quantity, lastMarketValue and reconciliationValue should be in USD, not in local Ccy.
3/5/08
BrownMan
Will be fixed
35
Christian wanted MRT to confirm list of portfolios provided by SBS
3/7/08
Christian
Provided feedback with the list
36
Re: BP record #12 0 value/missing info- (see below table for details). As you can see first of all industry is missing and firstCouponDate has been changed (which will drive duration changes, bat in different value?). The "missing/0 values" is really missing (0 values)d or due to priceValuationFlag/sensitivityValuationFlag changes?
2/29/08
Hrachia
37
Is Industry being used by VARS?
2/29/08
Christian
No per EMTS
38
Aggregation Level -We would like to knwo what is the aggregation level of the data that is being sent bu Murex in the new EMTS feed.Is the aggregation level same as compared to the original/production verison of the feed file.
2/29/08
Siddharth
Explained
Closed
39
There are some additional positons for which do not exist in the original/production verison of the feed file. PFA an XLS with the positons corresponding to addtional portfolio & additional unmapped positions.
2/29/08
Siddharth
Fixed by EMMI but not really fixed per Siddharth
Closed
40
whether the following is a valid portfolio - this one neither had book or instrument populated. Also, there are few others marked "UAT TEST", I don't see any of them in emts_pos file.
3/6/08
BrownMan
Not a valid portfolio, will be purged from Feed.
Closed
41
Specific to portfolio "BRADY DS SL" - The NOP, LASTMV, RecVal and Quantity are approximately half compared to corresponding EMTS values, values are in GBP instead of USD. This is known issue. The VAR is different entirely since it picks up a different calc, Calc 8 when it should really be Calc 9. This is driven by "distressedFlag" which is set to 0 in EMMI feed compared to 1 in EMTS feed. Also the "desk" values differ. See s/s
3/11/08
BrownMan
42
With regard to only VAR difference for a USD portfolio ( "LC PSM SL" ) . I see following differences in EMMI feed v/s EMTS one -- the most important being "countryOfIssuer" and parAmount, the latter impacting only 321 Calc.
3/11/08
BrownMan
43
Regarding "countryOfIssuer" confirmed that 3-letter currency code is required as it was the case in EMTS feed. We map this to 2-letter ISO country code internally.
3/12/08
BrownMan
EMMI will provide ISO country code only. Coding impact
44
with the position that we had seen before the diff was in MM being expanded into full million in numbers i.e 200 as 200000000 . But I am looking at some other positions and there is inconsistency with the values itself.
3/13/08
BrownMan
45
Here is a sample of the discrepancy that we see in the EMTS and EMM feeds. This is a non XCCY position(s) -
3/11/08
Imran
46
Cusips in EMTS are missing in EMMI
3/13/08
Hrachia
Summarizing "ISIN/CUSIP" part of the remarks: for me it looks like that ISIN information is enough for the VARS processing; RISKMAST feed is redundant and could be retired. However this would require changes in the feeds processing code;
47
In the sample s/s sent below by Imran in the previous mail the difference in "desk" field can be attributed to difference in portfolio names mostly but there is one important set of values missing i.e "DSTRSSD". There are no positions that are marked DSTRSSD in the EMMI feed. These are distressed based on price/rating or as dictated by business. We generate SN specific information specific to these records by processing the RISKMAST file. To process this accurately the ucn/cusip/isin values need to match too, but the Cusip values are different. RISKMAST information is used to generate SN records for for DSTRSSD positions. During processing of raw feed for each record with desk field = DSTRSSD a duplicate of that record with calculator set to 401 and a few other changes (for specific risk calculation) are done. We gather "RawIdentifiers" for SN from RISKMAST for each instrument whose desk is marked distressed. Basically without DSTRSSD positions we will miss generating 401 records for SN processing for that many positions.
3/17/08
BrownMan
As it was mentioned at yesterday meeting there is no such desk as 'DSTRSSD' in the Murex and the EMTS logic of overwriting the actual desk with the DSTRSSD value is not clear; As far as I know calculator 401, which is being assigned based on the 'DSTRSSD' value is used only for the specific risk and in reality is not a calculator - it does nothing but saves LMVs; I am wondering whether 401 plays any role in the specific risk calculations after GEM positions were migrated from CEDAR specific risk model to the PCM. I believe Han and Imran might answer on this question. Summarizing "DSTRSSD part" of my remarks - I doubt that DSTRSSD desk plays any role in the current process and necessary.
48
Though the file was loaded correctly I see some portfolio issues between previous and new EXPORTRM files. The portfolios listed in each are different. The BRD026 and REP012 are all MF positions which are not migrating to new but what about REP013 having REVREP positions. And there are 3 portfolios in the new that are not in before. Please explain.
3/21/08
BrownMan
49
Similar to EXPORTRM I found some portfolio inconsistencies in USTREAS also.
3/24/08
BrownMan
