Beat the Market: An Effective Intraday Momentum Strategy for S&P500 ETF (SPY)

Based on the provided Python code, there are a few potential issues that might be causing problems:

1. The self._vwap is initialized but never updated with new data. You might want to update it in the consolidate method.

2. The long_stop_price is calculated but never used. If it's supposed to be a stop price for long positions, you might want to implement logic that uses this value to exit long positions.

3. The self._deviation indicator is updated with the entire bar object, but it might be expecting a specific value like bar.close. Make sure to pass the correct data to the indicator's update method.

4. The consolidate method doesn't handle the case when self._vol is not ready or self.previous_close is None. You might want to add logic to handle these cases.

5. The end_of_day method is scheduled to be called every day before the market close, but it's not implemented in the provided code. You should implement this method if it's necessary for your strategy.

Remember, these are just potential issues based on the provided code. The actual issues might be different depending on the rest of your code and your specific strategy.

Here is the relevant part of the code with the potential issues:

def consolidate(self, sender, bar):
    current_date = bar.end_time.date()
    self.bars.append(bar)
    if current_date != self.previous_date:
        self.previous_date = current_date
        self.open_price = bar.open
        self.previous_close = self.bars[-2].close if len(self.bars) == 2 else None
    self._deviation.update(bar)
    if not self._vol.is_ready or not self.previous_close:
        return
    upper_band = (max(self.open_price, self.previous_close) * (1 + self._deviation.value))
    lower_band = (min(self.open_price, self.previous_close) * (1 - self._deviation.value))
    vwap_price = self._vwap.current.value
    long_stop_price = np.max([vwap_price, upper_band])

Please review your code and make sure everything is implemented correctly. If you're still having issues, you might want to consider asking for help on the QuantConnect forum.

The attached backtest provides a way to implement the strategy across a portfolio of assets

Based on the provided Python code, there are a few potential issues that might be causing problems:

1. The security._vwap is initialized but never updated with new data. You might want to update it in the consolidate_handler method.

2. The long_stop_price and short_stop_price are calculated but never used. If they're supposed to be stop prices for long and short positions, you might want to implement logic that uses these values to exit positions.

3. The security._deviation indicator is updated with the entire bar object, but it might be expecting a specific value like bar.close. Make sure to pass the correct data to the indicator's update method.

4. The consolidate_handler method doesn't handle the case when security._vol is not ready, security._previous_close is None, or security._deviation is not ready. You might want to add logic to handle these cases.

5. The end_of_day method is scheduled to be called every day before the market close, but it's not implemented in the provided code. You should implement this method if it's necessary for your strategy.

6. The vol_target variable is defined but never used. If it's supposed to be a target for position sizing, you might want to implement logic that uses this value to size positions.

Remember, these are just potential issues based on the provided code. The actual issues might be different depending on the rest of your code and your specific strategy.

Here is the relevant part of the code with the potential issues:

def consolidate_handler(self, bar):
    symbol = bar.symbol
    security = self.securities[symbol]
    current_date = bar.end_time.date()
    security._bars.append(bar)
    if current_date != security._previous_date:
        security._previous_date = current_date
        security._open_price = bar.open
        security._previous_close = security._bars[-2].close if len(security._bars) == 2 else None
    security._deviation.update(bar)
    if not security._vol.is_ready or not security._previous_close or not security._deviation.ready:
        return
    upper_band = (max(security._open_price, security._previous_close) * (1 + security._deviation.value))
    lower_band = (min(security._open_price, security._previous_close) * (1 - security._deviation.value))
    vwap_price = security._vwap.current.value
    long_stop_price = np.max([vwap_price, upper_band])
    short_stop_price = np.min([vwap_price, lower_band])
    is_up_trend = bar.close > security._vwap.current.value
    is_down_trend = bar.close < security._vwap.current.value
    is_long = self.portfolio[symbol].is_long
    is_short = self.portfolio[symbol].is_short
    is_long_stopped_out = is_long and bar.close <= long_stop_price
    is_short_stopped_out = is_short and bar.close >= short_stop_price
    is_not_last_trade_date = security._last_trade_date != current_date
    vol_target = 0.02

Please review your code and make sure everything is implemented correctly. If you're still having issues, you might want to consider asking for help on the QuantConnect forum.

Hi Flame,

I know it's been a while since you posted this. I have taken a shot at this algorithm and compared your QuantConnect implementation with the authors python implementation that they gratefully shared:

I compared trade by trade on a couple days. From what I can tell your algo runs as intended, but at QuantConnect the real bid/ask spread is considered compared to the authors backtest, which is a drag on the results. I tried to simulate “no spread” on QuantConnect and got almost the same performance as in the paper as a result.
Speaking of almost, the daily open/close prices of SPY seem to deviate a couple cents between different data sources which leads to trades firing a little different.

I would be glad to connect to talk about this algo, it's been a while, have people around here successfully traded with it? The authors added a section to their paper that an implementation with futures works as well, for example.

Best Regards
Nico

Hi Nico

Sorry I meant to reply last weekend but ended up losing track of time. I haven't been trading this live, mainly because I prefer to trade strategies over a portfolio of assets, and I'm not sure that this held up as well as hoped in other asset classes from memory, although it was a while ago and I'm sure more in-depth research would be needed. Happy to connect to discuss further!

Best

Flame

Dear Nicolai ten Brinke,

You stated: "I have tested it on a portfolio as well and my results were that it was consistently very good only for SPY, QQQ and TSLA." Could you please specify the backtesting period you used?

I ask because I have live deployed this strategy, and frankly, its performance over the past six months has not been good, as shown in the image below:

You are welcome to add me on Discord to discuss the live deployment issues:
 discordapp.com/users/1313085859385315348

