Matching Call and Put Data for Parity and Volatility Analysis
Summary
This document discusses pairing European call and put observations from separate price files when their option identifiers differ. It recommends matching on valuation date, expiration, and strike, with the underlying security also included where relevant. Such matched observations can support put-call parity checks and implied-volatility comparisons. Calls and puts at different strikes are not parity pairs; implied volatility across strikes instead forms a volatility smile for a given expiry.
The responses explain that unmatched records may arise because not every strike has quotes on both sides, often reflecting differences in trading interest and liquidity. One response also gives a database join approach using strike, expiration, date, and security identifier. The discussion is practical but does not address data-quality complications such as stale quotes, bid-ask selection, contract adjustments, or corporate actions, all of which can affect empirical comparisons.
Key ideas
- Match calls and puts by strike, expiration, valuation date, and underlying security.
- Different option identifiers do not prevent matching contracts with corresponding terms.
- Options with different strikes are not put-call parity pairs, though their implied volatilities can map a smile.
- Missing matches can reflect a lack of quotes or trading interest on one side.
- Quote quality and contract adjustments can complicate parity and volatility comparisons.
Tags
Full text
# How to synchronize put and call option-data? # How to synchronize put and call option-data? I recently retrieved a large amount of European option data, for call and put prices, from OptionMetrics. Doing so for the same time period I get a file consisting of 62558 rows of call prices & 62557 rows of put prices Additionally, both files contain on each row some characteristics such as - The option ID - The date of the price - The expiration data of the option - Bid/Ask price - Strike price As the option ID's do not match between the call and put options, I am wondering what the best way is to synchronize these data sets? This is needed for instance to calculate the pull-call parity; in that case I need for every call price a corresponding put price. My suggestion is to look at the strike price, date of option and expiration date and when those match to treat the put and call option as similar, i.e. they belong together. I tried this and immediately noticed that in some cases the corresponding strike price is different for the one or other, even when the dates and expiration dates match. - What are other ways to match the put and call data? - As the number of rows didn't match, some call options will not have a corresponding put price or vica versa, why is this? ## Answer by Rian Rizvi (score 1) https://quant.stackexchange.com/a/7783 European calls and puts have the same volatility value when they are matched by time to expiry and strike. So if you do match them by time to expiry, strike and price date then you can calculate the implied volatility and look for discrepancies, under the assumption that they should be the same, due to put-call parity as you say. Not all options of the same expiry have the same strike. On any given exchange expiration date, there will be many puts and many calls, with different strikes. Options with different strikes are not a put-call parity match. Instead you will be able to back out the different implied volatilities of different strikes and graph them. That graph (implied vol vs strike for a given expiration) is called the Volatility Smile. If a particular strike on a given expiration does not have both a put and a call, it is because there was not sufficient interest in the one of the options to deserve a quote. This is usually true for low strike calls and high strike puts, which have a high intrinsic value and as such demand too much capital to trade. ## Answer by Eli (score 0) https://quant.stackexchange.com/a/7844 If you load the table above into any RDBMS that supports SQL, the query you could use would be: ``` SELECT DISTINCT A.OptionID AS CallID, B.OptionID AS PutID FROM OPTION_PRICE A JOIN OPTION_PRICE B ON A.Strike = B.Strike AND A.Expiration = B.Expiration AND A.Date = B.Date AND A.SecurityID = B.SecurityID WHERE A.CallPut = 'C' AND B.CallPut = 'P' ``` This maps call option IDs to put option IDs. ## Answer by demully (score 0) https://quant.stackexchange.com/a/47086 Yes, matching by strike, expiry and valuation date makes total sense. My guess is that you're only getting valuations for options that have valuations, ie options that have been written. Or at least against which the dealers have bothered to offer quotes. In which case, I suspect the mismatch you're getting is lots of calls with high strikes that have no associated puts; and lots of puts with low strikes but no associated calls? In effect, you're just picking up the willingness of investors to invest in low-delta OTM "lottery ticket" structures. Imagine your local amateur football team got picked by random to play Man Utd at Old Trafford tomorrow. Odds of a win = 1 in 10,000. More people will be happy to risk a cheeky tenner to make a hundred grand, than lay down 99,990 to make the same tenner the other way. So it is with options - more people prefer the out-of-money position that costs peanuts to the deeply in-the-money one that costs market minus peanuts. If the liquidity is all on the OTM side, there is no incentive to ever trade thus ITM. Who will be around to trade with me if I want to close it before expiry? Far simpler to synthetically create the ITM call/put side via the OTM put/call plus future, both of which are liquid. hope this helps.
Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.