Stanislav

For those who are using TradeLogIB.py with Python 3.6 and ib_insync package I recommend to update and install latest ib_insync from the latest master code branch: https://github.com/erdewit/ib_insync ib_insync author merged in my Pull Request with a patch to solve the issue with fills for partially executed multi-legged option orders. I noticed TradeLogIB.py script based on ib_insync did not dump trades for a partially executed orders, I have to wait till order is completely filled or cancel an order and then run TradeLogIB.py to get my fills for that order in .csv file. More details here: https://github.com/erdewit/ib_insync/issues/36 That was quite annoying, and previous version of the script based on IbPy and Python 2.7 worked well with partially executed orders, dumping fills immediately. So decided to make some research and investigate the issue. As a result I developed a patch to ib_insync package which solves this issue, and author merged in this patch today. So, it may be a good idea to update ib_insync package.

Credits mostly go to ib_insync package, as it allowed me to greatly simplify the script. ib_insync is a good example of how well designed API should look like (compared to the garbage IB ships ).

Here it is, the latest version of the TradeLogIB written for Python 3.6+. It uses official IB Python API via an amazing ib_insync package: https://github.com/stenri/TradeLogIB Script is now more than two times shorter as ib_insync allows to use synchronous programming. So working with IB API becomes quite pleasurable. NOTE: Output of this version differs slightly from previous version output because of differences in number rounding in the last field "Total Cost". If you account for this, the rest of the output is the same.

I publicly released TradeLogIB.py on a github.com: https://github.com/stenri/TradeLogIB Next step will be to rewrite the script to support Python 3.6+ and official IB Python API as suggested by @Christof+.

ONE support send me a test build, I tried it and found it fixes the issue with crashes. They asked me not to distribute this test build as they are going to create a new version for release. So we can expect an official fix to be released soon.

Seems the issue is specific to IB datafeed. However deselecting [ ] "Use IB Option Chains" flag in ONE settings does not help to resolve the issue.

Yes, I also have the issues with ONE crashes after connecting to real-time TWS feed. I've already opened a ticket and sent ONE's support detailed info and logs. They said they are investigating the issue.

Thanks! Yes I use IbPy as it supports Python 2.7 which I currently use for all my Python scripts development. I've seen new IB API with Python support but for now decided to stay with IbPy solution, as there are more examples available in the internet and IB Python API only support Python 3+. I also have plans to adapt my own TradeLogIB.py script to be Python 3+ compatible (this mainly means changing print statement to print() function calls). Maybe I'll do this next time I update the script.

Actually my IB and ONE are not on the same machine as well. But IB machine is accessible via VPN, so my script connects from ONE's to a remote IB machine (there is a --host parameter in the script, plus TWS needs to be configured to allow API connection from specific IP addresses). It is also possible to run the script locally and somehow copy .csv file to the machine where ONE is installed. As for me, I hated waiting till the end of the session, and then login in into the Web interface each time, searching export e.t.c. That's too much work. But you are right, everyone's workflow is different.

@Djtux, take a look at my TradeLogIB script. It is much more convenient than a default IB import feature in ONE:

Based on discussions in this and New Subscriber Discussion threads TradeHawk currently is the best platform for Tradier. You can look at TradeHawk Pro (40$/mo) + SO offering ($49/mo) = $89 a months with unlimited trading option.

Brian's book is very good at explaining how to model earnings volatility. But there are no easy recipes there - one needs to put a lot of effort into developing a volatility model, calibrating it, finding proper ways to use it e.t.c. Excel spreadsheets that accompany the book can be of some help for SO straddles strategy, but they require a lot of user input. So, at least for now I am too lazy to try to use and apply them to calc pre-earnings straddles+strangles. My attention is focused at other things. Overall, I think it may be a good investment of time to read and study Brian's book, especially if you plan to develop your own option calculators/scripts/software that helps to automate the decision process.

They open accounts for non US citizen's on a case by case basis. Just write a letter to their support. See also my comment in this thread:

