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!