Quantopian's community platform is shutting down. Please read this post for more information and download your code.
Back to Community
Changes Coming to the Default Slippage Model

In the coming weeks we will be changing the default slippage model used to simulate the price at which orders are filled in the live market. Slippage is the difference between the price you see in the market when you place an order and the fill price you actually get. The new model is more accurate and more consistent with the tools we use internally to evaluate algorithms for capital allocations. This model will be the new default in all parts of the Quantopian platform, including backtesting, paper trading, and the upcoming new contest format.

Previously, the default model (the VolumeShareSlippage model) applied slippage to your orders as a function of two input parameters, a price impact constant and a participation volume limit. This model is conceptually sound, but research on our own live trading data has shown it to systematically underestimate slippage in many important cases. This makes some high-turnover strategies look better in simulation than we see in actual trading. For this reason we will be replacing our default model with a new FixedBasisPointsSlippage model. This model takes two input parameters: the impact to apply as a percent of the dollar amount of an order placed and the volume limit which determines how many shares of an order can be filled each minute. Our default will be 5 basis points (0.05%) charged on the order amount in dollars. In this new model, orders will fill at a price that is 0.05% worse than the close price of the minute following the order. Buys will fill at a price that is 0.05% higher than the close of the next minute, while sells will fill at a price that is 0.05% lower. The default volume limit will be 10% of the volume in each minute. An order can fill over multiple minute bars, but will be capped at 10% of the volume each minute. Attached is an implementation of this slippage model that you can use in your algorithms before we change the default.

This model will be more accurate than the old one, particularly for stocks in the QTradableStocksUS. Your backtests will be more in line with our evaluation process, and more predictive of their real-world behavior.

This 5bps fixed slippage model implicitly makes a number of simplifying assumptions, including the following:

  • Slippage doesn't vary with time of day. (In reality, slippage is typically worse when spreads are widest, in the first 30 minutes of the day.)
  • Slippage is the same in all stocks. (In reality, slippage is typically more severe in illiquid, thinly traded stocks.)
  • Slippage doesn't vary with participation rate. (In reality, slippage is more severe with high participation rates. Quantopian uses execution tactics and order types that are designed to spread your order out over time, lowering the participation rate and decreasing slippage costs.)

We are actively working on addressing each of these aspects in a next generation market impact model that is still in the research and validation phase.

Disclaimer

The material on this website is provided for informational purposes only and does not constitute an offer to sell, a solicitation to buy, or a recommendation or endorsement for any security or strategy, nor does it constitute an offer to provide investment advisory services by Quantopian. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. No information contained herein should be regarded as a suggestion to engage in or refrain from any investment-related course of action as none of Quantopian nor any of its affiliates is undertaking to provide investment advice, act as an adviser to any plan or entity subject to the Employee Retirement Income Security Act of 1974, as amended, individual retirement account or individual retirement annuity, or give advice in a fiduciary capacity with respect to the materials presented herein. If you are an individual retirement or other investor, contact your financial advisor or other fiduciary unrelated to Quantopian about whether any given investment idea, strategy, product or service described herein may be appropriate for your circumstances. All investments involve risk, including loss of principal. Quantopian makes no guarantees as to the accuracy or completeness of the views expressed in the website. The views are subject to change, and may have become unreliable for various reasons, including changes in market conditions or economic circumstances.

14 responses

Hi Jessica, anything that makes things more realistic is positive!

1) What about strategies that supply liquidity, that go against the direction of the market -- they should get beneficial slippage? For example, short term mean reversion.

2) Lets say I have a long-short algorithm with modest daily turnover of 30%, in the middle of the competition range. This will therefore turnover 76 times per year. This is an annual drag of about 4% before fees. This is a lot. Any suggestions to limit this?

Thanks Jess -

To your list of shortcomings, I'd add:

  1. "Fill Timing" described on https://blog.quantopian.com/accurate-slippage-model-comparing-real-simulated-transaction-costs/.
  2. The lack of fills for bars with zero volume.

