Imported from previous forum
[ original email was from Jim Northey - jnorthey@lasalletech.com ]
NEED FEEDBACK OR OPINIONS ON THE FOLLOWING:
I spent the last week analyzing the information on implementations of multileg orders in our industry and trying to determine the correct approach for dealing with multileg execution reports.
I have now concluded the following:
-
Reporting only by leg is not a full enough API for
markets or market participants. -
Having a separate Execution Report makes execution
report processing more difficult. -
I believe that as we move to XML and to future
versions of FIX we will fully generalize the
Instrument block to include an optional repeating
group for multileg instruments. This will reduce the
number of messages we require and greatly expand FIX
use in derivatives markets. We should not do this now
- this should be 4.4 or 5.0 - whatever comes next. We
have the messages off to the side where we can let
them mature on their own until we are ready to
integrate them within the specification.
- 90+% of all fields are the same between the
multileg execution and the multileg order.
For the above reasons 1,2,4 - I think we should
consider adding the optional repeating group into the execution report now.
Reason 3 - says don’t do this now wait as we do for orders - however - users are not required to support all order messages if they don’t need them for a market. However, all users need to be able to accept an Execution Report from a market (sell side) - so I think we should keep them together.
This is how the CBOE has decided to implement their systems in house - this is how CBOT, CME would like to proceed. I think that this is how NYBOT is building their non-standard implementation now based upon email posts (can someone please confirm this for us?)
My current recommendation to the Technical Committee is fold the repeating group into the Execution Report. The tags are optional - we will continue to have one execution reporting mechanism - which is a good thing.
This was addresssed in FIX 4.3 Draft #3. The ExecutionRpt was expanded to optionally provide a leg repeating group. Thank you. [PC20010725_2]
> NEED FEEDBACK OR OPINIONS ON THE FOLLOWING:
>
> I spent the last week analyzing the information on implementations of multileg orders in our industry and trying to determine the correct approach for dealing with multileg execution reports.
>
> I have now concluded the following:
>
> 1) Reporting only by leg is not a full enough API for
> markets or market participants.
>
> 2) Having a separate Execution Report makes execution
> report processing more difficult.
>
> 3) I believe that as we move to XML and to future
> versions of FIX we will fully generalize the
> Instrument block to include an optional repeating
> group for multileg instruments. This will reduce the
> number of messages we require and greatly expand FIX
> use in derivatives markets. We should not do this now
> - this should be 4.4 or 5.0 - whatever comes next. We
> have the messages off to the side where we can let
> them mature on their own until we are ready to
> integrate them within the specification.
>
> 4) 90+% of all fields are the same between the
> multileg execution and the multileg order.
>
> For the above reasons 1,2,4 - I think we should
> consider adding the optional repeating group into the execution report now.
>
> Reason 3 - says don’t do this now wait as we do for orders - however - users are not required to support all order messages if they don’t need them for a market. However, all users need to be able to accept an Execution Report from a market (sell side) - so I think we should keep them together.
>
> This is how the CBOE has decided to implement their systems in house - this is how CBOT, CME would like to proceed. I think that this is how NYBOT is building their non-standard implementation now based upon email posts (can someone please confirm this for us?)
>
> My current recommendation to the Technical Committee is fold the repeating group into the Execution Report. The tags are optional - we will continue to have one execution reporting mechanism - which is a good thing.
>
>