Options Support

[jaredbroad]

Support for options trading. Broadly speaking this will have several pieces. Lets scope out the depth of the changes needed here:

PHASE 1: LEAN

• New security type
• Options fill models
• Option pricing/fee models
• New option data type which holds the strike price/deltas/thetas etc for a specific option-strike-call/put-expiration..
• Option symbol builder (combining all the pieces which make the option unique)
• Option data type also needs to look up the option data for its symbol.
• AlgoManager sends in add subscription requests to the Datafeed who adds the option data requested (and creates associated security objects)

Proposed User Facing

• AddSecurity("SPX", +2(strikes assumed symetrical), Calls, TimeSpan.FromMonths(6)) User adds an Underlying, +- strike deltas from market, type, and TimeSpan in future.
• We access the option data in the slice array, simplify indexing:
• slice.Options["SPX", 2 (strikes), OptionType.Call].ToList() of Option objects.

ToolBox:

• Tool for converting from X-popular data provider into LEAN data format.

PHASE 2: Brokerage and live trading support. TBD.

[jaredbroad]

Mentioned in this forum post: https://www.quantconnect.com/forum/discussion/769/work-with-quantconnect-options-expert-required

[AlexCatarino]

I can't call me an options expert or trader, because I am neither, but since I am a CQF alumni, I think I can take care of phase 1.

[jaredbroad]

:) cool, lets scope out the design. Im sure there's things I've forgotten --- what else needs to be written to support options? Step by step -- from parsing the data, storing the data, creating objects... I think the work will touch all of LEAN at different levels.

[AlexCatarino]

I think that parsing and storing the data would be similar to equities. The objects would have the members that you mentioned and the model to calculate it. I think we have to use "vanilla" Black-Scholes to get implied volatility and the greeks as a default and the user could implement his/her own model replacing Black-Scholes if he/she wants to. We could implement options classical strategies such as straddle, butterflies, etc... too so that a user could just write Straddle("APPL", 2 strikes or sigma).

[guarilha]

I have worked with Options Trading. If you guys need some help I'd be happy to contribute.

I think QuantLib has two great lists: one for pricing models and one for financial instruments that could be used as reference.

[AlexCatarino]

1. Data

Step 1: Tool for converting from X-popular data provider into LEAN data format.

Step 2: Storing the Data.

Step 3: Parsing the Data

Concerning the storage, the folder with tick/second/minute/hour files must include the underlying name, type (call or put), style (european or american), strike and expiration month and year. Or the folder only include the underlying name and the files hold the rest of the information. Or, we could add more subfolders: Data/options/usa/underlying/type/style/expirationyear_expirationmonth/strike_yyyyMMdd.zip.

We need map files to account changes in the strike due to dividend payments.

[jaredbroad]

Good idea @AlexCatarino: lets start piece by piece -- creating and parsing the data is a good first step. Thanks @guarilha for the offier, please contribute to the thread! :)

Does the style vary within a market? (e.g. USA is all american style) are there both styles in European markets?

I think we need the full date to handle weekly options as well

The strike is sometimes fractional right - so it would be price of the strike in centi-cents (1/10000 of a dollar like our equities): expiration YYMMDD, then price of the asset over time in the final zip. e.g. $17.5 strike = 175000

Also finally it has to be trades and quotes: and to make it the same format as the other files lets flip the date:

Data/options/usa/spx/put/exercise/20140801/yyyyMMdd_1750000_trade.zip

[jaredbroad]

Tagging some others who've registered interest in options: @rbohac @cuda @craig-stevenson

[lssilva]

Wow Super, we are going to get Options support. It would be nice on the top-level to have some abstract order combos like Spreads, Iron-Condor, Calendar. It makes a bit hard to code the execution model but it is really a good help when writing the algo.

[AlexCatarino]

@jaredbroad According to the CBOE, many index options are European-style. I couldn't find any info that would tell me whether weekly options are all American or European-style.

So far, I got the following format to handle all kinds of options:

• Data/options/usa/ underlying / timespan / type / style / expirationdate / yyyyMMdd_1750000_trade.zip

