Calender Spreads for Listed Derivatives

, ,
1

Imported from previous forum

2

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

3

[ original email was from Jeremy Sutton - 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.

4

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.