Imported from previous forum
[ original email was from Mikael Brannstrom - mikael.brannstrom@ngm.se ]
How is a canceled trade conveyed in a MarketDataSnapshotFullRefresh? (except from simply being absent in the list).
For example if I have two trades with MDEntryIDs “1” and “2” and then cancel trade “1” with MDIncr with MDUpdateAction=delete. In a MDSnapshot msg, how can I say that there are two trades, “1” and “2” where the first one is canceled.
/Mikael
Mikael,
are you suggesting to send out all trades of the day everytime you send a snapshot? Not sure I understand the question.
Snapshots typically convey the book plus last sale and possibly statistics and trading status information, but not a list of trades.
Regards,
Hanno.
How is a canceled trade conveyed in a MarketDataSnapshotFullRefresh? (except from simply being absent in the list).
For example if I have two trades with MDEntryIDs “1” and “2” and then cancel trade “1” with MDIncr with MDUpdateAction=delete. In a MDSnapshot msg, how can I say that there are two trades, “1” and “2” where the first one is canceled.
/Mikael
[ original email was from Mikael Brannstrom - mikael.brannstrom@ngm.se ]
In the normal case market data vendors are informed about trades with the MarketDataIncrementalRefresh, where MDEntryType=2 (trade), MDEntryID=trade id, etc. MDUpdateAction tells if its a new, modification or delete.
We need to be able to send a snapshot of the trades, for example if a mdv have been offline for e.g. an hour and quickly want to get online. In that case retransmission of every message would take too long time. Currently we send a MarketDataSnapshotFullRefresh with entries for each trade that is not canceled, with MDEntryType=2 (trade) etc, in the same way as in the incremental case (except for the MDUpdateAction). The scope (time) of the trades can be limited in the request.
The thing is that some mdv:s would like to have an explicit indication of that a trade has been canceled, except from the fact that it is not present in the list of md entries in the MDSnapshot message. Trades are of special interest in contrast to orders; all trades (incl canceled) are needed while only the active orders are needed.
Regards,
Mikael
Mikael,
are you suggesting to send out all trades of the day everytime you send a snapshot? Not sure I understand the question.
Snapshots typically convey the book plus last sale and possibly statistics and trading status information, but not a list of trades.
Regards,
Hanno.How is a canceled trade conveyed in a MarketDataSnapshotFullRefresh? (except from simply being absent in the list).
For example if I have two trades with MDEntryIDs “1” and “2” and then cancel trade “1” with MDIncr with MDUpdateAction=delete. In a MDSnapshot msg, how can I say that there are two trades, “1” and “2” where the first one is canceled.
/Mikael
Hi Mikael,
Could you include the cancelled trades in the initial MarketDataSnapshotFullRefresh and then send a MarketDataIncrementalRefresh with all the cancelled trades?
Typically there aren’t that many cancelled trades in a given trading day so it shouldn’t be prohibitive.
Barring that (i.e. you absolutely must include both the trade and the cancel in the MarketDataSnapshotFullRefresh) then I would recommend you get agreement with the MDV’s for optionally including MDUpdateAction in the MarketDataSnapshotFullRefresh’s MDEntries repeating group. Have the trade MDEntry immediately followed by the cancel MDEntry.
Cheers,
Dennis
In the normal case market data vendors are informed about trades with the MarketDataIncrementalRefresh, where MDEntryType=2 (trade), MDEntryID=trade id, etc. MDUpdateAction tells if its a new, modification or delete.
We need to be able to send a snapshot of the trades, for example if a mdv have been offline for e.g. an hour and quickly want to get online. In that case retransmission of every message would take too long time. Currently we send a MarketDataSnapshotFullRefresh with entries for each trade that is not canceled, with MDEntryType=2 (trade) etc, in the same way as in the incremental case (except for the MDUpdateAction). The scope (time) of the trades can be limited in the request.
The thing is that some mdv:s would like to have an explicit indication of that a trade has been canceled, except from the fact that it is not present in the list of md entries in the MDSnapshot message. Trades are of special interest in contrast to orders; all trades (incl canceled) are needed while only the active orders are needed.
Regards,
MikaelMikael,
are you suggesting to send out all trades of the day everytime you send a snapshot? Not sure I understand the question.
Snapshots typically convey the book plus last sale and possibly statistics and trading status information, but not a list of trades.
Regards,
Hanno.How is a canceled trade conveyed in a MarketDataSnapshotFullRefresh? (except from simply being absent in the list).
For example if I have two trades with MDEntryIDs “1” and “2” and then cancel trade “1” with MDIncr with MDUpdateAction=delete. In a MDSnapshot msg, how can I say that there are two trades, “1” and “2” where the first one is canceled.
/Mikael
[ original email was from Mikael Brannstrom - mikael.brannstrom@ngm.se ]
Hi Dennis,
Your snapshot + incremental delete solution is clearly appealing, since no adaptation is required on the client side. However, I’m a little worried about the “transient effects” that this could cause at the client side.
I’ve been looking at the various TradeCondition values, and 0=Cancel seems to satisfy my requirements.
The field is present in both the snapshot and incremental md entries, but I guess the cancel value is only used in the snapshot case - it is overkill to use both TradeCondition=0 (cancel) and MDUpdateAction=delete in a incremental update.
Have you (or anyone else) used the numerous “Cancel …” values of TradeCondition? What are they used for?
Regards,
Mikael
Hi Mikael,
Could you include the cancelled trades in the initial MarketDataSnapshotFullRefresh and then send a MarketDataIncrementalRefresh with all the cancelled trades?
Typically there aren’t that many cancelled trades in a given trading day so it shouldn’t be prohibitive.
Barring that (i.e. you absolutely must include both the trade and the cancel in the MarketDataSnapshotFullRefresh) then I would recommend you get agreement with the MDV’s for optionally including MDUpdateAction in the MarketDataSnapshotFullRefresh’s MDEntries repeating group. Have the trade MDEntry immediately followed by the cancel MDEntry.
Cheers,
Dennis
In the normal case market data vendors are informed about trades with the MarketDataIncrementalRefresh, where MDEntryType=2 (trade), MDEntryID=trade id, etc. MDUpdateAction tells if its a new, modification or delete.
We need to be able to send a snapshot of the trades, for example if a mdv have been offline for e.g. an hour and quickly want to get online. In that case retransmission of every message would take too long time. Currently we send a MarketDataSnapshotFullRefresh with entries for each trade that is not canceled, with MDEntryType=2 (trade) etc, in the same way as in the incremental case (except for the MDUpdateAction). The scope (time) of the trades can be limited in the request.
The thing is that some mdv:s would like to have an explicit indication of that a trade has been canceled, except from the fact that it is not present in the list of md entries in the MDSnapshot message. Trades are of special interest in contrast to orders; all trades (incl canceled) are needed while only the active orders are needed.
Regards,
MikaelMikael,
are you suggesting to send out all trades of the day everytime you send a snapshot? Not sure I understand the question.
Snapshots typically convey the book plus last sale and possibly statistics and trading status information, but not a list of trades.
Regards,
Hanno.How is a canceled trade conveyed in a MarketDataSnapshotFullRefresh? (except from simply being absent in the list).
For example if I have two trades with MDEntryIDs “1” and “2” and then cancel trade “1” with MDIncr with MDUpdateAction=delete. In a MDSnapshot msg, how can I say that there are two trades, “1” and “2” where the first one is canceled.
/Mikael
Dennis,
MDUpdateAction is a key field and drives the semantics of a message. The snapshot message intentionally does not have such a field and you would change its semantics. As soon as you do this, my view is that you have created a user-defined message and need to change MsgType to “U…” whereby it could be “UW” to indicate that you have based it upon the standard MsgType “W” (snapshot).
FIX provides a lot of flexibility but my view is that you cross a boundary for this when you change the intended semantics/concepts of the message. Adding tag 84 CxlQty to the OrderCancel is another example of this. The FIX concept is to use OrderCancel whenever the order is to be removed in its entirety and to use OrderCancelReplace when you want to change only bits and pieces of the order. A single field such as CxlQty would allow you to circumvent the intended semantics of the OrderCancel message. Using MsgType = “U…” clearly marks such messages as being outside of the agreed standard and should be the only legitimate approach for such cases.
I admit there are reasons when this is warranted, mostly due to legacy systems that have not been built with FIX concepts in mind. Mapping the legacy concepts to the FIX concepts can lead to a major implementation on the gateway leading to a significant cost increase and performance decrease. As new systems are built, this should be less and less the case (unless FIX is ignored as the key provider of standard concepts for pre-trade and trade).
Regards,
Hanno.
Hi Mikael,
Could you include the cancelled trades in the initial MarketDataSnapshotFullRefresh and then send a MarketDataIncrementalRefresh with all the cancelled trades?
Typically there aren’t that many cancelled trades in a given trading day so it shouldn’t be prohibitive.
Barring that (i.e. you absolutely must include both the trade and the cancel in the MarketDataSnapshotFullRefresh) then I would recommend you get agreement with the MDV’s for optionally including MDUpdateAction in the MarketDataSnapshotFullRefresh’s MDEntries repeating group. Have the trade MDEntry immediately followed by the cancel MDEntry.
Cheers,
Dennis
In the normal case market data vendors are informed about trades with the MarketDataIncrementalRefresh, where MDEntryType=2 (trade), MDEntryID=trade id, etc. MDUpdateAction tells if its a new, modification or delete.
We need to be able to send a snapshot of the trades, for example if a mdv have been offline for e.g. an hour and quickly want to get online. In that case retransmission of every message would take too long time. Currently we send a MarketDataSnapshotFullRefresh with entries for each trade that is not canceled, with MDEntryType=2 (trade) etc, in the same way as in the incremental case (except for the MDUpdateAction). The scope (time) of the trades can be limited in the request.
The thing is that some mdv:s would like to have an explicit indication of that a trade has been canceled, except from the fact that it is not present in the list of md entries in the MDSnapshot message. Trades are of special interest in contrast to orders; all trades (incl canceled) are needed while only the active orders are needed.
Regards,
MikaelMikael,
are you suggesting to send out all trades of the day everytime you send a snapshot? Not sure I understand the question.
Snapshots typically convey the book plus last sale and possibly statistics and trading status information, but not a list of trades.
Regards,
Hanno.How is a canceled trade conveyed in a MarketDataSnapshotFullRefresh? (except from simply being absent in the list).
For example if I have two trades with MDEntryIDs “1” and “2” and then cancel trade “1” with MDIncr with MDUpdateAction=delete. In a MDSnapshot msg, how can I say that there are two trades, “1” and “2” where the first one is canceled.
/Mikael
Hello Mikael, Hello Hanno,
Admittedly I am straying into a usage of this message which is not how we ourselves use it.
Hanno, I only accept that this is how Mikael and his partners are using/considering using the message and thought to contribute a suggestion as to how their challenge could be resolved.
Mikael, I agree with Hanno that this is perhaps best as a user defined message. Further, I agree re: “transient effect” concerns. This is why I suggested somehow including the trade and the trade cancel both as separate entries in the full refresh.
It sounds as though you are trying to facilitate downstream parties doing detailed market modelling using market data and trades. If this is the case could you compliment Market Data messages with the use of Trade Capture Reports? (Just another thought.)
Good luck!
Dennis
Dennis,
MDUpdateAction is a key field and drives the semantics of a message. The snapshot message intentionally does not have such a field and you would change its semantics. As soon as you do this, my view is that you have created a user-defined message and need to change MsgType to “U…” whereby it could be “UW” to indicate that you have based it upon the standard MsgType “W” (snapshot).
FIX provides a lot of flexibility but my view is that you cross a boundary for this when you change the intended semantics/concepts of the message. Adding tag 84 CxlQty to the OrderCancel is another example of this. The FIX concept is to use OrderCancel whenever the order is to be removed in its entirety and to use OrderCancelReplace when you want to change only bits and pieces of the order. A single field such as CxlQty would allow you to circumvent the intended semantics of the OrderCancel message. Using MsgType = “U…” clearly marks such messages as being outside of the agreed standard and should be the only legitimate approach for such cases.
I admit there are reasons when this is warranted, mostly due to legacy systems that have not been built with FIX concepts in mind. Mapping the legacy concepts to the FIX concepts can lead to a major implementation on the gateway leading to a significant cost increase and performance decrease. As new systems are built, this should be less and less the case (unless FIX is ignored as the key provider of standard concepts for pre-trade and trade).
Regards,
Hanno.Hi Mikael,
Could you include the cancelled trades in the initial MarketDataSnapshotFullRefresh and then send a MarketDataIncrementalRefresh with all the cancelled trades?
Typically there aren’t that many cancelled trades in a given trading day so it shouldn’t be prohibitive.
Barring that (i.e. you absolutely must include both the trade and the cancel in the MarketDataSnapshotFullRefresh) then I would recommend you get agreement with the MDV’s for optionally including MDUpdateAction in the MarketDataSnapshotFullRefresh’s MDEntries repeating group. Have the trade MDEntry immediately followed by the cancel MDEntry.
Cheers,
Dennis
In the normal case market data vendors are informed about trades with the MarketDataIncrementalRefresh, where MDEntryType=2 (trade), MDEntryID=trade id, etc. MDUpdateAction tells if its a new, modification or delete.
We need to be able to send a snapshot of the trades, for example if a mdv have been offline for e.g. an hour and quickly want to get online. In that case retransmission of every message would take too long time. Currently we send a MarketDataSnapshotFullRefresh with entries for each trade that is not canceled, with MDEntryType=2 (trade) etc, in the same way as in the incremental case (except for the MDUpdateAction). The scope (time) of the trades can be limited in the request.
The thing is that some mdv:s would like to have an explicit indication of that a trade has been canceled, except from the fact that it is not present in the list of md entries in the MDSnapshot message. Trades are of special interest in contrast to orders; all trades (incl canceled) are needed while only the active orders are needed.
Regards,
MikaelMikael,
are you suggesting to send out all trades of the day everytime you send a snapshot? Not sure I understand the question.
Snapshots typically convey the book plus last sale and possibly statistics and trading status information, but not a list of trades.
Regards,
Hanno.How is a canceled trade conveyed in a MarketDataSnapshotFullRefresh? (except from simply being absent in the list).
For example if I have two trades with MDEntryIDs “1” and “2” and then cancel trade “1” with MDIncr with MDUpdateAction=delete. In a MDSnapshot msg, how can I say that there are two trades, “1” and “2” where the first one is canceled.
/Mikael
Mikael,
Is your feed a multicast feed? If you use the Market Data Snapshot message to send missed trades to a late joiner, will you be able to fit all of the trades within the request window into a single snapshot message?
Why don’t you send individual Market Data Incremental Refresh messages for each trade? Is the usage of a Market Data Snapshot message going to significantly reduce the transmission time?
In the normal case market data vendors are informed about trades with the MarketDataIncrementalRefresh, where MDEntryType=2 (trade), MDEntryID=trade id, etc. MDUpdateAction tells if its a new, modification or delete.
We need to be able to send a snapshot of the trades, for example if a mdv have been offline for e.g. an hour and quickly want to get online. In that case retransmission of every message would take too long time. Currently we send a MarketDataSnapshotFullRefresh with entries for each trade that is not canceled, with MDEntryType=2 (trade) etc, in the same way as in the incremental case (except for the MDUpdateAction). The scope (time) of the trades can be limited in the request.
The thing is that some mdv:s would like to have an explicit indication of that a trade has been canceled, except from the fact that it is not present in the list of md entries in the MDSnapshot message. Trades are of special interest in contrast to orders; all trades (incl canceled) are needed while only the active orders are needed.
Regards,
MikaelMikael,
are you suggesting to send out all trades of the day everytime you send a snapshot? Not sure I understand the question.
Snapshots typically convey the book plus last sale and possibly statistics and trading status information, but not a list of trades.
Regards,
Hanno.How is a canceled trade conveyed in a MarketDataSnapshotFullRefresh? (except from simply being absent in the list).
For example if I have two trades with MDEntryIDs “1” and “2” and then cancel trade “1” with MDIncr with MDUpdateAction=delete. In a MDSnapshot msg, how can I say that there are two trades, “1” and “2” where the first one is canceled.
/Mikael
[ original email was from Mikael Brannstrom - mikael.brannstrom@ngm.se ]
Thank you all for your comments,
We (NGM) will use TradeCondition=0 (cancel) to convey canceled orders in snapshots.
Regarding large snapshot messages, we do fragment these into smaller ones, so fitting all trades in a snapshot is not an issue. BTW, you can have the same problem in Market Data Incremental Refresh when a single transaction results in “lots” of trades and order updates.
Best Regards,
Mikael
Mikael,
Is your feed a multicast feed? If you use the Market Data Snapshot message to send missed trades to a late joiner, will you be able to fit all of the trades within the request window into a single snapshot message?
Why don’t you send individual Market Data Incremental Refresh messages for each trade? Is the usage of a Market Data Snapshot message going to significantly reduce the transmission time?
In the normal case market data vendors are informed about trades with the MarketDataIncrementalRefresh, where MDEntryType=2 (trade), MDEntryID=trade id, etc. MDUpdateAction tells if its a new, modification or delete.
We need to be able to send a snapshot of the trades, for example if a mdv have been offline for e.g. an hour and quickly want to get online. In that case retransmission of every message would take too long time. Currently we send a MarketDataSnapshotFullRefresh with entries for each trade that is not canceled, with MDEntryType=2 (trade) etc, in the same way as in the incremental case (except for the MDUpdateAction). The scope (time) of the trades can be limited in the request.
The thing is that some mdv:s would like to have an explicit indication of that a trade has been canceled, except from the fact that it is not present in the list of md entries in the MDSnapshot message. Trades are of special interest in contrast to orders; all trades (incl canceled) are needed while only the active orders are needed.
Regards,
MikaelMikael,
are you suggesting to send out all trades of the day everytime you send a snapshot? Not sure I understand the question.
Snapshots typically convey the book plus last sale and possibly statistics and trading status information, but not a list of trades.
Regards,
Hanno.How is a canceled trade conveyed in a MarketDataSnapshotFullRefresh? (except from simply being absent in the list).
For example if I have two trades with MDEntryIDs “1” and “2” and then cancel trade “1” with MDIncr with MDUpdateAction=delete. In a MDSnapshot msg, how can I say that there are two trades, “1” and “2” where the first one is canceled.
/Mikael