Usage of MDEntries in Depth maintenance

, ,
1

Imported from previous forum

2

Hi,

I’m in the process of developing a market data gateway. When implementing the depth (restricted to several rows in a book Market By Order) I have a concern in the following scenario.

  • Actual book is beyond the viewable depth (say depth shown out side is 5 and there are 10 entries)
  • An entry is deleted from the viewable depth (say the 3rd order is canceled)
  • The gateway should send the deletion update for the 3rd row
  • Then an update should be sent to lift up the entry which was at the 6th position as an add to the client’s book (to maintain the depth)

My concern is:

  • Do we pack two MDEntries (add and delete) within the same Incremental Refresh (NoMDEntries = 2)as this scenario can be considered as a single transaction?
  • OR do we send separate Incremental Refresh for delete and add of entries (NoMDEntries = 1 in each)?

Please provide the best way of implementing the above scenario (according to the FAST standards)

Thanks a lot.
Sajith

3

The incremental instructions within a single MDIncGrp should not be applied in parallel but sequentially, i.e. you only need to make sure that the deletion of row 3 comes first, followed by the add for row 5. Row 5 is empty after the first instruction, i.e. it is not an update.
As a side note, when best prices shift it is important that you send the instruction first that widens the spread to avoid the possibility of a crossed book in between instructions of the same MDIncGrp, even though a user should not take any trading action prior to having processed all instructions of one MDIncGrp (but you cannot rule it out).
Regards,
Hanno.

Hi,

I’m in the process of developing a market data gateway. When implementing the depth (restricted to several rows in a book Market By Order) I have a concern in the following scenario.

  • Actual book is beyond the viewable depth (say depth shown out side is 5 and there are 10 entries)
  • An entry is deleted from the viewable depth (say the 3rd order is canceled)
  • The gateway should send the deletion update for the 3rd row
  • Then an update should be sent to lift up the entry which was at the 6th position as an add to the client’s book (to maintain the depth)

My concern is:

  • Do we pack two MDEntries (add and delete) within the same Incremental Refresh (NoMDEntries = 2)as this scenario can be considered as a single transaction?
  • OR do we send separate Incremental Refresh for delete and add of entries (NoMDEntries = 1 in each)?

Please provide the best way of implementing the above scenario (according to the FAST standards)

Thanks a lot.
Sajith

4

[ original email was from John Harris - john.harris@bondmart.com ]
I have a question on this topic for High Frequency Trading Working Group purposes, if not of more general applicability…

If I understand this question correctly, the market data gateway is trying to keep track of order book state. That strikes me as the wrong approach.

I would prefer that the market data gateway help me, as client, construct my own notion of order book state, and otherwise get out of the way. If it sends me Side, Instrument, Price, Quantity, and some form of guaranteed-to-be-incrementing identifier, I can construct and maintain my own notion of the order book. Because of the incrementing identifier, I will know that lower numbers represent older orders - thus it is easy for me to rank orders first by price and then by age. As orders expire, fill, or are cancelled, the gateway just needs to tell me that, referencing the same identifier.

If the gateway plays the order-book-construction game, too, then we have three versions of reality instead of two:

  1. The real state of the order book;
  2. What the market data gateway thinks is the state of the order book; and,
  3. What my app thinks is the state of the order book.

Why not get rid of the middleman, so to speak?

Sorry if I am missing something…

Best,
John

The incremental instructions within a single MDIncGrp should not be applied in parallel but sequentially, i.e. you only need to make sure that the deletion of row 3 comes first, followed by the add for row 5. Row 5 is empty after the first instruction, i.e. it is not an update.
As a side note, when best prices shift it is important that you send the instruction first that widens the spread to avoid the possibility of a crossed book in between instructions of the same MDIncGrp, even though a user should not take any trading action prior to having processed all instructions of one MDIncGrp (but you cannot rule it out).
Regards,
Hanno.

Hi,

I’m in the process of developing a market data gateway. When implementing the depth (restricted to several rows in a book Market By Order) I have a concern in the following scenario.

  • Actual book is beyond the viewable depth (say depth shown out side is 5 and there are 10 entries)
  • An entry is deleted from the viewable depth (say the 3rd order is canceled)
  • The gateway should send the deletion update for the 3rd row
  • Then an update should be sent to lift up the entry which was at the 6th position as an add to the client’s book (to maintain the depth)

My concern is:

  • Do we pack two MDEntries (add and delete) within the same Incremental Refresh (NoMDEntries = 2)as this scenario can be considered as a single transaction?
  • OR do we send separate Incremental Refresh for delete and add of entries (NoMDEntries = 1 in each)?

