Calendar Backtesting the COVID-19 Crash (Part 4)

I left off asking about a subtlety that would probably be identified by only serious option traders. Submitted for your approval is a question about why one backtested calendar is ~30% more expensive than all the others. Were you able to explain it?

The nuance here is that calendars generally get more expensive when purchased closer to expiration. To lower the cost, I would generally go farther from expiration, but that is not the case with the Sep/Oct calendar I mentioned in the second-to-last paragraph of Part 3. The calendar I backtested was an Oct 3225 put priced at 24.09% IV and a Nov 3225 put priced at 26.24% IV. Is that normal contango? I’d have to survey a large sample size to find out but my guess is no.

I suspect two factors have contributed to make this calendar atypically expensive. First, it is 35 days wide. This happens four times per year [(4 * 5 weeks in between mos) + (8 * 4 weeks in between mos) = 32 + 20 = 52 weeks for the full 12 mos] and it means paying for one extra week of extrinsic value in the long leg.

Second, and what I believe to be of greater importance, is the 2020 presidential election. I think the Nov options are priced rich due to election uncertainty.* On 7/31/20, IV for Nov and Dec are 24.55% and 24.66%, respectively (beyond which term structure decreases). Purchasing the Nov/Dec 2020 112/140 (DTE) calendar would cost $4,650: much less than the $8,840 seen here. The horizontal skew on the Nov/Dec would be -0.19, which is much lower in magnitude than -2.15 for the backtested Oct/Nov. Term structure rises steeply through November and then starts to trail off. This is unusual.

Incidentally, I’m puzzled why I exited this adjusted DC at 43 DTE when a third adjustment point was hit on 9/3/20 to open a single Nov (78 DTE)/Dec calendar. I could have rolled to ATM, as the presenter’s guidelines suggest (green):

I could have also gone an extra 100 points OTM (green):

Theta is comparable for both and cost is slightly less for the latter. TD is even higher for the latter (17 vs. 7). Either of them look doable. Every time I adjust a calendar, PnL gets dragged down a bit by transaction fees. Since it usually takes a few days of positive theta to recoup that, maybe I should never adjust too close to my drop-dead 21 DTE. That is no excuse here with 43 DTE and plenty of time left.

I will continue next time.

*—As an exercise for another post, I should plot this term structure in Python. An additional
     detail would be to scale the x-axis properly since data points start one month apart and
     later increase to points that are three months apart.

Calendar Backtesting the COVID-19 Crash (Part 3)

Today I continue discussing calendar trades, which I recently revisited after viewing an online presentation on performance during the COVID-19 2020 crash.

I left off explaining that my second backtest was an attempt to be well-defined compared to the first, especially with regard to margin by implementing a constant number of contracts. No more starting out with one contract, adjusting by adding another, taking it away, etc. Also, no more double calendars with different expiration months, which may be regarded as different numbers of contracts from a theta perspective (e.g. on Jan 3, a Feb/Mar calendar will generally generate more positive theta than an Apr/May).

The second backtest returned $7,681, which seems significantly higher than the +$5,072 from the first backtest. Looking closer, though, $7,681 on a maximum margin of $10,074 is 76.2% ROI, which is only slightly better than 65% for the first backtest. The latter ROI is based on a max margin of $7,775.

With all that effort given to maintaining a constant number of contracts, why is max margin ~30% higher in backtest #2?

Here is the trade list from the second backtest:

Looking down the “MaxAbsRisk” column, the first thing I noticed was the highlighted $10,074. This intuitively seemed to be about 25% more than the rest, but a look across the entire distribution suggests otherwise. Note the low values marked with red. Going one step farther, the standard deviation of these numbers is 1756. For the first backtest, the standard deviation of max risk (recorded after every trade) is 1734. Evidently, consistency across number of contracts (check!) is not the same as consistency across nominal risk (miss!). I could normalize the latter by selecting a position size (e.g. $10,000 or arguably X% of account value) and always trading the number of contracts coming closest to matching it.

The $10,074 trade bothered me enough to take a closer look for understanding. I opened that PCal 28 points OTM on 7/31/20. This appears to be a choice (maybe an attempt to bias the backtest negatively as mentioned in the second paragraph here) to lean bearish because I could have placed it 3 points OTM or 22 points ITM (bullish). Either way, all three of these have similar cost and therefore would not explain the anomaly.

