We use “order update” messages from User Data streams to create blotters for the purpose of trade surveillance and risk management. (Here, “order update” messages are "e":"executionReport"
for spot and "e":"ORDER_TRADE_UPDATE"
for futures). We do not place orders; we are a third party that only monitors trading activity on behalf of our clients.
The documentation states that we should expect a server-side disconnection at least once every 24 hours, and we do see this commonly. Upon disconnection, our software will reconnect within one second. My question has to do with how to ensure data integrity across these disconnects. There seems to be no way to detect what messages might have been missed during the reconnection lag.
There are helpful suggestions on this forum to manage these disconnections by creating a redundant websocket connection and synchronizing the messages based on the “update ID” field. This sounds reasonable, but unless I’m mistaken there is no field in the order update messages that serves as an “update ID”, nor any kind of message sequence number. Did I overlook something in these messages? (Reference: Binance API Documentation).
Is there a field in the messages that we could reliably use as a message sequence number? If not, then how exactly are we supposed to maintain data integrity across the forced disconnections? What about the case where an infrastructure problem (for example) caused an extended disconnection? It would be nice if the websocket API offered true message sequence numbers that allowed for easy gap detection and also had a “replay” ability for back filling gaps – virtually all FIX feeds have these capabilities. Given that the websocket feeds don’t have these capabilities, and there doesn’t seem to be a field in the messages that serves as a sequence number, then what is the correct method to ensure that no data is lost during a forced disconnect/reconnect cycle?
Thanks for any insights.