Trading directly on a multileg strategy

, ,
1

Imported from previous forum

2

What’s the standard FIX method of trading directly on the calendar spread RIC code in FIX4.4?

Example, trading a calendar spread on 35=AB message and using the multi-leg format you would specify:

  • 555=2
  • add the two expiries in the repeating group section (600 tags)

Now, lets say a client wanted to trade directly on the instruments’ RIC code without the use of leg data, what does FIX state as the best way to do this?

Should user:

  1. send FIX4.4 35=AB and 555=0 and 22=5 and 48=FEIZ2-H3
  2. send FIX4.4 35=D and 22=5 and 48=FEIZ2-H3
  3. something else?

thanks

3

Option 2, i.e. do not send an “empty” repeating group with NoLegs=0. There are use cases when you use SecurityID=FEIZ2-H3 as well as NoLegs=2, i.e. when you need to provide leg level information such as open/close via LegPositionEffect (564). This means that you do not use LegOrdGrp to define the multileg instrument as such but do use it to convey dynamic, leg level data which can be different from one order to the other. You would not use InstrumentLeg in this case unless the user can selectively provide leg level information and needs to identify the leg(s) to you. FIX has made this easier recently by adding LegID (1788) to the InstrumentLeg where you can use 1,2,3,4,… to identify the first, second, third, fourth,… leg of its definition saving you from having to give all leg attributes. Note that this requires a well-defined ordering of the legs by the issuer of the RIC.
Regards,
Hanno.

What’s the standard FIX method of trading directly on the calendar spread RIC code in FIX4.4?

Example, trading a calendar spread on 35=AB message and using the multi-leg format you would specify:

  • 555=2
  • add the two expiries in the repeating group section (600 tags)

Now, lets say a client wanted to trade directly on the instruments’ RIC code without the use of leg data, what does FIX state as the best way to do this?

Should user:

  1. send FIX4.4 35=AB and 555=0 and 22=5 and 48=FEIZ2-H3
  2. send FIX4.4 35=D and 22=5 and 48=FEIZ2-H3
  3. something else?

thanks

4

What you say is interesting, ie define the instrument in the body of the message (48 & 22) and use the leg-level repeating tags to convey other info.

I was trying to find guidelines from the FIX4.4 spec, whether 35=D or 35=AB should be the preferred method in such cases but to no avail.

Dont suppose you have such a reference to the FIX standard?

Option 2, i.e. do not send an “empty” repeating group with NoLegs=0. There are use cases when you use SecurityID=FEIZ2-H3 as well as NoLegs=2, i.e. when you need to provide leg level information such as open/close via LegPositionEffect (564). This means that you do not use LegOrdGrp to define the multileg instrument as such but do use it to convey dynamic, leg level data which can be different from one order to the other. You would not use InstrumentLeg in this case unless the user can selectively provide leg level information and needs to identify the leg(s) to you. FIX has made this easier recently by adding LegID (1788) to the InstrumentLeg where you can use 1,2,3,4,… to identify the first, second, third, fourth,… leg of its definition saving you from having to give all leg attributes. Note that this requires a well-defined ordering of the legs by the issuer of the RIC.
Regards,
Hanno.

What’s the standard FIX method of trading directly on the calendar spread RIC code in FIX4.4?

Example, trading a calendar spread on 35=AB message and using the multi-leg format you would specify:

  • 555=2
  • add the two expiries in the repeating group section (600 tags)

Now, lets say a client wanted to trade directly on the instruments’ RIC code without the use of leg data, what does FIX state as the best way to do this?

Should user:

  1. send FIX4.4 35=AB and 555=0 and 22=5 and 48=FEIZ2-H3
  2. send FIX4.4 35=D and 22=5 and 48=FEIZ2-H3
  3. something else?

thanks

5

