Fully automated futures trading

Discussion in 'Journals' started by globalarbtrader, Feb 11, 2015.

  1. Sure you can use shares instead of futures, but the costs will probably be higher (might also be harder to leverage / short); though SPY is pretty cheap (very narrow bid/ask). Not a problem but you may need to trade a little slower to compensate. There's more on this subject in chapter 12 of my book.

    #411     Jun 7, 2016
  2. tradrjoe


    Will you reduce exposure in GBP-related instruments leading up to the "brexit" referendum given the potential for GBP to drop 20% in one day?
    #412     Jun 7, 2016
  3. No

    #413     Jun 7, 2016
  4. #414     Jun 8, 2016
    AvantGarde likes this.
  5. lawry


    Hi GAT,

    I tried a few mean reversion systems on FX following your book's framework (test on 9 developed currencies against the USD and 6 EM against the USD). According to what I understand, you're a not a big fan of such systems. For instance, I tried the so-called "Clenow plunger" (http://www.followingthetrend.com/2014/06/a-counter-trend-indicator/). As this signal has far too much variance I just smoothed the signal with an ema (I can share the python code should anyone be interested). However, my results are not that good when scaling-in/out. The problem is that most of these signals are too aggressive and then decay too fast (slow rise of the signal, entering too early against the trend followed by a fast fall, reducing positions very (too) fast (we are better off keeping our position for a few days and escape)). MR seems more suited to be triggered when the signal reaches a threshold and closed according to a given threshold/risk target without position scaling (although I have always been dubious about using fixed thresholds combined with "indicators"... taste too much like overfitting for me). Do you have any advice on how to integrate / develop a MR system in your framework? Or do you believe all these systems are pure garbage? Thanks

    #415     Jun 8, 2016
  6. I think mean reversion works in the relatively short term, and in the longer term. It also works for certain synthetic assets (eg interest rate flys).

    I'm not familiar with the plunger, but I know (and respect) Andreas well enough and I doubt he would publish something he thought was 'garbage'. It's probably trying to capitalise on shorter term mean reversion, so that's okay.

    There is no exit rule in the article. One option is to combine Andreas' entry rule with the 'semi automatic trader' stop loss rule. That means you'd get something a bit like mean reversion; it would buy high but only sell once a certain pullback had been made. However it sounds like you might want to do something a bit more in keeping with my normal style.

    I've certainly used mean reversion in my framework, and spookily at lunchtime today I was jotting down some notes on a fast mean reversion system (holding period of a few days) I've been thinking about.

    Warning: The following is something of a train of thought, rather than a well though out argument.

    Conceptually a mean reversion system has a forecast f = price - equilibrium price; where the equilibrium could come from a moving average or a regression or something.

    Often these systems only 'fire' when the absolute forecast is greater than some value (x). This is similar in spirit to how I handle small account sizes http://qoppac.blogspot.co.uk/2016/03/diversification-and-small-account-size.html so I am comfortable with that. Often they are binary in nature. So if f< -x then buy, if f then drifts up to +x close and sell, i.e. sell two units. Notice that this is then a path dependent system, something I don't like, since our position at f between 0 and +x will be different depending on whether f first went below -x. I'd set x according to something like one standard deviation of the distribution of f. So if f is already normalised according to my normal preference I'd use x=10.

    Now, do forecasts have to be binary? It makes sense to have a stronger forecast the more price drifts from equilibrium. Perhaps we don't need the threshold eithier, just a simple system f = price - equilibrium, with the usual scaling. This has the advantage of not being path dependent.

    However this will trade a lot, if the price ticks up or down it will trade every day. What to do? Smooth the forecast?

    Shorter term signals will get hammered by smoothing. We smooth to drive the costs of slower systems down where this doesn't affect raw performance unduly. Notice that if you smooth the price, and your equilibrium is also a (slower) smooth, then you have a reverse EWMA system. I've found before that these don't do especially well in backtests (though they work pretty well for synthetic asset mean reversion). This suggests smoothing is not the way to go.

    There are two solutions. If we can get zero negative costs we don't need to smooth. Bear with me - I'll come back to that. Or, for a retail trader where costs don't scale in a non linear way with size it's probably just as good to trade in a binary way, using a threshold. Then we won't do the little buys or sells every day.

    The hard part comes we think about stop losses (unless we use a seperate stop loss rule as above). So it's probably sensible to have one (unless your MR system is dominated by a trend component on the same instrument that will do this job for you). Something like if abs(f) > y (where y is larger than x). Then we close our position. But when do we reopen it? The moment f dips below y? Or do we wait until f is in the range -x to +x again, so it looks like the system is in a new equilibrium? Again this introduces a path dependence.

    Execution is different for these kind of systems. Since our position depends very directly on price (indirectly if we're smoothing; very directly in a binary system), and since we're usually (except for stop losses) buying low and selling high we can use passive limit orders exclusively, and not worry about chasing the market to get a fill, as I would do for my normal system if my initial limit order failed. Hence we can get those negative execution costs (assuming the commission doesn't wipe out the positive slippage).

    Except when we hit a stop loss; then we need to close immediately and cross the spread. This differentation of order types is something I don't currently have in my slower system. It also means you need a backtesting framework that can cope with this. If we introduce path dependence, we also need a new backtester.

    Things that are the same; we can size positions properly according to volatility. If we're holding for shorter periods of time it's probably not necessary to adjust them if vol changes during the life of a trade. Diversification would be good across instruments. It would probably be hard to diversify forecasts. We'd need to run multiple strategies, one for each kind of rule. We'd need something smart to net trades where possible.

    Hope this helps.

    #416     Jun 8, 2016
  7. #417     Jun 14, 2016
    AvantGarde likes this.
  8. isotope1


    Hi GAT,

    I just wanted to check that you ignore the inherent drift in panama stitching when calculating EWMACs, as it's not significant over the longest lookback? (corn picture for fun)

    download (3).png
    #418     Jun 15, 2016
  9. To be clear there is no 'inherent drift' in panama - that implies panama is "wrong" - it's just that if you compare two different roll methods they won't give you exactly the same method. No roll method is perfectly "correct" and the simplicity of panama is what I like; though I'll probably introduce other methods in pysystemtrade when I get round to implementing it.

    But yes, you'd get a small difference in the average size of your forecast on the longest lookbacks using these two methods.

    #419     Jun 15, 2016
  10. isotope1


    How likely is it that you hit your volatility target in the long term?

    On my single instrument model (Corn), no matter what I do, my annual returns volatility works out about 10%, when the target is 25%.

    (Sharpe 0.27 without slippage, 0.08 with).

    I'm wondering if this is a bug in my code.
    #420     Jun 24, 2016