QuantConnect Community

Radu Spineanu, I just remembered your thread here: Yesterday, I have posted an implementation in the In & Out thread which might be of interest. I also attach it here for reference. It comes close to the 40,000% displayed in the picture that Vovik had posted in the thread. A few days/weeks back the implemented algo actually was at 50,000%+ total return which was then diminished by the recent market drawdown particularly pertaining to high-flying tech stocks. So, this might be the implementation you are after. Of course, an issue is that the algo is based on a fixed selection of stocks and hence non-negligible lookback bias (i.e. a selection of stocks that we know performed well in the past). A dynamic selection is likely to be preferable.

Thanks Peter Guenther

On a previous thread I thought I read that DistilledBear did a great job with the current pullback vs the standard InOut. Was planning on testing it soon, is that still the case?

We are living in weird times with what's happening right now.

That's right, Radu Spineanu, and is still the case, although it really depends not only on the in & out type you use but also (and critically) on the stock selection that you combine the in & out with. The winning combination currently seems to be the [QualUp] + [DistilledBear] combo. See attached regarding the returns since the beginning of the year. We also have a related discussion in our Amazing returns = superior stock selection strategy + superior in & out strategy thread.

However, tech might recover at some point and then possibly quickly, so that we'll have to see what will happen in the next few weeks. The QualUp stock selection also seems to have benefitted from Reddit meme stocks and it's not fully clear whether this can be replicated in the future (plus, we also have to acknowledge the massive drawdown because of these stocks).

Awesome! Really appreciate this! Can't wait to play with this over the weekend.

Peter Guenther have you tried paper trading this last version? Seems to get stuck for some reason.

Radu Spineanu, I recall that there was an issue regarding the warmup (350 days) and that it consumes more memory than available. You could reduce the number of warmup days or remove/comment out the corresponding line completely. Not sure whether this might solve the issue (?). Did it give you an error message or did the algo just not perform any trades?

Peter Guenther I keep on adding debug logs, right now it's printing this after two days:

It seems to be entering this branch:

I'll research what CurrentSlice does.

Hi Peter & Radu,

The call to `SetWarmUp` is not necessary since all the indicators are manually warmed up. In addition, we can replace the position sizing logic in the algorithm by using the `SetHoldings` and `Liquidate` methods. See the attached backtest for reference.

When paper trading this algorithm, trading may not start immediately because we have to wait for the `rebalance_when_out_of_the_market` Scheduled Event to be called before the first order is placed.

Best,
Derek Melchin

Great work, all. 

I'm curious: for these strategies that were sparked from Quantopian days: has anyone tried backtesting option trades of these securities, rather than the securities themselves?

Great algo update, thanks for sharing, Derek Melchin!

Very timely question, .ekz.. I am currently trying to get my head around options and hopefully there is something to share at some point. It can take a bit of time, though . . .

Peter Guenther: I implemented an options version, attached below. I'd recommend some refactoring before considering it ready for live trading. It can also probably be optimized for performance. 

New Behaviour:
Instead of stock, buy call options that are X% above current price and expire in Y days (it picks the options contract that matches X and Y the closest). I've abstracted the logic out so there's been minimal change to the main code, and externalized X & Y as parameters. You can see my code diffs at a quick glance here (visual generated from diffchecker), and here are the external parameters:

• tradeOptions : Set to '1' to toggle options trades, '0' for regular trading
• distFromPrice : (the 'X' ) Distance from the current price, at which we select a strike price. '10' = 10% above price
• daysTillExpiry : (the 'Y') Days till expiration for the contract 

For each opened order, I have added a message to the order memo, with the strike price and current price. For each liquidated order, I add a message for the proft / loss incurred. In either case, you can see these in the 'Tag' column of the orders tab in your backtest results (see example for liquidated orders in this scr shot).

