Order Cancel Replace - ClOrdID and OrigClOrdID

, ,
1

Imported from previous forum

2

[ original email was from Dean S. Bourloukas - dbourloukas@montgomery.com ]
I have a question about the use of ClOrdID (11)
and OrigClOrdID (41).

Here is the scenario:

  1. I send a "New Order - Single"
    ClOrdID=12345-1

  2. I Receive execution acknowledgement.

  3. I send a "Order Cancel Replace"
    OrigClOrdID=12345-1
    ClOrdID=12345-2

  4. I Receive an Order Cancel Reject.

  5. I send an "Order Cancel Replace/Request"
    OrigClOrdI=12345-1
    ClOrdID=12345-2

Is it legal to reuse ClOrdID 12345-2 since
the first attempt to use it was rejected?
Or must the ClOrdID be unique no matter what?

Thanks in Advance

Dean S. Bourloukas
NationsBanc Montgomery Securities
dbourloukas@montgomery.com

3

[ original email was from John Armstrong - johna@ms.com ]
The ClOrdID must be unique no matter what.
You are correct, though, on the OrigClOrdID
of the second Cancel/Replace request.

> I have a question about the use of ClOrdID (11)
> and OrigClOrdID (41).
>
> Here is the scenario:
>
> 1. I send a "New Order - Single"
> ClOrdID=12345-1
>
> 2. I Receive execution acknowledgement.
>
> 3. I send a "Order Cancel Replace"
> OrigClOrdID=12345-1
> ClOrdID=12345-2
>
> 4. I Receive an Order Cancel Reject.
>
> 5. I send an "Order Cancel Replace/Request"
> OrigClOrdI=12345-1
> ClOrdID=12345-2
>
> Is it legal to reuse ClOrdID 12345-2 since
> the first attempt to use it was rejected?
> Or must the ClOrdID be unique no matter what?
>
>
>
> Thanks in Advance
>
> Dean S. Bourloukas
> NationsBanc Montgomery Securities
> dbourloukas@montgomery.com
>
>
>

4

[ original email was from Koji Kubota - koji.kubota@gs.com ]
This was one of the topics in Japan Tech Working
Group. Our conclusion is that the following.
Does everyone have the same understanding
in US and UK? We are trying to set this
sequence as a "recommendation" in Japan.

If a modification request is rejected,a
subsequent modification request should still use
the original ID for OrigClOrdID. However, in the
subsequent modification (the second
modification), ClOrdID should be a new unique
value. Therefore, the first modification
and the second modification use different
values for ClOrdID, no matter what.

Example:

  1. "New Order Single" with
    ClOrdID=001

  2. Acknowledgment ("Execution Report") received

  3. "Order Cancel Request" with
    OrigClOrdID=001
    ClOrdID=002

  4. "Order Cancel Reject" received

  5. "Order Cancel/Correct Request" with
    OrigClOrdID=001
    ClOrdID=003

> The ClOrdID must be unique no matter what.
> You are correct, though, on the OrigClOrdID
> of the second Cancel/Replace request.
>

5

[ original email was from Mark Hinman - mhinman@easetech.com ]
Every "new order single", order cancel/replace request and order cancel request must have a unique ClOrdID. The ClOrdID in cancel/replace and cancel are proposed changes to the new order including a new ClOrdID. If the change is rejected, so is the ClOrdID, and therefore it cannot be reused.

Good luck

> This was one of the topics in Japan Tech Working
> Group. Our conclusion is that the following.
> Does everyone have the same understanding
> in US and UK? We are trying to set this
> sequence as a "recommendation" in Japan.
>
> If a modification request is rejected,a
> subsequent modification request should still use
> the original ID for OrigClOrdID. However, in the
> subsequent modification (the second
> modification), ClOrdID should be a new unique
> value. Therefore, the first modification
> and the second modification use different
> values for ClOrdID, no matter what.
>
> Example:
>
> 1) "New Order Single" with
> ClOrdID=001
>
> 2) Acknowledgment ("Execution Report") received
>
> 3) "Order Cancel Request" with
> OrigClOrdID=001
> ClOrdID=002
>
> 4) "Order Cancel Reject" received
>
> 5) "Order Cancel/Correct Request" with
> OrigClOrdID=001
> ClOrdID=003
>
> > The ClOrdID must be unique no matter what.
> > You are correct, though, on the OrigClOrdID
> > of the second Cancel/Replace request.
> >
>
>