How did you go about picking rollover timing triggers?

Discussions about the testing and simulation of mechanical trading systems using historical data and other methods. Trading Blox Customers should post Trading Blox specific questions in the Customer Support forum.
AFJ Garner
Roundtable Knight
Roundtable Knight
Posts: 2071
Joined: Fri Apr 25, 2003 3:33 pm
Location: London
Contact:

Post by AFJ Garner »

ecritt wrote: But I believe it's worth pursuing. Just looking for any like-minded people that want to discuss.
I could not agree more. Its just that (a) we need to build continuous contracts of some sort not only for back testing but also for signal generation and (b) CSI UA is the only option many of us have.

I very much like Roger Rine's take on rolling: roll your own as and when your particular criteria is met; don't let the decision be taken by algorithmic software.

I also entirely agree that there is much research to be done on this topic and, as ever, I value your thoughts.

Unfortunately (and disgracefully) I can't find my research on Crude but certainly I am prompted by your thoughts to re-visit the matter again.

In the meantime I continue to make good money. The question is whether I can make "better" money with a bit more effort along the lines you suggest.
Kiwi
Roundtable Knight
Roundtable Knight
Posts: 513
Joined: Wed Apr 16, 2003 1:18 am
Location: Nowhere near

Post by Kiwi »

There seem to be two possible discussions going on here:

- using better rollover dates for testing than the standard OI or date based
- getting a better real result than your test result.

It's probable that I'm the only one discussing the second part (yes, I hear the sound of 1 hand clapping). Has anyone else considered the approach of testing on a basic approach then improving the actual result as a way of enhancing their systems' outputs?

- the simplest approach to this might be to wait until the trigger occurs and then roll iff an X% better swap becomes available (with some obvious give-in point).
sluggo
Roundtable Knight
Roundtable Knight
Posts: 2987
Joined: Fri Jun 11, 2004 2:50 pm

Post by sluggo »

Hi Kiwi,

Alan Pryor, proprietor of long term trading dot com and vendor of mechanical systems, suggests the very thing you are talking about. He advises you to compute the intramonth spread using yesterday's closes, and then to place a LIMIT order to roll over, at yesterday's close-to-close spread value. His purpose is to minimize roll slippage, i.e., to "meet" (rather than to "beat") the hypothetical rollover that Blox + CSI computes.

He also suggests that when you're sitting on a whopping fat profit and not likely to be stopped out soon, skip a contract and roll into a more distant back month:
In the users manual for the Ready-Set-Go trading system, Alan Pryor wrote:It is sometimes advisable to roll over into a more distant contract than the next expiring contract if you are carrying a very large profit in your position and your Stop And Reverse point is the equivalent of $3000 per contract or more away from the current price. I only do this if the next current month into which I would otherwise roll into is less than 60 days away from expiration and I have a very large profit on the current position and the Stop And Reverse point is some distance away. Typically, this situation only occurs in the energy commodities that have expiring contracts every month. In these cases, I will often skip a month or two and position myself in a more distant month to avoid the rollover every month. The published track record (for the Ready-Set-Go trading system) dies not reflect this, however, and assumes you always roll over into the next most liquid future contract.
It seems eminently sensible to me; a promising reward-versus-risk gamble.
+SLUGGO+
AFJ Garner
Roundtable Knight
Roundtable Knight
Posts: 2071
Joined: Fri Apr 25, 2003 3:33 pm
Location: London
Contact:

Post by AFJ Garner »

Kiwi wrote: (yes, I hear the sound of 1 hand clapping)
There is no hearer. :lol:
Emptor
Contributing Member
Contributing Member
Posts: 5
Joined: Thu Nov 19, 2009 10:44 pm

Post by Emptor »

Just wanted to quickly thank everyone for their responses, threw a great deal of light on the subject for me.

At risk of gushing, the concentration of knowledge and talent on this forum, as well as its spirit of sharing and helping, really is a marvel.

Many thanks,
Emptor.
Emptor
Contributing Member
Contributing Member
Posts: 5
Joined: Thu Nov 19, 2009 10:44 pm

Post by Emptor »

Hi guys,

I've just gone through just about every roll option the CSI platform offers for Cocoa (Open, Open and volume, specific date, uncluding the suggested date from Pinnacle) and they all share the common trait of having the abnormal volumes in 2007 as indicated by the chart I've posted. I've tried refreshing my historical database as well and this hasn't solved the issue.