I fixed TradeLogIB.py script to work with the latest ONE 1.28.6 BETA which has been released several days ago. It seems they fixed locale specific bugs in ONE when importing OptionXpress data. And now ONE always expect date and time to be in US locale format (however, ONE still needs AM/PM symbols to be set in Regional and Language settings in Control Panel. See TradeLogIB_1.02_for_ONE_1.28.6BETA.zip attachment in the original thread post.

I publicly released TradeLogIB.py script on a github.com: https://github.com/stenri/TradeLogIB So I moved all documentation and script itself there. Here I only leave Motivation section from TradeLobIB.py documentation, so occasional visitor may read it and get interested. Motivation: As you may know, OptionNET Explorer lacks proper broker integration: it can only send orders to the broker but after the order is sent, it lives its own life. ONE does not know when and if the order is filled, at what price, how much commissions are paid and so on. It is assumes user manually downloads trades from the broker and uses Import Wizard to import trades, or just enters trades and commissions manually into Trade Log. In case of Interactive Brokers user is only able to export broker activity statements after the session is over. So after you place an order and receive a fill you have to wait till the end of the session for activity statements or save the trade into Trade Log and manually enter commissions (this process is very error-prone). All this makes trading process much less convenient than it should be. And we need a solution to import trades from a broker Trade Log into ONE without much effort. Here it is: TradeLogIB.py.

@RapperT, sorry my exaggerated last post. I just did not like your remark "but there is a ton of helpful info online about this subject already". As if I could go somewhere on the web and read something that could explain you methodology. I have no problems with your charts. I see many other member find them to be valuable. I just, having a technical mind, want clear and precise understanding what the charts are and how they are calculated. And for me it is not enough just to write something like "blue line is a return forecast using Black Scholes" and expect this will explain anything. Without even providing a link to the academic publication or an article. It is even unclear what exactly do you mean by "price forecast" or "a return forecast" in relation to Black and Scholes, as, as you definitely know, BS model does not forecast anything. So when I see something like that, I come up with a question. A lot of them. I agree, yesterday was unnecessary busy with messages between us. And, since it seems there is a lot of misunderstanding between us, it may be a good idea to postpone our discussion till the better times. Sorry if my questions trouble you.

Ok. I just want to point out that your explanation is not explaining anything. I know BS formula, know what it calculates and how people use and apply it. Know BS assumptions and it's limitations and so on. I wrote a numerous scripts for option calculations, reverse engineered Brian Johnson earnings volatility model e.t.c. Also I am professional developer. So I feel am I pretty competent. If I do not understand something on the topic, this means the explanations are very imprecise.. to say the least. If you do not want or not ready currently to explain you methodology - that is ok. But, please, do not point "go google it and read". As far as I can tell, my misunderstanding is due to lack of proper documentation, not due to lack of my own knowledge. If some other forum member tells he or she understands your explanation, and is able to provide some simple example how blue line is calculated. Then ok, I'll recognize I am wrong. But I assume you won't find such person.

Yes, exactly. Sorry, no trolling. But I still do not understand. Can you, please, provide some example for the calculation? So, we have historical pre-earnings IV, let's say IV1, IV2, IV3, IV4 from the past cycles. And we have a NormalIV from current cycle. And we know T - days till expiration as a fraction of the year. Then, what do you do with this data to receive a point on a chart representing a blue line? And how and what for Black Scholes formula is used here? I think a calculation example with some simple numbers can help here to clarify the things.

@RapperT, can you, please, explain in more detail how Normalized straddle prices (blue line) is calculated? Previously my understanding was that this is just an average IV from past cycles normalized by Normal IV (i.e. divided by Normal IV). But here you mention Black Scholes model is also used to calculate the blue line. So I feel I do not get what the blue line really is.

@RapperT, thanks for a great discussion! I think all members can benefit if you provide complete description of what and how is calculated in such a way and in such details that other member could potentially take the data and recreate the implementation from scratch. This is the way RV charts were discussed and many members recreated the technology (including myself) and made some improvements (@Djtux's chart design is a big step forward!). Possibly your new Forecasting Charts thread can be a good place for this. Some pseudo-code could help to clarify charts implementation. Surely, if you wish to leave the technology proprietary, that is ok too. That just won't make it easy for others to suggest how to improve these charts. As for the edge, yes I, as well as other SO members, understand the rationale behind pre-earnings straddle strategy. The issue is implementation specific. Me and some other members (@Kim), asked a reasonable question: - What exactly subtracting blue line and orange line means, why this subtraction is legitimate, how can we mathematically prove that this really extracts or helps to identify an edge, what is physical sense behind these calculations? @Kim formulated it in a different way, but I believe his line of thought is the same. These are a kind of questions any good system developer asks himself when designing a trading system. So precise, complete and clear description of the chart calculation can help to answer these questions. Anyway, thanks for the discussion again! I am going to monitor your Forecasting Charts and keep an eye on further charts development.

Do not take my words on simplification personally. I actually simplified things for me. Since I realized that it is not easy to write a post which explained my point in details and at the same time not to quote half of the book. I updated my post to include the original aggregate volatility formula from the book, found that formula not only contains coefficients but is also non-linear SQRT(A^2+B^2). This invalidates all my attempts to find some mathematical validity in subtracting blue and orange lines assuming they represent option prices or IVs. So my previous post can be safely ignored. Sorry for this. Then, I was assuming you are plotting option prices (and not IV's). Since y axis did seems to be like option price. But now you are talking about normalization. Thus, it turned out I still do not understand what and how you exactly calculate and plot. And how normalize the data. So I think there is no point to further discuss your implementation and the charts. I'll just assume you know what you are doing. I believe RV charts have no such issues, since they just show straddle prices from different expirations expressed as percentages. It is very clear what they show, and what their limitations are. There are no attempts to subtract some BS based calculated volatilities e.t.c. All straddle prices have the same source (market) the dimentions match. Surely, these charts can be significantly improved if one implements a volatility model designed specifically for earnings events. I can not suggest a better that this methodology, since I do not completely understand the rationale behind you methodology as well as some implementation details (for example what is the normalization procedure). But, if I was going to implement "better RV charts methodology", I would take Aggregate Volatility Formula and Earnings Volatility Model from Brian's book. Then implement a methodology to split market IV into EarningsIV and NormalIV (I am using terminology strictly as in book). Then I would think what our edge really is? We are trying to find situations when IV rise is more or equal to the theta decay. So the first idea will be to plot RV charts using the EarningsIV component only, ignoring NormalIV component. Second idea, take the Earnings Volatility Model and calculate the TrueGreeks, which take into account earnings events. Then we can plot charts like TrueVega/TrueTheta. That can possibly allow us to find situations where Vega/Theta ratio is good enough to enter the trade. And third idea is having calibrated earnings volatility model run a MonteCarlo simulation on a range of potential price movements till earnings, average the results and check where average NetProfit/MaxDD ratio good enough to trade the strategy (this is exactly what Brian's EEVIntegrated2 Excel spreadsheet does).

.

Ok, thanks! Now I believe I understand the idea behind, and the implementation. One more question. When you calculate OrangeLine and take IV of the straddle from T-25, what are you using: is this an IV of the current cycle, or an average IV from the past cycles? I can see some value in taking IV of the straddle from T-25 from an average IV of past cycles (this will be close approximation to a Normal IV of the past cycles on average, since it is around 25 days to earnings and IV does not start to rise much). But if OrangeLine is derived from current cycle prices, it becomes really difficult to tell what the difference from BlueLine and OrangeLine really means in a mathematical sense.

@RapperT, Well, then I am not sure in what part I misunderstood you as you indicated above. My description of how the orange line is calculated and why this calculation is not correct in a presence of a binary event seems to be accurate enough. That said, I found ORATS service does have some proprietary method to calculate what they call Fair Volatility (levels to which implied volatilities are projected to fall after earnings, plus an adjustment for the forecast earnings move - https://orats.com/data/earnings). If you are using this service as a data provider, it seems this data can be used to properly model earnings volatility without creating sophisticated volatility models manually. I just do not see any indication you are using some kind of differentiation between earnings volatility and normal volatility in your calculations. You mentioned ORATS IV skew - I am not sure what exactly this references to (IV30, horizontal skew?).

Can you, please, at least, explain how do you calculate the orange line? The blue line seems to be an average volatility from the past cycles. But there were no clear description for the orange line calculation. This does not make it easy to properly interpret the charts.