Queuing ExecutionReports when client is not connected

, ,
1

Imported from previous forum

2

Hello,

does the standard say anything about how to handle ExecutionReports when the client is not connected?

I see several way how this can be handled:

  1. Queuing all updates with a sequence number, client has to initiate a resend request after login.

  2. Queuing these updates without a sequence number and send the updates immediatly after login of a client.

  3. Don’t queue anything, but provide a facility to request the last fills and the current order states.

Is there a defined or prefered way how this scenarios can be handled?

Thanks

Oliver

3

[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> does the standard say anything about how to handle ExecutionReports when the client is not connected?
>
> I see several way how this can be handled:
>
> 1. Queuing all updates with a sequence number, client has to initiate a resend request after login.
>
> 2. Queuing these updates without a sequence number and send the updates immediatly after login of a client.

Both of these methods are employed by firms using FIX. I don’t believe the spec makes a statement either way about which is better. Note that with the #2 approach, it is best to make sure the client is in sync before potentially bombing the client with hundreds out of messages the client believes are out of sequence, resulting in hundreds of Resend Requests in response.

> 3. Don’t queue anything, but provide a facility to request the last fills and the current order states.

This has significant business implications, and I doubt it would be effective for most firms. There’s no way in FIX to request replays of execution reports at an application level. (At a session level, one can do a Resend Request, but in this example you’re not assigning them sequence numbers.) The Order Status Request provides the client with the current state, cumulative quantity, and average price for an order, but often a firm is going to require individual execution reports for each partial fill.

> Is there a defined or prefered way how this scenarios can be handled?

I believe both #1 and #2 work.