where timespan is the string "monthly" or "weekly". I don't think that full date is enough to distinguish monthly and weekly options, since CBOE itself uses a "W" in the ticker for weeklys and Fridays are not reserved for weeklys to expire.

Are we going to put together in the same "options" folder equity options, fx options, commodity options, etc?

[jaredbroad]

Great to know US has both styles,

I believe "timespan" is still good as a date, " (i.e, Weeklys are not listed if they would expire on a 3rd Friday or if a Quarterly option would expire on the same day)." -- does this mean if the Weekly and Monthly line up, the monthly wins. I don't think there really is a "timespan" its just a date the option sold for, is there some page where we can see two identical options with same date?

[jaredbroad]

"Are we going to put together in the same "options" folder equity options, fx options, commodity options, etc?" -- Good question, do you know the variation of the namespace for the different types? What format are each name?

Whether we split them up physically in data should depend on whether the Option object which is generated is different across each sub-option-class. i.e. What extra information will each option have? Is it enough to have an option base class, with CommodityOption extension?

[rbohac]

I thought it would be handy to throw some possible use cases on here:

Short Put & Vertical use case 1) I'll commonly want to enumerate expiration dates for an underlying. As an example I'll want to find a monthly expiration nearest to 45 days out. 2) I'll commonly want to select strike prices based on the greeks. As an example, I may look for a PUT with nearest to a delta of -0.05 3) From number 2 I'd want to move up or down the option chain based on the open interest.

Covered Call Use Case: Using technical analysis I'll select an underlying and want to manage covered call writing for cost basis reduction. This scenario is a little easier: 1) Enumerate expiration looking for an appropriate expiration based on a calculation 2) Ability to enumerate strikes finding strikes that are nearest to a goal with enough open interest and/or a bid/ask spread within a calculated range (a helper property for midpoint would be handy) 3) Ability to easily compare a call price against a price for the same strike on a different expiration (compare shorter weekly to monthly for example)

Note: Strike price availability varies by expiration. For example: WYNN -> Oct15 offers in $1 increments whereas OCT215 (weekly) offers in $0.50 increments. We will need to have the concept of "Not Offered".

Would be handy to have functions like (in Psuedo-code): Securities[symbol].GetMonthlyOptionChain(12).GetStrike(1200).Put.Midpoint

[AlexCatarino]

@jaredbroad I just read specifications here and I understand that all is fine, we don't need to make an explicit distinction between monthly or weekly or quarterly options which is wonderful because it would imply different pricing models.

The difference between options for different underlying security is the cost-of-carry. We need to inform the dividend yield to compute it for equity options and risk-free rate for the foreign currency for FX. So we don't need to split them physically and one option class is enough. If we split it, it would be only a matter of organization, so that's up to you.

Very handy, @rbohac. Thanks. You would like functions like GetMonthlyOptionChain(12) and GetWeeklyOptionChain(12) to make a distinction between both and maybe GetAllOptionChain(12) to be able to trade monthly and weeklys indifferently?

[mchandschuh]

@AlexCatarino @rbohac - can you explain the importance of the distinction between the weekly/monthly/quarterly contracts? My understanding is that the weeklys are just offered closer to the expiry, so CBOE states that weekly contracts are available for a consecutive six weeks.

Are there benefits to trading one verse the other? I would imagine the open interest would be higher in the monthly/quarterly since they've been offered for longer. I just want to understand the desire to segregate them in the algorithm.

[AlexCatarino]

Hey, @mchandschuh! Fact is that I've never looked closed into weeklys. I'm learning here that there's no actual difference from the quantitative finance perspective. I hope other could tell us if there is a difference from the options trading perspective (apart of liquidity and open interest, of course).

[glyphard]

Weeklys are actually quite liquid in some names like SPY and QQQ. Take a look at the open interest and the volume. They are traded primarily on the nearest few weeks to the extent that demand supports it, and they are priced just like any other option.

Weeklies are popular with hedgers, but have also become quite popular with premium sellers who want to have steeper theta decay in their portfolio as much as possible, which is well suited to a weekly product vs a monthly/quarterly cycle product.