Suggestions:
Given that it's trading a universe, strike selection shouldnt really be done via '% above price', as this will have different implications depending on the asset's trading price. This test just selects the at-the-money strike, by setting this to 0%.  You could also explore opening a vertical spread instead of a single call option, and allocating only a portion of capital as tradable funds (rather than ALL of it).

Note:
There were some tickers for which the options contracts arent being retrieved, but i havent had time to troubleshoot. You can have a look at the debug console to see which. It depends on your testing period. For this year, i'm seeing the issue with BEEM and BTB

Another thought... When it comes to shares, buying one share of a symbol is the same as buying another share. 

However, with options, we have more specificity --we can choose contracts based on conviction, much the same way we assign higher weights in our portfolio based on our conviction (of higher return). 

For example, if we've determined a particular symbol should have higher weight in our long portfolio (presumably because we expect a stronger move), we might pick a call contract that is farther out of the money (OTM).  Since OTM calls have higher rate of return than ATM or ITM calls, we stand to be well rewarded (assuming you don't go too far OTM). You could decide which OTMs to pick based on ATR, perhaps. 

Just a thought. Would love to hear from others. 

Hi .ekz.,

Great addition to the algorithm! We can improve its efficiency by only subscribing to the option contract that we trade instead of subscribing to the entire option chain. To accomplish this, we can first remove the OnData method. Next, we replace the call to QueueOptionHoldings with a new method, TradeOption.

Lastly, we extend the LiquidateOptionsOfType method to ensure we remove our option contract subscription.

See the attached backtest for reference.

Best,
Derek Melchin

That's great Derek Melchin I was hoping for some performance tips. Thanks.

I added that options order 'queueing' logic to an old algo to troubleshoot an empty option chain. I wasnt sure if it was necessary but the code stuck around.   

Question: if I wanted to use greeks (like Delta) to select strikes, would i have had to pre-subscribe to the feed, like I am doing? Or would your way work just as well? 

receiving error message: ArgumentException : The underlying equity asset (TLT) is set to Adjusted, please change this to DataNormalizationMode.Raw with the SetDataNormalization() method

can be solved by adding below in initialization.

self.Securities["TLT"].SetDataNormalizationMode(DataNormalizationMode.Raw)

Strange. I dont think we are seeing that error, spacetime

As you can see from the backtest, it ran just fine.  Perhaps you are using an older LEAN build.  

if you run the backtesting for a longer duration, then that error is seen.

Ah, great catch. Thanks.

I'm mobile only at the moment and can't make any changes. Feel free to attach an updated backtest with the fix. 

Kudos to your options algo, .ekz.! This looks very elaborate (= lots of work) and interesting, thanks a lot for sharing it with us. I am looking forward to playing around with it in the next few days.

Have added the fix inside the Initialize function in main.py to avoid the data normalization erorr.

Error: ArgumentException : The underlying equity asset (TLT) is set to Adjusted, please change this to DataNormalizationMode.Raw with the SetDataNormalization() method

Solution: self.Securities["TLT"].SetDataNormalizationMode(DataNormalizationMode.Raw)

Thank you!

I made a minor update as well, removing the OptionsUtils.py, which is not used here and may cause confusion. Updated backtest attached.

I use that for managing spreads in another algo of mine I will share some day.

Peter Guenther : Thanks for the kind words. Please let me know if you run into any issues. As Derek Melchin 

pointed out, there are some bits we dont need anymore. specifically the queue and dequeue logic. I've removed those now. 

One question i have, Peter: what exactly does this method do "derive_vola_waitdays" , the one with the log function.  I'm not quite able to wrap my head around whats happening here. I'm a software engineer, with limited data science & trading knowldege.  

