Imported from previous forum
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
I’m quite glad to see fields for trading futures and options. Granted, there’s probably going to be considerable symbology issues to overcome, but at least the fields are in place to get started.
I noticed what looks like a typo in a lot of places:
201 PutOrCall N For Futures.
202 StrikePrice N For Futures.
Shouldn’t this really be for options?
Also, there’s no ISITC SecurityType for options on futures. I don’t have experience with ISITC, so could someone more knowledgeable please clarify if options on futures contracts should be considered OPT or FUT?
Ryan Pierce
Townsend Analytics Ltd. / Archipelago LLC
rpierce@taltrade.com
Yes the "For Futures" should read "For Options" for those two fields and will in the final version. Sorry for the typo.
> I’m quite glad to see fields for trading futures and options. Granted, there’s probably going to be considerable symbology issues to overcome, but at least the fields are in place to get started.
>
> I noticed what looks like a typo in a lot of places:
>
> 201 PutOrCall N For Futures.
> 202 StrikePrice N For Futures.
>
> Shouldn’t this really be for options?
>
> Also, there’s no ISITC SecurityType for options on futures. I don’t have experience with ISITC, so could someone more knowledgeable please clarify if options on futures contracts should be considered OPT or FUT?
>
> Ryan Pierce
> Townsend Analytics Ltd. / Archipelago LLC
> rpierce@taltrade.com
>
[ original email was from Alan Painter - ]
For trading stock options on the DTB and the SOFFEX, you’ll want to include a “Version Number” Field. On these exchanges, it is common to distinguish between contracts before and after new issues, etc.
On the MONEP (Paris Option Exchange) it is normal to have a LONG and a SHORT version of most of the stock options. The LONG options are "European" and the SHORT are "American", so it is very important to differentiate the two.
Personally, I think that it is better to have a single, but flexible, text field for identifying option contracts, rather than to try to hash out the list of universal option identifiers.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Personally, I think that it is better to have a single, but flexible, text field for identifying option contracts, rather than to try to hash out the list of universal option identifiers.
I would disagree strongly.
My firm works with several data vendors for futures and options, and we’ve found quite a number of different ways to represent options and futures. Just using one text field will cause an enormous symbology war, the thought of which gives me a headache already.
I suggest instead that we use the minimum number of separate attribute fields to unambigously define an option or future. I.e.
Symbol: CSCO
ExDestination: W (Chicago Board Options Exchange)
SecurityType: OPT
Maturity: 19980321
PutOrCall: 1 (Call)
StrikePrice: 65.00
It’s perfectly clear that I’m trading a March 98 Cisco 65 call option on the CBOE. Now some systems may represent it as CYQCM, others as CSCO650C.W so who is right, and how can they interoperate? Breaking down the option into these structures makes the option unambiguous, and each party is only required to know the mapping between their own symbology and these FIX parameters, rather than being forced to translate symbology with all of their trading partners.
> For trading stock options on the DTB and the SOFFEX, you’ll want to include a “Version Number” Field. On these exchanges, it is common to distinguish between contracts before and after new issues, etc.
I take it that in this case two different contracts for the same underlier, put/call indicator, and strike price expire on the exact same day? In this case I would agree that we should add a version number field to handle such options.
> On the MONEP (Paris Option Exchange) it is normal to have a LONG and a SHORT version of most of the stock options. The LONG options are "European" and the SHORT are "American", so it is very important to differentiate the two.
Couldn’t this be accommodated more generally by making Maturity a date rather than YYYYMM? It will uniquely indicate if the option is long or short. I would think that it should be a function of the trading interface, not the FIX protocol, to handle displaying things in terms of LONG / SHORT rather than the exact date if this is what the trader desires to see.
Another note - it may be helpful to add ExDestination to all messages that relate to options, since many options are multiply listed.
Ryan Pierce
Townsend Analytics Ltd. / Archipelago LLC
rpierce@taltrade.com
[ original email was from Alan Painter - alan.painter@ota.fr.socgen.com ]
> > For trading stock options on the DTB and the SOFFEX, you’ll want to include a “Version Number” Field. On these exchanges, it is common to distinguish between contracts before and after new issues, etc.
>
> I take it that in this case two different contracts for the same underlier, put/call indicator, and strike price expire on the exact same day? In this case I would agree that we should add a version number field to handle such options.
>
That’s right. Following capital adjustments (shares issues, splits, reverse splits, etc) the contracts before and after the adjustments are identified with signle-digit version number (0 or blank is the current, 1 is just before the last adjustment, 2 before that, etc). In the case of small adjustments on capital, there will often be two contracts which are identical other than the version numbers.
> > On the MONEP (Paris Option Exchange) it is normal to have a LONG and a SHORT version of most of the stock options. The LONG options are “European” and the SHORT are “American”, so it is very important to differentiate the two.
>
> Couldn’t this be accommodated more generally by making Maturity a date rather than YYYYMM?
No. Example: today on the MONEP there are France Telecom contracts which long and short options, both expiring 29 Sep 1998. You cannot distinguish between them by maturity. You’d have to add another field. The MONEP distinguishes between the two by using different contract symbols (FTE and FTE-L).
My point is that you may need to add a lot of different fields to address all of the obscure, but important, contract distinctions of the world’s different options exchanges. It would be better to add some flexibility. Perhaps adding a textual field “OptAttribute” which would only have meaning in the context of a particular exchange woud do the trick?
> Another note - it may be helpful to add ExDestination to all messages that relate to options, since many options are multiply listed.
This can even be useful for multiple shares listings in European stock exchanges. They are currenly in different currencies, but everything is in EURO as of 4 Jan 1999, which means that you’ll have a larger choice of exchanges for the same stock/currency pair.
>
> Ryan Pierce
> Townsend Analytics Ltd. / Archipelago LLC
> rpierce@taltrade.com
Alan Painter
Société Générale Equity Derivatives, Paris
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> My point is that you may need to add a lot of different fields to address all of the obscure, but important, contract distinctions of the world’s different options exchanges. It would be better to add some flexibility. Perhaps adding a textual field “OptAttribute” which would only have meaning in the context of a particular exchange woud do the trick?
Sorry, I misunderstood your point.
I was opposing using just one text field to describe the entire option or future, which I thought you were proposing, as that would cause a symbology war. Using the ticker / CUSIP / SEDOL / whatever of the underlying stock, possibly specifying an exchange to route to, and a set of fields to handle the most common attributes, seems to be the least ambiguous way that everyone can agree upon, and hopefully can easily map their own symbology to or from it.
I think I remember hearing that option versions are not a Europe-only thing, and that it happens for US options as well. And I agree that an OptAttribute field would be helpful for those we can’t think of.
So how does the current draft + the folllowing sound?
- Maturity being a full FIX date, i.e. YYYYMMDD
- ExDestination being added as an optional field to all records specifying a symbol
- Adding an OptAttribute char field for exchange-specific attributes to a security, i.e. denoting Long / Short or option versions
Ryan Pierce
Townsend Analytics Ltd. / Archipelago LLC
rpierce@taltrade.com
[ original email was from Alan Painter - alan.painter@ota.fr.socgen.com ]
> So how does the current draft + the folllowing sound?
>
> * Maturity being a full FIX date, i.e. YYYYMMDD
> * ExDestination being added as an optional field to all records specifying a symbol
> * Adding an OptAttribute char field for exchange-specific attributes to a security, i.e. denoting Long / Short or option versions
I think that would work.
>
> Ryan Pierce
> Townsend Analytics Ltd. / Archipelago LLC
> rpierce@taltrade.com
>
>
>
> So how does the current draft + the folllowing sound?
>
> * Maturity being a full FIX date, i.e. YYYYMMDD
> * ExDestination being added as an optional field to all records specifying a symbol
> * Adding an OptAttribute char field for exchange-specific attributes to a security, i.e. denoting Long / Short or option versions
>
> Ryan Pierce
> Townsend Analytics Ltd. / Archipelago LLC
> rpierce@taltrade.com
>
>
-
The only potential issue with Maturity being a full FIX Date YYYYMMDD is whether or not to require everyone to compute the exact day of the month for something which is common and standard such as March S&P’s or as you suggested allow one to use this field as a date of the first of the month to represent SPH8 as 19980301 for instance. Thoughts?
-
If we need to specify Exchange as part of security identification, then I would propose that we add a new SecurityExchange field for this purpose. We have two fields which allow for exchange values to be specified, LastMkt and ExDestination. LastMkt has been (4.0) part of ExecutionRpt and Allocation messages. 4.1 has added this field to Advertisement and the new SettlementInstructions message. ExDestination has been (4.0) part of NewOrder-Single, OrderCancel/ReplaceRequest, and NewOrder-List. I think it’s cleaner that if the exchange is needed to help identify the symbol we don’t try to re-use a field like ExDestination. Thoughts?
-
Sounds like we have support for OptAttribute as part of the symbol identifying portion of each message with the following enumerations: 1=Long Option, 2=Short Option. Any other enumerations which need to be specified? Like/dislike for the names of the tags?
Thanks.
Scott Atwell
American Century
[ original email was from Joe Friedman - ]
> 1) The only potential issue with Maturity being a full FIX Date >YYYYMMDD is whether or not to require everyone to compute the >exact day of the month for something which is common and >standard such as March S&P’s or as you suggested allow one to >use this field as a date of the first of the month to represent SPH8 >as 19980301 for instance. Thoughts?
Why not DD = 00 as the sentinel value for situations where the exact day of the month is not relevant?
Joe Friedman
Pershing
>
> > 1) The only potential issue with Maturity being a full FIX Date >YYYYMMDD is whether or not to require everyone to compute the >exact day of the month for something which is common and >standard such as March S&P’s or as you suggested allow one to >use this field as a date of the first of the month to represent SPH8 >as 19980301 for instance. Thoughts?
>
> Why not DD = 00 as the sentinel value for situations where the exact day of the month is not relevant?
>
> Joe Friedman
> Pershing
>
I’m not in favor of using DD = 00 as that is an “invalid date”. I know my engine and others out there expect and require a value in a date field to be a real value in the month, i.e. don’t allow 19980230 for example. This is a validity check handled at the session level vs. business level. I would rather use 1st day of the month as a default taken in context or have two fields MaturityDate as a date and MaturityMonthYear or something as YYYYMM. Thoughts?
Scott Atwell
American Century
[ original email was from Anthony Collyer, Trinitech Systems - ]
> >
> > So how does the current draft + the folllowing sound?
> >
> > * Maturity being a full FIX date, i.e. YYYYMMDD
> > * ExDestination being added as an optional field to all records specifying a symbol
> > * Adding an OptAttribute char field for exchange-specific attributes to a security, i.e. denoting Long / Short or option versions
> >
> > Ryan Pierce
> > Townsend Analytics Ltd. / Archipelago LLC
> > rpierce@taltrade.com
> >
> >
>
> 1) The only potential issue with Maturity being a full FIX Date YYYYMMDD is whether or not to require everyone to compute the exact day of the month for something which is common and standard such as March S&P’s or as you suggested allow one to use this field as a date of the first of the month to represent SPH8 as 19980301 for instance. Thoughts?
>
> 2) If we need to specify Exchange as part of security identification, then I would propose that we add a new SecurityExchange field for this purpose. We have two fields which allow for exchange values to be specified, LastMkt and ExDestination. LastMkt has been (4.0) part of ExecutionRpt and Allocation messages. 4.1 has added this field to Advertisement and the new SettlementInstructions message. ExDestination has been (4.0) part of NewOrder-Single, OrderCancel/ReplaceRequest, and NewOrder-List. I think it’s cleaner that if the exchange is needed to help identify the symbol we don’t try to re-use a field like ExDestination. Thoughts?
>
> 3) Sounds like we have support for OptAttribute as part of the symbol identifying portion of each message with the following enumerations: 1=Long Option, 2=Short Option. Any other enumerations which need to be specified? Like/dislike for the names of the tags?
>
> Thanks.
>
> Scott Atwell
> American Century
>
>
This has been a very interesting thread for me. Thanks Guys.
Point 1. On balance YYYYMMDD sounds best to me. The front-end will have to deal with the logic of what exact date 98H for the BUND on LIFFE means. The clincher was seeing the point made about Futures contracts on the LME which can have virtually any working day as an expiry.
Point 2. On Balance I would prefer extra-bulk in the message and greater exactitude to the alternative. So yes to the SecurityExchange field
Point 3. IMHO I would favour calling the two types of options “American” and “European” (rather than the confusing sounding “Long” or “Short”). This has nothing to do with the geographical location of where the option was granted but (as has already been pointed out by more learned people than myself) purely whether the option can be excercised prior to expiry (“American”) or only at expiry (“European”)
Best Regards
[ original email was from Alan Painter - alan.painter@ota.fr.socgen.com ]
> Point 3. IMHO I would favour calling the two types of options "American" and "European" (rather than the confusing sounding "Long" or "Short").
Long and Short is the MONEP terminology. It’s true that one is American and the other is European. But that’s only part of the picture. For example, there are currently three long France Telecom contract maturities and three short:
short: Mar97 Jun98 Sep98
long: Sep98 Mar99 Sep99
So, in the case of the MONEP, it’s logical to think in terms of LONG and SHORT options. (“Longues” and “Courtes” for the frogs.)
Alan Painter
Société Générale Equity Derivatives
[ original email was from Alan Painter - alan.painter@ota.fr.socgen.com ]
>
> 3) Sounds like we have support for OptAttribute as part of the symbol identifying portion of each message with the following enumerations: 1=Long Option, 2=Short Option. Any other enumerations which need to be specified? Like/dislike for the names of the tags?
>
> Thanks.
>
> Scott Atwell
> American Century
>
>
I was thinking of OptAttribute as a free-format field.
If we’re going to enumerate all the possibilities, we can start at least with:
DTB, SOFFEX, HongKong
– a single digit version number (0, 1, 2, … 9)
MONEP
– L for long, S for short
Alan Painter
Société Générale Equity Derivatives
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> 1) The only potential issue with Maturity being a full FIX Date YYYYMMDD is whether or not to require everyone to compute the exact day of the month for something which is common and standard such as March S&P’s or as you suggested allow one to use this field as a date of the first of the month to represent SPH8 as 19980301 for instance. Thoughts?
Assuming we all agree that the protocol must allow specifying a date, the following alternatives immediately spring to mind:
A. Require everything to use the exact date.
B. Use an invalid date, like 00 to mean that the exact day is irrelevant.
C. Use a valid date, like 01, to mean that the exact day is irrelevant.
D. Keep Maturity YYYYMM but with an optional int field to specify a relevant day.
E. Use B, C, or D with the possibility of the broker optionally responding in the Execution messages with the real expiration date.
I’d be happy with any of these, as they all get the job done, but they vary in design philosophy and elegance.
I can see some arguments for requiring A. One could argue that a trading system really needs to know stuff about the symbol in question, that it either needs a local instrument table with the ability to compute or look up this data, or that it has an out-of-band means to query some server somewhere for the info on an instrument, and that it should prevent stupid orders, like orders for an option that has expired.
On the flip side, one could argue that the buy-side trading system really should be allowed to be stupid, and the sell-side broker should be responsible for rejecting stupid orders, like contracts that have expired or prices ridiculously away from the market. One could argue that adding out-of-band lookups on instrument info complicates the trading application, and should the proprietary system feeding instrument data to the trading system fail, the system can no longer send FIX orders.
It all depends where sanity checks, like price reasonableness and whether a security expires, are done. My firm’s trading applications have a proprietary database connection to get instrument info, and we take a smart-client-dumb-server approach, so requiring expiration lookup would not hurt us. However, it is just as valid to take a dumb-client-smart-server approach, and requiring a date lookup would hurt such developers. I don’t think the FIX protocol should endorse one client-server architecture over another, hence I’m disinclined towards option A.
As Scott pointed out, using B and calling it a date can easily break many FIX engines. It doesn’t seem elegant to use a date field for something that really isn’t a date. Now we could still use that format but call it a char.
C has the same problem old telephone switches using in-band signalling faced. You can’t differentiate between a certain valid datum and a signal. You don’t know if the person is specifying a contract that really does expire on the first of the month, or if it is a signal that date is irrelevant. Now one could argue that in context the distinction should be clear. Then again one could argue that human voices generally don’t contain 2600 Hz tones, but using it as a signal in early phone switches gave many bored high-schoolers countless hours of fun.
D states clearly, with a MaturityMonth and MaturityDay, whether only a month or month + day is specified. Its disadvantages are that it doesn’t make use of the FIX date type (although one could argue that we really aren’t talking about a date here), adds a new tag to the namespace, and makes the messages with date 4-5 bytes longer.
E seems generally to be a good idea. The only problems are that, combined with B or C, the Maturity specified by the trader might not match the Maturity in the Execution, which could cause confusion. However E goes very elegantly with D, as the broker can add the MaturityDay field while leaving MaturityMonth unchanged.
So I guess my preference is D + E, as it seems the most elegant compromise, allows for “dumb” clients, and doesn’t have any gotchas.
> 2) If we need to specify Exchange as part of security identification, then I would propose that we add a new SecurityExchange field for this purpose.
Fine by me, although some elaboration on the difference between the fields in New Order messages is necessary. I take it that SecurityExchange would be used only to differentiate a given option from similar options trading on other exchanges, without specifying an actual routing preference, while ExDestination would be used to override where the order is really sent? I.e. for US equity options, SecurityExchange makes no sense, as a Cisco option is the same anywhere. But ExDestination makes a lot of sense, as a trader might prefer the CBOE or the Pacific in terms of liquidity, execution speed, or price, or all that could be left blank and it would be up to the broker’s routing table to determine where the best place to send the order would be.
> 3) Sounds like we have support for OptAttribute as part of the symbol identifying portion of each message with the following enumerations: 1=Long Option, 2=Short Option. Any other enumerations which need to be specified? Like/dislike for the names of the tags?
I agree with what was posted. Numeric tags should be reserved for option versions. L and S could be used for Long and Short contracts. Maybe you could define E and A as well for European and American, however the one used in a given case depends on what notation the exchange in question prefers to use.
Ryan Pierce
Townsend Analytics Ltd. / Archipelago LLC
rpierce@taltrade.com
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
On a closer look at the field definitions, I noticed that date was specified as char, format YYYYMM. I recommend that it be in FIX date format, YYYYMMDD. This has its advantages in that it is more consistent with the rest of the protocol, and that it can accomodate bizarre options or futures where more than one series expires per month.
Ryan Pierce
Townsend Analytics Ltd. / Archipelago LLC
rpierce@taltrade.com
The issue with using YYYYMMDD as it was explained to me is that many futures and options are referred to as "March such-and-such year contracts" or ("H8" for "March 1998") and have moderately complex rules which determine what the day within the month that happens to be i.e. the 2nd Friday unless a holiday and then, such and such date. It seemed better to specify year and month without a day than to "dummy up" a day i.e. "0" to refer to a month and year only and still fit into the format of a date. Maybe the "bizarre options or futures" requirements will necessitate a different field which is a date but those needs have not yet been brought forward.
> On a closer look at the field definitions, I noticed that date was specified as char, format YYYYMM. I recommend that it be in FIX date format, YYYYMMDD. This has its advantages in that it is more consistent with the rest of the protocol, and that it can accomodate bizarre options or futures where more than one series expires per month.
>
> Ryan Pierce
> Townsend Analytics Ltd. / Archipelago LLC
> rpierce@taltrade.com
>
>
[ original email was from Ryan Pierce - rpierce@taltrade.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
On the LME (London Metals Exchange) you can trade a future
for any specific date within 90 days.
So you can have an contract for 25Feb98 and 11Mar98, so the date really does mean something in this case.
> 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
>
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
>