Drop Copy Best Practices


#1

Are there any drop copy best practices to follow in terms of what type of messages and/or events that the drop copy should provide? Should the message types in drop copy scope be restricted to only those where CopyMsgIndicator (797) is present?
Currently the implementation is such that we copy all exec reports that denote an order add/delete/replace/fills. Is it common to copy rejects as well (e.g., Exec Report with OrdStatus = Reject, or 35=9 - Order Cancel Reject) though the concern is that such reject events may not entirely echo the originally submitted request contents?

Thanks in advance.


#2

Hi vasanthacharya,

I hope I understood you right: Probably the question would be what is required by the applications using your drop copy session and not how to disseminate any possible information by chance.

Is it
A.) a typical back office session which only cares about trade information (msgtype 35=AE) for settlement and middle office CCP purposes or
B.) is it really crucial for those (drop-copy) receiving application to update information about any order status change
1 right after it happened or
2 at start of or
3 end of
trading hours ?

2 and 3 could be achieved by receiving sell side initiated restatement messages (150=D) or by DoneForDay messages in a batch driven mode during a short pre- and post trade period I guess.

The effort to achieve 1 may be possible by making the following tags mandatory:
102 in 35=9
103 and 378 in 35=8
373 in 35=3 (technical/session rejects)

But also let’s keep in mind: As long as a (Cxl) Request was rejected the request had no influence on the order status and it has not changed. Even for an order that had become invalid (“too late” to Chg/Cxl) before the request was received and processed (due to message crossing).

Do your non-trading (=drop copy session) applications require updates on order status and even then:
If that was true do they really bother about rejects and the reasons and the request content ? This should be clarified in deatil beforehand I believe.

About Restatements and Drop Copies also refer to Hanno’s document about “Recommended Practices for the use of FIX by Exchanges Phase” from 2007 ready for download here in “https://www.fixtrading.org/recommended-practicesguidelines/”. Probably you are already aware of it.

Best wishes
Uli


#3

Thanks Uli,

The receiving side wishes to have a copy of everything that their trading session receives; not merely looking at drop copy from middle or back office perspective. Hence my question, should we be restrictive to what we currently send (as in my original post) or should we open up a bit and send even rejects?


#4

I would argue against rejects as these should be left to request/response workflows. Drop copies are basically broadcasts that allow a different (remote) session to take over trading at any time by maintaining an orderbook as a copy. As Uli says, rejects do not change anything and there is nothing to consider. Drop copy streams typically only contain ExecutionReport (ER) messages. Often, the ERs in the trading session do not echo information from the requests for performance reasons and only the drop copy (backup) session does.

The only use case I see is when you want to establish an audit trail of a session as a sort of “drop copy”. But that means that you also have to provide copies of the requests being made. Rejects make no sense without the corresponding requests. You have not said much about the business requirements you need to fulfill.