Inferring a complete Maturity Date ?

, ,
1

Imported from previous forum

2

Hello all –

As any fule kno, many FIX messages allow for a Maturity Date to be specified. This is split into two fields - MaturityMonthYear and MaturityDay.

According to the 4.1 spec., it is quite legal for only one of the two fields to be sent. So my question is, how do I infer the missing field to get a complete date?

If I only receive the MaturityDay field then I think I am safe in assuming that I can infer MaturityMonthYear from the SendingTime field.

But if I only receive MaturityMonthYear, then how do I correctly infer MaturityDay? Is it the first or last day of the month?

Many thanks,

3

If one sends MaturityDay, one should also send MaturityMonthYear. The premise behind why these were split was a requirement to be able to refer to “March 2000” S&P’s without having to know and specify the exact date. We split them to avoid having to support some sort of “dummy” day value in a normal date format. This provides the ability to provide a specific date (by using MaturityMonthYear and Maturity Day) or a commonly agreed and well understood representation of MaturityMonthYear.

>
> Hello all –
>
>
> As any fule kno, many FIX messages allow for a Maturity Date to be specified. This is split into two fields - MaturityMonthYear and MaturityDay.
>
> According to the 4.1 spec., it is quite legal for only one of the two fields to be sent. So my question is, how do I infer the missing field to get a complete date?
>
> If I only receive the MaturityDay field then I think I am safe in assuming that I can infer MaturityMonthYear from the SendingTime field.
>
> But if I only receive MaturityMonthYear, then how do I correctly infer MaturityDay? Is it the first or last day of the month?
>
>
> Many thanks,
>
>
>
>

4

> If one sends MaturityDay, one should also send MaturityMonthYear. The premise behind why these were split was a requirement to be able to refer to “March 2000” S&P’s without having to know and specify the exact date.

This is unnatural for Fixed Income – do people (in particular the FI working group) prefer i) Using MaturityDay+MaturityMonthYear or ii)introducing a new ‘Maturity’ field?

>> As any fule kno,
Nice to see a St. Custard’s alumnus gainfully employed!

5

I think the maturity date is in two pieces like this because, for options, no day need be sent. Options expire the Saturday after the third Friday of the expiration month.

I don’t know the answer to your question insofar as futures are concerned.

>
> Hello all –
>
>
> As any fule kno, many FIX messages allow for a Maturity Date to be specified. This is split into two fields - MaturityMonthYear and MaturityDay.
>
> According to the 4.1 spec., it is quite legal for only one of the two fields to be sent. So my question is, how do I infer the missing field to get a complete date?
>
> If I only receive the MaturityDay field then I think I am safe in assuming that I can infer MaturityMonthYear from the SendingTime field.
>
> But if I only receive MaturityMonthYear, then how do I correctly infer MaturityDay? Is it the first or last day of the month?
>
>
> Many thanks,
>
>
>
>

6

>Options expire the Saturday after the
>third Friday of the expiration month.

Is this a global rule? It seems slightly arcane… But then I’m only a programmer, not a trading wizz - I wouldn’t know an Option or a Future if one bit me.

Can anyone tell me the rule for Futures? Better yet, does anyone know of a resource somewhere that contains this kind of information?

Thanks as ever,

7

> >Options expire the Saturday after the
> >third Friday of the expiration month.
>
> Is this a global rule?

Yes. I was quoting "AfterThe Trade is Made" by David M. Weiss, a book we received at a seminar given by the N.Y. Institute of Finance.

> It seems slightly arcane… But then I’m only a >programmer

Me too. There is so much to learn about the stock market. I was overwhelmed by the seminar I just mentioned.

8

[ original email was from Tom Healey - thealey@thpartners.com ]

Regarding the expiration month and date, it is possible to infer one from the other for a given contract on a specific exchange but the expiration rules will vary between exchanges and possibly between contracts on the same exchange. As an example:

Australian equity options expire on the last Thursday of the expiration month, but the monthly cycles will vary.
Belgium equity options expire on the 3rd Friday of the expiration month, which are on a 3,6,9,12 cycle.
Japanese equity options expire on the business day prior to the second Friday of the contract month.

I’m sure you get the point and futures, options on futures and commodity derivatives all have different expiration rules.

To keep your programs flexible and avoid future coding changes, you should utilize a separate database to hold the contract specifications and create a program that can interpret the rules to determine the date. You will also need holiday rules on top of the expiration rules.

A good source for contract specifications is the "Futures and Options Fact Book", from the Futures Industry Institute, but new contracts come out all the time so it requires considerable effort to maintain a database.

Regards,

Tom Healey
TH Technology Partners
thealey@thpartners.com
212-832-3619

> Hello all –
>
>
> As any fule kno, many FIX messages allow for a Maturity Date to be specified. This is split into two fields - MaturityMonthYear and MaturityDay.
>
> According to the 4.1 spec., it is quite legal for only one of the two fields to be sent. So my question is, how do I infer the missing field to get a complete date?
>
> If I only receive the MaturityDay field then I think I am safe in assuming that I can infer MaturityMonthYear from the SendingTime field.
>
> But if I only receive MaturityMonthYear, then how do I correctly infer MaturityDay? Is it the first or last day of the month?
>
>
> Many thanks,
>
>
>
>

9

Thanks to all who assisted me with this issue.

From the information gathered, it seems clear that there is no point in attempting to infer a day of Maturity/Expiration from the Month+Year field alone.

So my FIX engine will have to expose this date as two string properties, as per the fields defined by the spec. It is a shame to have to be so unfriendly to FIX client developers but there appears to be no practical alternatives.

Very best regards,