Someone may have already said this, but in regards to the option symbols and the chain, there is no difference in the option symbol nomenclature for weeklies vs monthlies vs quarterlies, just the date is different. And the regular monthly/quarterly options end up being the weekly option of the week that they expire in, so there is no dual listing/valuation issue to be concerned with.

HTH

-Ashley.

On Sep 17, 2015, at 15:40, Alexandre Catarino notifications@github.com wrote:

Hey, @mchandschuh! Fact is that I've never looked closed into weeklys. I'm learning here that there's no actual difference from the quantitative finance perspective. I hope other could tell us if there is a difference from the options trading perspective (apart of liquidity and open interest, of course).

— Reply to this email directly or view it on GitHub.

[jaymjordan]

This is fantastic. I just stumbled on QuantConnect a couple of days ago and was disappointed to see options weren't supported yet. It's great to see some action here as I haven't found anyone else doing anything around options.

A couple of thoughts on the discussion so far:

Weekly Options: As @glyphard pointed out I find them useful for premium selling. There can be issues with liquidity and you often need to adjust your strikes when rolling from weeklies to monthlies. That's only a problem for execution.

The only issue I see is marking weekly and quarterly options so you can screen them in or out. I like the (W), (R) or (M), (Q) format you see on some platforms.

A couple ways I often see expiration dates being quoted are SEP 4(W), SEP 11(W), SEP 18, SEP 25(W), SEP 30(Q) or SEP1, SEP2, SEP3, SEP4, SEP5. I find the former much more clear.

[jaredbroad]

Welcome @jaymjordan! :)

@all, In general its important to separate engine concerns from API concerns. I think we're all in agreement there's no physical difference in the data between a weekly/monthly/quarterly option. So for the purposes of the engine we'll treat the data as the same. We can separate them in the API once we get there.

Now we've roughly figured out the data structure, I think its important to do this in tiny tiny steps to make sure we can actually finish and keep the reviews manageable.

So, first mini-project: Create a QuantConnect.ToolBox project which converts options data from a popular vendor into LEAN format discussed above. @AlexCatarino can you spearhead this one? Which vendor should we start with?

[AlexCatarino]

@jaredbroad Yes, I can take the data conversion. By the way, I'll be moving my GitHub project on converting Bovespa data into LEAN format.

I don't know about vendors. You do the shopping, I cook the dinner. ;-)

[jaredbroad]

@AlexCatarino - excellent, I've chatted with a few vendors and will pick one and get a sample file to begin the conversion.

[jaredbroad]

OK after chatting with some vendors we might need to process the data to get it into a format useful for us / something we can use for options backtesting. What do you guys think about this data: 1 Minute Aggregations: With Values of:

Time, Underlying, Strike, Expiration, Trade(Open, High, Low, Close), Quote(Open(Bid,Ask), High(Bid,Ask), Low(Bid,Ask), Close(Bid, Ask)), TradeVolume, QuoteVolume

If there were no trades in a minute we'd just have an updated quote range bar and 0-volume on the final column.

Would this be enough to correctly do custom IV models? With the close bid-ask we can at least model the fill prices accurately.

[glyphard]

You also need to include the option type( e.g. put or call). IB's API call's this property 'Right' but that's always been a confusing property name, IMHO... So I suggest choosing something more descriptive, like 'OptionType'.

On Sep 23, 2015, at 16:58, Jared notifications@github.com wrote:

OK after chatting with some vendors we might need to process the data to get it into our format, something we can use for options backtesting. What do you guys think about this data: 1 Minute Aggregations: With Values of:

Time, Underlying, Strike, Expiration, Trade(Open, High, Low, Close), Quote(Open(Bid,Ask), High(Bid,Ask), Low(Bid,Ask), Close(Bid, Ask)), TradeVolume

If there were no trades in a minute we'd just have an updated quote range bar and 0-volume on the final column.

Would this be enough to correctly do custom IV models? With the close bid-ask we can at least model the fill prices accurately.

— Reply to this email directly or view it on GitHub.

[AlexCatarino]

