Dieter, thank you for the depth of your post. Note that you are a responding to a rather old posting and it was a pre-FIX 4.1 release discussion.
In FIX 4.1 (released April 1, 1998) we added two fields: MaturityMonthYear and MaturityDay thus we have the capability to provide the YYYYMM part only or the ability to provide both pieces so that one can form an exact date.
Re: "an instrument definition message type", we have had a proposal on the table for such a message for several months and it is slated to go into FIX 4.2. A draft of this proposal can be found under "Specs", "Drafts". It is called "Security Messages". Thanks.
> It seems to me that there is a conceptual difference between the identification of the exact expiry/maturity/prompt date of a futures or options series and the identification of the contract month, or more precisely, the series itself.
>
> 95% of all futures and options listed anywhere have ‘expiry months’, with market convention using a simple MMMYY character representation to denote the date element of the series specification. On a side note, there are umpteen market conventions for denoting a contract month a.k.a expiry month a.k.a series. Many exchanges use a single letter for a month code (e.g. OPRA), but start getting themselves into trouble when they list contracts that need more than one series per month, or have very long dated instruments where they run out of letters. The Japanese markets are the worst with some completely implausible alphanumeric scheme. I believe the common denominator most people would prefer most of the time is MMMYY.
>
> The exact expiry date for series in contracts with monthly expiries is in 99.9% rule-based, as determined by the exchange contract specifications and the applicable market holiday schedule. The exception are some agricaltural instruments depending on crop data and some US Treasury based instruments which depend on the publication data of certain government statistics. In any case, exact expiry dates (as opposed to a unique identifier of the date element of the series) are a different kettle of fish and would belong into an instrument definition message type in its own right (not in FIX 4.1 I assure you, unless you use FIXML within a FIX message and agree with your counterparty what an instrument definition should look like) As long as both parties of a trade/order message can ensure that series are uniquely identified, we don’t need to worry about other properties of the particular series or contract, interesting as they may be (more about this below if you can take it).
>
> The exceptions to the 95% MMMYY rule are where it gets interesting. As has been pointed out, there are markets that list more than one series of the same instrument per month, e.g. the LME with their daily prompt dates or the CME with weekly contracts. A particular bizarre animal amongst the unusual ones is the ‘overnight option’ as traded on the SFE, which has daily (or rather nightly) expiry, i.e. a new series is created and perishes every day/night. I will not go further into the latter, since the SFE themselves (or rather TMI, their consultants) have found a way to model this in FIX 4.0 (albeit with some custom extensions). Anyway, if you have more than one series per month you have to move from a MMMYY representation to a DDMMMYY or such like representation, and the exact expiry date which was implied/omitted in the other 95% of cases now becomes mandatory.
>
> As has been explained, a date where the DD part is sometimes <space><space> and sometimes an actual date will not fly with the validation of typical fix engines.
>
> The way we handle date representations in some of our futures & options accounting system is by storing two dates, a character representation for display purposes and date representation for computational purposes. The ‘Display Date’ is what users see on screens, reports etc. and is a character field in either MMMYY or DDMMYY format. The ‘Internal Date’ is a true date format. If the Display Date is MMMYY, the application will calculate the Internal Date to be 01MMMYY, which is a default value. It is up to the application which ultimately uses the FIX message to recognize that 01MMMYY in the Internal Date field is actually a dummy date because the Display Date field doesn’t have a DD identifier. Now, if - as per exchange contract specification - we DO need to specify the DD part in the Display Date, the Internal Date will also be DDMMMYY, with the DD part being the same for the Display and Internal Dates. It is quite possible that the Internal Date, as a result, ends up being 01MMMYY because the series happens to really expire/mature on the first of the month. Again, it is up to the application ultiomately using the information to identify that, i.e. because the DD part of the Display Date is specified, 01MMMYY in the Internal Date field is not a dummy, but a real expiry/maturity date.
>
> Thus, the use of two date fields, one character and one in true date format, allows your FIX engine to validate the Internal Date if it needs to, and at the same time the application at the other end to figure out which series you really mean. Yes it looks like this is extra overhead in the FIX message, but actually you only need one date in 95% of all cases, the character-represented Display Date. To either construct (based on stored application business rules) or alternatively look up (in some central instrument repository) the correct expiry/maturity date would be the job of the application ultimately processing the message. The Internal Date would be optional as far as the FIX message is concerned. Only if the Display Date contains a non-blank DD identification, the Internal Date becomes mandatory and can (and should be!) verified by the FIX engine.
>
> On another side note, those familiar with listed derivatives will know that for a traded series in listed derivatives, the expiry date is only one of numerous date fields of interest to an application. Other such dates include the settlement/delivery date, first/last notice date and last trade date. A FIX message related to a quote, order or execution is the wrong place to specify these dates. The only thing we need in that FIX message is to be able to uniquely identify the instrument and series traded, and the rest is up to the application ultimately processing the FIX message.
>
> Dieter Stein
> dstein@sbsintl.com
>
> > It turns out that options which expire more frequently than monthly are not as uncommon as I thought. When I asked around, I found that some currency options expire twice a month (often referred to as long or short-dated options). And the CME has options which expire WEEKLY on all of their currency products.
> >
> > I don’t think this is an issue we should put off till next year’s spec, or force people to provide their own (incompatible?) way of supporting such options, when we can agree upon a solution now that doesn’t restrict the kinds of options we can trade.
> >
> > How about making this a date field, and stating that counterparties can agree to use the first day of the expiration month for instruments which expire once per month (i.e. a March S&P)? This way trading partners who need the exact date are free to use it, those who don’t aren’t burdened with computing it, and it fits with the standard FIX concept of date.
> >
> > Ryan Pierce
> > Townsend Analytics Ltd. / Archipelago LLC
> > rpierce@taltrade.com
> >
>