I've noticed similar weird volume readings on other contracts as well, though most are fine. In all cases the issue is with volume and/or OI, price seems fine. In all cases the problem does not seem to be affected by changes in roll timing or refreshes to the historical database. Note below the chart for RB.

Does this still seem like a roll timing issue or am I dealing with something else entirely?

Cheers,
Emptor
Attachments
Untitled.jpg
Untitled.jpg (242.2 KiB) Viewed 12556 times
sluggo
Roundtable Knight
Roundtable Knight
Posts: 2987
Joined: Fri Jun 11, 2004 2:50 pm

Post by sluggo »

After reading these two articles, ask yourself what you would do if you were a futures data vendor. What would your customers want you to do?

http://www.pbs.org/nbr/site/research/le ... 0216_rbob/

http://www.mrci.com/client/gasoline.php
Emptor
Contributing Member
Contributing Member
Posts: 5
Joined: Thu Nov 19, 2009 10:44 pm

Post by Emptor »

So am I correct in understanding that the volume pattern is an artifact from the blending of data from the old unleaded contract into the new RBOB symbol in this instance?

That being the case would the correct response to be to simply leave it as such?
sluggo
Roundtable Knight
Roundtable Knight
Posts: 2987
Joined: Fri Jun 11, 2004 2:50 pm

Post by sluggo »

I think you're asking "Exactly what did CSI do, when they merged the old Harbor Unleaded (HU) contract with the new Reformulated Blendstock for Oxygen Blending (RB) contract?"

The only people who actually know the answer, are the folks at CSI.

Depending on your degree of curiosity, you could do some forensic exploration yourself, and generate a proposed answer (your hypothesis) with very high confidence.

First you could find out the very last contract of HU, perhaps by Google or other investigations (image below may help). Next you could find the very first contract of RB. Then you could pick, say, the last 10 HU contracts and the first 10 RB contracts, form all possible (10*10 = 100) pairs, and manually splice together those 100 pairs on your fateful rollover date in Q2 2006. One of them will look exactly like your screen image, and that pair would be an excellent choice for a hypothesis, a proposed answer to the question "Exactly what did CSI do and when did they do it?"

If you also want to know WHY they did it, you may have a more difficult time answering that question by examining price data. Price data may not reveal human motivation very clearly.

To decide what you personally will do, as a trader, a simple approach would be to write out a list of your options. Next to each one, write the pros and the cons as you perceive them; take your time and be thorough. Choose one of the options according to your own gut feeling about which is best for you and feel happy. Naturally one of your options is to eliminate HU/RB from your testing & trading portfolio. Another is to consider them to be two different markets with different symbols; one that ends in Q2 2006 and another that begins on (whatever date you choose, perhaps Q1 2007?). I'm sure you will be able to invent several more options.
Attachments
from CSI UA
from CSI UA
Harbor_Unleaded.png (16.91 KiB) Viewed 12419 times
Emptor
Contributing Member
Contributing Member
Posts: 5
Joined: Thu Nov 19, 2009 10:44 pm

Post by Emptor »

That's an extremely indepth answer, ill suited to 10pm and my second glass of red when I originally read it. In the sober light of this morning it makes a lot of sense however, and moreover forces me to actually think about the mechanics of what is occurring. I am in your debt once more.

Cheers,
Emptor.
jklatt
Roundtable Knight
Roundtable Knight
Posts: 102
Joined: Sat Feb 17, 2007 11:51 am

Post by jklatt »

I finally finished my liquidity data mining project and I thought I'd follow up with a fixed date rollover metrics report for CSI symbol CC2.

A few things to know. The scripts initially build a "highest" volume continuous contract with the ability to roll only once into a forward contract and with the ability to see the future. The amount of time spent in each delivery month is then calculated and the scripts weed out the low percentage delivery months. In this case, I used 1 divided by 12 divided by 2 or about 4%. If the instrument doesn't spend 1/2 of a month on average in the delivery month every year, it gets the boot. I then reconstruct the "highest" volume continuous contract based upon the filtered active months.

From there I set an analysis start date (I can choose whatever I like, I chose 1/1/1990 for this report) and I calculate a volume based analysis start date and the script uses whichever date is closest to today. The volume based start date basically looks at the highest volume continuous contract and picks the oldest date that continuously meets my volume requirements. In this case, I chose 50% of the trading days over a 250 trading day time period had volume of 500 contracts or more. I added this filter because I noticed that a lot of the instruments were rather illiquid early in their histories and I didn't want to gather potentially unhelpful information.

