Winton risk target is famously low; around 10% target and 8% realised. They cut it in 2008; basically shat themselves in the turmoil, regardless of whatever ex post justification you here.
GAT
Fully automated futures trading
- Thread starter globalarbtrader
- Start date
Winton risk target is famously low; around 10% target and 8% realised. They cut it in 2008; basically shat themselves in the turmoil, regardless of whatever ex post justification you here.
GAT
I guess their business is to earn recurring management fees, and vol scares off customers!
Hi - I wanted to follow-up briefly on the impact of vol jumps after rolls, related to the question I posed late last year. If we ignore carry for now, the main smooth for TF is the vol lookback. If we are using vol lookbacks approximately one month long and we are rolling on a monthly basis, the 'vol rolldown' of the new contract will have an opposing effect to the increasing impact of the new contract's vol as it feeds into the risk scaling calculation over time. So on balance for monthly rolls I can see this is probably not an issue to lose sleep over.
However, when we do seasonal rolls a year out, as far as I can tell, after about a month all the risk scaling will be based off the new contract and this new contract might have a very different risk scale (which means practically we will be adjusting towards this over a period of a month). As a practical example, I know that the dec8/dec9 crude vol is backwardated by about 25% (and price is backwardated by about 5% currently). Therefore I was wondering for seasonal rolls, if it makes sense to roll based on a ratio of the relative riskiness of the two contracts rather than on a one to one basis. I am sure this is not a new idea but I thought I would ask if this something you have looked at or if it is worth pursuing because it would involve (quite) a bit of effort in refactoring my current codebase.
@Elder why do you worry so much about a jump in volatility after rolling a contract?
Possibly my view is rather simplistic, but I consider it "part of life". I let it happen, and let the system adjust the position size. And position size gets readjusted when the volatility changes over time. In my view, that is the whole basis of letting the system adjust position size to the desired overall account volatility.
Possibly my view is rather simplistic, but I consider it "part of life". I let it happen, and let the system adjust the position size. And position size gets readjusted when the volatility changes over time. In my view, that is the whole basis of letting the system adjust position size to the desired overall account volatility.
I guess my reasoning is that if we roll into a new contract which say has a vol of 125% of the old contract, then we initially have 25% too much risk on. Plus there is the issue of extra trading costs to get the risk to the right level whether or not the risk is too high or too low.
Indeed, if you take the same number of contracts for the new contract as the old contract, then you temporary have a higher risk. How long this higher risk exists depends on how frequently your system readjusts. In my case that would take one day. I would not worry about this. And indeed, this would lead to one additional trade, having extra trading costs. I don't roll over so often, and consider the trading costs low, so I don't worry about this.
If you want to avoid all this, then you have to calculate the number of contracts of the new contract based on its volatility. And not simply roll over one for one. You could for example do this:
let Rate = (volatility new)/(volatility old)
then Position_New = (1/Rate)*Position_Old
But I don't bother to do this.
@HobbyTrading Thanks v much for this. Out of interest how do you manage to rescale so quickly? If you are using any kind of vol smoothing then wouldn’t there be a lag?
As I mentioned, I don't do anything special. So I guess the verb "manage" does not apply in my case.
My software implementation trades each instrument near the end of its trading day. In other words: it gets reviewed once per day. Suppose that a forced rollover is necessary the following happens:
I define the date on which the rollover is required. On this date is the desired position size calculated based on the current contract, using forecast and value volatility. Then I close out all remaining contracts of the current contract and create a position in the new contract based on the calculated position size. As already mentioned: this calculation was based on the current contract, not the next one. Once this is done do I modify the relevant settings file such that the previous contract is forgotten and only the new contract is being used for further calculations.
The following trading day is the forecast and value volatility calculated based on the historical prices of the new contract. This might result in an adjustment of the position size.
My experience is that, from the instruments I'm using, the value volatility hardly changes when going from one contract to the next. Usually, when the volatility does change substantially, is it caused by some error in data collection (or construction of the stitched file, if necessary). Same applies to calculated forecast. I compare the calculation results as a sanity check. The only one which deviates from this is VIX/V2TX rollovers.
A good reason to trade further out on the curve for the cold futures and eurodollar is that the changes in vol are much smaller
GAT