# Calender Spreads for Listed Derivatives **URL:** \ **Category:** General Q&A\ **Tags:** imported, derivatives, xid\_168647\ **Created:** [April 13, 2004, 5:48pm UTC](https://forum.fixtrading.org/t/calender-spreads-for-listed-derivatives/12575 "2004-04-13T17:48:00Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![mariomuth\_x](https://avatars.discourse-cdn.com/v4/letter/m/b5ac83/32.png) [@mariomuth\_x](https://forum.fixtrading.org/u/mariomuth_x)\ **Post date:** [April 13, 2004, 5:48pm UTC](https://forum.fixtrading.org/t/calender-spreads-for-listed-derivatives/12575/1 "2004-04-13T17:48:00Z")
Imported from previous forum ---
**Author:** ![mariomuth\_x](https://avatars.discourse-cdn.com/v4/letter/m/b5ac83/32.png) [@mariomuth\_x](https://forum.fixtrading.org/u/mariomuth_x)\ **Post date:** [April 13, 2004, 5:48pm UTC](https://forum.fixtrading.org/t/calender-spreads-for-listed-derivatives/12575/2 "2004-04-13T17:48:00Z")
Calendar Spreads for Listed Derivatives We are currently implementing the ability to send orders for calendar spreads using 4.2. We would like to be as close to the published spec, however, have a requirement to retrofit into 4.2. The 4.2 Appendix I mentions spreads, however, does not have a working examples, so can the group pls look at the example below and come back with comments. Example for Bund Sep/Dec spread (check sums will not work): 8=FIX.4.29=024235=D49=MARIO\_EXLINK56=EXLINK\_MARIO52=20040126-16:35:135 7=MARIOGATE50=DCL3100134=6397=N43=N60=20040126-16:35:13207=XEUR55=XEU RFGBL0F2004M48=20040922=171200=20040340=159=044=01=L60954=111=32:10 75134913.09109=DBL9991121=238=1167=FUT10=015 Tag 55 is used to identify the contract (we use 55 containing 200 and 207) Tag 48 contains the expiry month of the 2nd leg Many Thanks Mario Muth ---
**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\ **Post date:** [April 16, 2004, 5:13pm UTC](https://forum.fixtrading.org/t/calender-spreads-for-listed-derivatives/12575/3 "2004-04-16T17:13:00Z")
[original email was from Jeremy Sutton - [jezza.sutton@patsystems.com](mailto:jezza.sutton@patsystems.com) ] The group has not yet got to discussing multi-leg orders but will do so in the near future (certainly it is a subject dear to my heart!). Your comments have been noted. FIX 4.2 provides the "2 step" method where you first send a SecurityDefinitionRequest stating what you wish to trade, the response contains a SecurityDefinition that you are supposed to be able to submit for NewOrderSingle to trade this multi-leg order. This is not very popular. In fact, we did not implement this at all. While I cannot say what our recommendations from the group will be, I can tell you what we personally at Patsystems are doing. Since we desire people to progress to FIX 4.3 and 4.4, and since we want their migration to be as easy as possible, we did not see the benefit in implementing the 2 step approach. Neither did we wish to use the "CME method" of specifying both legs in tag 55. Niether of these mechanisms "make progress" towards FIX 4.3 Incidently, the group will likely recommend tag 55 be used to identiy the instrument and tag 200 be used to identify any expiry, which is another reason not to use the tag 55 method. We have chosen to extend our FIX 4.2 session to accept the FIX 4.3 multi-leg order messages. This will not be suitable for all FIX engines of course, but was quite easy to do with ours by extending the XML used by our libraries. The group has no comment, at this stage, on whether such a mechanism is appropriate or not as a best practise. As mentioned, the topic has not yet been discussed. I personally would be interested in your feedback on what Patsystems is doing in this field. ---
**Author:** ![chandwadka\_x](https://avatars.discourse-cdn.com/v4/letter/c/8baadc/32.png) [@chandwadka\_x](https://forum.fixtrading.org/u/chandwadka_x)\ **Post date:** [March 7, 2005, 11:49am UTC](https://forum.fixtrading.org/t/calender-spreads-for-listed-derivatives/12575/4 "2005-03-07T11:49:45Z")
> The group has not yet got to discussing multi-leg orders but will do so > in the near future (certainly it is a subject dear to my heart!). Your > comments have been noted. > > FIX 4.2 provides the “2 step” method where you first send a > SecurityDefinitionRequest stating what you wish to trade, the response > contains a SecurityDefinition that you are supposed to be able to submit > for NewOrderSingle to trade this multi-leg order. > > This is not very popular. In fact, we did not implement this at all. > > While I cannot say what our recommendations from the group will be, I > can tell you what we personally at Patsystems are doing. Since we desire > people to progress to FIX 4.3 and 4.4, and since we want their migration > to be as easy as possible, we did not see the benefit in implementing > the 2 step approach. Neither did we wish to use the “CME method” of > specifying both legs in tag 55. Niether of these mechanisms “make > progress” towards FIX 4.3 > > Incidently, the group will likely recommend tag 55 be used to identiy > the instrument and tag 200 be used to identify any expiry, which is > another reason not to use the tag 55 method. > > We have chosen to extend our FIX 4.2 session to accept the FIX 4.3 multi- > leg order messages. This will not be suitable for all FIX engines of > course, but was quite easy to do with ours by extending the XML used by > our libraries. > > The group has no comment, at this stage, on whether such a mechanism is > appropriate or not as a best practise. As mentioned, the topic has not > yet been discussed. I personally would be interested in your feedback on > what Patsystems is doing in this field. For the exchange listed calendar spreads the combination of Tag 48 and 22 ( Tag 48=Spread contract code ) with SecurityType(167) as MLEG can be used in NewOrderSingle. This way you don’t have to deviate from the FIX standard implementation as you are using the tags as FIX protocol has specified it. But this method of identifying the contracts is not sufficient for the Custom spreads.