[This message was posted by Namrata Palicha of Santander Investments <[email protected]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/60512f1f - PLEASE DO NOT REPLY BY MAIL.]
Hi Thanks for the feedback. Mohamed your input to use custom tags as agreed with the 3rd party will help us to track the final ClOrdID that was create by the 3rd party before routing to the exchange. In most cases as i understand we will always have to do a automatic cancel of the order - for this we will always refer to our ClOrdID so there will be no need of knowing the ClOrdID that the 3rd party submitted to the exchange. Hanno - thanks for providing more info that it is quite likely that the 3rd party may combine several orders before they submit it to the exchange. So in that case knowing the ClOrdID that was sent to the exchange is going to be of no use. > On your first question about order identification: If your third party > indeed issues its own ClOrdIDs when communication with the exchange, > they should use SecondaryClOrdID to communicate these to you. You can > then use this field in the OrderCancelRequest to identify the order at > the exchange. Question is why you really need to know them if you do not > interact directly with the exchange. > > You say "we do not know what was the final ClOrdID created when the > order reached the exchange". Just to be clear, the exchange does not > create ClOrdID when the order arrives, it will create OrderID. Your > third party might create their own ClOrdID/OrderID values. > > Why can't the third party simply route your orders through and send you > the responses? If they aggregate orders from multiple clients like you > and then send just a single order to the exchange, you do not have a 1:1 > relationship between your transactions and those going to/coming from > the exchange. Then you only have your own ClOrdID and the OrderID issued > by the third party. Why should you need exchange IDs if you do not > communicate directly? Your third party has to map your IDs to the ones > he has created towards the exchange. > > Regards, Hanno. > > > Hi > > > > We are looking to offer DMA connectivity to our clients. We are in the > > process of analysing the requirements - from IT point of view and > > trying to outline our project task. based on some initial analysis i > > am listing the details. I will appreciate if anyone with DMA > > implementation experience can provide some suggestions as they have > > experienced during their implementation. > > > > 1.We will have seperate FIX session for DMA order flow from client. > > 2. We will route the order to the exchange directly - or through a > > third party in case we cannot route the order directly to the > > exchange. > > 3. All message routed to exchange/3rd party - will be recorded in our > > OMS for monitoring purpose only. In case of an event where the > > client connection is down - and orders need to be cancelled on the > > exchange we will have the capability to cancel open orders from the > > OMS to the exchange. > > 4. We will also receive FIX drop copies of executions and may be the > > order messages, so we can book the trades into our Middle office > > system > > > > Questions > > 5. In the situation where we need to manually cancel the open orders > > in the exchange - will it be sufficient to only have the > > information of OrderID - since if we are not directly routing the > > order to the exchange, then we do not know what was the final > > ClOrdID created when the order reached the exchange. Has anyone > > encountered this situation. How have you managed to get the > > information on the final ClOrdID that the exchange knows - in what > > situation will this be required. > > > > 6. If you do not have a direct FIX session with the exchange - how do > > you track that the order that you routed has actually reached the > > exchange. - I am thinking that we have the option where we can set > > the time limit on which we need to receive an Ack back on the DMA > > order - will this be sufficient. If we do not receive the ack in an > > acceptable time range - then we may decide to issue cancel on those > > orders. What is the norm in this situation > > > > 7.Has anyone seen the need to provide FIX drop copies to DMA clients > > along with the real time executions? > > > > 8. Does any client request an end of day replay of all FIX messages ? > > > > 9. How did you test exchange connectivity while the project was > > ongoing > > - without actually testing with the exchang. Is there any open > > source for an exchange simulator. > > > > Any other suggestion are appreciated. > > > > Regards [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 -~----------~----~----~----~------~----~------~--~---