.ekz., these functions come from the In & Out discussion on Quantopian (link). The basic idea is that we want to stay out of the market (wait_days) for longer when there are more jitters in the market, i.e. when the market volatility is higher.
Regarding the volatility formula's general structure: There are certain advantages in using standard log-transformed returns instead of raw returns. I found this web site here that explains certain advantages: https://quantivity.wordpress.com/2011/02/21/why-log-returns/. I reckon the 0.6 was chosen to optimize the results. The multiplication with the square root of 252 is to express the standard deviation in annualized terms: https://www.fool.com/knowledge-center/how-to-calculate-annualized-volatility.aspx#:~:text=To%20present%20this%20volatility%20in,root%20of%20252%20is%2027.4%25..
In the wait_days formula, the constant is optimized, but the formula follows the general idea that we stay out for longer when the volatility is higher.
The returns_lookback also is a function of the volatility. I think that the idea here is that in volatile markets, the return differences that we are checking for (see Distilled_Bear signal) should show in shorter time periods.

Thanks for this, @Peter! 

This is exactly the level of detail I needed and the links are a huge help.  Also, the historical context (the old quantopian thread) has been a big missing element; reading the previous conversations will fill a lot of gaps for me.  Thanks again. 

I tried running the algo with 

        self.go_inout_vs_dbear = 1 # 1=In&Out, 0=DistilledBear

and it fails with 

Runtime Error: In Scheduled Event 'EveryDay: SPY: 30 min after MarketOpen', AttributeError : 'QualUp_inout' object has no attribute 'history_shift'
at signalcheck_inout
returns_sample = (self.history / self.history_shift - 1)
File "main.py" in main.py:line 248
AttributeError : 'QualUp_inout' object has no attribute 'history_shift' (Open Stacktrace)

Is that expected?

Aalap Sharma, thanks for the note. I have added the creation of history_shift to our warmup (line 155), see the algo update.

Another issue: I still have to have a closer look but there seems to be an issue regarding maintaining the cash level in the current algo version. We are going more than $1 million into the negative territory, see the cash level chart :) In the order log, there are margin call warnings starting in about August 2020 and notes that we fill at stale prices. It seems that we are currently buying more than we can afford.

Still looking at the issue, but I think the key problem is this: When the time to expiry is too short, or is running out, then we have to execute the call options, meaning that we are buying the underlying stock, resulting in cash running low and the margin calls that we see in the orders log. So, what we need:
The options must have a minimum duration (time to expiry) which is the rebalance time (plus X days to be safe; I think currently it is 60 days between rebalances). When rebalancing, we then exclude all options that do not have sufficient time left in terms of their expiry date which should prevent that we actually have to execute the options. This also means that we need to make sure that we sell all those options that we are currently holding which do not have sufficient time left on them (i.e. days to expiry < 60 + X).

Great, so this looks promising: Attached is an update of the algo. We are not running into liquidity problems anymore that occurred due to calls that got executed.

Details:
In the OptionsManager.py, I have added the following lines to where we sort by expiry:

min_expiry = int(self.algo.GetParameter('reb_freq'))
contractsSortedByExpiration = [p for p in contractsSortedByExpiration if ((p.ID.Date - self.algo.Time).days > min_expiry+5)]
if len(contractsSortedByExpiration) == 0: return

For this, I have also added a new parameter that determines the rebalance frequency (reb_freq) and set it to 60 days.

We still have a few orders that get rejected due to insufficient buying power, so this might be the next issue that needs addressing. Also, we now have a bit of cash lying around ($50k at the end of the backtesting period) that does not get invested.

By the way, the CAGR is currently at about 344% ... although it's of course a wild ride to get there :)

Peter Guenther , 

hmm... I have performed a quick backtest with your latest version of the algo and was receiving the below error.

I am not certain how to solve this yet, but if I find a solution, then will post it here.

14 | 14:00:05:
Backtest Handled Error: Order Error: id: 2, Insufficient buying power to complete order (Value:735), Reason: Id: 2, Initial Margin: 736, Free Margin: 0
01/02/2015 10:00:00 - Executed MarginCallOrder: TLT   160115C00125000 - Quantity: 1 @ 0