I have finished a first version of the data converter where we read the data from a vendor and write it on Lean format. Next, we will feed Lean with this data. I've noticed that the Tick and TradeBar object need to be extended to incorporate options information (strike price, expiration date, call or put, etc). Also I think that Tick and TradeBar are not quite ready to accept quote data. For example, tick don't have any field for quantity of bid and ask.

It'd be odd to out quote data in an object called TradeBar, but I don't know if we want to rename it or create a QuoteBar object.

[jaredbroad]

This is a tricky question! It covers virtually all aspects of data + options and future proofing! :) I had a brain storming session with Michael and this is what we sketched up so far:

0> Adding BidSize and AskSize to the Tick type will allow it to support all the tick information required.

1> Like Equity and Forex, Option type can be the security: Option : Security

3> Add an IContract type to all BaseData as well. This would be part of the Subscription for the security object and we'd set a readonly reference to it in the BaseData.

4> Then OptionContract is a type of IContract, which holds expiry, strike, deltas, greeks etc. for the Tick/Bar specific to options.

4.5> TradeBar changed to implement an IBar. TradeBar : BaseData, IBar {} -- IBar would define the Time-OHLC comonents of the bar. TradeBar would add in the Volume.

4.6> QuoteBar :BaseData, IBar, where the OHLC is the midpoints of bid and ask. Then QuoteBar.Bid and QuoteBar.Ask are also IBar properties which are the OHLC of the bid and ask prices. They could be accessed by quote.Ask.High

5> In the same way as Ticks, TradeBar/QuoteBar types could have an IContract field which specifies the option contract we're talking about (IContract lives on the BaseData object). So data (Ticks, QuoteBar and TradeBar etc) all have contracts.

5.5> We create an EquityContract and ForexContract which might hold other unknown information specific to the equity/forex. e.g. Shortable, Counterparty etc OptionContract : IContract { Expiry, Strike, Delta, Greeks, ...Derived values }

6> Like Ticks and TradeBars type, Options type could hold collections of chains indexed by symbol so users can use OnData(Options data) { data['GOOG'] } Options : DataDictionary < Symbol, OptionChain >

