Ahhh Implied volatility

As mentioned that wark was indeed resumed, I was doing extensive work on an AAPL ticker downloaded from google. When I compare it to the COEB (Chichago board of trade) I see that data is not in its complete form. But for playing purposes is just fine. Tough Implied volatility started to be calculated on a heard beat, I think there were either some problems with data but more likely with my algo calculating it. The put version is doing fine and is in pair with the volatility smile, however, the call version is having some problems being evaluated properly. Too many negative values (well only on the call side the negative values are emerging) but also there needs to be a small adjustment with time to maturity being expressed as a fraction of the year. But in any case... a graf was produced... any hints would be much appresciated. Thank you web for making all this things available for free for people to study and learn the beauty of python.

Work being resumed

Some fears have passed. We are back on track.

At the moment I am creating a database and downloading all the options before the new machine becomes functional for development purposes. It is still in its eary phase and some technical difficulties are arising along the way, but if nothing else, I have learned more about installations, drivers, firmware, ...bla bla. Mainly the importance of a haing the luck in setting up the computer in a way that is ready for production. There is enough space to hold all the data and analysis in one place and after this initial obsacle is over... the real production Will take place. Can't wait to translate what is in my head into something useful. Till new updates folks!

Soo.. the new environment is set up. Data being downloaded every day, have created a FRED's account and my volatility is calculated like a charm with a Newton Raphson metod. The oter paramaters are still in production as well as graphics and useful hints programs to be installed. I have some concerns on the dataset and the fact that somebody may get angry to make the invisible visible. But this is just for studying purposes and realizing the size of the options market to make better predictions with other algorithms. Once useful graphs will be produced, it will be updated. However, I have some problems with interpretation and the fact that some outragious numbers are coming out of a bisection. The only answer I have is... the algo is working purely. But we will rewrite and use other methods to check and verify what is coming out. The SSL error stopet being annoying and next time it pups up the pycharm debugger will step me trough.

Also, I think that ECB shall provide a pythion api for the researchers to obtain data much faster to do creative and productive work the same way FED has it. I don't like the upgrade from the latest pandas version that requires an API key to obtain data.. but hey, if data is there and one line of code gets it.. I would not think why not. So, again, we in the EU are some steps behind with this issue and more shall be done to teach in economics classes how to program in pythin to facilitate data retrival and do more productive work.

Project O5X

As regulators are giving higher and higher fines to prevent money laundering and market manipulations with benchmark values and fixing points, the need to establish a well defined analytical framework to prevent such malpractice is crucial. The problem is not as much the available technology, but data access and real time visualization of such practice done by an independent supervisory body that also has authority in stopping transactions and charging individuals that designed such algorithms or human involvement. The malpractice shall be stopped when it happened and the authority shall not have to wait to discover methods and obtain data with days and weeks of delay.

As fines were given for old periods (with years of delay) the case is either the inability of the regulators in understanding the malpractice done in real time or inadequate know how of the loopholes of the regulative framework that allows the players to conduct such scrutiny to their investors. If some practice has been done for years, it is a necessity that the post festum data starts to be analyzed in more debth to establish profits and methods of market manipulations.

For such reason, I propose once more a mobile device, that will capture market data in real time and visualize where and how the orders are coming to the trading platform. Being aware that the detailed, insight into the trading activity is mainly hidden from the analytical side, to increase transparency, it shall be necessary to capture and analyze trading patterns of the registered traders and to have a deeper look into their activity with the analysis of profit generated margins (who and how much is going in and what was the decision being set from the investor and the trader).

As this is the fxcycle blog, I am almost certain that there exists such a thing as the trading cycle and the cyclical pattern like behavior of individuals traders in the fx market. I hope I am wrong, but first, I will have to prove that. :)

Project extension

Past weeks have been intense in realizing how many tools are already available to devlop clever solutions in providing financial transparency to the analysts. Visualization capabilities of centralized market data can give an insight of every outragious order going into the game and flag the transaction as suspicious linking it to the source. So my question at the moment is: If we take into account all instruments that rely on a "fix" system placing real time visualization tool on incoming orders, it would fastly provide a clue wether or not market manipulation is taking place and spotting exactly the order sources. So, if manipulation was taking place on such important and prifine instruments as exchange rates, it is doubtful that other instruments relying on the fix system would not be a subject of such scrutiny. Would such monitoring bug be efficient in spotting machine manipulations as well?

Implied volatility cont. (my processor hates you!)

Question of the day: What to do when implied volatility from Yahoo! Finance is 0.00% or is repetitive for a too long period of time????

I decided that I will go the hard way in obtaining its value. I could use any build in functions that uses the BS formula and solve it , but I thought to myself, why using the black-box if I can program it myself. So, I made use of the Newton-Raphson Methond. It took some time to realize how to apply it to my specific data, but once I was done with implementation a monster came out that is killing my poor processor. And the worst it will be that at the end of the process, there will be something wrong with calculations and the process will have to be repeated. Noooo.... it has been going for 20 minutes already, and I am just goofing off in the meanwhile since the rest of the things work extremely slow.

Doing some calculations, if such a thing has to be repeated over and over again for about 300 * 15 times.. how long it would take to compute a simple Implied volatility for values that are 0??? So please, dear Yahoo! Finance, be so kind and evaluate the IV for me otherwise I will melt my processor to do this project! If somebody would like to give me some help, here is what I have been strugguling with in python:

http://stackoverflow.com/questions/33988048/inneficient-loop-accesing-option-types

Implied volatility vs delta

The clasification of options between out-of-the-money, in-the-money, and at-the-money will be a determining factor in properly applying the extraction methodology and obtain meaningful results for different options monsters. After some python experimentation, the dataset is ready to be analyzed and available for calculations. My question today revolves around the the mening of the obtained graf in delta vs. volatility space.

The shape from the graph makes sense, since delta values for calls and puts are positive and negative. Volatility is positive since is the percent change and is provided by the courtesy of Yahoo! finance. On this note, I will spend some time in finding out two things:

1. How does yahoo! finance calculate implied volatility? (probably BS!)

2. What Risk free rate do they use for calculations?

Literature and internet review showed that many people that deal with the BS formula omit the discussion about the risk free rate and its estimation or use. Given that IV is provided, one can extract the risk free rate from it. Once I compounded the BS formula with D-parameters, I came to find out that this will not be a simple task to do. The r parameter is found both in the original equation and in the proces of calculating the normal distribution. Have fun whomever will decide to figure this out!!! :)

Lastly.... from one paper where deltas and implied volatilities are plotted, only positive deltas are used for both calls and puts that are out-of-the-money. Were deltas put in absolute values to extract the estimation function?

Python can keep you entertained all day!

It was about time. As the route in implementing probability density functions to option data is somewhat leghty, being as stubborn as I am, I continued with solving problems regarding data acquisition and preparation for further calculations and analysis.

Data from yahoo! finance is an excellent medium to observe options prices and doing simple quests and calculations for the unindexed parameters. The best part, that such data became freely available to the public (I do not know exactly where it comes from, but for studying and testing purposes is excellent). However, making use of the Black Scholes formula with the downloaded data is a total nightmare to obtain (yes, I can save you some time with my going around the bush script if you want to come up to speed with this development).

After a nice day with reading about python, I finally made a put-call graph that normally you do not see in any classes. I will polish it and make it more readable in the future.