Quantopian's community platform is shutting down. Please read this post for more information and download your code.
Back to Community
delayed order fill for SPY - why?

Unless I've made a mistake, this algorithm should submit orders for SPY and BND at 9:31. I'd expect both to be filled at 9:32. However, only BND is filled immediately. SPY is filled at 9:35 (see below), even though lots of volume is reported for SPY over the intervening minutes. Any idea what's going on?

--Grant

2014-02-18 09:32:00     BND     BUY     100     $81.10  $8,110.00  
2014-02-18 09:32:00     BND     BUY     100     $81.10  $8,110.00  
2014-02-18 09:35:00     SPY     BUY     100     $184.20     $18,420.00  
2014-02-18 09:35:00     SPY     BUY     100     $184.20     $18,420.00  
2014-02-19 15:22:00     SPY     SELL    -100    $183.31     ($18,331.20)  
2014-02-19 15:22:00     SPY     SELL    -100    $183.31     ($18,331.20)  
11 responses

Was it because they were limit orders based upon current_price?

Current_price, if it is like "last" used by some software, that could have been a bid or an ask, or something in between. So, if the current_price was a bid, then adding a penny might not force the buy (at the ask) you were hoping. Maybe get the ask price instead of current, and penny that up to hit it?

At least that's my speculation.

Thanks Ken,

Yes, the behavior is likely due to the use of limit orders. I was in a rush when I posted, and it just slipped my mind that I'd coded limit orders. Everything is probably working just fine...I'll need to write out more data to the log to confirm.

Cheers,

Grant

Perhaps someone can help interpret the algo behavior (see next post for algo). It submits two limit orders, with limits:

2014-02-18 PRINT orders submitted with limits:  
2014-02-18 PRINT SPY: 184.24  
2014-02-18 PRINT BND: 81.13  

Then, it appears that the BND order is filled at a wrong price of 81.1:

2014-02-18 PRINT 2014-02-18 14:32:00+00:00  
2014-02-18 PRINT SPY: 184.28  
2014-02-18 PRINT BND: 81.1  
2014-02-18 PRINT order fills:  
2014-02-18 PRINT SPY: 0  
2014-02-18 PRINT BND: 100  

And SPY is filled at a wrong price of 184.20:

2014-02-18 PRINT 2014-02-18 14:35:00+00:00  
2014-02-18 PRINT SPY: 184.2  
2014-02-18 PRINT BND: 81.12  
2014-02-18 PRINT order fills:  
2014-02-18 PRINT SPY: 100  

Am I missing something? Or is this a bug?

Grant

Backtest for my post immediately above. --Grant

You got a better price than your limit (think: maximum you'd be willing to pay).
Nothing wrong with that, including in real life :) That's the way limit orders work.

Thanks Ken,

Something still doesn't seem right. According to Interactive Brokers:

A Limit order is an order to buy or sell at a specified price or
better. The Limit order ensures that if the order fills, it will not
fill at a price less favorable than your limit price, but it does not
guarantee a fill.

So, as you point out, I think that the attached backtest is sorta working as one would expect per the IB definition. The problem that still needs to be resolved is that the backtester should not be filling orders within the bar, but rather the limit order should be converted to a market order to be filled at the closing price of the next bar. So, I'm confused that the order status shows the filling at the prior closing (although this would model live trading better, it would seem).

Grant


2014-02-18PRINT2014-02-18 14:31:00+00:00
2014-02-18PRINTSPY: 184.23
2014-02-18PRINTBND: 81.12
2014-02-18PRINTorder fills:
2014-02-18PRINTorders submitted with limits:
2014-02-18PRINTSPY: 184.24
2014-02-18PRINTBND: 81.13
2014-02-18PRINT2014-02-18 14:32:00+00:00
2014-02-18PRINTSPY: 184.28
2014-02-18PRINTBND: 81.1
2014-02-18PRINTorder fills:
2014-02-18PRINTSPY: 0
2014-02-18PRINTBND: 100
2014-02-18PRINT2014-02-18 14:33:00+00:00
2014-02-18PRINTSPY: 184.29
2014-02-18PRINTBND: 81.12
2014-02-18PRINTorder fills:
2014-02-18PRINTSPY: 0
2014-02-18PRINTBND: 100
2014-02-18PRINT2014-02-18 14:34:00+00:00
2014-02-18PRINTSPY: 184.25
2014-02-18PRINTBND: 81.12
2014-02-18PRINTorder fills:
2014-02-18PRINTSPY: 0
2014-02-18PRINTBND: 100
2014-02-18PRINT2014-02-18 14:35:00+00:00
2014-02-18PRINTSPY: 184.2
2014-02-18PRINTBND: 81.12
2014-02-18PRINTorder fills:
2014-02-18PRINTSPY: 100

Perhaps due to the slippage model?

I am using:

set_slippage(slippage.FixedSlippage(spread=0.00))  

This should disable the slippage model entirely, if I understand it correctly.

In any case, it is not slippage, but rather something fundamental that I'm missing, since I thought that once a trigger level is reached, a limit order will effectively convert to a market order (I say "effectively" since I don't think another order is generated automatically). Then, the market order will be filled according to the usual backtester filling--upon the next call to handle_data. But in the example I provide, the order is showing filled before the next call.

Grant

Hi Grant, why do you say "since I thought that once a trigger level is reached, a limit order will effectively convert to a market order" ?
This is what happens to a stop order, not to a limit order. In real trading a limit order just stays in the order book until it becomes the best offer and is joined
by a market order and therefore executed (at a price not exceeding the limit). If the order is not filled it stays in the book until is cancelled (for GTC orders) or expires (e.g. at the end of the trading day for DAY orders).

Thanks Leopoldo,

Yes, I didn't describe a limit order correctly (still learning). Any ideas on how to verify that limit orders handled in the backtester correctly model actual limit orders in the market?

Grant

I do not see any particular difficulty in modelling the limit orders in the market, so I just trust the backtester. (Things could be different for stop orders, but that is another story...)

In any case, to check the correctness of the backtester I would use the same technique that you used: print statements to make a log of the orders. In fact the example you posted is enough to verify that the two limit orders issued are correctly handled.