Hi,

Thanks for sharing your findings and the code to impose your own limits, I'm sure other members will make use of it.

portfolio.cash is updated as each transaction is processed. Orders are converted to simulated transactions by passing them through a configurable slippage+commissions model. Orders placed in the handle_data invocation for bar T will be processed by the model in T+1. The default slippage model enforces a limit on the percentage of the T+1 bar that your order can take, and any part of the order that is not filled will be kept open and re-evaluated in the next bar. As a result, one order can result in multiple transactions, and an order's fill can lag the order itself by one or more bars.

More detail on slippage and commissions is available in our help: https://www.quantopian.com/help#ide-slippage

Thanks again,
fawce

I like the slippage and commissions model, but from your description it would seem to be quite hard to determine what the portfolio approximate cash position is - transactions in flight are not available?

I suppose an additional check would be to cap trades to volume, with knowledge of the slippage model, so that an order is not split. This would reduce the error.

The problem with an unrestricted overdraft is that it effectively gives you leverage, which distorts returns. Is there any chance of putting an "available cash" circuit breaker into the simulator algorithm?

John,

Great points all. We could definitely make current open orders available via the API. The data is sitting there in memory, we just haven't exposed it to your algorithm.

Restricting borrowing on cash is also possible. I lean toward giving the algorithm access to the data and leaving responsibility for such controls to the algorithm, but I could be convinced of the convenience of a set_leverage_limit function.

Both of these changes would be done in Zipline and then exposed to Quantopian. Up for hacking on Zipline with us?

thanks,
fawce

Hello John,

In your post above, you state "that order raises an event and that processing this event is deferred until after running handle_data." An order doesn't actually get processed until the next market event (tic) for the associated security. So, for example, if you place an order during the last trading minute of a day, you should see it get fulfilled during the opening minute of the market the next day (assuming that the security is highly liquid). The implication for thinly traded securities is that even in the middle of the trading day, an order submitted at time T won't necessarily be fulfilled at time T+1 minute (unless the backtester doesn't run as it used to).

Fawce...I'm not sure that the distinction between order submission and order fulfillment is ever explained in the Help & API Docs. Might be worth a write-up and example.

Grant

Adding a volume limit, so as to avoid unexpectedly trading over several ticks:

  # cap shares to 0.25 of volume, in order to prevent splitting into multiple orders  
  volume = data[security].volume  
  max_vol = 0.25 * volume  
  shares = min(max_vol, shares)  

This nearly works to prevent overdraft against minute data. The final step is to only trade alternate ticks.

def initialize(context):  
  ...  
  context.is_odd_tick = True

def handle_data(context, data):  
  context.is_odd_tick = not context.is_odd_tick  
  if context.is_odd_tick:  
    return  

With these adjustments my strategy runs against minute data without suffering a significant overdraft.