Perhaps these will fall out of the analysis as inconsequential, but it is always good to start with a complete list, and then winnow it down.

@ Burrito Dan -

I've started dinking around with the Optimize API MaxTurnover constraint, in an attempt to resuscitate my algo that has been mortally wounded by the new slippage model.

@Dan - You're correct, this model doesn't give you credit for supplying liquidity even if you'd expect your strategy to do so. I think this is a conservative, but realistic assumption for the contest for the time being. I'll double check the market impact model our trading team has been developing, but I don't think I've seen any proposal where we'd model making money on slippage.

On the turnover back of the envelope calculations - I think this really gets to the heart of the issue, and calls out a guidance challenge from our side with the allowable turnover range. From a trading cost perspective, I don't actually think 30% daily t/o would be considered 'moderate' at least in isolation from knowing the expected return. Like you showed, 30% turnover creates a sizable drag your strategy would need to overcome in risk adjusted returns (tall ask!). This might argue for us setting a tighter range of allowable turnover in order to provide narrower guidance, on the other hand, where possible we've tried to leave the field as open as possible in order to allow for someone who actually does create a strategy that can make money at higher turnover levels.

With respect to tools to mitigate turnover, I think Grant's right that the proper way to do this really is to have some type of alpha forecast (quality of prediction / expected return per trade) and to then optimize for alpha with a turnover constraint or penalty function. At a more fundamental level though, the 'holy grail' if you will is to figure out which trades you expect to clear costs and only do those - so good luck with that, I know it is tricky :)

Thank you, that's very clear. I've had some success reducing the frequency of my strategy using downsample('month_start') on the alpha signal. The new tearsheet create_event_returns_tear_sheet was very useful indeed.

I have to wonder if the Optimize API with its single call and the MaximizeAlpha objective may result in a lot of churn. Basically, some sort of smoothing/averaging over an appropriately sized trailing window can be done (the term 'bootstrapping' is sometimes applied). I haven't done this yet with the Optimize API, but with the new slippage model, I think it will help. Smoothing alpha factors within Pipeline may help, too (I have done this).

Unfortunately, as I understand, the Optimize API can't be run within Pipeline (correct?), which would seem to be the better way of doing things. However, CVXPY can be run in Pipeline, so rolling your own optimization is a possibility.

There's also the potential of running the Optimize API repeatedly from within before_trading_start but outside of Pipeline. Presumably, it'll work there.

The other thought is that optimization would seem to be best applied as a little nudge versus a shove. So, if the Optimize API is inducing large rotations of the portfolio vector in its N-dimensional space, then it is probably not being used appropriately. In other words, the combined alpha vector supplied to the Optimize API should just be tweaked; if the Optimize API completely re-jiggers it, then potentially something is amiss.

You could run the optimizer with just the sizing constraints and compare the achieved Alpha with the Alpha achieved with the optimizer with all the competition constraints. This would give you a sense of how constraining the competition rules are: how much it degrades your Alpha. By Alpha I mean the weights of each chosen position times the Alpha of each position

@ Burrito Dan -

Thanks for the downsample tip. Is there an example of its usage (and perhaps a bit more information on what it does)? The help page is kinda opaque:

downsample(frequency)

Make a term that computes from self at lower-than-daily frequency.  
Parameters:   frequency ({'year_start', 'quarter_start', 'month_start', 'week_start'}) --  

A string indicating desired sampling dates:  

    'year_start' -> first trading day of each year  
    'quarter_start' -> first trading day of January, April, July, October  
    'month_start' -> first trading day of each month  
    'week_start' -> first trading_day of each week