The scripts then scan the various rollover dates throughout the highest volume continuous contract and an array of potential roll dates is generated. It looks for the roll date closest to expiration and furthest from expiration and then generates a list of every possible roll date definition for those two dates and everything inbetween.

I then construct a fixed date continuous contract for each potential roll date in my array and I take some measurements.

I first sort the list by whether or not the roll trigger ever rolled on or after expiration or first notice (whichever occurs first -- column C). I then sort the list by the percentage of time the roll trigger kept me in the highest volume continuous contract (column D).

I then thought about a measure of goodness for rollover liquidity and decided I wanted both contracts to be "liquid" and decided upon the smallest of the two following ratios:

current contract's volume divided by forward contract's volume
AND
forward contract's volume divided by current contract's volume

This ratio shows me when there is balance between the 2 contract's volumes and when there isn't. Maybe some of you would use a different measure of goodness. These measurements are in columns E and F.

Columns G shows how much liquidity on average is retained relative to the highest volume contract when I'm not in the highest volume contract's delivery month and H shows the worst 1 day liquididty retention when not in the highest volume contract's delivery month.

Columns I through L show the average time the roll occured (in terms of calendar and business days) before expiration/first notice (whichever comes first).

So... my conclusion from this report is that anywhere from the 8th to the 12th of the month prior to delivery would work pretty good. Maybe pick the 10th and be right in the middle?

Edit- huge image trimmed down to smaller footprint - MODERATOR
Attachments
CC2_Fixed_Date_Rollover_Metrics_Report.xls
(15.5 KiB) Downloaded 494 times
cc2_fixed_date_liquidity_rpt_NARROWED.jpg
cc2_fixed_date_liquidity_rpt_NARROWED.jpg (177.67 KiB) Viewed 12079 times
sluggo
Roundtable Knight
Roundtable Knight
Posts: 2987
Joined: Fri Jun 11, 2004 2:50 pm

Post by sluggo »

Congratulations on creating software that allows you to prepare such a thorough report! It will help the human trader make a sensible decision, considering a multitude of variables. Me, I would probably sort by column D in descending order, as you did in the figure, then choose a setting that had plenty of safety margin in columns J and L.

It is interesting that Pinnacle Data chose approximately the same setting you did, see figure below. However, don't take their choices as pure Gospel truth, see for example (this) posting.
Attachments
From Pinnacle Data's website
From Pinnacle Data's website
Pinnacle_cocoa.png (29.71 KiB) Viewed 12033 times
jklatt
Roundtable Knight
Roundtable Knight
Posts: 102
Joined: Sat Feb 17, 2007 11:51 am

Post by jklatt »

I was thinking the same thing about prioritizing the time distance from exp/fnd as well, but for some of the instruments volume seems to roll pretty close to exp/fnd and the volume is pretty thin in the forward contract relative to the current contract. I think I'm going to add a field that lists the volume in the forward contract on my worst case scenario days. A ratio of 0.025 when the volumes are 50,000 / 2,000,000 is less worrisome than when they're 50 / 2,000. Maybe also a script to simulate 100 years of expiration/first notice dates and generate a rollover setting that you never want to exceed. For example, if expiration is the third Friday of the delivery month, the drop dead date might be the 15th (the 15th will be the very earliest expiration in any given month -- 1st + 2 weeks = 15th) minus a buffer of say 4 calendar days (2 weekend days + 1 day for a possible holiday + 1 more day for good measure). This would help guard against possible problems down the road when my current report is looking at newer instruments that only have 3-4 years (or less) worth of testable data. Like you said, there are a lot of variables and not all of the instruments are as clean and straightforward as CC2.

Thanks for the heads up regarding Pinnacle's suggested roll times. After spending a few months digging through CSI's data, I've come to not trust any of it. It has really helped me realize that I need to run broad tests (scrambling the portfolio, running 10s of thousands of tests and looking for general performance characteristics) instead of focusing on specific setting and specific portfolio results.
jklatt
Roundtable Knight
Roundtable Knight
Posts: 102
Joined: Sat Feb 17, 2007 11:51 am

Post by jklatt »