7> Inside the OptionChain collection would be all the strikes and expiration for a symbol at a point in time, along with a lot of helper methods for accessing / searching the data: OptionChain { Time, Symbol, BarCollection (TradeBars and QuoteBars)
//All the helpers -- get X . get Y . Call . Get(strikes: -2, expiry: TimeSpan.FromWeeks(2)); }

Feedback welcome!

Other thoughts:

Make liquidation behaviour at the delisting event a pluggable setting, so then option exercising can be handled using the standard QC delisting system.

Each option-strike-expiry would be a unique security, with a long type symbol code. This would enable actions like: Buy(symbol:"SPY.C.1950.20151101", quantity:11); The Long form symbol could have a wrapper which converts it to real numbers: Buy("SPY.C.-2Strike.14-Days", 11);

We'd need a brand new concept we don't have yet, an IExerciseModel, for converting the contract to stock. This could be set on the Option security like the fill models, and would allow for designing European vs American style exercise.

[AlexCatarino]

Concerning the data conversion and parsing, I don't have nothing to add to the solution @jaredbroad and @mchandschuh 's brainstorm gave us for now. In order to change LeanDataWriter to convert the vendor data properly (without relying on alternative objects for Tick, TradeBar and QuoteBar) and parse the converted data into Lean, we need to parts of all @jaredbroad listed from 1 to 4. For this phase, OptionsContract doesn't need the greeks and implied volatility.

[glyphard]

Jared's proposed solution makes sense to me.

The only piece that I'm unclear on is how you tell that the option you are looking at in the 'ondata' is a put or a call. I may have missed that detail in the thread.

On Oct 21, 2015, at 12:37, Alexandre Catarino notifications@github.com wrote:

Concerning the data conversion and parsing, I don't have nothing to add to the solution @jaredbroad and @mchandschuh 's brainstorm gave us for now. In order to change LeanDataWriter to convert the vendor data properly (without relying on alternative objects for Tick, TradeBar and QuoteBar) and parse the converted data into Lean, we need to parts of all @jaredbroad listed from 1 to 4. For this phase, OptionsContract doesn't need the greeks and implied volatility.

— Reply to this email directly or view it on GitHub.

[jaredbroad]

Hey @glyphard -- it would be specified in the OptionContract : IContract, which would live on the base data. Then the Collection of TradeBars / QuoteBars in the OptionChain for this timestep would have all the information it needs to be searched by the UX layer.

[glyphard]

Ok, makes sense. Thanks for clarifying.

On Oct 21, 2015, at 15:26, Jared notifications@github.com wrote:

Hey @glyphard -- it would be specified in the OptionContract : IContract, which would live on the base data. Then the Collection of TradeBars / QuoteBars in the OptionChain for this timestep would have all the information it needs to be searched by the UX layer.

— Reply to this email directly or view it on GitHub.

[mchandschuh]

Just to clarify, the addition of the IContract abstraction will be done separately. It will require some serious changes and thought to the way essential subscription information is passed around the system.

Looking at he roadmap, we should be able to skip number 3 ( add IContract) and continue with the IBar implementation. Also, work can continue on the concept of the OptionChain which should be relatively insulated from the IContract changes.

I'll try and implement the IContract system within the next week so that this doesn't turn into a roadblock.

Apologies for any confusions/miscommunication.

[rbohac]

Something to think about. How will a user request to watch pricing updates for a particular option? We will need to have something that limits this.

For instance AddSecurity(SecurityType.Option, Symbol, Resolution.Minute,Expiration,Strike,Put);

There is too much data to continuously refresh the entire option chain for a security.

Also note that brokers (IB for sure) have limits on the number of securities you can subscribe to at any given time. If I recall their limit is 200 unless you buy extra data packs.

Bonus: It would be handy to also have a way to iterate through the option chain for a certain expiration. A use case for this would be to find a strike price where the Delta is within a certain threshold

Example: I commonly go ~ 65 days out on SPX puts and look for a strike that is a multiple of 25 where the delta is closest to -0.08

[glyphard]

There is an important distinction to draw here.

IB's limit is in place because their data is live, not for back testing, and as such data has to flow out from a ticker plant in a data center to quote terminals (TWS client) and they have to pay egress charges for the bandwidth that their data consumes. They place that limit on live option quotes so that they don't have every customer asking for all strikes from all expirys and not really using the data... For the simple reason that this would explode their data costs.

The situation in options backtesting is very differnt. The data is already present in the environment where it needs to be processed and does not have to stream outside of the datacenter. So having a subscription to one strike or all strikes for an expiry in an underlying does not place a significant overhead on a back test. Granted there are limits to this, as the data set for options, even sampled as 1minute bars, is still quite large, the limit is much much higher than anything one would be subject to in live trading platform like TWS.

Regarding the Bonus, I agree that it would be very helpful to have a way to 'discover' where the end's of the chain are, and to be able to know the strike granularity as strikes are not evenly spaced and they evolve over time as the particular expiry draws near. (Probably worth discussing this in a separate thread though...).

Super excited to see options in QC. Keep up the great work guys!

On Wed, Oct 28, 2015 at 9:55 AM, Ray Bohac notifications@github.com wrote:

Something to think about. How will a user request to watch pricing updates for a particular option? We will need to have something that limits this.

For instance AddSecurity(SecurityType.Option, Symbol, Resolution.Minute,Expiration,Strike,Put);

There is too much data to continuously refresh the entire option chain for a security.

Also note that brokers (IB for sure) have limits on the number of securities you can subscribe to at any given time. If I recall their limit is 200 unless you buy extra data packs.

Bonus: It would be handy to also have a way to iterate through the option chain for a certain expiration. A use case for this would be to find a strike price where the Delta is within a certain threshold

— Reply to this email directly or view it on GitHub https://github.com/QuantConnect/Lean/issues/166#issuecomment-151852614.

[tedpenner]

I'm new to programming in general and have not yet written my first strategy. The wheel just spins for me on the left of the page so I have been unable to use the platform. However, the ability to code in C# seems to have significant promise. The promise of Options support is incredibly exciting.

I have not seen anyone doing automated trading for options in as robust a way as this site appears that it may support, at least not the way that I like to think of doing them. With one platform, I did see some 'attempt' at trading automated equity options trading, but the real issue for me comes in with specifying an explicit strike price to trade. The reason, is that the trigger comes from looking at the underlying, where to trade an option, an explicit strike price must be identified in the option code.

In-The-Money (ITM) trades for instance, have a different strike price than those that are Out-of-The-Money (OTM). It would be nice to be script something that measures the underlying, and then trades based on the number of strikes either OTM or ITM. This way, you would not have to say "closest to a delta of 50" or anything. Rather, you could just specify the number of strikes OTM or ITM as a designator for which strike you wanted to choose at the time of your trigger.

[pms1969]

Not sure how much farther you are through this right now, but I can add some coding grunt to help get this done. If you have a task that is relatively contained and you'd like done, I'd be happy to contribute.

[AlexCatarino]

Thanks @pms1969 and all who wants to contribute. Let me make an update, using Jared's post on October 21st: we have implemented BidSize, AskSize, IBar/Bar and part of QuoteBar (these are points 0, 4.5 and 4.6). @mchandschuh is, as we speak, finishing IContract up. After this is done, we can code OptionsContract and have all the information we need these to code the app that will write the vendors' data in Lean format. That would cover all points, but 6 and 7.

Once we get there, we could talk about new assignments.

[jaredbroad]

Thank you Paul! We'd welcome your help and should make headway/ship the OptionsContract type this week. We've been doing some tidy up on data and universe selection :) As always thanks to @AlexCatarino & all the contributors!

