Imported from previous forum
Hi
Is it valid to send both Tag 11 and Tag 41 in an execution report for a modified order?
Or is this against FIX protocol?
Many thanks
Kim
It is absolutely necessary to support the FIX order chaining model. How can you omit one or the other and still figure out what the Execution Report is about?
Tag 11 is the ID of the OrderCancelReplace request message.
Tag 41 is the ID of the order that you have successfully modified.
The spec says that 41 is conditionally required in such a scenario.
Regards,
Hanno.
Hi
Is it valid to send both Tag 11 and Tag 41 in an execution report for a
modified order?Or is this against FIX protocol?
Many thanks
Kim
The FIX 5.0 specification Volume 4 has some outstanding order state change matrices describing cancel/replace message flows.
See pages 63-75 of http://www.fixprotocol.org/documents/4486/FIX-5.0_SP2_VOL-4.pdf
When you say execution report do you mean the response to the Cancel/Replace message(i.e Pending or Replaced msg)? If so, then tag 41 is required and tag 11 can be sent but is not required.
If you mean sending executions (fills) on a modified order, then tag 41 and 11 can be sent, it is not against the FIX protocol, but they are not required.
Tag 11 ClOrdID is required in all execution reports which are sent in response to electronically submitted orders.
Tag 41 OrigClOrdID is required when Tag 150 ExecType is PendingCancel (6), Replaced (5) or Canceled (4), for other ExecTypes, sending Tag 41 is meaningless as many FIX engines would not be looking for it in ExecReports.
When you say execution report do you mean the response to the
Cancel/Replace message(i.e Pending or Replaced msg)? If so, then tag 41
is required and tag 11 can be sent but is not required. If you mean
sending executions (fills) on a modified order, then tag 41 and 11 can
be sent, it is not against the FIX protocol, but they are not required.
According to the FIX protocol spec, tag 11 is not required in the execution reports, yes almost all firms send this tag in the execution reports but it is not a required tag, it is only required in the New Order messsges.
Tag 11 ClOrdID is required in all execution reports which are sent in
response to electronically submitted orders.Tag 41 OrigClOrdID is required when Tag 150 ExecType is PendingCancel
(6), Replaced (5) or Canceled (4), for other ExecTypes, sending Tag 41
is meaningless as many FIX engines would not be looking for it in
ExecReports.When you say execution report do you mean the response to the
Cancel/Replace message(i.e Pending or Replaced msg)? If so, then tag
41 is required and tag 11 can be sent but is not required. If you mean
sending executions (fills) on a modified order, then tag 41 and 11 can
be sent, it is not against the FIX protocol, but they are not
required.
I think this needs to be clarified to avoid confusion. The column “Req’d” in the spec is not the only way for FIX to declare a field to be required or not. The comment column is another possible source. The position of a field in a repeating group is a third possible source when using the tag=value syntax. The previous poster actually quoted from the comment in the spec.
What happens if you do not send tag 11 in the Execution Report responding to a New Order Single? The submitter of the order will have a hard time to know which report refers to which order entry message if he does not wait for a response before sending another new order. From then on he could use the exchange order ID (tag 37) but it is neither permitted nor recommended to omit tag 11 in the Execution Report in the plain vanilla cases. There are very few exceptions where tag 11 is not available and thus cannot be returned.
What advantage does it have to suppress tag 11 on an ExecutionReport? I would like to understand why that makes life easier for the recipient of order messages, regardless of what the spec says.
Thank you,
Hanno.
According to the FIX protocol spec, tag 11 is not required in the
execution reports, yes almost all firms send this tag in the execution
reports but it is not a required tag, it is only required in the New
Order messsges.Tag 11 ClOrdID is required in all execution reports which are sent in
response to electronically submitted orders.Tag 41 OrigClOrdID is required when Tag 150 ExecType is PendingCancel
(6), Replaced (5) or Canceled (4), for other ExecTypes, sending Tag 41
is meaningless as many FIX engines would not be looking for it in
ExecReports.When you say execution report do you mean the response to the
Cancel/Replace message(i.e Pending or Replaced msg)? If so, then tag
41 is required and tag 11 can be sent but is not required. If you
mean sending executions (fills) on a modified order, then tag 41 and
11 can be sent, it is not against the FIX protocol, but they are not
required.
Hanno,
In FIXimate / FIX specifications, presently the required column just says yes or no. I think this should be changed to have the words
Reqd - The field has to be present in the message - there are no ifs and buts
Cond - The field is conditionally required based on presence or absence of other fields or values in other fields
Opt - The field is optional
I have come accross many people interpreting the Required = N without looking at the comments column. Having value Cond would make these folks look further towards conditions in which the field is required.
Regards,
Mahesh
I think this needs to be clarified to avoid confusion. The column
“Req’d” in the spec is not the only way for FIX to declare a field to be
required or not. The comment column is another possible source. The
position of a field in a repeating group is a third possible source when
using the tag=value syntax. The previous poster actually quoted from the
comment in the spec.What happens if you do not send tag 11 in the Execution Report
responding to a New Order Single? The submitter of the order will have a
hard time to know which report refers to which order entry message if he
does not wait for a response before sending another new order. From then
on he could use the exchange order ID (tag 37) but it is neither
permitted nor recommended to omit tag 11 in the Execution Report in the
plain vanilla cases. There are very few exceptions where tag 11 is not
available and thus cannot be returned.What advantage does it have to suppress tag 11 on an ExecutionReport? I
would like to understand why that makes life easier for the recipient of
order messages, regardless of what the spec says.Thank you, Hanno.
According to the FIX protocol spec, tag 11 is not required in the
execution reports, yes almost all firms send this tag in the execution
reports but it is not a required tag, it is only required in the New
Order messsges.Tag 11 ClOrdID is required in all execution reports which are sent
in response to electronically submitted orders.Tag 41 OrigClOrdID is required when Tag 150 ExecType is
PendingCancel
(6), Replaced (5) or Canceled (4), for other ExecTypes, sending Tag
41 is meaningless as many FIX engines would not be looking for it
in ExecReports.When you say execution report do you mean the response to the
Cancel/Replace message(i.e Pending or Replaced msg)? If so, then
tag 41 is required and tag 11 can be sent but is not required. If
you mean sending executions (fills) on a modified order, then tag
41 and 11 can be sent, it is not against the FIX protocol, but
they are not required.
Mahesh,
I agree that there is benefit in doing this but this would be a major undertaking for FPL and is a task that is far from trivial. There are many reasons for a conditional requirement and these would still have to be described in the comment column.
A special (and trivial) case of a conditional requirement are the repeating groups where the first field is always required when using the tag=value syntax and other fields are required for every instance of a repeating group (Conditionally required when NoXXX>0).
Less trivial are conditional requirements that FPL cannot pre-define but that are still needed in the rules of engagement. For example, the ExecutionReport has an optional InstrmtLegExecGrp which becomes conditionally required when you convey a multi-leg execution on the leg level and not on an instrument level. What I am trying to say is that a large number of fields are conditionally required for semantic reasons that may or may not be relevant for any given implementation. This should be left for the Rules of Engagement to describe.
It might make sense and be a reasonable effort to automatically flag message fields in the Req’d column that have the term “conditionally required” in their comment column. This would give a heads up to developers that they really need to read the comment column :-).
Regards,
Hanno.
Hanno,
In FIXimate / FIX specifications, presently the required column just
says yes or no. I think this should be changed to have the wordsReqd - The field has to be present in the message - there are no
ifs and butsCond - The field is conditionally required based on presence or absence
of other fields or values in other fieldsOpt - The field is optional
I have come accross many people interpreting the Required = N without
looking at the comments column. Having value Cond would make these folks
look further towards conditions in which the field is required.Regards, Mahesh
I think this needs to be clarified to avoid confusion. The column
“Req’d” in the spec is not the only way for FIX to declare a field to
be required or not. The comment column is another possible source. The
position of a field in a repeating group is a third possible source
when using the tag=value syntax. The previous poster actually quoted
from the comment in the spec.What happens if you do not send tag 11 in the Execution Report
responding to a New Order Single? The submitter of the order will have
a hard time to know which report refers to which order entry message
if he does not wait for a response before sending another new order.
From then on he could use the exchange order ID (tag 37) but it is
neither permitted nor recommended to omit tag 11 in the Execution
Report in the plain vanilla cases. There are very few exceptions where
tag 11 is not available and thus cannot be returned.What advantage does it have to suppress tag 11 on an ExecutionReport?
I would like to understand why that makes life easier for the
recipient of order messages, regardless of what the spec says.Thank you, Hanno.
According to the FIX protocol spec, tag 11 is not required in the
execution reports, yes almost all firms send this tag in the
execution reports but it is not a required tag, it is only required
in the New Order messsges.Tag 11 ClOrdID is required in all execution reports which are sent
in response to electronically submitted orders.Tag 41 OrigClOrdID is required when Tag 150 ExecType is
PendingCancel
(6), Replaced (5) or Canceled (4), for other ExecTypes, sending
Tag 41 is meaningless as many FIX engines would not be looking
for it in ExecReports.When you say execution report do you mean the response to the
Cancel/Replace message(i.e Pending or Replaced msg)? If so, then
tag 41 is required and tag 11 can be sent but is not required.
If you mean sending executions (fills) on a modified order, then
tag 41 and 11 can be sent, it is not against the FIX protocol,
but they are not required.
I had suggested this to Matt quite some time ago. I believe there are a “handful” of tags that are structurally conditionally required, one of which you indicate regarding repeating groups.
A couple of others relate to the Execution report (as mentioned below)which has several purposes.
The general purpose specification would be not be the best place for other “conditionally required” tags that are subject to the rules of engagement. This could get quite tedious and lengthy (and subject to change).
Perhaps any field indicated as “not required” (on “inbound” messages anyways) should ALWAYS be investigated according to the rules of engagement.
Mahesh,
I agree that there is benefit in doing this but this would be a major
undertaking for FPL and is a task that is far from trivial. There are
many reasons for a conditional requirement and these would still have to
be described in the comment column.A special (and trivial) case of a conditional requirement are the
repeating groups where the first field is always required when using the
tag=value syntax and other fields are required for every instance of a
repeating group (Conditionally required when NoXXX>0).Less trivial are conditional requirements that FPL cannot pre-define but
that are still needed in the rules of engagement. For example, the
ExecutionReport has an optional InstrmtLegExecGrp which becomes
conditionally required when you convey a multi-leg execution on the leg
level and not on an instrument level. What I am trying to say is that a
large number of fields are conditionally required for semantic reasons
that may or may not be relevant for any given implementation. This
should be left for the Rules of Engagement to describe.It might make sense and be a reasonable effort to automatically flag
message fields in the Req’d column that have the term “conditionally
required” in their comment column. This would give a heads up to
developers that they really need to read the comment column :-).Regards, Hanno.
Hanno,
In FIXimate / FIX specifications, presently the required column just
says yes or no. I think this should be changed to have the wordsReqd - The field has to be present in the message - there are no ifs
and butsCond - The field is conditionally required based on presence or
absence of other fields or values in other fieldsOpt - The field is optional
I have come accross many people interpreting the Required = N without
looking at the comments column. Having value Cond would make these
folks look further towards conditions in which the field is required.Regards, Mahesh
I think this needs to be clarified to avoid confusion. The column
“Req’d” in the spec is not the only way for FIX to declare a field
to be required or not. The comment column is another possible
source. The position of a field in a repeating group is a third
possible source when using the tag=value syntax. The previous poster
actually quoted from the comment in the spec.What happens if you do not send tag 11 in the Execution Report
responding to a New Order Single? The submitter of the order will
have a hard time to know which report refers to which order entry
message if he does not wait for a response before sending another
new order. From then on he could use the exchange order ID (tag 37)
but it is neither permitted nor recommended to omit tag 11 in the
Execution Report in the plain vanilla cases. There are very few
exceptions where tag 11 is not available and thus cannot be
returned.What advantage does it have to suppress tag 11 on an
ExecutionReport? I would like to understand why that makes life
easier for the recipient of order messages, regardless of what the
spec says.Thank you, Hanno.
According to the FIX protocol spec, tag 11 is not required in the
execution reports, yes almost all firms send this tag in the
execution reports but it is not a required tag, it is only
required in the New Order messsges.Tag 11 ClOrdID is required in all execution reports which are
sent in response to electronically submitted orders.Tag 41 OrigClOrdID is required when Tag 150 ExecType is
PendingCancel
(6), Replaced (5) or Canceled (4), for other ExecTypes, sending
Tag 41 is meaningless as many FIX engines would not be
looking for it in ExecReports.When you say execution report do you mean the response to the
Cancel/Replace message(i.e Pending or Replaced msg)? If so,
then tag 41 is required and tag 11 can be sent but is not
required. If you mean sending executions (fills) on a modified
order, then tag 41 and 11 can be sent, it is not against the
FIX protocol, but they are not required.
The Repository Working Group will be taking this up some time in the near future after we ship the repository 20109215 edition later this month. The plan would be able to expand to include conditionally required and to also have some form of rules language that could be used to specify the rule. Natural Rules Language has immediate appeal from a practitioners perspective. It can be easily read and used, but could also be parsed and read by computer systems. The drawback is which natural language? It would continue and even strengthen our English language bias. OCL version 2.0 was considered - but I think this much to esoteric and difficult to learn for the majority of FIX practitioners. I taught formal methods and University and have found OCL difficult to use as a practitioner.
We could take your suggestion as a first step - just introduce the Conditional enumeration value for Required and only use it for NumInGroup fields that are required when NoXXXX > 0 or NoXXX Exists.
In fact - I am thinking this is a good next increment for the repository - one step before we introduce a full rules language.
I had suggested this to Matt quite some time ago. I believe there are a
“handful” of tags that are structurally conditionally required, one of
which you indicate regarding repeating groups. A couple of others relate
to the Execution report (as mentioned below)which has several purposes.
The general purpose specification would be not be the best place for
other “conditionally required” tags that are subject to the rules of
engagement. This could get quite tedious and lengthy (and subject to
change). Perhaps any field indicated as “not required” (on “inbound”
messages anyways) should ALWAYS be investigated according to the rules
of engagement.Mahesh,
I agree that there is benefit in doing this but this would be a major
undertaking for FPL and is a task that is far from trivial. There are
many reasons for a conditional requirement and these would still have
to be described in the comment column.A special (and trivial) case of a conditional requirement are the
repeating groups where the first field is always required when using
the tag=value syntax and other fields are required for every instance
of a repeating group (Conditionally required when NoXXX>0).Less trivial are conditional requirements that FPL cannot pre-define
but that are still needed in the rules of engagement. For example, the
ExecutionReport has an optional InstrmtLegExecGrp which becomes
conditionally required when you convey a multi-leg execution on the
leg level and not on an instrument level. What I am trying to say is
that a large number of fields are conditionally required for semantic
reasons that may or may not be relevant for any given implementation.
This should be left for the Rules of Engagement to describe.It might make sense and be a reasonable effort to automatically flag
message fields in the Req’d column that have the term “conditionally
required” in their comment column. This would give a heads up to
developers that they really need to read the comment column :-).Regards, Hanno.
Hanno,
In FIXimate / FIX specifications, presently the required column just
says yes or no. I think this should be changed to have the wordsReqd - The field has to be present in the message - there are no ifs
and butsCond - The field is conditionally required based on presence or
absence of other fields or values in other fieldsOpt - The field is optional
I have come accross many people interpreting the Required = N
without looking at the comments column. Having value Cond would make
these folks look further towards conditions in which the field is
required.Regards, Mahesh
I think this needs to be clarified to avoid confusion. The column
“Req’d” in the spec is not the only way for FIX to declare a field
to be required or not. The comment column is another possible
source. The position of a field in a repeating group is a third
possible source when using the tag=value syntax. The previous
poster actually quoted from the comment in the spec.What happens if you do not send tag 11 in the Execution Report
responding to a New Order Single? The submitter of the order will
have a hard time to know which report refers to which order entry
message if he does not wait for a response before sending another
new order. From then on he could use the exchange order ID (tag
37) but it is neither permitted nor recommended to omit tag 11 in
the Execution Report in the plain vanilla cases. There are very
few exceptions where tag 11 is not available and thus cannot be
returned.What advantage does it have to suppress tag 11 on an
ExecutionReport? I would like to understand why that makes life
easier for the recipient of order messages, regardless of what the
spec says.Thank you, Hanno.
According to the FIX protocol spec, tag 11 is not required in
the execution reports, yes almost all firms send this tag in the
execution reports but it is not a required tag, it is only
required in the New Order messsges.Tag 11 ClOrdID is required in all execution reports which are
sent in response to electronically submitted orders.Tag 41 OrigClOrdID is required when Tag 150 ExecType is
PendingCancel
(6), Replaced (5) or Canceled (4), for other ExecTypes,
sending Tag 41 is meaningless as many FIX engines would not
be looking for it in ExecReports.When you say execution report do you mean the response to
the Cancel/Replace message(i.e Pending or Replaced msg)? If
so, then tag 41 is required and tag 11 can be sent but is
not required. If you mean sending executions (fills) on a
modified order, then tag 41 and 11 can be sent, it is not
against the FIX protocol, but they are not required.
When you say execution report do you mean the response to the
Cancel/Replace message(i.e Pending or Replaced msg)? If so, then tag 41
is required and tag 11 can be sent but is not required. If you mean
sending executions (fills) on a modified order, then tag 41 and 11 can
be sent, it is not against the FIX protocol, but they are not required.
Sorry I should have been more specific. We are sending back Tags 11 and 41 on all execution reports for the modified order. i.e. the pending replace (150 = E), the replace (150 = 5) and subsequent execution reports for any fills done to the modified order after the modification.