Imported from previous forum
[ original email was from Vivien Lee - vivien.wm.lee@ing-barings.com ]
I have a scenario as below:
A FIX order with ClOrdID = X and Price = 10, then Client send Replace with
ClOrdID = Y and Price = 11. A Replaced execution with ClOrdID, OrigClOrdID
(y,x) was sent to client to confirm the change. Now an execution comes back
from exchange for the previous order that I sent with Price = 10. How am I
suppose to report this to client? Since ClOrdID = x no longer exist as it
was changed to y. But Y order price is 11, not 10. Do we use X or Y to
report his partial filled of Px 10?
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> A FIX order with ClOrdID = X and Price = 10, then Client send Replace with
> ClOrdID = Y and Price = 11. A Replaced execution with ClOrdID, OrigClOrdID
> (y,x) was sent to client to confirm the change. Now an execution comes back
> from exchange for the previous order that I sent with Price = 10. How am I
> suppose to report this to client? Since ClOrdID = x no longer exist as it
> was changed to y. But Y order price is 11, not 10. Do we use X or Y to
> report his partial filled of Px 10?
There are two messages sent in response to a successful change.
The firxt, Pending Cancel/Replace, indicates that you’ve received a change and are attempting to act on it, but you cannot guarantee the results. At this point, trades are still sent to the client using the old (X) ClOrdID.
The second, Replaced, indicates that the change has been successful. Now, trades are sent with the new (Y) ClOrdID.
Assuming the order in question is to sell, if you tell your customer that he’s successfully raised his selling price from 10 to 11, he’s going to be upset (and rightfully so) if he gets a trade at 10. I’m guessing one of four things caused this:
#1. You sent Replaced without hearing back from the Exchange that the order was, indeed, successfully replaced.
#2. The Exchange reported the order as replaced, and later proceeded to report a fill to you.
#3. There was some form of out-of-order message flow (i.e. parallel pipes from the exchange to you) causing you to process the Replaced message prior to processing the trade.
#4. There was an outage between you and the exchange, and during recovery you processed the replaced message before the trade message.
In case #1, this would be an error on your part. You cannot report to the client that an order is replaced if the old order is still live at an exchange without opening yourself up to a lot of risk. If the exchange, like FIX, sends the equivalent of a "Pending" and a "Replaced" message, make sure the "Replaced" message from the exchange triggers a FIX "Replaced" message to your client.
In case #2, this is the exchange’s fault. I would suggest reporting the trade with ClOrdID=Y and sending an exception report to a human operator. You’re likely going to get a call from the customer on this, and you should probably be on the phone to the exchange to determine how this mistake was made, and what they propose to remedy it.
Case #3 is complicated, and the solution depends a lot on the protocol you use to communicate with the exchange. CMS, which operates on parallel pipes, gets around this by requiring the customer to specify what they believe to be the open quantity on the order, and rejecting the cancel/replace if there’s a disagreement (i.e. a trade happened.) This has the disadvantage of effectively preventing changes to marketable orders in fast markets, but at least it prevents this kind of ambiguity. Now FIX wasn’t really designed to operate on parallel pipes, but if you’re running it this way, your application can note that the CumQty on the Replaced message is greater than what you expect, and delay processing the Replaced message until the trade comes through.
With case #4, I would hope that the exchange protocol you’re using, like FIX, has some form of sequencing and gap recovery. In that case, after an outage, it becomes important to Resend Request or otherwise have the exchange replay the missed messages, and for you to process the old messages before the new if you wish to avoid this kind of problem.
[ original email was from Vivien Lee - vivien.wm.lee@ing-barings.com ]
What if we didn’t send the original order (ClordID=X) to the exchange. Say the Qty is 100000 and we only sent 1000 to market with px=10.
Before we receive any fills from exchange, and we accepted the replace request. So the ClOrdID is now Y. Then fills comes back from Exchange with Px=10. If we report to client with Px=10 but ClOrdID=Y (since we modified the ClOrdID from X to Y), does it make sense.
The proper way to handle replace request is to cancel the placed order in the market, and then amend the order. But if the amendment is to increase the quantity. I don’t want to cancel the placed order in the market as I have the advantage that I’m in the first queue of the line. From the business prospective, I really don’t want to line-up again.
Any guideline on how we handle this?
Many thanks,
> > A FIX order with ClOrdID = X and Price = 10, then Client send Replace with
> > ClOrdID = Y and Price = 11. A Replaced execution with ClOrdID, OrigClOrdID
> > (y,x) was sent to client to confirm the change. Now an execution comes back
> > from exchange for the previous order that I sent with Price = 10. How am I
> > suppose to report this to client? Since ClOrdID = x no longer exist as it
> > was changed to y. But Y order price is 11, not 10. Do we use X or Y to
> > report his partial filled of Px 10?
>
> There are two messages sent in response to a successful change.
>
> The firxt, Pending Cancel/Replace, indicates that you’ve received a change and are attempting to act on it, but you cannot guarantee the results. At this point, trades are still sent to the client using the old (X) ClOrdID.
>
> The second, Replaced, indicates that the change has been successful. Now, trades are sent with the new (Y) ClOrdID.
>
> Assuming the order in question is to sell, if you tell your customer that he’s successfully raised his selling price from 10 to 11, he’s going to be upset (and rightfully so) if he gets a trade at 10. I’m guessing one of four things caused this:
>
> #1. You sent Replaced without hearing back from the Exchange that the order was, indeed, successfully replaced.
>
> #2. The Exchange reported the order as replaced, and later proceeded to report a fill to you.
>
> #3. There was some form of out-of-order message flow (i.e. parallel pipes from the exchange to you) causing you to process the Replaced message prior to processing the trade.
>
> #4. There was an outage between you and the exchange, and during recovery you processed the replaced message before the trade message.
>
> In case #1, this would be an error on your part. You cannot report to the client that an order is replaced if the old order is still live at an exchange without opening yourself up to a lot of risk. If the exchange, like FIX, sends the equivalent of a “Pending” and a “Replaced” message, make sure the “Replaced” message from the exchange triggers a FIX “Replaced” message to your client.
>
> In case #2, this is the exchange’s fault. I would suggest reporting the trade with ClOrdID=Y and sending an exception report to a human operator. You’re likely going to get a call from the customer on this, and you should probably be on the phone to the exchange to determine how this mistake was made, and what they propose to remedy it.
>
> Case #3 is complicated, and the solution depends a lot on the protocol you use to communicate with the exchange. CMS, which operates on parallel pipes, gets around this by requiring the customer to specify what they believe to be the open quantity on the order, and rejecting the cancel/replace if there’s a disagreement (i.e. a trade happened.) This has the disadvantage of effectively preventing changes to marketable orders in fast markets, but at least it prevents this kind of ambiguity. Now FIX wasn’t really designed to operate on parallel pipes, but if you’re running it this way, your application can note that the CumQty on the Replaced message is greater than what you expect, and delay processing the Replaced message until the trade comes through.
>
> With case #4, I would hope that the exchange protocol you’re using, like FIX, has some form of sequencing and gap recovery. In that case, after an outage, it becomes important to Resend Request or otherwise have the exchange replay the missed messages, and for you to process the old messages before the new if you wish to avoid this kind of problem.
>
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> What if we didn’t send the original order (ClordID=X) to the exchange. Say the Qty is 100000 and we only sent 1000 to market with px=10.
> Before we receive any fills from exchange, and we accepted the replace request. So the ClOrdID is now Y. Then fills comes back from Exchange with Px=10. If we report to client with Px=10 but ClOrdID=Y (since we modified the ClOrdID from X to Y), does it make sense.
>
> The proper way to handle replace request is to cancel the placed order in the market, and then amend the order. But if the amendment is to increase the quantity. I don’t want to cancel the placed order in the market as I have the advantage that I’m in the first queue of the line. From the business prospective, I really don’t want to line-up again.
In this case that you describe, you’re really managing the state between two loosely coupled streams of order flow: between you and the customer, and between you and the exchange.
From a FIX standpoint, once you accept the change (OrdStatus=Replaced), then ClOrdID must be Y. From a business standpoint, any fills from this point forward must be compatible with the type of order that Y represents.
I would think that you could base your decision on when to accept the change based on whether the change is "dangerous" or "safe."
For example:
Increasing limit price when buying or decreasing limit price when selling - safe.
Decreasing limit price when buying or increasing limit price when selling - dangerous.
Increasing order quantity - safe.
Decreasing order quantity - if new volume ?= the amount you have live in the market, safe. If new volume < volume you have live in the market, dangerous.
You might be able to immediately accept "safe" changes. If the customer increases order volume, you could immediately accept the change and submit an additional order for the difference to the exchange. If the customer increases the limit price when buying, you could immediately accept the change and then submit a cancel/replace to the exchange to increase the limit price.
For “dangerous” changes you would likely need to wait to ack them until the matter has been changed at the exchange, or you’re opening yourself up for potential liability. If the customer decreases a 100,000 open order to 50,000 but you have 70,000 live at the exchange, I’d suggest waiting before accepting the customer change, otherwise an immediate execution on 70,000 could leave your firm owning 20,000 shares, since you can’t really accept the change and then over-fill the customer. Now if you delay accepting the change, you can give the customer the full 70,000 shares and then accept the change, reporting the order as filled.
Likewise, if the customer is buying and raises the price from 10 to 11, you can accept it immediately. If a fill comes back at 10, then the customer has been price improved. But if you’re selling, accepting the change immediately could be a mistake. If you get filled at 10, you would probably end up having to eat a loss of 1 per share, since you can’t really tell a customer that his selling price has been raised successfully and then turn around and fill him with the old lower price.