The "SID" / "Symbol" class will be our new way of uniquely identifying securities inside the engine (vs strings). The new "SID" system can hold all the option type data in a single symbol object, check it out here: https://github.com/QuantConnect/Lean/blob/sid/Common/Symbol.cs https://github.com/QuantConnect/Lean/blob/sid/Common/SecurityIdentifier.cs

With SID there's a chance we won't even need the OptionContract type anymore, we'll need to think about this to double check its still required.

If possible,@pms1969 https://github.com/pms1969 @AlexCatarino please review this new code/branch and make sure we havent overlooked anything! This would be a great starting contribution :) Please put any comments on the relevant files,

On Sat, Nov 21, 2015 at 2:44 PM, Alexandre Catarino < notifications@github.com> wrote:

Thanks @pms1969 https://github.com/pms1969 and all who wants to contribute. Let me make an update, using Jared's post on October 21st: we have implemented BidSize, AskSize, IBar/Bar and part of QuoteBar (these are points 0, 4.5 and 4.6). @mchandschuh https://github.com/mchandschuh is, as we speak, finishing IContract up. After this is done, we can code OptionsContract and have all the information we need these to code the app that will write the vendors' data in Lean format. That would cover all points, but 6 and 7.

Once we get there, we could talk about new assignments.

— Reply to this email directly or view it on GitHub https://github.com/QuantConnect/Lean/issues/166#issuecomment-158677066.

Jared Broad

[AlexCatarino]

I had a look at those files (and other at the branch to learn more) and I don't think you overlooked anything. With that we have all we need to write the input files in Lean format. Maybe we don't need the OptionContract to specify the option characteristics, but we still need a class to hold (and probably calculate) the greeks and implied volatility.

[pms1969]

Jared, how do I supply feedback on the 2 classes? And are you purely after logic feedback, or are you open to architectural input as well?

[jaredbroad]

Hey Paul -- all of the above! :) Symbol is an enormous and powerful change in LEAN, allowing complete, deterministic identification of assets with any market, security type, issue date and ticker in a single class. We rewrote hundreds of files to support the new change. This way we can specify options expiry date, type and strike price with the symbol class. If we've missed something architecturally its better to know now rather than later,

To keep discussions focused please comment directly on the symbol changes (not on this options thread).

JB

On Tue, Nov 24, 2015 at 2:10 AM, Paul Saunders notifications@github.com wrote:

Jared, how do I supply feedback on the 2 classes? And are you purely after logic feedback, or are you open to architectural input as well?

