I think that there are so many variables… you give 5 people $100,000 to trade the same stock on the same day and there will be a discrepency in the average price per share. Give 10 traders different amounts of capital between $10,000 and $300,000 and the difference will be even greater.
So scientifically arriving at one number that satisifes everyone is impossible. I used to trade for rebate credits at a prop shop so I would fiddle with a stock all day and technically have the opposite of slippage letting them come to me.
I think Marco’s variable slippage is better than simply basing it on market cap and using an average volume - be it entry or exit - coupled with an average of the daily high and low - is a fair way to do it. If I was building it solely for me - I might do it differently - but we are doing it for our subs so I am happy.
Steve, the variable slippage applies both to buys/sells. If a model holds up using variable slippage, it simply means that the returns are realistic with a “reasonable” $ amount. Has nothing to do with # subs, that’s next.
The max $ amount by ALL subs that a model can support without causing too much friction needs to be estimated. The designer needs to estimate this to protect his model against over-subscription. The subscriber to decide if the investment amount is too much. This one is trickier because there are more variables: #subs, #positions, avg amount per sub, rebalance frequency, and turnover.
Please note that we need everyone to sort of fill in the blanks otherwise we open ourselves up for problems down the road. All we can do is give you numbers/stats to help you figure out if market friction will destroy a model:
1- setup a framework where a simulation is realistic for at least one “average” investor in terms of slippage
2- give you a a statistic that can help calculate the max # subs that the model will support
I think variable slippage (possibly adjusting it further as Brian suggests) solves (1). For (2) I think the avg $ amount traded of bottom 20% is adequate.
To my mind, a more important question is what is the profit per trade rather than turnover, when it comes to slippage. Of course, the high turnover generally goes with a lower profit per trade (percentage) but this is not always the case.
There is no easy answer. I consider the portfolio to be somewhat “experimental”, and that is why there are two versions, one which restricts to stocks larger than $200m. While the backtest gives this a lower annualised return, one might find the lower slippage more than compensates in real life for this shortfall.
I have also put in a lower turnover strategy which I expect to be more realistic.
To be honest though, I am waiting to see how this new slippage implementation is going to work out, because I expect I am going to reorganise those portfolios.
OK Marco - I agree with almost everything you said. Perhaps I was jumbling $Volume and slippage although the two are indirectly related. But let’s take a look at this point a little more carefully:
“The max $ amount by ALL subs that a model can support without causing too much friction needs to be estimated. The designer needs to estimate this to protect his model against over-subscription. The subscriber to decide if the investment amount is too much. This one is trickier because there are more variables: #subs, #positions, avg amount per sub, rebalance frequency, and turnover.”
The model provider already knows the approximate $Volume at buy entry. It is not that much different than his buy rule filter (which he/she should have implemented). The model provider is generally pretty good about spelling out what his $Volume filter is so potential subscribers also know.
What is not known but the provider or potential subscriber should know is what the sell $Volume is. I have attached a spreadsheet with a small sample of GARP 100K buy and sell $volume - I didn’t process all as there are too many the transactions to process. What I found is there is absolutely no relationship between the two for individual stocks. You can see hundreds of % increases or decreases in $Volume between buy and sell. And depending on the system rules and stock liquidity, it is quite conceivable that a consistent decrease in $Volume could easily be seen from buy to sell.
So the question I have is whether or not there is a technical reason that makes it too difficult to implement the statistic on sell side instead of buy side.
After seeing Stittsville123’s list, I’ve got two questions which might might make a BIG difference to the discussion:
Can users do as Stittsville123 has done and use the trade list to calculate ADT?
Does Portfolio123 internally adjust volume to matach adjusted prices to calculate ADT?
Backgrouind to these questions.
Some other non-Portfolio123 databases I’ve used adjust the volume as well as the price after stock splits (so the ADT numbers can be calculated across stocks split dates using Excel) and other databases I’ve used do not back adjust volume for splits (so one can use average volume formulas in buy rules, but can’t use Excel to calculate ADT). Which approach does Portfolio123 take to volume adjustments.
I know Portfolio123 adjusts the price history to reflect changes in price due to stock splits (in order to correctly calculate profit and loss) and that the actual “historic” price on the day is not back adjusted for splits (so buy filters work properly and stocks with multiple splits don’t appear to be penny stocks in their early history), but does Portfolio123 adjust the “volume” to account for stocks splits?
The huge difference between the buy and sell dollar volume in Steve’s tables above is the very reason I always use a 60 day average for my Sims. I have been bit to frequently in the past using a 20 day average because a stock had a unusually high volume the week before the buy and the volume dried up when it was time to sell.
Using only a 10 day average for the calculations for the slippage in the Sims will only make that problem worse. When I use the 60 day average I have never had a problem selling a stock with a small and expected slippage. The market makers seem to be doing their job at the 60 day dollar volume level. I recommend that P123 uses a 60 day average for calculating the variable slippage.
I agree. The only way to make the 10 day average “safe” would be to look at two 10 day periods separated by something like 6 weeks. Something like the following formula:
Min( ADT(10,0 days offset), ADT(10,30 days offset)
Years ago when trading relatively illiquid stocks, I had a buy rule (not yet possible in P123) something like this:
Look at the most recent 50 trading days (about 2 and 1/2 months) and count the number of days when the trading volume was less than $50,000 (if I was taking a $5K position). If there were more than 5 days below the minimum, then don’t buy the stock no matter what how high its ADT number might be. Why? Because I wanted no more than a 10% risk I would be trying to sell on a day when I would be more than 10% of the volume. For a couple months after Christmas I would move the maximum number of low volume days up to 6 or 7 since there are typically a couple days in the holidays when volume is abnormally low.
Since I don’t trade those semi liquid stocks any more, Denny’s ADT(60) suggestion looks good to me. I definately know a single ADT(10) filter is not reliable for lower liquidity stocks.
I have never understood why filling in slippage in the portfolio is optional. The system knows the recommended price and when the buy is made and edited it knows the actual slippage. The system should calculate and fill it in. No work on the part of the user and no guessing on the value.
In fact your system may already contain a lot of real data on slippage if you examine the ports and can see the recommended buy price verses the actual as edited amount.
Steve still don’t follow. The variable slippage recalculates on the sell too. So the buy could pay little slippage in % but the sell a high one. All independent
Bill (bfinboca) has a good point! If a Sim is run using average of next Hi & Low then the Sim contains (but not necessarily kept) all of the data necessary to calculate the average slippage, the min and max slippage, and any other slippage stat we can dream up. Having a slippage stat attached to the summery page of every Sim would be helpful in the design of robust Sims.
Steve,
I vote against using the sell daily average. When we place a buy we have no way of knowing what the daily average will be when we need to sell. At the time of the buy, the best we can do is make sure that there is a high probability that there will be high enough volume to sell without moving the market more than the slippage we got when we placed the buy. In my experience, using a 60 day average does that. We can always (and should) check the volume when we sell and break the sell into smaller orders if the volume becomes to low.
All,
These discussions of the limits we “need” to place on R2G ports can get way too conservative when we start adding one limit onto another and another. Pretty soon there will be no more alpha in our R2G Ports and few people will be interested in subscribing to them when their own Ports are outperforming, although with fewer and less conservative limits. All we need is reasonable and prudent design of our Sims, tested for robustness, followed by clear disclosure of the assumptions, methods, and limits applied.
We already have to design around the price of the average of the next day’s hi & low, a slippage table that is greater than most all of my real trades, a daily amount that penalizes more than is realistic the smallest caps and lowest prices where the highest alpha is, and no use of the advantage of taking profits with a partial sale. When I add it all up and create Sims that meet all of the rules, I am left with performance that is 1/3 less than the Sims I have been successfully trading for years. I agree, we need to be conservative, but please, let’s not get carried away with it!
"I vote against using the sell daily average. When we place a buy we have no way of knowing what the daily average will be when we need to sell. "
Denny - precisely. This is why I want to see this stat on the sell side.
It is important for modellers when determining number of subscribers. Likewise, it is important for potential subscribers.
"At the time of the buy, the best we can do is make sure that there is a high probability that there will be high enough volume to sell without moving the market more than the slippage we got when we placed the buy. "
How do you know that without seeing the stats? Every model will have its own buy and sell rules. This is out of our control. Thus we can’t be sure the model isn’t buying into abnormal volume.
“In my experience, using a 60 day average does that. We can always (and should) check the volume when we sell and break the sell into smaller orders if the volume becomes to low.”
Well I don’t think that will work. You can give two different people the same system and I can guarantee one will make money and one will lose money The rules have to be precise.
Quite frankly, I’m not sure why there is so much resistance to what I am asking. The existing stat doesn’t add much if any value. The sell trade stat does. This stat does not affect the performance calculation so what’s the problem.
I think Marco and I both were still thinking on the slipping calculation discussed in this thread. My discussion was more toward the design of the Sim and the trading of the recommended stocks. I see you are trying to display the stats in a way that might be most valuable to a potential sub. For that I can see the value of having both the buy and sell amount displayed. Sorry about the confusion.
Thank you Denny! There is a lot of confusion around this slippage issue. In the beginning when I suggested displaying the (average) $volume on trade day I said that the sell day should be included or preferably displayed separately. They went on to display only the buy day (which kind of frustrated me.)
Using high low in the sims and portfolios to calculate slippage would only work if you aggregated thousands of trades. Marco could do that but individual portfolios probably would not have enough information unless I am missing something. Actual trades would be randomly distributed between the high and low for the day. A few trades averaged would be far away from the average of the day, statistically. Thousands of random trades minus the slippage would be statistically close to the mean and might possibly be statistically significant to within .01%, maybe.
My window trades at 11:00 are almost never going to be very close to the average of the high and low. The difference between the average of the high/low and my fill price won’t have too much to do with slippage but rather will depend more on how the market moves that day.
I think about it this way. The tools that we have to use at P123 enable us to get recommendations that have a positive gain 60 to 70% of the time. It follows then that it is probable that the stocks on average will go up on the first day, and that implies that on average the stocks go up during the day. Therefore the best price, on average, is early in the day. By running the Sims using the average between next day High & Low only implies that when you get a recommendation that the probabilities imply that you can buy the stocks, on average, at a lower price than the average of hi & low.
Therefore, using average of hi & low is a conservative way of running the Sim. That is backed up by the fact that most of the best Sims will have a higher performance using next open than using average of hi and low. At least my Sims do that.
Marco,
I would like to second Denny’s concerns about adding in conservative rules for slippage, commissions, etc. As it is, it was my understanding that the R2G portfolio returns were to be calculated using Next Close - which was to account for slippage that is now being captured elsewhere. This adds a double penalty to high turnover strategies.
Can you please confirm whether the R2G stats are still to be based on next close.
Steve, I agree the sell side stats are as important as the buy side, though I don’t see why they should be more important.
Let the subscriber run simulations using their own slippage numbers. I personally use avg of high and low without any slippage and my ports vs. simulated results match well enough.
The simulations would be run without giving the subscriber access to the details of the core trading system. ie. hide the buy/sell and ranking rules of the core trading system from the subscriber (or potential subscriber)
This concept could be carried out further by allowing the subscriber to change other input variables, and run their own simulations on the core system.
This way I would create and update my own portfolio of stocks based on my own input conditions.
A subscriber can always choose to use default input conditions if desired.
Denny I believe you when you say the current settings may be on the conservative side based on your experience. But I also believe you are probably a good , patient trader that finds the right time to get in/out. Someone who’s been trading for a while. And I also don’t think you are trading $2500/stock where an $8 commission is 0.3%.
So when you take into account multiple subscribers, who just want to get trades filled, average experience, and probably have lower amounts to invest per stock, do you think your slippage stats would be the norm?
I believe under promising and over delivering is what keeps customers. In any case I think the variable slippage is still getting the support. Or is it being voted down? The current implementation is the one described here . Is there another specific proposition or changes?
Don, portfolio returns are the out-of-sample returns. sim returns use whatever the designer picked (except prev. close which is not allowed) I’ll get back to you on that. I’m not sure the slippage is being taken out
The rules have to be precise.