Order Change Matrix - Order of Messages

, ,
1

Imported from previous forum

2

[ original email was from Witold Sames - witold@javtech.com ]
We came accross the following scenario:

  1. Send order to sell side, like BUY 1000
    shares IBM at 100.

  2. Receive ExecRpt, OrdStatus = new, and
    ExecTransType = new. This is the ack,
    and ok this way.

  3. Send a cancel request for this order.

  4. Now, we receive an ExecRpt with
    OrdStatus = pending cancel, ExecTransType
    = new, LastShares = 0, LastPx = 0.0,
    CumQty = 100, AvgPx = 100.

  5. Following, ExecRpt with OrdStatus = Canceled,
    ExecTransType = new, other items the same
    as in 3).

  6. Finally, here comes a partial fill,
    OrdStatus - part fill, LastShares = 100,
    LastPx = 100, CumQty = 100, AvgPx = 100,
    ExecTransType = 0.

In our opinion, the first execution report in this scenario should already be rejected, since
there is a CumQty implied that we have no fill to account for. I would like to know what you think about this, if there’s better way to handle this maybe?

On the other hand, I think that receiving an execution report with a part fill AFTER receiving
the cancel pending but before the canceled is legal and is being practised.

Thank you.

Witold
witold@javtech.com

3

I don’t think #4 should show CumQty of 100 and have an AvgPx without having previously provided the fill for 100. If #4 had CumQty and AvgPx of 0, then #6 could come between #4 and #5. For #4 to have CumQty of 100, then #6 should have been sent before #4. Does the MsgSeqNum order match the order you’re describing (i.e. are they being received out of order but sent in order)?

> We came accross the following scenario:
>
> 1) Send order to sell side, like BUY 1000
> shares IBM at 100.
>
> 2) Receive ExecRpt, OrdStatus = new, and
> ExecTransType = new. This is the ack,
> and ok this way.
>
> 3) Send a cancel request for this order.
>
> 4) Now, we receive an ExecRpt with
> OrdStatus = pending cancel, ExecTransType
> = new, LastShares = 0, LastPx = 0.0,
> CumQty = 100, AvgPx = 100.
>
> 5) Following, ExecRpt with OrdStatus = Canceled,
> ExecTransType = new, other items the same
> as in 3).
>
> 6) Finally, here comes a partial fill,
> OrdStatus - part fill, LastShares = 100,
> LastPx = 100, CumQty = 100, AvgPx = 100,
> ExecTransType = 0.
>
> In our opinion, the first execution report in this scenario should already be rejected, since
> there is a CumQty implied that we have no fill to account for. I would like to know what you think about this, if there’s better way to handle this maybe?
>
> On the other hand, I think that receiving an execution report with a part fill AFTER receiving
> the cancel pending but before the canceled is legal and is being practised.
>
> Thank you.
>
> Witold
> witold@javtech.com
>

4

[ original email was from Witold Sames - witold@javtech.com ]
That’s the problem, sequence numbers are perfectly in order, it’s the system generating the application messages (or passing them through) that mixes up the order of messages.
Thank you for the clarification.

> I don’t think #4 should show CumQty of 100 and have an AvgPx without having previously provided the fill for 100. If #4 had CumQty and AvgPx of 0, then #6 could come between #4 and #5. For #4 to have CumQty of 100, then #6 should have been sent before #4. Does the MsgSeqNum order match the order you’re describing (i.e. are they being received out of order but sent in order)?
>
>
> > We came accross the following scenario:
> >
> > 1) Send order to sell side, like BUY 1000
> > shares IBM at 100.
> >
> > 2) Receive ExecRpt, OrdStatus = new, and
> > ExecTransType = new. This is the ack,
> > and ok this way.
> >
> > 3) Send a cancel request for this order.
> >
> > 4) Now, we receive an ExecRpt with
> > OrdStatus = pending cancel, ExecTransType
> > = new, LastShares = 0, LastPx = 0.0,
> > CumQty = 100, AvgPx = 100.
> >
> > 5) Following, ExecRpt with OrdStatus = Canceled,
> > ExecTransType = new, other items the same
> > as in 3).
> >
> > 6) Finally, here comes a partial fill,
> > OrdStatus - part fill, LastShares = 100,
> > LastPx = 100, CumQty = 100, AvgPx = 100,
> > ExecTransType = 0.
> >
> > In our opinion, the first execution report in this scenario should already be rejected, since
> > there is a CumQty implied that we have no fill to account for. I would like to know what you think about this, if there’s better way to handle this maybe?
> >
> > On the other hand, I think that receiving an execution report with a part fill AFTER receiving
> > the cancel pending but before the canceled is legal and is being practised.
> >
> > Thank you.
> >
> > Witold
> > witold@javtech.com
> >
>