I revised the report and ran it for CSI symbol US (picture attached).

I created a Latest Roll Date (get out by this date no matter what) statistic by reading in the expiration/fnd structures and calculating the oldest of the 2 dates for each active delivery month from 1900 to 1999 (100 years worth of deliveries). I captured the date with the furthest monthly offset from delivery and the smallest calendar date and then added a business day buffer (5 weekdays for this example). For CSI symbol US, if you want to ensure that you're at least 5 weekdays away from expiration/first notice, you have to roll by the 19th during the month prior to delivery. This makes sense. First Notice for March deliveries occur on the last business day in February and the smallest calendar date that the last business day in February could be is the 26th (28th and 27th are weekends). Move 5 business days back from there and you've got the 19th (with the 20th and 21st being weekends). Of course, the report doesn't account for holidays (maybe I'll build that in some day) so there is a small degree of error.

I sorted based on whether or not the rollover date came on or before the latest rollover date and then by % of time in the highest volume continuous contract.

Sluggo said he'd probably sort by column D and then choose something that had plenty of safety margin in columns N and P (calendar/business days away from expiration/first notice). So I chose 5 weekdays as my choice for "plenty of safety margin" and I'm left with some pretty thin conditions until the end of the month (that's when volume tends to rollover according to the report). Even if I were to move closer to first notice and use the 23rd, I still might run across similar thin conditions.

So... assuming I'm not going to explore other roll timing methods (like OI, volume, etc.), what's worse? Rolling a little early and dealing with some relatively illiquid conditions for a week or two or occasionally rolling near or possibly even after first notice/expiration? For those of you that have real trading experience and have maybe even experienced one or both of these situations, which situation would you prefer? What fixed date do you guys use for US?

Edit: Columns M, N, O and P aren't reporting the correct figures. I've since fixed the issue.

Note to moderator: Sorry for the wide picture again. I can't figure out how to downsize it, but I'll make an effort to figure that out before I post another.
Attachments
Rollover Report.jpg
Rollover Report.jpg (711.39 KiB) Viewed 11933 times
Jez Liberty
Roundtable Knight
Roundtable Knight
Posts: 123
Joined: Tue Nov 03, 2009 8:49 am
Location: London
Contact:

Post by Jez Liberty »

I have to admire the report you created, it really provides a depth of analysis...
klatt_attack wrote: So... assuming I'm not going to explore other roll timing methods (like OI, volume, etc.),
If liquidity is such a concern (and I guess it ought to be), why not use it as an input in the rolling method (ie roll on volume shift for example - with maybe an added buffer from Exp/FND for the latest "drop dead date" for rolling over )?
Are you using fixed dates mostly for the convenience of it? Or is it because of your distrust of CSI data for liquidity figures?... (I have to admit I have not done such in-depth analysis of my CSI historical data and use fairly standard roll on liquidity methods for my backtests).
jklatt
Roundtable Knight
Roundtable Knight
Posts: 102
Joined: Sat Feb 17, 2007 11:51 am

Post by jklatt »

Jez Liberty wrote:If liquidity is such a concern (and I guess it ought to be), why not use it as an input in the rolling method (ie roll on volume shift for example - with maybe an added buffer from Exp/FND for the latest "drop dead date" for rolling over )?
How would you do that with US? Even if I were to back the buffer down to 1 weekday, I'd be rolling on the 25th every month and the vast majority of volume crossovers occur after the 25th. So the buffer is essentially rendering the volume trigger useless. I do get better volume conditions by rolling on the 25th instead of the 19th, but I'm also increasing the odds of carrying the position into or past first notice. What happens if I'm unable to roll the position on the 25th for some reason? Does my broker force me out of the position? Does a black van pull up in my driveway and carry me off into the night?

I'm pretty sure I'll go with something like the 22nd and call it a day for now, but I was just curious what some of the traders with real life experience thought about the trade offs between rolling early and having less liquidity and rolling late and dealing with first notice/expirations.
Jez Liberty wrote:... (I have to admit I have not done such in-depth analysis of my CSI historical data and use fairly standard roll on liquidity methods for my backtests).
You might want to put it on your "to do" list. I figured it was best to understand what is going on with the data and analyze the data before testing and funding a trading account. I certainly have gotten caught up in the minutia, but it has been an illuminating experience.
Jez Liberty
Roundtable Knight
Roundtable Knight
Posts: 123
Joined: Tue Nov 03, 2009 8:49 am
Location: London
Contact:

Post by Jez Liberty »

I suppose this could be a "best of both worlds" general approach, in which you would define a rolling-over deadline for each contract (ie buffer before Exp/FND) - but by also tracking the liquidity, you'd have the option to roll over before that deadline with the volume shift.

Obviously for US (and probably most other financials), if the volume shift occurs very close to the FND you'd have to roll-over at your deadline, before the volume shift, but for some other markets you'd be able to roll-over as the volume shifts, before your failsafe deadline - no worries with the black van... (ps. I believe most brokers close out your position if you have not rolled over "on time").

Just an idea - but as I said you're much more advanced than me on this subject.
klatt_attack wrote: You might want to put it on your "to do" list. I figured it was best to understand what is going on with the data and analyze the data before testing and funding a trading account. I certainly have gotten caught up in the minutia, but it has been an illuminating experience.
It definitely IS on my todo list.. Just been "dragging my feet" on it as other "more fun" pieces of research relegate this to the backburner... But you're right it's a "system foundation" to get right
jklatt
Roundtable Knight
Roundtable Knight
Posts: 102
Joined: Sat Feb 17, 2007 11:51 am

Post by jklatt »

Jez Liberty wrote:I suppose this could be a "best of both worlds" general approach, in which you would define a rolling-over deadline for each contract (ie buffer before Exp/FND) - but by also tracking the liquidity, you'd have the option to roll over before that deadline with the volume shift.
I think using that type of method would be more useful than a fixed date approach when a fixed date approach can't achieve scores of around 90% or more in column D (% time in the highest volume contract). ED (eurodollar) looks like a candidate for something like this, but I haven't really looked ED's report over well.
Jez Liberty wrote:It definitely IS on my todo list.. Just been "dragging my feet" on it as other "more fun" pieces of research relegate this to the backburner... But you're right it's a "system foundation" to get right
LOL... I've felt like doing just that numerous times throughout this process.

Thanks again for your thoughts!
sluggo
Roundtable Knight
Roundtable Knight
Posts: 2987
Joined: Fri Jun 11, 2004 2:50 pm

Post by sluggo »

klatt_attack wrote:... [ do something else ] when a fixed date approach can't achieve scores of
around 90% or more in column D (% time in the highest volume contract)

You might want to ponder that, from the perspective of "What is my actual goal?"

Is it really your goal to maximize the % time in the highest volume contract?

Perhaps your goal is actually to minimize the % time in unacceptably low volume contract(s) ?

Maybe (as with ED) the 2nd highest or 3rd highest volume contract, is still plenty
liquid enough
for you; in which case, you can optimize for other objectives
besides max-time-in-highest-volume-contract. Maybe in cases like this your
objective might be simplicity of implementation, or maximum safety margin,
or something else. Not everything is a non-G10-country's national stock index
future, which rolls 12 times a year, and has approximately zero liquidity in any
month except the front month. Not everything trades like the MSCI Taiwan
Index, or the Ibex 35, or the JSE All Shares Index, or ...
jklatt
Roundtable Knight
Roundtable Knight
Posts: 102
Joined: Sat Feb 17, 2007 11:51 am

Post by jklatt »

Jez Liberty wrote:Or is it because of your distrust of CSI data for liquidity figures?...
Early in the data mining process, I realized there were a lot of subtle issues with CSI's data. Some, not so subtle. I emailed them a list of some of my concerns and asked for them to look into things. They looked into some and I never got a response on others. I later made a decision to not worry about the errors so much. There's a LOT of data out there. Some of it is rather old. I came to accept that it isn't going to be perfect.

Here's an example I ran across last night. In January, I downloaded a lot of the individual contracts for a lot of CSI's instruments. I haven't since updated those contracts so this error could be fixed by now, but in my data it still exists. AEX1999G appears to be missing 02.22.99 and 02.23.99. Those 2 dates show up in the March and April deliveries, but not in February. These types of discrepencies show up more often than you would think. Maybe they're meaningful to your simulation data, maybe they're not. I can tell you that policing all of this isn't very fun and and the juice certainly isn't worth the squeeze (most of the time anyway). So, as I mentioned above, I made a decision to not worry so much about it and to build into my scripts the ability to deal with it and to tell me when it's occuring.
Post Reply