Imported from previous forum
The 4.1 spec says that 37=OrderID and 17=ExecID are both optional fields in a DK message.
I think they should be mandatory: if you can’t use these fields to refer to the Execution Report you are DKing, what can you use? None of the other fields are necessarily unique, and if the ExecutionReport didn’t have OrderID and ExecID, it would have been rejected as failing validation.
[ original email was from Yevgeniy Tovshteyn - yevgeniy@javtech.com ]
That’s the whole point. DK might be issued as a result of not being able to locate Order, so OrderID is complitly invalid.
> The 4.1 spec says that 37=OrderID and 17=ExecID are both optional fields in a DK message.
> I think they should be mandatory: if you can’t use these fields to refer to the Execution Report you are DKing, what can you use? None of the other fields are necessarily unique, and if the ExecutionReport didn’t have OrderID and ExecID, it would have been rejected as failing validation.
>
> That’s the whole point. DK might be issued as a result of not being able to locate Order, so OrderID is complitly invalid.
No, that would be the ClOrdID (assigned by the buy side). If buy side gets an ER without a known ClOrdID, they would DK the ER. The ER would have an OrderID (assigned by the sell side), which I maintain should always be quoted in the DK.
I agree with Richard that the OrderID and ExecID should be required in the DK message. The DK is issued in response to an ExecutionRpt message and those two fields are required in the ExecutionRpt thus should be available to the customer who is DK’s the ExecutionRpt message. ClOrdID is not required in the ExecutionRpt thus must be optional in the DK. I’ll add this to the list of proposed changes for the next release.
> > That’s the whole point. DK might be issued as a result of not being able to locate Order, so OrderID is complitly invalid.
>
> No, that would be the ClOrdID (assigned by the buy side). If buy side gets an ER without a known ClOrdID, they would DK the ER. The ER would have an OrderID (assigned by the sell side), which I maintain should always be quoted in the DK.
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> I agree with Richard that the OrderID and ExecID should be required in the DK message. The DK is issued in response to an ExecutionRpt message and those two fields are required in the ExecutionRpt thus should be available to the customer who is DK’s the ExecutionRpt message. ClOrdID is not required in the ExecutionRpt thus must be optional in the DK. I’ll add this to the list of proposed changes for the next release.
So in a case where either the OrderID or ExecID are missing, the FIX Execution message should be rejected at session level?
> > I agree with Richard that the OrderID and ExecID should be required in the DK message. The DK is issued in response to an ExecutionRpt message and those two fields are required in the ExecutionRpt thus should be available to the customer who is DK’s the ExecutionRpt message. ClOrdID is not required in the ExecutionRpt thus must be optional in the DK. I’ll add this to the list of proposed changes for the next release.
>
> So in a case where either the OrderID or ExecID are missing, the FIX Execution message should be rejected at session level?
>
>
I should think so: OrderID and ExecID are both required fields of Execution Report.
My original query was a bit pedantic – it would be very perverse not to include OrderID and ExecID in a DK. However the spec change would let you assume that these fields do exist when handling a DK at the application level.
<snip>
> > So in a case where either the OrderID or ExecID are missing, the FIX Execution message should be rejected at session level?
> >
> >
>
> I should think so: OrderID and ExecID are both required fields of Execution Report.
>
<snip>
Well, I disagree. It is clearly stated in the 4.1 specification that:
"The reject message should be issued when a message is received butcannot be passed through to the application level."
The missing OrderID and ExecID fields, though required, does not hinder the session layer to pass the message to the application layer.
IMO, there are very few errors that will generate a reject message if one follows the spec to the letter…
Ulf Eriksson - Interbizz Financial Systems
I believe that if a message is missing a field required by the specification, then that message should be rejected unless you and your counterparty have worked out some other arrangement.
How would you handle this particular case at the application layer?
> <snip>
> > > So in a case where either the OrderID or ExecID are missing, the FIX Execution message should be rejected at session level?
> > >
> > >
> >
> > I should think so: OrderID and ExecID are both required fields of Execution Report.
> >
> <snip>
>
> Well, I disagree. It is clearly stated in the 4.1 specification that:
>
> "The reject message should be issued when a message is received butcannot be passed through to the application level."
>
> The missing OrderID and ExecID fields, though required, does not hinder the session layer to pass the message to the application layer.
>
> IMO, there are very few errors that will generate a reject message if one follows the spec to the letter…
>
> Ulf Eriksson - Interbizz Financial Systems
>
>
> I believe that if a message is missing a field required by the specification, then that message should be rejected unless you and your counterparty have worked out some other arrangement.
>
> How would you handle this particular case at the application layer?
>
My main objection is that if the session layer would check all required and conditionally required fields in an application message, much of the interpretation of the meaning of the fields would have to be included into the session layer. This would complicate matters when dealing with mutually agreed exclusions and/or extended and/or customized messages.
According to the spec, the DK message can be used as an execution reject message and I can’t see any benefits from using a session level reject instead of a DK message. Sure enough, the application layer may send a reject message, but the counterpart, IMHO, will not get any more information from it than it will from a DK message.
If the execution message passed the checksum check with missing OrderID and ExecID, one can assume that the message was assembled without these fields and that the transmission was OK. Knowing the sequence number of the faulty execution report would not really be of any use.
Ulf Eriksson - Interbizz Financial Systems
I was only referring to required fields. Conditionally required becomes a grayer area and there I would agree with your argument about "business knowledge" in the session layer. My engine (session layer) can "know" about the field reference, tags, data types, valid values or ranges for fields, valid fields for messages and which ones of those are required per the spec without having any business logic, in my opinion. In that case the session layer is simply parsing and screening to ensure that valid, usable messages per the spec are provided to the application/business layer processing. I would argue that the application layer should not initiate a FIX session-level Reject.
This posting started out with what one should do about a DK message missing required fields. We are not suggesting that the Reject message be used instead of the Don’t Know Trade message, rather that if the DK message (or any other message) is missing a required field, then the session-level Reject is the appropriate response. There is no application-level response message to the DK so in your example, you would have to simply accept and ignore what one could argue is a fundamental problem with the message you received.
> > I believe that if a message is missing a field required by the specification, then that message should be rejected unless you and your counterparty have worked out some other arrangement.
> >
> > How would you handle this particular case at the application layer?
> >
>
> My main objection is that if the session layer would check all required and conditionally required fields in an application message, much of the interpretation of the meaning of the fields would have to be included into the session layer. This would complicate matters when dealing with mutually agreed exclusions and/or extended and/or customized messages.
>
> According to the spec, the DK message can be used as an execution reject message and I can’t see any benefits from using a session level reject instead of a DK message. Sure enough, the application layer may send a reject message, but the counterpart, IMHO, will not get any more information from it than it will from a DK message.
>
> If the execution message passed the checksum check with missing OrderID and ExecID, one can assume that the message was assembled without these fields and that the transmission was OK. Knowing the sequence number of the faulty execution report would not really be of any use.
>
> Ulf Eriksson - Interbizz Financial Systems
>
>