Please provide the best way of implementing the above scenario (according to the FAST standards)

Thanks a lot.
Sajith

5

I might have misunderstood the question as I assumed an aggregated book and was referring to price levels. With individual orders, I just send them out and let the recipient figure out the book (order priority given by their relative position in the data stream), possibly using cloaking mechanisms to reduce the probability of identifying reserve orders, hidden orders etc.

I have a question on this topic for High Frequency Trading Working Group purposes, if not of more general applicability…

If I understand this question correctly, the market data gateway is trying to keep track of order book state. That strikes me as the wrong approach.

I would prefer that the market data gateway help me, as client, construct my own notion of order book state, and otherwise get out of the way. If it sends me Side, Instrument, Price, Quantity, and some form of guaranteed-to-be-incrementing identifier, I can construct and maintain my own notion of the order book. Because of the incrementing identifier, I will know that lower numbers represent older orders - thus it is easy for me to rank orders first by price and then by age. As orders expire, fill, or are cancelled, the gateway just needs to tell me that, referencing the same identifier.

If the gateway plays the order-book-construction game, too, then we have three versions of reality instead of two:

  1. The real state of the order book;
  2. What the market data gateway thinks is the state of the order book; and,
  3. What my app thinks is the state of the order book.

Why not get rid of the middleman, so to speak?

Sorry if I am missing something…

Best,
John

The incremental instructions within a single MDIncGrp should not be applied in parallel but sequentially, i.e. you only need to make sure that the deletion of row 3 comes first, followed by the add for row 5. Row 5 is empty after the first instruction, i.e. it is not an update.
As a side note, when best prices shift it is important that you send the instruction first that widens the spread to avoid the possibility of a crossed book in between instructions of the same MDIncGrp, even though a user should not take any trading action prior to having processed all instructions of one MDIncGrp (but you cannot rule it out).
Regards,
Hanno.

Hi,

I’m in the process of developing a market data gateway. When implementing the depth (restricted to several rows in a book Market By Order) I have a concern in the following scenario.

  • Actual book is beyond the viewable depth (say depth shown out side is 5 and there are 10 entries)
  • An entry is deleted from the viewable depth (say the 3rd order is canceled)
  • The gateway should send the deletion update for the 3rd row
  • Then an update should be sent to lift up the entry which was at the 6th position as an add to the client’s book (to maintain the depth)

My concern is:

  • Do we pack two MDEntries (add and delete) within the same Incremental Refresh (NoMDEntries = 2)as this scenario can be considered as a single transaction?
  • OR do we send separate Incremental Refresh for delete and add of entries (NoMDEntries = 1 in each)?

Please provide the best way of implementing the above scenario (according to the FAST standards)

Thanks a lot.
Sajith

6

Thanks a lot Hanno for your feedback!
And John, it’s nice having your ideas here and I think the document “Recommended Practices for Book Management(2.00)” will answer some of your concerns. That’s a very good guide on handling stuff in the FAST standard. I’m not sure whether this document is there for reference now (Someone please put a link here).

Hanno, regarding your best prices approach, I think there is a separate implementation for the Top of Book in the above document to prevent such intermediate problems.

I’d like more ideas/concerns on best practices of depth handling if anyone of you is interested discussing here.

Thanks a lot again!
Sajith

I have a question on this topic for High Frequency Trading Working Group purposes, if not of more general applicability…

If I understand this question correctly, the market data gateway is trying to keep track of order book state. That strikes me as the wrong approach.

I would prefer that the market data gateway help me, as client, construct my own notion of order book state, and otherwise get out of the way. If it sends me Side, Instrument, Price, Quantity, and some form of guaranteed-to-be-incrementing identifier, I can construct and maintain my own notion of the order book. Because of the incrementing identifier, I will know that lower numbers represent older orders - thus it is easy for me to rank orders first by price and then by age. As orders expire, fill, or are cancelled, the gateway just needs to tell me that, referencing the same identifier.

If the gateway plays the order-book-construction game, too, then we have three versions of reality instead of two:

  1. The real state of the order book;
  2. What the market data gateway thinks is the state of the order book; and,
  3. What my app thinks is the state of the order book.

Why not get rid of the middleman, so to speak?

Sorry if I am missing something…

Best,
John