— Reply to this email directly or view it on GitHub https://github.com/QuantConnect/Lean/issues/166#issuecomment-159179205.

Jared Broad

[pms1969]

Found out how to do it. Some comments already made. I'll look at it further tomorrow.

[tedpenner]

Very exciting! On Nov 24, 2015 12:51 PM, "Paul Saunders" notifications@github.com wrote:

Found out how to do it. Some comments already made. I'll look at it further tomorrow.

— Reply to this email directly or view it on GitHub https://github.com/QuantConnect/Lean/issues/166#issuecomment-159370494.

[lurium]

Is there a separate branch for the options support? I can probably offer some advice, as I've built a few options trading systems....

[mchandschuh]

@lurium -The options branch will be coming shortly, trying to get a first rev working!

@AlexCatarino, @glyphard, et all: Any ideas what kinds of input data do options models require? Ideally we can set the system up to be flexible to support as many different models as possible.

[AlexCatarino]

Options models need, at least, three "submodels": volatility model, interest rate model and dividends yield model. The simplest volatility model doesn't need data: the trader would assume a constant volatility. Another volatility model (the one we will probably implement as default), takes the underlying price, the information about the option contract and its price, and yields the implied volatility. We already got these input data. To model interest rates, we need US Treasury Bond, Libor rates or Overnight indexed swap (OIS) rates. To model dividend yields, we need dividend data.

[mchandschuh]

@AlexCatarino - does it make sense for us to provide these abstractions? For example, should we have an IOptionVolatilityModel, IInterestRateModel, IDividendYieldModel ? Or should we keep it more generally as an IOptionPriceModel and allow the model internally to use the submodels? Or maybe it makes sense that an IOptionPriceModel would use the volatility/interest rate/div yield models?

[lurium]

Agree on two of the models-- Vol, and Rate.

However, instead of Divs, it might be simpler and more general to provide a "IForwardModel," which is really what the Divs and Rates are trying to accomplish in the case of equity and equity index options. For commodities, the forwards are usually derived directly from some function of the future prices. For Vol Futures (VX), it's a more complex derivation, but the concept is the same -- all option pricing requires the concept of a "forward price"

On Thu, Feb 25, 2016 at 10:21 AM, Michael notifications@github.com wrote:

@AlexCatarino https://github.com/AlexCatarino - does it make sense for us to provide these abstractions? For example, should we have an IOptionVolatilityModel, IInterestRateModel, IDividendYieldModel ? Or should we keep it more generally as an IOptionPriceModel and allow the model internally to use the submodels? Or maybe it makes sense that an IOptionPriceModel would use the volatility/interest rate/div yield models?

— Reply to this email directly or view it on GitHub https://github.com/QuantConnect/Lean/issues/166#issuecomment-188835671.

[AlexCatarino]

Thanks for the suggestion, @lurium! I think we should have a IOptionPricingModel that would be internally use the submodels (IOptionVolatilityModel, IInterestRateModel and IForwardModel). If the OptionPricingModel has a constructor that takes IOptionVolatilityModel, IInterestRateModel, IForwardModel, the quant would be able to use his own proprietary model(s). That's the goal.

[lurium]

Sounds good.

On Feb 25, 2016, at 1:20 PM, Alexandre Catarino notifications@github.com wrote:

Thanks for the suggestion, @lurium! I think we should have a IOptionPricingModel that would be internally use the submodels (IOptionVolatilityModel, IInterestRateModel and IForwardModel). If the OptionPricingModel has a constructor that takes IOptionVolatilityModel, IInterestRateModel, IForwardModel, the quant would be able to use his own proprietary model(s). That's the goal.

— Reply to this email directly or view it on GitHub.

[AlexCatarino]

I wonder if the volatility model interface should not be named IVolatilityModel. After all, the underlying volatility will be modeled, not the option volatility.

By the way, the volatility model can live outside the derivatives world, since its output can be used as an indicator (if (vol>0.5) TrendFollow(); else MeanRevert();) and/or allocation parameter.

[mchandschuh]

@AlexCatarino - good point, maybe it lives on the underlying Security object as just another model. What would a 'default' IVolatilityModel look like?