Instead of doing the 77/112 (DTE) Oct/Nov 2020 calendar for $8,840 (initial margin), I could have [violated the guidelines and] opened a 49/77 Sep/Oct 2020 calendar for $7,190. This would have replaced a winning trade with a losing one and instead of making $7,681 on $10,074 (max risk ever seen on any trade) for +76.2% ROI, the strategy would have returned $6,099 on $8204 for +74.3% ROI: pretty much the same.

Did you catch that? Something strange is afoot. If it rattled your bones the first time you read it, then you certainly deserve a free pizza for prowess!

*—I should plot this distribution in Python as an exercise for another post.

Calendar Backtesting the COVID-19 Crash (Part 2)

I recently viewed an online presentation about a monthly calendar, which motivated me to revisit the strategy.

As mentioned in Part 1, I backtested a second time because my results fell short of the advertised +100% return. As also discussed, I wasn’t overly concerned about this because he did not offer details about his trades or his calculations.

Although I didn’t consider it after completing the first backtest, I probably overestimated slippage with $21/contract. Factoring in too much slippage can result in backtested returns falling short of live-trading counterparts.* I would be curious to know what slippage the presenter realized on his trades. I have a feeling very few actually track this. I do it by noting difference between my limit and midprice. Once my order is executed, I look immediately at the mark to see how far off I got filled.

I did give serious consideration to the fluctuating number of contracts that is typical of rolling calendar trading strategies [beyond the current scope is an entire debate awaiting to be had over this approach]. If I start with one calendar and adjust by adding a second, then I have roughly doubled margin. Trading strategies generally need consistency to be successful. Cruising along winning 1, 1, 1 on single calendars only to suddenly hit turbulence and lose 4 on a[n] [adjusted] calendar with double the margin can be very painful (see third-to-last paragraph here).

In my initial backtest, much of the profitability took place with one contract in place rather than two. Calendars make consistent profits when the market trades sideways. A cursory scan through the backtest shows 288 trading days with one contract and 163 trading days with two. As a weighted average, I was trading 1.36 contracts per day, which is 68% of the full 2-contract position size. I would expect a lower return with a smaller position size because maximum risk (denominator), is equal. Maximum risk relates to the largest position size ever seen whether it happens once, 36% of the time, or always.

In the subsequent backtest, I implemented two contracts at all times. I started with two and rolled one of two when I had to adjust. I paid much closer attention to when trades started and when they ended. Rather than ever having calendars with different expiration months on at the same time (e.g. Jan/Feb and Feb/Mar), I closed the entire position and started a new trade with the short leg around 60 DTE.

I will continue next time.

*—So many other things can also affect the comparison including strike prices, DTE of
     individual trades, timing of adjustments, etc. It’s also worth noting that difference in
     the headline return may not be statistically significant (see bottom of this post).

Calendar Backtesting the COVID-19 Crash (Part 1)

I recently saw a presentation extolling the virtues of a monthly calendar trade. I have backtested calendars in the past without convincing results. After seeing this presentation, I decided to give another look.

The presenter claimed to be a full-time trader for several years. He said he has now traded calendars for at least two years. He traded through the COVID-19 crash and did well. This gives him the confidence to trade calendars in any environment because March 2020 was “the worst thing to happen to the market since 9/11.”

These are his official guidelines on trade setup and management:

• Buy calendar 60-80 DTE with long leg 30 days farther out in time.
• NPD < 30% of NPT
• If NPD too high/low, buy second calendar ATM to form a DC.
• Manage by TD ratio and maintain position under profit tent.
• Profit target: 15-20%
• Exit around 30 DTE (no later than 21 DTE).

My initial backtest guidelines were as follows:

• Buy ATM PCal with ~60 DTE and one month between legs.
• Monitor TD ratio daily and adjust if < 4.
• Adjust by adding second calendar ATM or slightly OTM to raise TD > 4.
• If TD < 4 again, close OTM calendar and continue.
• If adjustment results in “excessive” sag between strikes, then reposition with 60-DTE ATM calendar.
• Rinse and repeat should further adjustments become necessary.
• Exit no later than 21 DTE.
• Assess $21/contract to include $0.20 slippage and $1 commission per contract.