Just adding on to my previous post.

self.SetStartDate(2015, 1, 1) is the starting date.

Same thought here, I was also starting from 1 Jan 2015 onwards and was running into the same issue :) The algo seems to buy too much of the TLT option at the beginning. We can get past this by reducing the holdings from 1 to 0.85 (lines 325 and 350). However, anyway, the whole system collapses for some reason after Feb 2015 and then constantly underperforms. Backtest attached.
We will get our heads around this one, just a matter of time.

I'll have a version soon that opens put credit spreads instead of calls.  This is more in line with how one would trade 'in real life'.

Thanks ekz for your options implementation. I've traded options for years manually, and can provide some more thoughts around using them.

The further out of the money the strike is, the cheaper they are to buy. But they are also less liquid. It quickly gets difficult to execute the order at a good price if the bid ask is 0.20 x 0.25, and low size on the bid or ask. If you are only trading $500 you can work with it, but buying $10,000 worth of a 0.25 option is 400 contracts, and if the size on the ask is 50 then you will likely pay more for that entire position.

So going far OTM liquidity and execution becomes troublesome with any kind of size, unless you are trading only the most liquid underlyings. Same thing goes with spreads, however spreads also require more patience when executing an order, especially to maximize profits. A spread quote may be 0.95 x 1.15, and you want a good fill so you place it at 1.05 and may wait for an hour or 2 to get it filled.

We can go the opposite way of OTM and go ITM. with ITM, the closer the strike is to zero the more the option behaves like a leverage stock position. If the stock is at 100, and you buy a 50.00 strike call, then if the stock goes up to 101, then the call will go up near $1.00 in value for example. But deep ITM options have less liquidity too, so also troublesome.

For this strategy I would suggest the following 2 option methods.

1. Buy Calls less than 1 standard deviation away between ATM and ITM. These should have good liquidity, and not be so cheap that execution becomes troubleshome.

2. sell an ATM put credit spread, and use those proceeds to buy a slightly OTM call. This means you put up the requirement for the short spread, and if the stock drops then you just lose the requirement. But if the stock takes off you have got a slightly OTM call for free.

I'm a trader learning to program, so I'm not capabale of implementing this logic in a strategy yet, but hopefully it helps.

Good stuff, Mark! I'm a manual optionsrader as well, and  I especially like your clever combo in #2 :)

In my manual options trading, I typically decide between selling put verticals and buying call verticals, depending on IV (with high IV, I'm a seller). Curious, would you use make a similar decision, or always sell put verticals, regardless? 

With the short put spread and long call method, your on both sides, so the IV premium isn't that important. Seems like you know that with a high IV you sell the trade, and low IV you buy the trade.

But if you're only doing one side either buying or selling, than IV becomes a lot more important in general. Regarding the IV and this strategy, it would be worth to see a backtest that trades regardless of upcoming earnings, and one that excludes a stock if there is an upcoming earnings and IV is high. A lot of people that trade options just do earnings plays, usually selling the IV premium.

For this strategy, there is are expectations that the stock will move up a lot, so I would be inclined to have a long call position instead of a spread only. A long spread is used when you want to be long the trade, but you sell a farther away strike to offset the purchase cost. So you would be expecting a move up in the underlying, but not a drastic move. This stock filtering I think is geared towards strong upward potential moves.

I also don't think this stock filtering is built to look for selling just bull put spreads. Really if your selling any spread only (not adding a long call/put) then you are deciding that the spread alone is very over priced, and the probability of the underlying reaching your short strike is low, so you sell it expecting to buy it back for cheaper at a later date. Usually this is around earnings.

The selling of a put spread to get a long call for very cheap seems like a good fit for this stock filtering.

I tried to keep my comment short, but thats hard to do when talking about options :)

Brilliant. Love the thinking here. Agreed on all counts. 

I will try to implement the PCS over the weekend/week.