Bug with option expirations

Here is the log for Workshop8 script (w smaller WEEKS) with Zorro-provided data:
The price of an underlying at expiration is taken 1 day earlier.

Same goes for Z13 system:

Maybe you are confusing EOD and underlying prices? Otherwise, for checking if a historical price is right or wrong, open the .t6 and .t8 files and compare. Options expire at the most recent underlying price, not at the EOD price.

If by "EOD prices" you mean "EOD option prices" - then no, I am not looking at them for an EXPIRED option. I am looking at the price of an underlying in *.t8 file at the time of option expiration.

Have a look at the log snippet above:

- expiry date is 2021-04-16 (Fri, eod)
- the price of an underlying on Fri, eod is 417.26

- yet Zorro calculates P&L based off 415.90 - which is a underlying price on Thu, the day before.

You can confirm this more evidently in the first log snippet (from Workshop8):

- the sold 417 Call has a time value of 2.98+(417-419.17) = 0.81
- the price of SPY at expiration on Wed, eod is 419.01.
- the P&L after expiration is 0.81 + (419.01-419.17) = 0.65 or $65 per 100 shares.

- yet Zorro books +$165 - which means it really calculates as the log states - based off 418.33 - the price of SPY the day before.

EOD = underlying price at market close
Expiration = underlying price at ExpiryTime

Maybe this helps? Both are in the historical data and normally different. Also, EOD price is normally adjusted, expiration price is unadjusted.

I must be really missing something. Would really appreciate if you could please point out a line in my post above where I go wrong?

SPY options expire at the market close at the day of expiry, so for an option expiring on Wed, SPY close price on Wed is the one used for settlement.

This price - the unadjusted SPY daily close price - is taken by Zorro from a "*.t8" file.

Is this correct?

Workshop8 - my first example - specifically has "History="*.t8" - so Zorro is only aware of unadjusted SPY prices..

All prices in a backtest are read from historical data.

The prices printed at any bar are from the files that you set up with the "History" variable. If that was a .t8 file, it's the first, highest, lowest, and last underlying price of that bar.

The underlying price at which an option expires is the last underlying price of that particular option in the t8 file. As you can easily see in the log, it is not identical to the prices printed at bars.

So if you don't trust a certain price, look into that .t8 file and check the prices.

Pls look at the attached prices from a .t8 file: the last existing price of an underlying on 05-26-2021 is 419.04 - which is the settlement price of options expiring same day.

But here is the log again:
418.33 is not the price on Wed, it is the price on Tue(!), 1 day earlier.

Thanks for the screenshot. I see that the underlying price is indeed taken from the previous, not from the last bar. So you have been right all the time. I'll check if there is a reason for that, and will post here when I know what the problem is.

I can already tell you what the reason probably is, ExpiryTime is 12 UTC by default and at that time, the most recent underlying is the price from the previous bar and not from market close because that would be in the future.

That makes sense for intrabar selling but not for expiration. So I think it should be changed, zheka is right, for expiration the market close price should be used regardless of ExpiryTime.

Setting ExpiryTime=2200 solves the problem (though the log message is now incorrect

I don't think using market close regardless of actual expiry time/abandoning ExpiryTime is reasonable: CME FX options have moved in Sept 2019 to morning expirations(10am)...there might be some other cases.

But:
- the default ExpiryTime should indeed be set after the market close - to cover the majority of cases
- it should be in BarZone time, not UTC.

The problem would be solved by setting the ExpiryTime default at 23:00. The options expire then at the Friday close price. The log is then not incorrect because we're in the next bar, but admittedly confusing.

We'll find a solution for the upcoming release, probably with a 23:00 UTC detault for ExpiryTime and a different log message.

For options that expire in the morning or at a different time, ExpiryTime must be set to that time, and the timestamps in the historical options data must then also reflect that time. There is no perfect solution except using higher resolution data.

Can ExpiryTime be made to respect BarZone? There are no options in the world expiring in UTC...

..And Z13 system will have to be adjusted/stats restated..

It can not, because that would break existing scripts that already use ExpiryTime.

is there a way to set the option expiration time manually in order to experiment with this feature?

I am comparing now Zorro versions 2.40 and 2.44 and would like to emulate the old option expiration handling procedure in the new 2.44 version.

Thank you in advance!

Its a variable. You can set it.

Petra – thank you!

Indeed when set to ExpiryTime=1200, I see the old option trading behavior around the expiration time.

However, the option strategy performance I am testing is still different between the different Zorro versions.

Using the same Zorro script, same data, same R installation I have also noticed that Zorro 2.40 used to select longer expiry options (than specified 6 weeks) more often and Zorro 2.44 tends to be more precise – is it possible that some bugs in option selection procedure were fixed or some other changes were implemented?

Yes, the contract chain is now sorted by expiration and strike. So it finds the contract faster. Still, it should normally be the same contract, since the best match is not affected by sorting order. You could post details about what contract you wanted and what contract you got in both versions.

Hi JCL,

thank very much for the comments – that explains a bit the results.

At this stage I am trying to understand the differences between the Zorro versions by simply “observing” the major differences between the trades/options selected.

It is tricky to meaningfully compare the option trades (generated by different Zorro versions) since those are path dependent. Here is one example at the beginning of the testing period - in both cases the maturity is specified to be 6 weeks / 42 days for call options on SPY:

Zorro 2.40
Open - Close - ExitType - Days
2015-07-01 19:20 - 2015-08-21 19:20 - Expired - 51
2015-08-21 19:20 - 2015-10-16 19:20 - Expired - 56

Zorro 2.44
Open - Close - ExitType - Days
2015-07-01 19:20 - 2015-08-21 19:20 - Expired - 51
2015-08-21 19:20 - 2015-10-02 19:20 - Expired - 42

As I wrote – in tendency Zorro 2.44 selects options with maturities “closer” to 6 weeks. I use this function to select options:

contract (int Type, int Days, var Strike): CONTRACT*

and the documentation says that the function “selects the option or future contract that has an expiration closest to the given minimum life time in Days and strike closest to the given Strike value”. So in both cases the function results are correct.

As in the example above - it makes sense “sometimes” to select 3rd Friday options because of liquidity/costs/etc, but it would be good to know or even control those trade-offs somehow.

I was wondering – is there a code or documentation how the distance is measured (in the function above) to find an option with the “closest to the given minimum life time in Days and strike closest to the given Strike value” ?

When selected? With which parameters? Strikes? Which ExpiryTime?

it was already mentioned that those results were produced using the same script/input data, the trading time is provided in the example above and option type was always a call, underlying – always SPY, option maturity – always 42 days. You could trust me that the strikes were the same across both Zorro versions...

However, that information is just to provide you the context. My main question is – whether one could find more details how the above mentioned CONTRACT function optimizes the “distance” - selects “closest” options with respect to provided expiry life time and strike price so that one could replicate the results?

"Closest" means the options with shortest lifetime at or above your minimum days, and from these the option with the smallest strike difference to your strike parameter.

OK - thank you!