Imported from previous forum
I would like to have a cancel/reject qty or a new leaves quantity in the execution cancel/reject message.
Today when we interface with Selectnet, we seem to get messages from the SDP in any random order.
Today when an order is sent out to preference a market maker, and that market maker gives several partial fills, followed by a decline the remainder of the order, the messages received by the order entry firm can be received in any random order.
If the decline is received first, we like to forward that information to our customer when it is received. We do that today by sending and execution reject report. When the trades are eventually received, we send the executions. Since the execution reject does not have a field that reflects the number of shares rejected, it is often processed incorrectly by our customer. Our customer assumes that the entire order has been rejected.
[ original email was from John Armstrong - johna@ms.com ]
Currently there is no standard way to partially
reject an order in FIX. What some ECNs do in the
SelectNet partial-decline situtaion is send
an unsolicited "Replaced" execution report message with the OrderQty field reflecting the reduction in quantity. However, this is ambiguous because it is not clear from the message exactly
how many shares are being rejected by this message.
Furthermore, it can also be confused with a reply to an outstanding Cancel/Replace message.
In FIX4.1, a possible solution to standardize on
is the following Execution report message:
ExecType=Rejected;
OrderStatus=New(or PartiallyFilled)
OrderQty=<the original # shares>
LeavesQty=<current # of shares open>
CumQty=<total # of shares executed>
This should create no ambiguity as to exactly what is happening.
> I would like to have a cancel/reject qty or a new leaves quantity in the execution cancel/reject message.
>
> Today when we interface with Selectnet, we seem to get messages from the SDP in any random order.
> Today when an order is sent out to preference a market maker, and that market maker gives several partial fills, followed by a decline the remainder of the order, the messages received by the order entry firm can be received in any random order.
>
> If the decline is received first, we like to forward that information to our customer when it is received. We do that today by sending and execution reject report. When the trades are eventually received, we send the executions. Since the execution reject does not have a field that reflects the number of shares rejected, it is often processed incorrectly by our customer. Our customer assumes that the entire order has been rejected.
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
I think we can kill several birds with one stone.
The issue is that currently in a FIX connection, all changes to an order have to be initiated by the buy-side. If we define a way for the sell side to initiate a change to an order in an Execution message, we can accomplish several things:
-
With a partial reject of 400 shares on SelectNet, the sell-side can say, "Your 1000 share order is now really just a 600 share order."
-
A buy-side institution’s trader may be talking on the phone with the sell-side broker working the order the trader submitted via FIX. A new opportunity may present itself, and the trader may verbally request a change of the order. The broker can key in the change and execute the trade, and what comes back to the trader’s FIX system is first a message with the restated order, and second, the trade.
-
For GTC orders and corporate actions, the sell-side can make adjustments to the order, as stated in the rules of the appropriate exchange and based on whether the customer set DNR/DNI. Then an execution message could be sent which would tell the buy-side the parameters of the new order.
-
For GTC orders without corporate actions, the sell-side may want to give the buy-side as the first thing in the morning a complete list of all GTC orders still live even if they haven’t changed.
I’d suggest doing this by creating an ExecType of “Restated” along with an optional RestatementReason field with values including:
Nothing Changed
Corporate Action
Verbal Change
Partial Reject
On a 1000 share order that receives a SelectNet partial reject of 400 shares, prior to any of the trades arriving, the sell-side would send:
ExecTransType=New
ExecType=Restated
RestatementReason=Partial Cancel
OrdStatus=New
OrderQty=600
LastShares=LastPx=0
(Note - I’m only listing interesting fields; other fields are required/should be sent in an Execution message.)
For a 1000 share order that had 200 shares traded at 50 one day and then the stock split 2:1, one would send:
ExecTransType=New
ExecType=Restated
RestatementReason=Corporate Action
OrdStatus=Partially Filled
OrderQty=2000
CumQty=400
AvgPx=25.0
LeavesQty=1600
LastShares=LastPx=0
Thoughts?
I recognize that this is a somewhat sizeable change, so I don’t know if it is reasonable to include it at this point in FIX 4.2.
For my original request, the current message would would beautifly, and would not be dependant on the order they were received, if the reject and cancel only specified the number of shares. I would prefer not putting a new message in to satisfy my request.
Putting a new leaves quantity in will also mean that message sequencing is important. If we get to a situation where 2 or more partial cancels need to be sent, then if the come out of order, the order entry firm will also be in error.
We like to send messages to some clients over multiple fix connections. When this occurs, sometimes messages can be received out of order because of performance and processing on the redundant fix connections. Putting the number of shares on the reject or cancel removes the need to maintain the order of the messages transmitted.
It is more flexible than trying to reset an absolute new leaves quantity.
> I think we can kill several birds with one stone.
>
> The issue is that currently in a FIX connection, all changes to an order have to be initiated by the buy-side. If we define a way for the sell side to initiate a change to an order in an Execution message, we can accomplish several things:
>
> 1. With a partial reject of 400 shares on SelectNet, the sell-side can say, “Your 1000 share order is now really just a 600 share order.”
>
> 2. A buy-side institution’s trader may be talking on the phone with the sell-side broker working the order the trader submitted via FIX. A new opportunity may present itself, and the trader may verbally request a change of the order. The broker can key in the change and execute the trade, and what comes back to the trader’s FIX system is first a message with the restated order, and second, the trade.
>
> 3. For GTC orders and corporate actions, the sell-side can make adjustments to the order, as stated in the rules of the appropriate exchange and based on whether the customer set DNR/DNI. Then an execution message could be sent which would tell the buy-side the parameters of the new order.
>
> 4. For GTC orders without corporate actions, the sell-side may want to give the buy-side as the first thing in the morning a complete list of all GTC orders still live even if they haven’t changed.
>
> I’d suggest doing this by creating an ExecType of “Restated” along with an optional RestatementReason field with values including:
>
> Nothing Changed
> Corporate Action
> Verbal Change
> Partial Reject
>
> On a 1000 share order that receives a SelectNet partial reject of 400 shares, prior to any of the trades arriving, the sell-side would send:
>
> ExecTransType=New
> ExecType=Restated
> RestatementReason=Partial Cancel
> OrdStatus=New
> OrderQty=600
> LastShares=LastPx=0
>
> (Note - I’m only listing interesting fields; other fields are required/should be sent in an Execution message.)
>
> For a 1000 share order that had 200 shares traded at 50 one day and then the stock split 2:1, one would send:
>
> ExecTransType=New
> ExecType=Restated
> RestatementReason=Corporate Action
> OrdStatus=Partially Filled
> OrderQty=2000
> CumQty=400
> AvgPx=25.0
> LeavesQty=1600
> LastShares=LastPx=0
>
> Thoughts?
>
> I recognize that this is a somewhat sizeable change, so I don’t know if it is reasonable to include it at this point in FIX 4.2.
>
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> For my original request, the current message would would beautifly, and would not be dependant on the order they were received, if the reject and cancel only specified the number of shares. I would prefer not putting a new message in to satisfy my request.
>
> Putting a new leaves quantity in will also mean that message sequencing is important. If we get to a situation where 2 or more partial cancels need to be sent, then if the come out of order, the order entry firm will also be in error.
Adding a new ExecType to satisfy your request is not, in my view, too excessive when it solves several other important issues, such as GTC orders and corporate actions, and verbal changes to orders.
The order which the partial cancels / SelectNet declines are received by the sell-side does not matter. If a SelectNet order for 1000 shares arrives as:
Decline 500
Decline 300
Trade 200
It can be sent in FIX as two order restatements:
OrderQty=500
CumQty=0
LeavesQty=500
OrderQty=200
CumQty=0
LeavesQty=200
And then the trade.
Scrambling the order of the SelectNet messages still results in a valid set of FIX messages sent by the sell-side, so long as CumQty and LeavesQty are calculated by the sell-side’s state machine, not necessarily lifted from the out of order SelectNet messages.
> We like to send messages to some clients over multiple fix connections. When this occurs, sometimes messages can be received out of order because of performance and processing on the redundant fix connections. Putting the number of shares on the reject or cancel removes the need to maintain the order of the messages transmitted.
This, in my view, goes well outside the scope of the FIX specification. FIX goes to great pains to guarantee ordered message delivery, and the application message processing is designed around it. If you run multiple FIX connections and allow race conditions to occur between them, other fields will be wrong regardless, such as CumQty and LeavesQty.
Jim,
I am curious if you ever got a response, either from FIX or any other source, to this inquiry of your idea about the need for a "new leaves" quantity.
I have been working on documenting the various functional differences between CMS and FIX messaging for broker-to-exchange implementation to eventually replace CMS between member firms and the exchanges. This particular problem seems to be one of the most glaring differences, because CMS handles all order modifications ( including order quantity reduction on an order that is partially filled ) as an order cancel / replace rather than a modification of an existing order, with no attempt to carry over the executed quantity on the original order to the changed order. The difficulty seems to lie in having the receiving system interpret or "deduce" the "new leaves" quantity from interrogating all of the CMS execution messages received up to the point of receiving the execution reject message, and as you pointed out the execution messages may not come in sequentially or in chronological order, or in a timely manner to properly deduce the new leaves amount. I agreee it certainly would be preferable to have a "new leaves" quantity explicitly defined in the execution reject message…
Is it a fair assumtion that this has been the cause of trade errors at your firm since your customers interpreted the execution reject as a "done-for-the-day" only to discover they were executed on more shares than they first thought?
Please advise if you got any response to this issue.
Mark SPann at Charles Schwab & Co
> I would like to have a cancel/reject qty or a new leaves quantity in the execution cancel/reject message.
> Today when we interface with Selectnet, we seem to get messages from the SDP in any random order.
> Today when an order is sent out to preference a market maker, and that market maker gives several partial fills, followed by a decline the remainder of the order, the messages received by the order entry firm can be received in any random order.
>
> If the decline is received first, we like to forward that information to our customer when it is received. We do that today by sending and execution reject report. When the trades are eventually received, we send the executions. Since the execution reject does not have a field that reflects the number of shares rejected, it is often processed incorrectly by our customer. Our customer assumes that the entire order has been rejected.
>