[This message was posted by Hanno Klein of Deutsche Börse Systems <[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/4eeb2eba - PLEASE DO NOT REPLY BY MAIL.]
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 -~----------~----~----~----~------~----~------~--~---
