[This message was posted by John Harris of BondMart Technologies, Inc. <[email protected]> to the "FAST Protocol" discussion forum at http://fixprotocol.org/discuss/46. You can reply to it on-line at http://fixprotocol.org/discuss/read/cd1f5a5d - PLEASE DO NOT REPLY BY MAIL.]
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 > > > > [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
