Using Put-Call Parity to Price the Less Liquid Option

Summary

The document explains why an option pricing engine may calculate one European option price and derive its paired call or put price using put-call parity. Because parity is a no-arbitrage relationship, deriving the second price from the first helps keep the two prices internally consistent while avoiding separate numerical calculations that could introduce independent errors.

The practice is especially relevant when calibrating pricing engines to market data. Liquid options are often at the money or out of the money, so the corresponding in-the-money option for the same strike and expiry can be obtained through parity. The explanation is concise and does not provide the parity equation, discuss settlement conventions, or quantify numerical error or computational savings. Its guidance assumes the options satisfy the standard European put-call parity conditions and that the relevant market inputs are available.

Key ideas

• Put-call parity imposes a no-arbitrage relationship between European calls and puts with the same strike and expiry.
• A pricing engine can derive one option price from its paired option to maintain internal consistency.
• Separate calculations may introduce independent numerical errors without adding useful information.
• Calibration often uses liquid at-the-money or out-of-the-money options, with the paired in-the-money price derived by parity.

Tags

# Call options or put options with put-call parity


# Call options or put options with put-call parity












When pricing European call options, is it preferred to price them directly or pricing a put first, then using put-call parity?

I've read somewhere that the latter method is preferred in some numerical methods. Why? Isn't that just an extra step in the calculation that might slow us down?

## Answer by siou0107 (score 1)

https://quant.stackexchange.com/a/50963

Put-call parity is a basic no-arbitrage requirement of any option pricing engine. Why would you consume computation time and get numerical errors in pricing the call AND the put? Alternatively, you could only have some numerical error on the, say, put, and then an internally consistent call price at almost no extra computational cost.

In practice, pricing engines are calibrated using liquid options, which are ATM and OTM options, and the corresponding ITM option's (for a given $(T, K)$ pair, if the call is OTM the put is ITM) price is computed using put-call parity.

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.