So, based on the Python code in the Colab they shared, there are a few problems IMO:

1. They use trade prices at the bar close for fill, this ignores both close/open price gaps and bid/ask spreads unlike QuantConnect.
2. They estimate real-life slippage to be around $0.001 by simulating sending orders few milliseconds before bar close and comparing fill price with opening price. I don't get how that helps, we can only get close bar price after the bar was closed, not milliseconds before that.
3. When calculating Sharpe ratio and drawdowns they use end of day portfolio values, ignoring intra-day volatility. I'm actually not sure if QuantConnect doesn't do this as well though. But at least drawdowns look legit to me in QuantConnect.
4. There is no margin check, with leverage as high as 4x you can get margin calls very easily and you do get them simulated in QuantConnect.
5. I don't know how they have chosen volatility target 0.02 and if it works for all securities.
6. Minor thing: they round number of shares, but they should floor this number instead to make sure it is within margin. Since they don't check margin, this passes in their code, but you can get order rejected if it is above margin requirement. QuantConnect reserves some cash to avoid this, but it gets you even closer to margin calls anyway.
7. Since they had it running in live, it would be very beneficial if they have shard actual slippage they've encountered in trading in their paper.

I've sent an email to authors with my questions. If I get any useful response, I will add a comment.

I've attached my implementation. It is a single-asset algorithm, I'm sure you can extend it on multiple assets easily, or just use Flame's algorithm.

These are results with mid-close-price order fills and no margin calls. 

Curiously, I noticed that in the custom fill model I don't have access to next bar's opening price, because that would be peeking into the future, however, standard fill model, apparently, can do that.

And here are results with proper order fills and margin calls. You can see how hard even this simulation hits the results. And this only based on historical data, now add to this network delays in real-time, which can be even worse because of this behavior: Delay on the first security order of the day in live trading by Yuri Lopukhov - QuantConnect.com

So we have to be very carefull when examining academic research papers which only use trade prices at the bar close for backtesting. At least for intraday strategies.

Thanks to Yuri and all others for coding and the clear words and all your observations.
 

I have tested first on the authors provided Colab Notebook and fully agree to Yuri's mentioned topics.

In addition I would like to add a few more strategy challenges, most important the amount of trades and brokerage slippage would eat your profit.

To be precise with a leverage of 1 = fair benchmark comparison you'll get a Sharpe Ratio of 0.399 and a PSR of 12.329%, so the risk-adjusted performance is fairly low. Second the Total fees of $27,317.98 (16.7 % of your return) and 6940 total orders suggest that transaction costs may be eating into returns. Next the low Alpha and Negative Information Ratio: Alpha of 0.022 and Information Ratio of -0.257 mean the strategy is not adding much value above the benchmark and may be slightly inefficient in its risk-taking.

And finally the Win Rate and Loss Rate: The 63% loss rate vs 37% win rate might raise concern for confidence in execution, even though your gains are bigger than your losses.

I've gotten response from Carlo on some of my questions (in italic):

1. regarding close/open gap:

You can test the strategy assuming signals are computed at the close of minute m, with execution at the open of minute m+1. The results should remain largely unchanged

2. difference between quote (bid/ask) and trades prices:

If you're working with minute-level OHLC data, some approximation is inevitable. To stay conservative, you can assume a slippage of $0.005 per share.

3. regarding slippage simulation

Since the strategy trades every 30 minutes, it’s not uncommon for the price movement in the 10 seconds preceding order placement to go against the actual trade direction. As a result, slippage is generally less of a concern compared to pure breakout strategies, where assuming execution at the exact breakout level may be overly optimistic.Keep in mind that the approach proposed in the paper is a baseline model. Investors should adjust the backtesting assumptions based on their specific trading constraints. For a more formal and academic discussion on slippage, please refer to Q15 in the FAQ section of the paper.We also recently shared some real-world slippage figures from an Interactive Brokers account where we tested a similar intraday momentum strategy on SPY with approximately $100k. You can find the details in this post. 

https://x.com/ConcretumR/status/1920144786864169133 

note that values of slippage and commission in this post are $0.005 (vs $0.001 in paper) and $0.012 per share (vs $0.0035 in paper).

4. Why did you choose 2% as volatility target? Is there a reasoning behind this specific value? Does it work equally good for all symbols?

This is quite subjective… you can use whatever volatility target makes you feel more comfortable. Since the strategy captures only a portion of intraday moves and often remains in cash during the day, a 2% volatility target does not actually translate into a 2% × √252 annualized volatility.

ok, well it looks like volatility target + volatility multiplier could be tools for overfitting to history

5. Sharpe and drawdown calculations:

I noticed that you are using end of day portfolio value for drawdown and volatility calculations, but doesn't it hide intraday fluctuations? If at the end of the day we have +1%, but intraday it was -4%, that will not be affected in drawdown calculation or volatility and hence Sharpe ratio. That may produce too optimistic values

This applies to all strategies: the higher the observation frequency, the higher the measured maximum drawdown (MDD). In this case, I'm not particularly concerned, as we're using a trend-following approach. It would be a more serious concern if the underlying strategy were mean-reverting, especially if combined with a martingale-style position sizing methodology.

6. Margin calls:

You can use micro futures to avoid 4x leverage issue

7. regarding alternative exit conditions

In our live implementation, we use more sophisticated trailing methods that ensemble multiple independent trailing stops.

hmm, if they don't use algorithm from paper for live-trading, does it makes sense to use live results to support it? I guess they kept some of the details out of the paper, not sure if this was used to get the main results that are in the body, but the follow up Q&A with actual live results should be taken as not directly related to the paper itself, as they may affect returns and risks heavily.