NewOrderSingle and NewOrderMultileg usage depends solely on the instrument and not on the fields that you need to use. If you want to enter an order for a mulitleg instrument then 35=AB is your only choice to be compliant with the standard even if 35=D provides you with all the tags you need from a technical point of view. The business view drives the usage. The recipient of such an order then knows whether he should look up the definition from somewhere else, in your case he should find 22=5 telling him that it is a RIC value. That points hin to reference data from Reuters to find out what the legs look like.

What you say is interesting, ie define the instrument in the body of the message (48 & 22) and use the leg-level repeating tags to convey other info.

I was trying to find guidelines from the FIX4.4 spec, whether 35=D or 35=AB should be the preferred method in such cases but to no avail.

Dont suppose you have such a reference to the FIX standard?

Option 2, i.e. do not send an “empty” repeating group with NoLegs=0. There are use cases when you use SecurityID=FEIZ2-H3 as well as NoLegs=2, i.e. when you need to provide leg level information such as open/close via LegPositionEffect (564). This means that you do not use LegOrdGrp to define the multileg instrument as such but do use it to convey dynamic, leg level data which can be different from one order to the other. You would not use InstrumentLeg in this case unless the user can selectively provide leg level information and needs to identify the leg(s) to you. FIX has made this easier recently by adding LegID (1788) to the InstrumentLeg where you can use 1,2,3,4,… to identify the first, second, third, fourth,… leg of its definition saving you from having to give all leg attributes. Note that this requires a well-defined ordering of the legs by the issuer of the RIC.
Regards,
Hanno.

What’s the standard FIX method of trading directly on the calendar spread RIC code in FIX4.4?

Example, trading a calendar spread on 35=AB message and using the multi-leg format you would specify:

  • 555=2
  • add the two expiries in the repeating group section (600 tags)

Now, lets say a client wanted to trade directly on the instruments’ RIC code without the use of leg data, what does FIX state as the best way to do this?

Should user:

  1. send FIX4.4 35=AB and 555=0 and 22=5 and 48=FEIZ2-H3
  2. send FIX4.4 35=D and 22=5 and 48=FEIZ2-H3
  3. something else?

thanks

6

Thanks for the update, much appreciated.

My initial view was the 35=AB was the right message to represent the strategy and you’ve confirmed my suspicions.

Just one thing - I searched the FIX specs but couldn’t find anything that would point to 35=AB as the preferred method of representing the strategy if trading directly on the instrument identifier.

If you have a link or know the reference that would be great.

thanks again

NewOrderSingle and NewOrderMultileg usage depends solely on the instrument and not on the fields that you need to use. If you want to enter an order for a mulitleg instrument then 35=AB is your only choice to be compliant with the standard even if 35=D provides you with all the tags you need from a technical point of view. The business view drives the usage. The recipient of such an order then knows whether he should look up the definition from somewhere else, in your case he should find 22=5 telling him that it is a RIC value. That points hin to reference data from Reuters to find out what the legs look like.

What you say is interesting, ie define the instrument in the body of the message (48 & 22) and use the leg-level repeating tags to convey other info.

I was trying to find guidelines from the FIX4.4 spec, whether 35=D or 35=AB should be the preferred method in such cases but to no avail.

Dont suppose you have such a reference to the FIX standard?

Option 2, i.e. do not send an “empty” repeating group with NoLegs=0. There are use cases when you use SecurityID=FEIZ2-H3 as well as NoLegs=2, i.e. when you need to provide leg level information such as open/close via LegPositionEffect (564). This means that you do not use LegOrdGrp to define the multileg instrument as such but do use it to convey dynamic, leg level data which can be different from one order to the other. You would not use InstrumentLeg in this case unless the user can selectively provide leg level information and needs to identify the leg(s) to you. FIX has made this easier recently by adding LegID (1788) to the InstrumentLeg where you can use 1,2,3,4,… to identify the first, second, third, fourth,… leg of its definition saving you from having to give all leg attributes. Note that this requires a well-defined ordering of the legs by the issuer of the RIC.
Regards,
Hanno.

What’s the standard FIX method of trading directly on the calendar spread RIC code in FIX4.4?

