Hi All,
If the MassActionReportID (1369) is generated in a non-deterministic manner by the application, the MassActionReportID generated for a possible resend of a previous mass cancel report may always include a new MassActionReportID. However, the clients may rely on the ClOrdID (11) to identify and link these mass cancel reports given that we always echo the ClOrdID (11) that was present in the original mass cancel request even when with the PossResend flag (in cases where the application doesn’t support unsolicited mass cancels).
-
Is it acceptable, from FIX point of view, for the MassActionReportID (or any other field) to be different from the original when resending a mass cancel report with the PossResend flag?
-
If the answer to above is ‘No’, are there any FIX exemptions that may allow such a variation from the FIX standard? For e.g. since client can alternatively use ClOrdID instead of MassActionReportID when processing PossResends.
Thanks,
Hiran
The FIX Spec (see Volume 2 up to FIX 4.4 and FIXT as of FIX 5.0) is fairly clear on this:
Ambiguous application level messages may be resent with the PossResend flag set. This is useful when an order remains unacknowledged for an inordinate length of time and the end-user suspects it had never been sent. The receiving application must recognize this flag and interrogate internal fields (order number, etc.) to determine if this order has been previously received. Note: The possible resend message will contain exactly the same body data but will have the PossResend flag and will have a new sequence number. In addition the CheckSum field will require recalculation and fields related to encryption (SecureDataLen and SecureData) may also require recasting.
However, the Rules of Engagement should always point to the fields in the application body that allow to determine whether the message content was sent before. I would see it as permissible (even though not 100% compliant) to also point out that MassActionReportID cannot be used as it is a different ID for technical reasons. The MsgSeqNum should be the only ID that changes when resending but I guess your architecture has to rebuild the report and hence issues a new MassActionReportID. Note that ClOrdID may not be sufficient if you send more than one report for a given request (I assume you do not). In general, the MassActionReport message supports fragmentation as the list of (un)affected orders may be very long. You cannot use this feature if you need your users to rely on ClOrdID alone.
1 Like