I find little bit unusual to use ExecID(17) in the DontknowTrade(35=Q) message as the message ID of the problem execution. We use this message to reject the ER received by our venue in last look RFQ workflow. As the rejection is an event for the venue, we generate our own ID. I do understand that we need to provide the ID of the specific messge that is being DKTed.Wouldn’t it make sense to use ExecRefID(19) instead ?
A DK isn’t an Execution, it shouldn’t have an ExecID of it’s own.
The ExecID for the DK is the Exec being DK’d.
More generally, ExecID is the ID of the Execution, not the UUID of the Execution Report message. The report is merely the notification of an Execution that took place.
If your platform assigns a UUID for the DK then feel free to put that in a custom tag (one option is 9262 - MsgID) if it’s useful internally, but in general you will have certification problems if you put that in ExecID instead of the ID of the execution being DK’d - the expectations of this tag in a DK is well specified.
@willson ExecRefID(19) is not part of the DK message and hence not an option. If you are proposing to add it to the DK message, then I would say the following. FIX fields XXXRefID (or RefXXXID) are provided whenever the same message needs to identify two instances of an entity or message. In the case of the ER message, it is for referencing a previous ER message in addition to identifying the ER message sending the reference.
In other words, if a message only needs to identify a single instance, it should always be just XXXID. The DK message does not need more than one and has been around for decades with just ExecID.
To be fair, the DK message does not have a message level identifier on the application level. The alternative ExecutionAck(35=BN) message also does not have one. You would need to combine the ExecID with the MsgType(35) in some way to distinguish the ER and its rejection message.
1 Like
Thanks for the response and providing the clarity on usage of ExecRefID.