Python Type Hints: A finance use case example: Part 1
Read the full article, and part 2 right now, on the Developer Portal.
in part 1: we will (i) automatically find the Option (of choice) closest to At The Money (ATM) and (ii) calculate its Implied Volatility & Greeks. We focus below on Future (Monthly) Options on the Index ‘.STOXX50E’ (EURO STOXX 50 EUR PRICE INDEX) (‘EUREX’) and ‘.SPX’ (S&P 500 INDEX), although you can apply the logic below for another index. To find the ATM instrument, we simply and efficiently use the Search API. Usually, the calculation of the Black-Scholes-Merton model’s Implied Volatility involves numerical techniques, since it is not a closed equation (unless restricting assumptions that log returns follow a standard normal distribution with mean is zero, μ = 0, and standard deviation is zero, σ = 1, are made). If we used these techniques in calculating each Implied Volatility value on our computer, it would take several seconds — if not minutes — for each data point computed. I have chosen to use the Instrument Pricing Analytics (IPA) service in the Python Refinitiv Data Library instead, as this service allows me to send model specifications (and variables) and receive several (up to 100) computed Implied Volatility values in one go — in a few seconds. Not only does this save a great deal of time, but also many lines of code! Finally, we will put it all in one function.
In part 2: We will implement a functionality allowing us to apply all we did in Part 1 to expired options. You’ll see, it’s not as simple as it seems. We will then put it all in one function using Type Hints. This, in itself, will also be rather new and exciting!
In this 1st part, we will go though:
Importing libraries such as `refinitiv.data` to collect financial data.
We’re 1st going to show case how one can calculate the Implied Volatility (IV) for Future Options on 2 indexes (.STOXX50E & .SPX) trading ‘ATM’, meaning that the contract’s strike price is at (or near — within x%) parity with (equal to) its current treading price (TRDPRC_1). We are also only looking for such Options expiring within a set time window; allowing for the option ‘forever’, i.e.: that expire whenever after date of calculation. To do so, we 1st have to find the option in question. To find live Options, we best use the Search API. To find Expired Options we will use functions created in Haykaz’s amazing articles “Finding Expired Options and Backtesting a Short Iron Condor Strategy” & “Functions to find Option RICs traded on different exchanges”.
Live Options, in this context, are Options that have not expired at time of computation.
We best use the Search API!
Now we have to use the aforementioned logic to construct expired Option RICs.
Now implement a logic to make our end-function more relevent to today’s traders.
Now things are getting tricky. Let’s collect all the data we need to make sure we cover all grounds.
We obviously need that to compute Implied Volatilities.
Let’s optimise our code for exchanges in mind.
We obviously need that to compute Implied Volatilities.
We obviously need that to compute Implied Volatilities.
We are going to assume no dividends.
On the Developer Portal, one can see documentation about the Instrument Pricing Analytics service that allows access to calculating functions (that use to be called ‘AdFin’). This service is accessible via several RESTful endpoints (in a family of endpoints called ‘Quantitative Analytics’) which can be used via RD. However, while we are going to build towards a Class that will put all our concepts together, I 1st want to showcase the several ways in which we can collect the data we’re are after, for (i) all trades & (ii) at option trades only (i.e.: not every trade of the underlying) and (a) using the RD delivery layer & (b) the RD content layer.
As you can see, not only can we use IPA to gather large amounts of bespoke, calculated, values, but be can also portray this insight in a simple, quick and relevant way. The last cell in particular loops through our built functions to give an updated graph every 5 seconds using ‘legacy’ technologies that would work in most environments (e.g.: Eikon Codebook).
