Page 1 of 1
WARNING: Potential problem with CSI Unadjusted Close field
Posted: Thu Jun 05, 2008 6:35 pm
I recently started scrutinizing the unadjusted close data generated by CSI UA ASCII field layout option "U" (Futures data only). Assuming that there are no specific issues with the versions of UA I tried (i.e. 2.9.3 and 2.10.3), there appears to be a serious problem with the unadjusted close data.
I ran some preliminary tests and noticed that UA generated erroneous unadjusted close data in more than a handful of markets. For example, in a portfolio containing 135 futures markets, 46 of these markets had at least one incorrect unadjusted close value (in fact, 34 of these markets each had more that 100 incorrect values).
The type of errors I noticed include decimal place shifts, constant price differences and seemly variable price differences (note that the analysis I did in TBB used the realPrice property to adjust the unadjusted close for negative adjustment shifts). I would have expected UA's algorithms to simply append the raw contract close to the various continuous contract series it generates.
I would greatly appreciate it if other users could confirm this problem with their install of UA. To do this, use UA to generate a single contract data file for the June 2007 contract of EJ (FINEX Euro/Japanese Yen). The image below isolates the problem with this particular market - the unadjusted closes that UA generates prior to April 5th, 2007 are 1/10 the value of the actual contract close.
Assuming that this is not an isolated problem, there appears to be a quick fix: select the "Closing Bid" field (B) instead of the Unadjusted Close (U) field. In my limited testing, the use of the closing bid does result in the proper raw contract closing value to be incorporated into single and continuous contract files.
Posted: Thu Jun 05, 2008 7:09 pm
I see a 10X jump in the unadjusted close field (column I) on CSI UA 2.9.1
Posted: Fri Jun 06, 2008 5:05 am
Thank you Sluggo. I will contact CSI tech support and inform them of the problem.
Posted: Fri Jun 06, 2008 7:29 am
CSI are a wonder of efficiency, politeness and information compared to some other data vendors.
If you want a real belly laugh, try subscribing to reutersdatalink and looking at some of their stock market index charts!
Posted: Tue Jun 24, 2008 2:40 pm
nickmar wrote:I will contact CSI tech support and inform them of the problem.
I wonder whether CSI have come back to you yet? Certainly the problem is widespread and I would dearly like it fixed.
Have you done further investigation with using the Closing Bid instead of the Unadjusted Close? If so, does it hold up to your further scrutiny?
Posted: Tue Jun 24, 2008 5:31 pm
I have yet to receive a reply from CSI. To be quite honest, I have not attempted to contact them a second time.
After completing numerous comparison tests, I am confident that the "Closing Bid" can indeed be used as a proxy for the "unadjusted close".
Posted: Wed Jun 25, 2008 2:46 am
Many thanks indeed. I will let you know whether I come accross any problems using the closing bid.
I e-mailed CSI last night and likewise will let you know what response, if any, I receive.
Posted: Thu Jun 26, 2008 2:46 am
I received a reply from CSI as follows:
I have reviewed June 07 EJ and am unable to find this condition. It may have arisen due to a conversion factor change transmission that wasn't applied? There was one reported for April 4th 2007.
If there is still a problem go to database/refresh price history and type in EJ
also - go to database/download replacement fact files.
Then take another look
All of which I did to no avail - the "conversion" worked forwards but not backwards. Prior to April 4th 2007, unadjusted close figures are still 1/10th of those post that date. I await further comeback from CSI. One obvious irritation is that such updates should be automatic, in any event, with the daily download?
Posted: Thu Jun 26, 2008 7:22 am
Further correspondence with CSI.
Sent: 26 June 2008 11:27
Subject: Re: Emailing: EJ_0_I0B
I am inclined to say the Unadjusted Close is more apt to be used
for the stock markets( no split, no dividend, no capital gains adjustment),
not the future markets. As has been shown, the unadjusted values
for the futures show precision changes, contact size changes, etc.
They are the correct values reported by the exchange, however I
personally don't see the value in using them with futures.
One may look at the unadjusted contract data by turning Historical
Adjustments off in the Preferences or Portfolio settings section.
That simply can not be right. Take a look at the attached data from the Euro Bobl produced from CSI data. Notice that supposedly the Bond price went from 10 to 100. Bonds do trade at 10. The figures of 10 and below can not be correct values reported by the exchange. These bonds did not trade at 10 â€“ bonds trade at or around par. Just imagine the interest rate change which could have caused a bond to go from 10 to 108!
26/02/1999 96.82 96.85 96.47 96.62 177925 193685 199903 10.843
01/03/1999 96.74 96.79 96.3 96.36 2384 24234 199906 108.04
The unadjusted close is a vital tool to use in analysis: in order to assess the CAGR of buying holding a futures contract over a long period of time, you must use unadjusted rather than back adjusted prices. I have written some code to work with this data to produce commodity indices and in order to capture the roll premium or discount it is helpful to use a back adjusted contract to tell you when the roll occurred along with unadjusted prices in the final column to use in the actual calculations.
If it sounds complex I am more than happy to telephone and explain. This matter is important to myself and other users. Also, perhaps you could tell me why the Unadjusted Closing Bid price is correct whereas the Unadjusted Close is not correct?
Posted: Thu Jun 26, 2008 8:24 am
Here is a further update. I had a long chat with Josh, a programmer at CSI.
He took at look at the coding for the "U" field and agrees with me that it is supposed to contain the underlying contract price.....as reported by the exchange. It does not (apparently) and would need re-coding to achieve this - which in turn would mean a CSI UA upgrade patch. Gulp.........I'd rather not, thanks. In other words, adjustments are applied to the "unadjusted" contract field C.
Josh confirmed that field B does contain the underlying contract price as reported by the exchange with no alteration. Is this what we want? I am be tempted to use field B; I do not want to risk an upgrade, even if it is only a patch.
Any comments anyone? Are there changes (in contract size, bpv etc) which do need to be reflected in exchange reported prices? I am still thinking this through.
Posted: Thu Jun 26, 2008 9:37 am
Just a thought for the paranoid: Is it possible, hypothetically, for the closing bid (B) to be a different number than the closing price (C) of a raw contract? If so then it may be a tiny ooch misleading to assume that in a backadjusted contract, the closing bid (B) is equal to the unadjusted close.
I think this can be tested, though. Even on the final backadjusted continuous contracts. I think if you made a little one-off Blox that printed (B minus C) for every single day of data, and if you had it print "today is a rollover day" on rollover days, that would suffice. You would just scan down the column of numbers, looking to see whether it ever occurs that (B minus C) changes value, on a non-rollover day. If so, uh-oh! You could even have your little Blox do this scanning for you, and just print out messages of dire warning if it ever encounters such a day.
Posted: Thu Jun 26, 2008 10:01 am
Yes, I am sure the prices will differ on many days. In my own case, it's a fudge I'm prepared to live with, so far as the creation of commodity indices is concerned.
I have looked through so many different ETC prospecti and index calculation methodologies and have come to the realistic realisation that â€œaccuracyâ€
Posted: Thu Jun 26, 2008 10:57 am
In order to test the "Closing Bid" to the raw contract close, I created about 1300 unadjusted price data files and combined them into one large CSV file. Thanks to Excel 2007, I was able to compare over half a million records in a snap.
Out of 1333 price files, only 6 of them had at least one instance of wrong Closing Bid data (by contrast, 268 price files contained inconsistent unadjusted close data). Strangely enough, the problem with these 6 files was not that the Closing Bid was different from the raw contract close but rather that the Closing Bid field was blank.
EDIT: changed "Opening Bid" to "Closing Bid"