How long of a history are you trying to create? If it is for backtesting purposes: you could consider to create your continuous data once and reuse it for each of your back tests. In that way would you ensure that your test results are always based on the same price data.
I think this depends on what you're trying to accomplish through the "iteration" over the contract months. If all you're trying to do is iterator over all delivery months in order, then all you have to do is a sort on the name of the file assuming your file names are in the format <market>_<year><month_code>.csv or something like that. All the <month_code>s are alphabetical making this really easy. If you're trying to stitch together continuous price series, then you need to decide which months you are going to trade first. This decision is based on price seasonality and contract volume at the very least -- there may be other factors that come into play. For example, I believe GAT has a blog post about stitching together continuous prices -- for example, for Crude Oil the December delivery contract is the most liquid with decent volume even 12 months away from delivery. If you are stitching together continuous prices for the purposes of backtesting, then using a pretty standard stitching algorithm that cuts over based on Volume or Open Interest is fine. There are additional nuances such as trading the second contract for VIX and VSTOXX, which would require stitching the continuous price for the second contract rather than the first, but that can come later. Having said all that however, I've found that the simple stitching algorithms are not quite good enough for deciding when to roll in live trading. So, for live trading (and for my backtesting since there is no extra effort), the approach I take is to have a static configuration file for each market. The configuration file specifies what delivery months I'm going to use for stitching. The config file also specifies whether to cutover based on Volume or Open Interest -- I use Volume since it's actually difficult (for me at least) to get Open Interest information during nightly updates; IBKR does not have reliable OI data, Quandl seems to have it, CSI does have it but I hate relying on a Windows based scheduled process in my automated system and thus I don't use it. So far, this is all pretty standard. In addition to the above, my market specific static configuration file also specifies a rule for determining the "last roll day" that I'm comfortable with. This is because I found that in practice the Volume and Open Interest based rules don't cutover in time to roll and so I also need to know the last trading day or first notice day (for markets with physical delivery) and roll before then in order to avoid contract expiration or IBKR closing my position for me. The "last roll day" rule is based on the contract specification which you can find at the exchange. Typically it's something like -- two business day prior to the third Friday of the delivery month. Although, some of the rules do get a bit whacky. If all of this sounds like a big pain in the ass, well ... it is It takes a lot of time to gather all the rules for all the markets that you want to trade -- especially if you're trading 40 or more markets. And, there is a fair amount of coding in this approach as well. The result is that I do have automated rolls, but I'm sure that they are not optimal in many ways. Ok, so all of the above thus far is just for stitching together continuous prices and determining roll dates. There's another level of complexity if you want to calculate carry based on futures prices. Calculating carry really can get quite complex and asset class specific. Probably the easiest markets for calculating carry are Volatility markets, US Bonds, US Equities, and major currency pairs. Things get more complex if the market displays seasonality or if the volume on the back months is too thin to get an accurate price point. Surprisingly, this is the situation (seasonality) with many commodities; and many non-US bonds and equities can display seasonality and typically do not have enough volume in the back month contract. I've spent months trying to get "nice" carry indicators on the challenging markets. Anyhow, that's my $0.02. I generally (unfortunately) over engineer stuff, so if the above seems like a lot of complexity to solve a rather simple problem, you're probably right. --Maciej
Hi guys, is it a problem that all the currency futures are exposed to USD risk? For example EURUSD, GBPUSD, USDJPY and AUDUSD all have USD risk factor in common which makes them highly correlated. Is there a good way to deal with this problem?
What about (al) most (all liquid) commodity futures or US stocks? Are they not quoted in USD? (MSFT is effectively MSFTUSD, Corn is effectively CornUSD). If you really want (let's assume that USD is not your base currency), you could opt to hedge the USD exposure into your base currency - although this will be a major pain (especially for smaller accounts)
Well for currencies, you have the choice of cross pairs instead of having the base in USD. Instead of USDJPY and EURUSD, maybe EURJPY Especially if you use spot market with good rolls, you can have lots of diff crosses.
Hi GAT, I was wondering if I might trouble you with a quick question on how I might use pooling to calculate the FDM for your system. When you pool the correlations are you a) simply getting the correlations of the forecasts for each instrument and averaging them out or b) are you stacking up the forecasts of the instruments and then generating one correlation matrix?
Hello Rob, My first question regarding your presentation "Trading Strategies That Are Designed Not Fitted": At a high level is the gist of the strategy you presented that it's a trend following strategy where the trend is defined by the slope of a regression line of a certain window_size where you're long if the slope is up and short if the slope is down? Seems like that's the general idea but wanted to make sure before I asked more questions. Thanks