The incremental instructions within a single MDIncGrp should not be applied in parallel but sequentially, i.e. you only need to make sure that the deletion of row 3 comes first, followed by the add for row 5. Row 5 is empty after the first instruction, i.e. it is not an update.
As a side note, when best prices shift it is important that you send the instruction first that widens the spread to avoid the possibility of a crossed book in between instructions of the same MDIncGrp, even though a user should not take any trading action prior to having processed all instructions of one MDIncGrp (but you cannot rule it out).
Regards,
Hanno.

Hi,

I’m in the process of developing a market data gateway. When implementing the depth (restricted to several rows in a book Market By Order) I have a concern in the following scenario.

  • Actual book is beyond the viewable depth (say depth shown out side is 5 and there are 10 entries)
  • An entry is deleted from the viewable depth (say the 3rd order is canceled)
  • The gateway should send the deletion update for the 3rd row
  • Then an update should be sent to lift up the entry which was at the 6th position as an add to the client’s book (to maintain the depth)

My concern is:

  • Do we pack two MDEntries (add and delete) within the same Incremental Refresh (NoMDEntries = 2)as this scenario can be considered as a single transaction?
  • OR do we send separate Incremental Refresh for delete and add of entries (NoMDEntries = 1 in each)?

Please provide the best way of implementing the above scenario (according to the FAST standards)

Thanks a lot.
Sajith

7

[ original email was from John Harris - john.harris@bondmart.com ]
Thank you, Sajith and Hanno.

I found version 1 of the Best Practices document, here:
http://www.fixprotocol.org/documents/4419/MDOWG_Book_Mgt_Final_draft.doc

If someone would be kind enough to post a link to version 2, I would be pleased to read it.

Thank you.

Best,
John

Thanks a lot Hanno for your feedback!
And John, it’s nice having your ideas here and I think the document “Recommended Practices for Book Management(2.00)” will answer some of your concerns. That’s a very good guide on handling stuff in the FAST standard. I’m not sure whether this document is there for reference now (Someone please put a link here).

Hanno, regarding your best prices approach, I think there is a separate implementation for the Top of Book in the above document to prevent such intermediate problems.

I’d like more ideas/concerns on best practices of depth handling if anyone of you is interested discussing here.

Thanks a lot again!
Sajith

I have a question on this topic for High Frequency Trading Working Group purposes, if not of more general applicability…

If I understand this question correctly, the market data gateway is trying to keep track of order book state. That strikes me as the wrong approach.

I would prefer that the market data gateway help me, as client, construct my own notion of order book state, and otherwise get out of the way. If it sends me Side, Instrument, Price, Quantity, and some form of guaranteed-to-be-incrementing identifier, I can construct and maintain my own notion of the order book. Because of the incrementing identifier, I will know that lower numbers represent older orders - thus it is easy for me to rank orders first by price and then by age. As orders expire, fill, or are cancelled, the gateway just needs to tell me that, referencing the same identifier.

If the gateway plays the order-book-construction game, too, then we have three versions of reality instead of two:

  1. The real state of the order book;
  2. What the market data gateway thinks is the state of the order book; and,
  3. What my app thinks is the state of the order book.

Why not get rid of the middleman, so to speak?

Sorry if I am missing something…

Best,
John

The incremental instructions within a single MDIncGrp should not be applied in parallel but sequentially, i.e. you only need to make sure that the deletion of row 3 comes first, followed by the add for row 5. Row 5 is empty after the first instruction, i.e. it is not an update.
As a side note, when best prices shift it is important that you send the instruction first that widens the spread to avoid the possibility of a crossed book in between instructions of the same MDIncGrp, even though a user should not take any trading action prior to having processed all instructions of one MDIncGrp (but you cannot rule it out).
Regards,
Hanno.

Hi,

I’m in the process of developing a market data gateway. When implementing the depth (restricted to several rows in a book Market By Order) I have a concern in the following scenario.

  • Actual book is beyond the viewable depth (say depth shown out side is 5 and there are 10 entries)
  • An entry is deleted from the viewable depth (say the 3rd order is canceled)
  • The gateway should send the deletion update for the 3rd row
  • Then an update should be sent to lift up the entry which was at the 6th position as an add to the client’s book (to maintain the depth)

My concern is:

  • Do we pack two MDEntries (add and delete) within the same Incremental Refresh (NoMDEntries = 2)as this scenario can be considered as a single transaction?
  • OR do we send separate Incremental Refresh for delete and add of entries (NoMDEntries = 1 in each)?

Please provide the best way of implementing the above scenario (according to the FAST standards)

Thanks a lot.
Sajith