From 12/23/2019 – 10/29/2021, this returned $5,072 on maximum risk $7,775: +65.2%. Over the period, SPX ↑ 42.4% from 3225 to 4594. Max drawdown was -47.4% (-$3,684) on 3/23/20 compared to -31.7% (2203) for SPX on the same date.

The calendar strategy performed comparably (risk/return) to the underlying index, but the presenter said he returned +100% in 2020 alone. Did I do something wrong?

I should never get overly concerned about discrepant performance statistics when I do not exact details about presenter calculations or accuracy. He may have rounded up to 100%—to the nearest 1%, 10%, or 100%!

While I don’t know these details about the presenter, a more detailed look at my methodology reveals:

1. I managed only by TD—not minding whether trade remained under the tent.
2. I usually closed at 21 DTE and adjusted as late as 24 DTE.
3. I did not implement a profit target.
4. I opened trades near 60 DTE going as short as 56 DTE.
5. I used only 25-point strikes.
6. I conducted one long campaign rather than grouping entries and exits into separate trades.

When others present results, I seldom find them forthcoming with a comprehensive, accurate account of methodology enabling me to replicate/verify the numbers. Changing any of these details can affect performance calculations. Live trading results are even worse because some degree of discretion is almost always present. A list of trades can provide opportunity for verification, but this was omitted as well.

I will continue next time.

Future Content Related to Python Backtester

Although I haven’t blogged in two months, the time has come to give an update on the long-sought-after option backtester.

As it turns out, I met a guy through a trading website who has been programming for decades. He’s a Python expert! He’s had a few different fits and starts with regard to trading and investing over the years, but he recently hit true retirement and thankfully has an interest in working with me to develop the trade backtester about which I have written much in the past.

In the last 18 months, I have taken a closer look at some automated backtesters on the market. In particular, I have researched eDeltaPro, getVolatility, and CMLviz TradeMachine. I did a detailed review about the latter. In coming posts, I will publish my findings on the other two. I really want our backtester to be something beyond what is currently available and to achieve that, we need to identify what has already been done.

This software will not be for commercial use. I am quant- and statistically-minded and looking to combine basic strategies to see how they fit together. The level of complexity will far surpass what introductory traders need. With regard to advanced retail traders out there who have studied and/or possibly developed some of these multifaceted approaches on their own—well, I don’t personally know any, as alluded to in the sixth paragraph here.

I don’t want to start a software company where I would be required to offer tech support.

I don’t really want to be an investment advisor selling my employer’s products.

I don’t really want to go into trader education: that’s a whole other industry of its own and would detract from my main focus.

As mentioned in the third paragraph here, I do want to remain on the quant-related course I have been following.

After reviewing the other two software solutions mentioned above, I will focus on some YouTube content I have been perusing. Videos are available on a wide variety of trading subjects. Some have captured my interest with regard to backtesting methodology. I will analyze these in a manner similar to this lengthy blog series in an attempt to gain a broader perspective on how we may go about backtesting different approaches.

Finally, I will start reviewing some Python concepts that will be integral to the backtester as a way to solidify my own personal understanding of the language.

Coming attractions, y’all!

STT Backtesting Notes (Part 2)

I continue with miscellaneous observations from recent STT backtesting done in OptionNet Explorer (ONE):