One curiosity is if downsample has an anti-aliasing filter, or if it is a pure decimation (e.g. see https://docs.scipy.org/doc/scipy/reference/generated/scipy.signal.decimate.html).

@ Jess -

I posed a question regarding the use of the Optimize API MaxTurnover constraint. Is it supported?

It just runs the pipeline every day, but then throws away everything apart from the value from the first day of the week/month/etc. It’s designed to stop your signal changing, so the only trades between samples will be the optimiser rebalancing your positions to stay within the constraints.

Hmm? If one is trading weekly/monthly then the alpha factor should be filtered/smoothed on that time scale, I would think. For example, for weekly trading, the alpha factor could still be computed daily, but the last week's mean would be used, rather than just grabbing the most recent point.

Also, if the signal is weekly/monthly, then why run the optimizer and order daily (unless the trailing average is updated daily)?

I think the goal is to minimise trading costs while staying within the constraints (e.g. position concentration, sector neutral, etc). Smoothing the signal with a moving average would probably cause more trades, and increase the lag. However, you do need to run the optimiser, as your positions will have moved, and if left too long, will break the constraints, but these will be small rebalancing trades.

I guess it depends on the signal. If the signal is based on an event, then I suppose the problem would be broken up:

  • When event occurs, profit from it by adjusting the portfolio.
  • Otherwise, adjust the portfolio to avoid risk.

If the profit does not come from discrete events, my thinking is that order_optimal_portfolio should be run every day with a fresh alpha vector (in my framework, I use pipeline_data.combined_alpha). If the algo is based on signals from pipeline, the highest frequency sampling rate is daily, so if combined_alpha is continuous in time, then re-compute it every day and adjust the portfolio daily, taking an itsy-bitsy profit every day (on average). So if one is going to call order_optimal_portfolio daily then rather than using downsample the combined_alpha should be constructed such that it varies slowly (i.e. it doesn't have a bunch of noise at a frequency higher than 1/(1 day)). In the lingo of signal processing, the combined_alpha needs to be filtered on an appropriate time scale. It basically amounts to a low-pass filter after the ALPHA COMBINATION step in the flowchart on https://blog.quantopian.com/a-professional-quant-equity-workflow/.

I'm wondering what happens if one does an equal-weight of QTradableStocksUS and updates daily with order_optimal_portfolio using the new contest constraints (but without a constraint on turnover) and the new slippage model? This might be revealing. I'm thinking that the optimizer will cause a lot of thrashing about and burn money on trading expenses.

What slippage and commission models will be used in the upcoming Contest 37? Is it as follows?

    set_commission(commission.PerShare(cost=0.001, min_trade_cost=0))  
    set_slippage(VolumeShareSlippage(volume_limit=0.025, price_impact=0.1))  

Hey everyone, we updated the default slippage model to the 5bps fixed slippage model today. As a reminder, this is also the slippage model used in Contest 38, and will be the model that's used in the new contest format.

Disclaimer

The material on this website is provided for informational purposes only and does not constitute an offer to sell, a solicitation to buy, or a recommendation or endorsement for any security or strategy, nor does it constitute an offer to provide investment advisory services by Quantopian. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. No information contained herein should be regarded as a suggestion to engage in or refrain from any investment-related course of action as none of Quantopian nor any of its affiliates is undertaking to provide investment advice, act as an adviser to any plan or entity subject to the Employee Retirement Income Security Act of 1974, as amended, individual retirement account or individual retirement annuity, or give advice in a fiduciary capacity with respect to the materials presented herein. If you are an individual retirement or other investor, contact your financial advisor or other fiduciary unrelated to Quantopian about whether any given investment idea, strategy, product or service described herein may be appropriate for your circumstances. All investments involve risk, including loss of principal. Quantopian makes no guarantees as to the accuracy or completeness of the views expressed in the website. The views are subject to change, and may have become unreliable for various reasons, including changes in market conditions or economic circumstances.

What is the explicit equivalent of

    set_slippage(slippage.FixedBasisPointsSlippage())  

in terms of volume_limit and price_impact as discussed in Jessica's post?

"volume limit will be 10% of the volume in each minute"
"orders will fill at a price that is 0.05% worse"

Not this?

    set_slippage(slippage.VolumeShareSlippage(volume_limit = 0.10, price_impact = 0.05))