Matt, given lack of satisfactory answer from Tradeintegration I am posting this question here hoping it gets some attention.
System: VT26
Trade: 1/22/10 6:51 BUY1 @JYH0 0.011090 1/22 7:26 0.011095 n/a $62
The C2 hypothetical results show a Buy @JYHO at 0.011090 and a Sell @JYHO at 0.011095. My live results in OEC show 0.011095 for both entry and exit (hence $0 profit). This is a 5 tick difference ($12.5x5=$62), not a minor difference.
There is a time stamp difference between ITM and “Autotrade performance results”. ITM showed 11:51:34 and 12:26:55 UTC whereas the fills in “Autotrade performance results” showed 11:51:37 (3 seconds late) and 12:26:59 (4 seconds late). Could this be the reason of the slippage? According to Tradeintegration the answer is ‘no’ as my fills were “perfect” and executed “at the same second”. Well… if my fills were perfect then the C2 hypothetical profit of $62 should be corrected.
Looking forward to your reply.
Ah, this is a very interesting problem. But it’s not what you think. Let me explain…
As you know, when people AutoTrade a system, C2 receives the real-life brokerage execution prices via electronic messages from the brokers. We then change the C2 hypothetical fill price (displayed on the C2 system page) to reflect the volume-weighted average real-life fill price of all AutoTraders. In other words, C2 automatically displays the real-life prices received by real-life traders.
We did that successfully in this case, but @JY is a weird symbol. Weird because it has six – count em, six – significant decimal places (!)
The problem is that, when C2 calculated the VWAP of real-life fills, it rounded to 0.01109 (five significant digits). But while the VWAP calculations rounded to five digits, the C2 display routines then subsequently rounded that back out to six digits. So the 0.01109 average fill price displayed on the C2 system page as a 0.011090 average fill price. (The real, accurate average fill price should have been 0.011095 – or maybe 0.011094 – I need to recalculate to be sure.)
Thus the problem here wasn’t one of slippage caused by late executions; it was instead a rounding/significant-digit issue within the real-life VWAP-calculating routines. I’ll try to get that fixed shortly. Thanks for pointing it out.