• I did not use PT or max losses, which would require separate tranche monitoring. I realized afterward that I had not separated tranches by trade ID. This is discouraging because as it was, I had difficulty switching between combined/separate isolation modes and [de]selecting position and/or model for adequate visualization to set up trades.
• I used a global bearish STT for adjustment when technicals turned bearish. Per previous bullet point, monitoring separate tranches is important to roll back or exit tranches by the time short/upper strikes are breached.
• My bias is to save money on debit spreads and to buy only when market conditions turn ugly even though I’ll have to pay more at that time. Although I believe the STT may be a profitable strategy, always-on insurance costs extra. Starting without the debit spreads is essentially trading an income STT. Either way, before hanging tight to this bias I really should give the standard STT a chance to see how it fares without loading the additional credit at inception.
• With or without always-on insurance, I still haven’t quantified exactly how profitable the strategy might be.
• I sometimes lost count of STT and tail-hedge tranches. The idea is to sell an STT every time a tail hedge matures. Upon realizing I had gotten behind with tail hedges, I doubled the number of NPs with the intent to sell one fewer STT upon maturation to catch up.
• The last bullet point suggests additional ONE limitations: not showing total count of long/short contracts, not being able to click on a particular expiration and see statistics for just those contracts, and not being able to click a button to jump straight to farthest-dated contract (as I am able to do with to the shortest-dated). I felt like I needed a separate spreadsheet to monitor current number of contracts and total tranches (and trade IDs) for STT and tail hedge.
• I discovered reverse calendar/diagonals taking shape from extra LPs with NPs in far-dated months after closing NTM/losing STTs. Closing NPs for max loss would avoid SOD risk. Alternatively, I could choose to pay some higher price to force tail-hedge maturity and sell a new STT at the same time.
• Tail hedges are always OTM from STTs themselves and I question their lift strength in this ratio (also see Part 1 comments on convexity). As noted in the third paragraph of Part 1, next time I will buy one month closer (perhaps planning to at least close the embedded STT PCS if necessary when associated tail hedges expire).
• What would happen if debit spreads were purchased one month closer?
• I kept an eye on PMR (down 12-14% on the underlying). I should also monitor LEL at trade inception.
• At one point, I clicked ahead to the next day and was surprised to see a blank risk graph. All positions had expired and the previous months had not given opportunity to sell new STT tranches as tail hedges did not mature. This argues for a supplemental volatility-based or episodic STT entry should market conditions turn bearish (although when the market gets crazy, being totally out isn’t a bad thing; see first bullet point in Part 1).
• The strategy is discretionary with many moving parts and I really don’t know what to track. For this reason, I didn’t keep a spreadsheet and don’t have concrete results to present. This doesn’t sit so well with me.
• Although not implemented in this backtest, I did try to model a couple standard 242s and they seemed nowhere close to delta neutral. I used 25-point strikes and I figure this must have been the result of low delta density. I can always tweak strikes as necessary to change NPD as desired.

I will be doing more backtesting, will hopefully sharpen some of the ill-defined points, and will ideally generate some results to share. Things that might help with this include: PT and max losses, guidelines for UEL and delta bias, clear technical criteria, attention paid to unique Trade IDs, and continuous tracking of inventory.

Easier said than done!

STT Backtesting Notes (Part 1)

Today I present miscellaneous notes based on observations seen doing manual STT backtesting in OptionNet Explorer (ONE).

I would like to give a disclaimer about level of sophistication. Someone recently looked at my blog and said, “I was completely lost after two sentences.” I have made particular effort in the past to explain things for an audience unfamiliar with trading concepts. I have cut back on this recently. Please realize my primary motivation for blogging is to organize my thoughts and to keep myself on track with my projects. I don’t need basic definitions because I’m immersed in this stuff every day. Should you have particular questions, always feel free to leave comments below or even contact me via website e-mail.

The backtest begins in Nov 2019 in order to be fully loaded for the March 2020 crash. This is primarily an income STT (BWB) backtested as 10 contracts (five tranches). I hedged starting with nakeds that become 40 LPs upon maturation. I sold the STT in the same month; next time, I will look to sell the STT one month farther out.

I tried to use some rudimentary technical analysis to guide whether I should lean positive or negative NPD. I looked at slope of 50-MA along with IV term structure.

If I’m going to trade this live, then I need to be very clear with technical criteria. Even if the criteria alone do not constitute a profitable strategy, they should at least filter out large contrary moves. I then need to make sure to lean directionally rather than letting NPD grow too large (especially in defensive periods where HV is high and big moves would not surprise).

I charged $20/contract to cover transaction fees. This should be sufficient as discussed here. All expiring contracts were BTC at 3:55 PM. This added expense may be considered to offset crash conditions where larger slippage would be expected.

Here are my general impressions:

• When things get crazy, look to peel back or exit because major adjustments moving around lots of contracts in market crash conditions may not be feasible. I totally forgot about this.
• I was usually short convexity although sometimes T+0 bottomed before reversing higher. I thought the idea with the tail hedge was to generally be long convexity, though.
• While I admit I did not add volatility stress to check convexity, never in 2020 did I see a T+0 smile. Neither was this realized when the underlying tanked despite tail hedges profiting handsomely.
• I did not harvest in this study, which could potentially remove risk for some added cost.

I will continue next time.