Imported from previous forum
The Don’t Know Trade message is used to reject an unknown order or an unknown or invalid execution. The DK Trade is always sent in response to an Execution Report. For FIX versions before FIX 5.0, assuming the previously listed assertions are valid,
What is an appropriate response to the DK Trade message that rejects an Execution Report reporting a fill or partial fill (assuming that the reject of the fill is valid from a business perspective)?
Would it be appropriate for the DK Trade recipient to send an Execution Report with ExecTransType=CANCEL to cancel the previous report or would it be more appropriate to send an ExecTransType=REPLACE to replace the rejected fill.
Has anyone implemented something like this in practice?
In this post I meant ExecTransType=CORRECT (not Replace)
The Don’t Know Trade message is used to reject an unknown order or an
unknown or invalid execution. The DK Trade is always sent in response to
an Execution Report. For FIX versions before FIX 5.0, assuming the
previously listed assertions are valid,What is an appropriate response to the DK Trade message that rejects an
Execution Report reporting a fill or partial fill (assuming that the
reject of the fill is valid from a business perspective)?Would it be appropriate for the DK Trade recipient to send an Execution
Report with ExecTransType=CANCEL to cancel the previous report or would
it be more appropriate to send an ExecTransType=REPLACE to replace the
rejected fill.Has anyone implemented something like this in practice?
I think this is more of what’s the business practice in this kind of situation type question. The protocol itself doesn’t prevent you from doing what you described if the two parties agree to that type of message flow, but it also begs the question of whether once a DKTrade is receive should that be an end state or not.
In this post I meant ExecTransType=CORRECT (not Replace)
The Don’t Know Trade message is used to reject an unknown order or an
unknown or invalid execution. The DK Trade is always sent in response
to an Execution Report. For FIX versions before FIX 5.0, assuming the
previously listed assertions are valid,What is an appropriate response to the DK Trade message that rejects
an Execution Report reporting a fill or partial fill (assuming that
the reject of the fill is valid from a business perspective)?Would it be appropriate for the DK Trade recipient to send an
Execution Report with ExecTransType=CANCEL to cancel the previous
report or would it be more appropriate to send an
ExecTransType=REPLACE to replace the rejected fill.Has anyone implemented something like this in practice?
“once a DKTrade is receive should that be an end state or not.”
I think so. The previous report (fill) that was DK’d is null and void by virtue of the DK. Therefore I wouldn’t try to REPLACE or CORRECT it. Instead, take the next appropriate action, e.g. if the order is already filled and they DK’d an overfill, do nothing. If the order is still open/unfilled then you’re clear to send more reports. Of course, as mentioned, this also depends on the business practice agreed to.
I think this is more of what’s the business practice in this kind of
situation type question. The protocol itself doesn’t prevent you from
doing what you described if the two parties agree to that type of
message flow, but it also begs the question of whether once a DKTrade is
receive should that be an end state or not.In this post I meant ExecTransType=CORRECT (not Replace)
The Don’t Know Trade message is used to reject an unknown order or
an unknown or invalid execution. The DK Trade is always sent in
response to an Execution Report. For FIX versions before FIX 5.0,
assuming the previously listed assertions are valid,What is an appropriate response to the DK Trade message that rejects
an Execution Report reporting a fill or partial fill (assuming that
the reject of the fill is valid from a business perspective)?Would it be appropriate for the DK Trade recipient to send an
Execution Report with ExecTransType=CANCEL to cancel the previous
report or would it be more appropriate to send an
ExecTransType=REPLACE to replace the rejected fill.Has anyone implemented something like this in practice?
[ original email was from John Prewett - jprewett@lavatrading.com ]
Hi Lisa & Jim,
From what I have witnessed, receipt of a DK Trade message typically indicates some type of serious system problem. Why is the trade being rejected? It’s not normal business practice to be permitted to refuse a trade unless there is some type of functional error involved.
As such, automating a response to some type of system error can often merely add to the confusion.
The automated sending of a DK Trade should also cause internal support teams to be alerted. Receiving a DK Trade should similarly cause internal support teams to be alerted. After that, manual procedures take over to handle what the automated systems are indicating by the very existence of a DK Trade message that they cannot manage.
So I recommend no automated response to a DK Trade message.
From experience, support teams on both sides get together and manually patch the data on both sides when agreement is reached as to what should be done. Typically, no further FIX messages flow.
DK Trade messages are merely something produced by automated systems to highlight a problem to the support teams on both sides of a FIX session.
I hope this helps.
JohnP
I think this is more of what’s the business practice in this kind of
situation type question. The protocol itself doesn’t prevent you from
doing what you described if the two parties agree to that type of
message flow, but it also begs the question of whether once a DKTrade is
receive should that be an end state or not.In this post I meant ExecTransType=CORRECT (not Replace)
The Don’t Know Trade message is used to reject an unknown order or
an unknown or invalid execution. The DK Trade is always sent in
response to an Execution Report. For FIX versions before FIX 5.0,
assuming the previously listed assertions are valid,What is an appropriate response to the DK Trade message that rejects
an Execution Report reporting a fill or partial fill (assuming that
the reject of the fill is valid from a business perspective)?Would it be appropriate for the DK Trade recipient to send an
Execution Report with ExecTransType=CANCEL to cancel the previous
report or would it be more appropriate to send an
ExecTransType=REPLACE to replace the rejected fill.Has anyone implemented something like this in practice?
John,
I’m in agreement with you which is why I said that this is more of a business/best practices question. In all implementations I’ve dealt with, a DKTrade is an end state and the problem is resolved off line.
Hi Lisa & Jim,
From what I have witnessed, receipt of a DK Trade message typically
indicates some type of serious system problem. Why is the trade being
rejected? It’s not normal business practice to be permitted to refuse a
trade unless there is some type of functional error involved.As such, automating a response to some type of system error can often
merely add to the confusion.The automated sending of a DK Trade should also cause internal support
teams to be alerted. Receiving a DK Trade should similarly cause
internal support teams to be alerted. After that, manual procedures take
over to handle what the automated systems are indicating by the very
existence of a DK Trade message that they cannot manage.So I recommend no automated response to a DK Trade message. From
experience, support teams on both sides get together and manually patch
the data on both sides when agreement is reached as to what should be
done. Typically, no further FIX messages flow. DK Trade messages are
merely something produced by automated systems to highlight a problem to
the support teams on both sides of a FIX session.I hope this helps.
JohnP
I think this is more of what’s the business practice in this kind of
situation type question. The protocol itself doesn’t prevent you from
doing what you described if the two parties agree to that type of
message flow, but it also begs the question of whether once a DKTrade
is receive should that be an end state or not.In this post I meant ExecTransType=CORRECT (not Replace)
The Don’t Know Trade message is used to reject an unknown order or
an unknown or invalid execution. The DK Trade is always sent in
response to an Execution Report. For FIX versions before FIX 5.0,
assuming the previously listed assertions are valid,What is an appropriate response to the DK Trade message that
rejects an Execution Report reporting a fill or partial fill
(assuming that the reject of the fill is valid from a business
perspective)?Would it be appropriate for the DK Trade recipient to send an
Execution Report with ExecTransType=CANCEL to cancel the previous
report or would it be more appropriate to send an
ExecTransType=REPLACE to replace the rejected fill.Has anyone implemented something like this in practice?
[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
I couldn’t resist adding some color to this thread: As new products are introduced on our platform there is often a time lag before our customers’ automated systems are ready to handle the new ERs. We allow them to send us DKs for committed trades they aren’t yet prepared to process as a way to purge them from their systems. In this case no system action is required on either side, and the DK has no effect on trade state.
John,
I’m in agreement with you which is why I said that this is more of a
business/best practices question. In all implementations I’ve dealt
with, a DKTrade is an end state and the problem is resolved off line.Hi Lisa & Jim,
From what I have witnessed, receipt of a DK Trade message typically
indicates some type of serious system problem. Why is the trade being
rejected? It’s not normal business practice to be permitted to refuse
a trade unless there is some type of functional error involved.As such, automating a response to some type of system error can often
merely add to the confusion.The automated sending of a DK Trade should also cause internal support
teams to be alerted. Receiving a DK Trade should similarly cause
internal support teams to be alerted. After that, manual procedures
take over to handle what the automated systems are indicating by the
very existence of a DK Trade message that they cannot manage.So I recommend no automated response to a DK Trade message. From
experience, support teams on both sides get together and manually
patch the data on both sides when agreement is reached as to what
should be done. Typically, no further FIX messages flow. DK Trade
messages are merely something produced by automated systems to
highlight a problem to the support teams on both sides of a FIX
session.I hope this helps.
JohnP
I think this is more of what’s the business practice in this kind of
situation type question. The protocol itself doesn’t prevent you
from doing what you described if the two parties agree to that type
of message flow, but it also begs the question of whether once a
DKTrade is receive should that be an end state or not.In this post I meant ExecTransType=CORRECT (not Replace)
The Don’t Know Trade message is used to reject an unknown order
or an unknown or invalid execution. The DK Trade is always sent
in response to an Execution Report. For FIX versions before FIX
5.0, assuming the previously listed assertions are valid,What is an appropriate response to the DK Trade message that
rejects an Execution Report reporting a fill or partial fill
(assuming that the reject of the fill is valid from a business
perspective)?Would it be appropriate for the DK Trade recipient to send an
Execution Report with ExecTransType=CANCEL to cancel the
previous report or would it be more appropriate to send an
ExecTransType=REPLACE to replace the rejected fill.Has anyone implemented something like this in practice?
[ original email was from Natan Kugel - Natan.Kugel@charter.net ]
Just to make sure we are on the same page, one of original statements “The Don’t Know Trade message is used to reject an unknown order or an unknown or invalid execution.” needs clarification. Please note that ‘Do Not Know Trades’ (DK Trades) are designed to reject execution reports. For rejecting orders, there is Order reject. Reasons for DK trades may vary: from overfill to incorrect order id referred. Intention is to allow the buy side (or execution report recipient) to reject execution reports back to the origin. This in turn serves as an indication at the point of the origin that there is mismatch in the order book and recipient of execution report did not process it. I recommend caution in handling DK trades. Depending on execution & order status reflected in execution reports, severity will vary. DK Trade for an acknowledgement may serve as an early warning for ‘fills’ that may follow. If noticed early, may prevent a larger problem. A ‘fill’, rejected by DK Trade, means a real issue with mismatch in cumulative quantity for an instrument.
Sincerely,
Natan
I couldn’t resist adding some color to this thread: As new products are
introduced on our platform there is often a time lag before our
customers’ automated systems are ready to handle the new ERs. We allow
them to send us DKs for committed trades they aren’t yet prepared to
process as a way to purge them from their systems. In this case no
system action is required on either side, and the DK has no effect on
trade state.John,
I’m in agreement with you which is why I said that this is more of a
business/best practices question. In all implementations I’ve dealt
with, a DKTrade is an end state and the problem is resolved off line.Hi Lisa & Jim,
From what I have witnessed, receipt of a DK Trade message typically
indicates some type of serious system problem. Why is the trade
being rejected? It’s not normal business practice to be permitted to
refuse a trade unless there is some type of functional error
involved.As such, automating a response to some type of system error can
often merely add to the confusion.The automated sending of a DK Trade should also cause internal
support teams to be alerted. Receiving a DK Trade should similarly
cause internal support teams to be alerted. After that, manual
procedures take over to handle what the automated systems are
indicating by the very existence of a DK Trade message that they
cannot manage.So I recommend no automated response to a DK Trade message. From
experience, support teams on both sides get together and manually
patch the data on both sides when agreement is reached as to what
should be done. Typically, no further FIX messages flow. DK Trade
messages are merely something produced by automated systems to
highlight a problem to the support teams on both sides of a FIX
session.I hope this helps.
JohnP
I think this is more of what’s the business practice in this kind
of situation type question. The protocol itself doesn’t prevent
you from doing what you described if the two parties agree to that
type of message flow, but it also begs the question of whether
once a DKTrade is receive should that be an end state or not.In this post I meant ExecTransType=CORRECT (not Replace)
The Don’t Know Trade message is used to reject an unknown
order or an unknown or invalid execution. The DK Trade is
always sent in response to an Execution Report. For FIX
versions before FIX
5., assuming the previously listed assertions are valid,What is an appropriate response to the DK Trade message that
rejects an Execution Report reporting a fill or partial fill
(assuming that the reject of the fill is valid from a business
perspective)?Would it be appropriate for the DK Trade recipient to send an
Execution Report with ExecTransType=CANCEL to cancel the
previous report or would it be more appropriate to send an
ExecTransType=REPLACE to replace the rejected fill.Has anyone implemented something like this in practice?