For backtesting, you can try this in handle_data:

import datetime

for stock in context.stocks:  
    if stock.security_end_date < get_datetime() + datetime.timedelta(days=5):  # de-listed ?  
        context.stocks.remove(stock)  
    if data[stock].price < 1.1:  
        context.stocks.remove(stock)  

Note that you'll need to end your backtest about 5 days before the present, otherwise all stocks will be filtered out. Also, I would put SPY in your universe, so that handle_data gets called every minute.

@Grant: That's not a good way to predict stock delisting! What you're suggesting is to use 100% lookahead bias and in fact not predictive at all. Using pure lookahead bias also means that technique can not be translated to live trading.

@Ujae: As per Simon's comment in this thread, I don't believe there's a hard and fast rule for predicting stock delistings. That being said, I encourage others to offer suggestions here!

Hi Jamie,

Correct regarding translating the technique to live trading--it won't work. However, it does predict delisting for backtesting, since if a stock gets delisted, it'll be dropped from the active Quantopian database. The idea here is that when a stock gets dropped from the Quantopian database, it is most likely due to a delisting that would have been scheduled within 5 days of its end date in your database. Is this a valid assumption? So, potentially it carries a look-ahead bias, but if a user is regularly checking his live-trading portfolio for potential delistings and managing them, then the bias should be minimal.

By the way, I think your colleague Seong recommended the same thing as I did here:

https://www.quantopian.com/posts/when-a-company-gets-acquired-my-portfolio-still-owns-shares-of-the-original-company-is-that-right

I'm guessing with the new pipleline, this problem is popping up more frequently. Any thoughts on providing a backtest helper function for flushing a stock out of a portfolio, if it ends up held after its end date?

Also, any plans to get data on scheduled stock delistings? Then there would be no risk of look-ahead bias.

Grant

Hi Grant,

The reality is, there's no way that you would ever get the end date of a stock before it actually stops trading! My claim that your workaround is not predictive was in regards to the fact that you can't actually predetermine whether a stock will become delisted using only information that you have prior to the delisting.

Regarding Seong's post in that thread, I'll have a chat with him later because I'm not sure that he was considering the lookahead bias when he posted it. Given that we understand it now, I think it's very important that others realize the dangers of using this in backtesting, because it really is a form of lookahead bias and could skew results. This is definitely a healthy discussion to have and highlights a weakness in our backtesting framework that we don't yet have a solution for.

I agree that the approach I posted above is kinda sketchy. For stocks that expire during a backtest, one could verify that they were scheduled to be de-listed and the announcement dates relative to the de-listings. This would be a check for no look-ahead bias in the backtest.

Maybe there are also cases where a stock listing goes "poof" without warning? When backtesting, you just have to end up holding the stock after it expires, but there should be some helper function to transact it (e.g. sell it at a specified price). I think once a stock stops trading, there's no way to sell it, right?

I found this discussion highly important.
If a stock is somehow dislisted from an index, it still should be considered the possibility of entering on it while backtesting the algorithm. Specially if we are comparing the performance to a benchmark which it timeseries considered that stock being part of it somewhere in time.