Imported from previous forum
[ original email was from John Cameron - jc@cameronsystems.com ]
1. In CrossOrderModification and CrossOrderCancel, should not the OrigClOrdID be a required field? That would be consistent with the scenarios given and with the general use of this field elsewhere in Fix.
-
The wording in the description of OrigCrossID in the message definitions for CrossOrderModification and CrossOrderCancel is misleading. It should not "match original cross order". It should match the -previous- cross order. The wording in the field definition (Vol 6) is much better and I would recommend that it be used in the message definitions as well.
-
I think there are some typo’s in the Cross Order Change Matrices - Cross Type 1. The message received should be Cross Cancel and the final state of OrdStatus should be Cancelled.
-
A typo in New Order - Multileg. In Component block <Instrument> notes it says SecurityType should = "MULTILEG". I think this should be "MLEG".
-
How do you cancel a multileg order?
-
It appears that the QuoteRequestReject message did not make it into Fiximate.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> 1. In CrossOrderModification and CrossOrderCancel, should not the OrigClOrdID be a required field? That would be consistent with the scenarios given and with the general use of this field elsewhere in Fix.
I think this is OK, and is the intended behavior.
For example, assume a firm receives two orders and wishes to cross them on an exchange. Tjat firm submits them to an exchange as follows:
CrossID=C1
…
Side=1 (Buy)
ClOrdID=B1
…
Side=5 (Sell Short)
ClOrdID=S1
…
Now let’s say that the selling party does a cancel/replace of S1 into S2, to turn the sell short into a sell. That means the side selling has a new ClOrdID, but the side buying is unchanged. A new CrossID also has to be generated. So the firm who sent the cross amends it as follows:
CrossID=C2
OrigCrossID=C1
…
Side=1
ClOrdID-B1
…
Side=2
OrigClOrdID=S1
ClOrdID=S2
…
Similarly, a parameter of the cross could be changed which doesn’t affect the legs. In that case, the legs keep the same ClOrdID, but the cross gets a new CrossID.
[ original email was from John Cameron - jc@cameronsystems.com ]
Thanks for the clarification. I had assumed that in a cancel/replace only the changed side would have to be submitted.
It might be worth noting in the spec that if a side’s details IS changed then OrigClOrdID is required and a new ClOrdID must be assigned.
What OrdStatus should be returned for unchanged sides? Should it be Pending Replaced/Replaced even for sides that have not been modified?
John
> > 1. In CrossOrderModification and CrossOrderCancel, should not the OrigClOrdID be a required field? That would be consistent with the scenarios given and with the general use of this field elsewhere in Fix.
>
> I think this is OK, and is the intended behavior.
>
> For example, assume a firm receives two orders and wishes to cross them on an exchange. Tjat firm submits them to an exchange as follows:
>
> CrossID=C1
> …
> Side=1 (Buy)
> ClOrdID=B1
> …
> Side=5 (Sell Short)
> ClOrdID=S1
> …
>
> Now let’s say that the selling party does a cancel/replace of S1 into S2, to turn the sell short into a sell. That means the side selling has a new ClOrdID, but the side buying is unchanged. A new CrossID also has to be generated. So the firm who sent the cross amends it as follows:
>
> CrossID=C2
> OrigCrossID=C1
> …
> Side=1
> ClOrdID-B1
> …
> Side=2
> OrigClOrdID=S1
> ClOrdID=S2
> …
>
> Similarly, a parameter of the cross could be changed which doesn’t affect the legs. In that case, the legs keep the same ClOrdID, but the cross gets a new CrossID.
>
>