Example, trading a calendar spread on 35=AB message and using the multi-leg format you would specify:

  • 555=2
  • add the two expiries in the repeating group section (600 tags)

Now, lets say a client wanted to trade directly on the instruments’ RIC code without the use of leg data, what does FIX state as the best way to do this?

Should user:

  1. send FIX4.4 35=AB and 555=0 and 22=5 and 48=FEIZ2-H3
  2. send FIX4.4 35=D and 22=5 and 48=FEIZ2-H3
  3. something else?

thanks

7

Please refer to teh FIX 5.0 SP2 Errata Specification, Volume 4, Category Multileg Orders, starting on page 151. There you will find different models for trading multileg orders but all have the usage of 35=AB in common. On page 154 you will find a section called “Messages Used for Multileg Trading” with the following guidelines:
Order Entry - Use the New Order - Multileg (MsgType=AB) message to submit a multileg order to a market place.
Execution Reports for Multileg Orders - The Execution Report (MsgType=8) has been modified to report the order status of Multileg Orders.
Modification of a Multileg Order - Use the Multileg Order Cancel Replace Request (a.k.a MultilegOrder Modification Request) (MsgType=AC) to modify a Multileg Order.
Cancellation of a Multileg Order - Multileg orders are canceled using the Order Cancel Request (MsgType = F). The entire multileg order is cancelled by OrderID (tag #37) or ClOrdID (tag# 11). The ability to cancel one leg of a multileg order is not supported in FIX 4.3 and above.
Regards,
Hanno.

Thanks for the update, much appreciated.

My initial view was the 35=AB was the right message to represent the strategy and you’ve confirmed my suspicions.

Just one thing - I searched the FIX specs but couldn’t find anything that would point to 35=AB as the preferred method of representing the strategy if trading directly on the instrument identifier.

If you have a link or know the reference that would be great.

thanks again

NewOrderSingle and NewOrderMultileg usage depends solely on the instrument and not on the fields that you need to use. If you want to enter an order for a mulitleg instrument then 35=AB is your only choice to be compliant with the standard even if 35=D provides you with all the tags you need from a technical point of view. The business view drives the usage. The recipient of such an order then knows whether he should look up the definition from somewhere else, in your case he should find 22=5 telling him that it is a RIC value. That points hin to reference data from Reuters to find out what the legs look like.

What you say is interesting, ie define the instrument in the body of the message (48 & 22) and use the leg-level repeating tags to convey other info.

I was trying to find guidelines from the FIX4.4 spec, whether 35=D or 35=AB should be the preferred method in such cases but to no avail.

Dont suppose you have such a reference to the FIX standard?

Option 2, i.e. do not send an “empty” repeating group with NoLegs=0. There are use cases when you use SecurityID=FEIZ2-H3 as well as NoLegs=2, i.e. when you need to provide leg level information such as open/close via LegPositionEffect (564). This means that you do not use LegOrdGrp to define the multileg instrument as such but do use it to convey dynamic, leg level data which can be different from one order to the other. You would not use InstrumentLeg in this case unless the user can selectively provide leg level information and needs to identify the leg(s) to you. FIX has made this easier recently by adding LegID (1788) to the InstrumentLeg where you can use 1,2,3,4,… to identify the first, second, third, fourth,… leg of its definition saving you from having to give all leg attributes. Note that this requires a well-defined ordering of the legs by the issuer of the RIC.
Regards,
Hanno.

What’s the standard FIX method of trading directly on the calendar spread RIC code in FIX4.4?

Example, trading a calendar spread on 35=AB message and using the multi-leg format you would specify:

  • 555=2
  • add the two expiries in the repeating group section (600 tags)

Now, lets say a client wanted to trade directly on the instruments’ RIC code without the use of leg data, what does FIX state as the best way to do this?

Should user:

  1. send FIX4.4 35=AB and 555=0 and 22=5 and 48=FEIZ2-H3
  2. send FIX4.4 35=D and 22=5 and 48=FEIZ2-H3
  3. something else?

thanks