I have been back-testing an option premium selling strategy on some agricultural commodity futures options (to start with), with and without dynamic delta hedging (using a position in the underlying future as the hedge). For short period of time (say trades of under 6 months), it seems that dynamic delta hedging needs to be done at least daily to improve results. Doing it weekly gives disastrous losses instead of improving profit or drawdown. Hedging delta daily via a position in the underlying future does improve the consistency of results for a number of such strategies, but the transaction costs of hedging daily are too high for me. Might it make sense to use static hedging instead of dynamic hedging in this context? According to the following paper by Peter Carr, http://faculty.baruch.cuny.edu/lwu/papers/CarrWuJFEC2014.pdf it is quite easy and effective to use static delta hedging. However, since static hedging would presumably involve the purchase of several nearer-dated options at a higher implied volatility that that of the longer-dated ones that I was selling, I am wondering whether static hedging would be nonviable for that reason. Does anyone think that static hedging could be useful to hedge longer-dated short option positions? I realize that is is viable for purposes other than mine (such as hedging sales of custom barrier options etc.)
Try gamma-delta neutral positions; they should reduce the need to rebalance the delta. http://www.investopedia.com/articles/optioninvestor/07/gamm_delta_neutral.asp
You can't beat trading underlying for transaction costs. Either increasing your delta band or lessening hedging frequency is the key. I'm from the 1 lot world. 1.00 commish controls about 50,000-80.000 in futures for a delta of 1. How big are your trading?
Which is why I recommended being gamma-delta neutral. Less gamma equal less change in delta equals less rebalancing equals less transaction costs.
Thanks I do plan on back testing with delta bands - it is just a matter of the programming time. I will also look further into the feasibility of gamma hedging as was suggested. Yes in futures a delta of 1 being the minimum increment is a bit of a problem. But I guess one can use some spreads etc. along with mini contracts to reduce the minimum increment. Time will tell whether I can get that to work. I am only trading a few lots at most but I have a feeling there will still be a way to get delta hedging helping one way or another as I try various possibilities. Thanks to both of you. I may report further when I have better results. My results with reduced frequency delta hedging are so bad that something may be wrong with them. Or else they may hint at an interesting inefficiency that might be exploitable!
I don't have a suggestion, but a question: Are you getting these types of results only in a relatively recent testing period (say Nov/Dec to the present), or are they consistent going back a few years?
It is over the last 3 and a quarter years of fully detailed daily closes of all months and strikes (of grain options in this case). (I will very soon also be able to run it over 10 years less exactly using just volatility history). But it still strikes me as unlikely so let me study the results for plausibility from some other angles. There could be coding or methodology errors. I should be able to figure out why this is occurring. I will post further when I have done that.
Still within topic, can you provide information on your research platform? I think you mentioned before that you work in excel and R? Also, did you design your database from the ground up or is it just a simple download of data that's ready to be worked on? From which vendor? Thanks.
That sounds like a thorough test. I thought if you were just getting started, the results might be skewed by the price and vol moves in corn, wheat, hogs, sugar and coffee over the last several months, some of them quite significant.
I currently parse the original data from several sources (mainly public or subscription web and ftp sites including the CME) in C# code and convert it into intermediate flat files. A lot of the C# code to parse site data and reduce it was extremely time consuming to write because of formatting issues and I do not think many people would do it. Then I read in the flat files a few at a time into R and do everything in R. I just keep it in R memory while working on it in R and read it in from the flat files over again when I restart R. I have extensive code by now in R. I am doing everything using using large data.tables with no loops so everything runs fast, even where I have a million lines of data in some tables. It takes some different coding styles to avoid using iteration. One has to code the varying parameters into the data rows and subselect off them to avoid iteration. I use Excel only a little bit for viewing the summary tables that I produce in R. Actually I use Ron's Editor a lot for that now instead of Excel as it is snappier for just displaying CSV table results that I write out of R.