Discussion Forum

Hi Joseph, if you don't liquidate the contract, the algorithm will hold the contract until it expires. If you want to liquidate the position before it expires, you should save the contract symbol and compare the contract strike price with the current underlying price and send the liquidation order. For example

Using Ask or Bid price depends on your algorithm.

Hello Jing,

Thank you very much for your time, code example and expertise: this is very much appreciated.

You explained to me how to liquidate an option contract before expiration and how to verify its strike price relative to the underlying price.

What I'd ideally want to achieve now is to liquidate the option contract at the worst possible moment: out of all the prices the underlying will touch, I'd like to identify the one which is further away from the option strike and liquidate it that day. Can you kindly confirm to me there is no way to do this automatically? I think I can code it myself if there's not: maybe it'll be useful to other people as well (LEAN engine's assumptions that american options are always liquidated at expiry might show some strategies to be performing better than what they'd do in the real market, where options might be assigned, for the better or for the worse, before they expire).

The only problem in coding something like this is that the OnData() function only looks at a single tick values: we can't possibly check the future or the past in there (nor we want to - we'd be searching every tick for something we only need once: the liquidation date according to the "worst possible" idea).

If I might ask: what do you think would be the best way to code something like this? I'm not asking for specific code examples, just a general "best practice" idea. I was thinking about a function that gets called every time we sell an option: the function would need the option strike and the underlying prices for the period before expiration, and would return either nothing or a flag that indicates when the market will assign the option. The result of this function should be stored in a global variable and OnData will always check this variable and call .Liquidate based on what's stored in it (we could use a date, or the underlying price).

Thanks again for your input!
Joseph.

If your liquidation condition is complicated you can create a function with arguments with the underlying price. if not, "if else" statement would be easier to implement.  "identify the one which is further away from the option strike and liquidate it that day" This "further away" is hard to define as you only have the history price without the future price. If you need the history price of underlying, you can use the rolling window to save the history bar.

Has this issue been addressed? Jing Wu's post is not really answering Joseph's question above. I am facing the same issue here : How does the backtesting engine decide WHEN to assign the options to the short seller? i.e. I sold put options on GOOG for $100 strike due date Jan 31. Before the expiration, on Jan20, GOOG trades at $99. Does the engine auto-assign the option on Jan 20 in this case? How does the algorithm work here?

Hi there, I am interested knowing how to do this too. I hope someone more expert could help and reply. Maybe it may be sufficient to retrieve future prices from the underlying in OnData (although I don't know how)? 

They are simulated with the BasicOptionAssignmentSimulation class which is added to the backtesting brokerage here. 

This is not configurable at this time but it was designed in a way it could be configurable. It's not simple stuff though, so I'm not sure it makes sense to 99% of the community to make it configurable on the algorithm layer.

What are you trying to achieve?

Hi Jared, thank you for your reply. As Joseph mentioned the objective is to simulate how we get assigned on an option in the worst case scenario. Let's assume we are in a SELL PUT strategy, we may want to be assigned when the underlying goes at its minimum, ie. at our most potential loss, and not at expiration. I know that none of the two policies would be 100% realistic, but I believe both of them are useful for backtesting purposes. In other words, we would like the "backend" to be the oracle, knowing what's the best time for it to sell stocks to us (in case of a SELL PUT strategy).

Anyway I will have a look at the class to figure out how it works. Thanks!

I'm not an expert in Options, but as far as I understand the likelihood of being assigned early on a short option is directy related to the extrinsic value of that option.

ATM or slighlty ITM options have mostly extrinsic value, so the option owner will make more money selling his option rather then exercise it, i.e. assignment is unlikely.

There are 3 cases where assignment is highly likely:

1. The option is close to expiration, in which case the theta decay will quickly depleate the extrinsic value of the option.
2. The option is deep ITM, in which case it has mostly intrinsic value and nearly no extrinsic value.
3. The option underlying is a stock which pays a dividend, the time is close to the ex-dividend day, and the dividend value is greater than the option's current extrinsic value. In such case the option's owner will make more money exercising the option into stock to capture the dividend.

I think coding these conditions into the backtest would produce more realistic results.

Looking at the LEAN backend implemenmtation of BasicOptionAssignmentSimulation:

/Brokerages/Backtesting/BasicOptionAssignmentSimulation.cs

It seems to use a heuristic of assigining short options if they are deeper then 5% ITM and close to expiration, which I think is over simplification and would produce overly optimistic backtest results.