Clarify definition of “optimal contract” in `Contract.find_optimal()`

[jayurbain]

Thanks for sharing. Looks interesting.

How do you define "optimal contract?" What is the learning objective?
Thanks

[xmootoo]

Hi @jayurbain, thank you for your question.

The optimal contract, which is the returned contract from calling Contract.find_optimal() is based on a fixed method which simply finds the closest contract to your specified conditions based on the available lists of expirations and strikes, for a contract starting on start_date. These lists can be queried directly from the ThetaData API.

Expiration

The core parameters that affect this are:

• target_tte: The desired length or Time to Expiration (TTE) of the contract (in days), e.g., 30 days.
• tte_tolerance: A tuple that specifies the lower and upper bounds of the TTE (in days). This is necessary when a contract with the exact target_tte does not exist.

The method queries against a list of expirations for contracts that begin on given start_date. If an exact match corresponding to target_tte (e.g., 30 days) is found, we use this expiration; otherwise, we find the closest expiration to target_tte (e.g., 27 days), and assert that it must be in the range of tte_tolerance (e.g., 15 days to 45 days). If no expirations are found within this range, it raises an error.

Strike

After the desired expiration is found, we then search for the optimal strike price, according to user-specified parameters in Contract.find_optimal(). If moneyness="ATM" (At The Money), then we simply select the strike price that is closest to the underlying's price at the specified start_date of the contract.

If moneyness="ITM" (In The Money) or moneyness="OTM" (Out of The Money) then there are two options for selecting a strike.

Fixed Strike Band

If volatility_scaled=False, the strike selection algorithm relies on a strike_band parameter which represents how far above (or below) the underlying's price to set the strike at. For example, if strike_band=0.05, right=C (Call), and moneyness="ITM" then we set the desired strike to 5% below the underlying's price on start_date. If right=P (Put), then this would be 5% above the underlying's price on start_date. A similar idea applies if moneyness="OTM", except we select 5% above for calls and 5% below for puts.

After we have found the desired strike (e.g., $147.29), we query the ThetaData endpoint's list of strikes, and find the closest valid strike (e.g., $145.00). After this step the contract selection step is complete, and we return the optimal contract.

Volatility-Scaled Strike Band

If volatility_scale=True, the strike selection algorithm relies on two parameters:

• hist_vol: The historical volatility of the underlying.
• volatility_scalar: The number of volatility units (i.e., standard deviations) to scale the strike up or down by.
  A pre-computed historical volatility of the underlying is required, however, it can be calculated using the utility function optrade.utils.volatility.get_historical_vol. The volatility_scalar parameter replaces strike_band from the previous case, where we select hist_vol*volatility_scalar % above or below the underlying's price on start_date. For example, if hist_vol=0.1425 (14.25%) and volatility_scalar=2.0, then for our previous example of right=C (Call) and moneyness="ITM", we set the desired strike at 28.5% below the current underlying price.

After setting the desired strike, we use the same method as described above by querying against the list of valid strikes, and selecting the closest one to the desired strike, and return the optimal contract.

This volatility-scaled strike selection was implemented for multi-underlying modeling in mind, where a fixed strike band such as 5% may not represent optimal strike selection between tech stocks (high volatility) and utility stocks (low volatility), if you are interested in modeling a "similar" contract among various different stocks, with a single parameter volatility_scalar but adjusting the hist_vol based on the underlying. Just keep in mind that hist_vol must be computed prior for each specific underlying, and in the method that you believe is most appropriate.

Thank you again for raising this issue as it's an important component to OpTrade, much appreciated! I will eventually add this information to the documentation under Usage section. If you have any more questions, please let me know.