Thanks GAT for the insights! Very interesting to see how things work on the buy side. A few follow-up questions if you don't mind: 1) Nice example! Now i remember I gave up and crossed the spread in a roll contract after 2 hours, because no one cares about the 200 bucks I could potentially save, and I wanted to go home early 3) - "execute this order at the best price you can, irrespective of what happens next, within this time frame (by the close of the market today)" I understand that funds like AHL has a lot of money , and hence 'big' positions, but how 'gradual' do you normally change your positions? For 'small' sizes, I think you can essentially 'trade at mid' at the opening auction/closing auction? This makes sense to me if you don't have intraday opinion/don't care enough about a day's move. If your size is big enough for market impact to be an issue, of course you need alternative solutions. I imagine options include something like execution algo on screen/block request OTC/ BTIC markets? - 'the difference between 'signal price' and 'mid price when execution begins' is a source only of small random noise, and not of bias' This makes sense. I'm wondering if you take into account 'slippage' per contract in signal generation? I imagine it's probably insignificant for 'slow' systems. This leads me to the following question. - Do you measure/predict/backtest % return per trade? If so, what are some benchmark numbers? From my understanding, this is not a typical statistic CTAs look at, and you are trying to maximise Sharp given a target annualised vol (i.e. max return for fixed risk)? Please correct me if I'm wrong! I mention this because I believe % return/trade is the stat which dictates how much slippage you can 'afford', and not necessarily how 'fast/slow' you trade, although the two are obviously related. An unrealistic example: you have a system which trades 'slow' (say holding period 6 months) by buying and holding 1000 uncorrelated stocks, Sharpe would be off the roof even if % return/trade was low, and high slippage would essentially kill the system.
Yup 100% agree what I'm saying is pretty much irrelevant for small sizes, only jumped in when I see discussions on execution algos
Can't say that easily, I record the initial and fill times and all changes in the state of the order (passive\aggressive) but not the reason for the change. (Actually I do record it, but only in the unstructured free-text log-table and it's a real pain to extract it from there). I can upper-bound it though, by counting how many orders ended up in the aggressive state and took more than the maximum passive time to execute - it's 12 out of 296, so yes not many.. Here's some more stats I can easily extract: 296 total orders (in about 9 months) 95 filled in Passive mode, all 95 made >=0$ compared to the worst side of the spread(no losers in passive mode) 201 filled in Agressive mode, 56 of which still made money compared to paying full spread (not sure how that happened, perhaps lucky price moves?) 31 orders took more than 10 min to fill: 3KTB 6 GBM 2 GE 4 N225M 1 NG 1 V2TX 6 ZT 11 151 orders took less than 1 minute to fill Yes, most of the time it will still be worth trading because (even though I reevaluate my forecasts in real-time) the system is mostly trend-following and crossing the spread will mostly happen when that trend continues away from me and I'm chasing it. It is possible though, that the price will be dancing around the point of buying and not buying that additional contract, but first when my system places an order and while it's active it considers it filled for the purpose of calculating my current position in this instrument., and second I have a "signal thresholding\buffering" which sort of runs position-sizing logic backwards from my current position (and that position counts active orders too) and outputs the theoretical signal which corresponds to my current position., and then I require the difference between that "signal of my current position" to be different by more than 30% of the average signal(10) from the current real-time signal to make a trade (oh, I really overthink things sometimes ). So basically yes, apart from bugs, the system will rarely want to cancel an order because of forecast change. Should I then always sit on my side of the spread unless the max timeout expires or the volume starts looking unfavorable ? - maybe.. But it needs experimentation on the PROD system and at least several months worth of data to be able to say if it makes things better.. Don't know, maybe I can try it on my paper system, first, though I would be relying on IB execution simulation.. - so you mean there's never a good reason to use market orders, and even if you just want a fast guaranteed fill it's still better to submit a limit order which crosses the spread but will not get out of it by a catastrophic amount? (e.g. if the spread is 110/112 and I want to buy at market, it's better to submit a limit order at, say 114, and I'll still most likely get a fill at 112, and if something goes wrong I get a partial fill at 112\113\114 but never worse than that)? - Sure, makes sense.. In fact, I'm thinking that at some point I'll add ICE-futures into the system, without paying for the real-time data (the only way they get that 200$\month is from my cold dead hands! )., which means I will have 15 minute delays for every bid\ask update and will have to deal with this somehow.. One simple approach could be to actually change nothing and keep using the same algo, and just pretend that I have a reeeally big internet latency from my provider. Or I could use some IB's algo orders, or just as you're proposing here, submit limit-orders just outside of the spread (towards a worse price from my perspective), but at least limiting the worst-case..
I've had similar thoughts about adding futures without real time data. Problem is, if your price is too far away from the current spread (which you can't see) the order will be rejected. Do IB have an order type which is just 'put in a limit at the current side eg buy at the offer, sell at the bid'? Because that would solve the problem. GAT
Depends on the contract. In an extreme case, we'd be liquidating a position over a few days. But normally it would take at least a week. No we didn't go near the auctions. With the size we were doing it was better to trade continously throughtout the day rather than drop a huge order in at the open or close. AHL used to trade OTC of course, but for future our attitude was that our algos (and human traders) were better than any kind of outsourced solution (bank algo, block trade). Of course we didn't take this for granted, but we would check by giving some of our flow to external providers and constantly running experiments to see if they could do better. Block trades make sense if the large marginal holders in a market are often doing different things, so you can genuinely exchange large blocks between parties with different axes. That's true of actively traded discretionary equities, but not so true of eg equity market neutral hedge funds with a similar kind of factor model. I'm not sure it's that true in futures where you have large CTA's mostly doing similar kinds of trade, mostly trading against smaller players who are doing the opposite. Not in signal generation per se, but in terms of designing the system. So what I do is calculate a risk adjusted total cost of trading (commission plus slippage), and that drives the decision about which speed of signals make it into the model for that instrument, basically how frequently I trade. You're right that we don't normally look at things on a 'per trade' basis. Of course I can measure the % return per trade, but it's not a key statistic. And I will measure the slippage and commission per trade, but that is then translated into annualised risk adjusted terms so it's now a Sharpe Ratio comparable with everything else. (For the 'fixed risk' I don't actually do that, but there is a longer discusison here) I think the key here is to look at the (risk adjusted) return per instrument, not on the entire system. So for example, suppose I can get a pre-cost SR of 0.4 trading any given instrument, and with diversification I can get that up to a SR of 1.0 (ie the diversification multiplier is 2.5). Now suppose I am willing to pay half my pre-cost SR in costs (which I'm not, that's much higher than I'd do, but for the sake of the maths....) . Well in theory I can easily pay 0.5 SR in costs, but of course I can't; I'd be losing 0.1 SR on each of my instruments. What I actually do is look at each instrument in turn, and from that make a decision on how much I can afford to pay in costs, and in this example I'd pay 0.2 SR in costs leaving 0.2 SR net per instrument. So my after cost SR would actually be 2.5 * 0.2 = 0.5 and I'd be paying 0.5 SR in costs on the entire system. GAT
Thanks for sharing your stats! Honestly you are probably already spending more time than you should on your algo with your trade frequency. '201 filled in Agressive mode, 56 of which still made money compared to paying full spread (not sure how that happened, perhaps lucky price moves?)' From my understanding of your algo, this only happens when you decide to cross the spread straight away instead of putting in a passive limit order (due to favourable conditions), and by the time your aggressive order arrives, the market has already moved in your favour and you got filled at a better price than you expected. This is happening quite often, and I think this suggests your speed is slow. Probably not worth trying to improve your algo further, as I think most 'clever' ideas will simply not work due to latency. And yes personally I'll never use market orders, I see them as limit orders with 0/infinity price, which look very dangerous to me. I've also seen MMs deliberately going wide straight after open in normally tightly-quoted products (admittedly I've done this myself, and it has worked more often than you think....) , just to catch potential market orders. Yes they are predatory......
Again thanks for the insights GAT. 1) Yup I do believe your in-house algos will do better than outsourced solutions. Even if someone has a slightly better algo, I doubt it's worth what they charge you for. 2) Interesting to see ultimately who's holding opposite positions against CTAs. I have no idea, but my guess is that there are enough random players out there to absorb the flow over a long enough time? 3) Yes I agree with looking at SR/instruments makes the most sense. I'm not sure if this can always be calculated/estimated though, depending on how your 'signal' is generated. E.g. Say I believe there is mean-reversion in ES/NQ spread, but splitting the SR in half may not really make sense.