Imported from previous forum
The notes for the CashOrderQty field tag 152 states:
Specifies the approximate "dollar quantity" for the order. Broker is responsible for converting and calculating OrderQty in shares for subsequent messages.
Shouldn’t it be expressed in the currency of the order? Something like:
Specifies the approximate "monetary quantity" for the order given in the currency of the order. Broker is responsible for converting and calculating OrderQty in shares for subsequent messages.
/Michel
Yes. I’ve changed the description from “dollar quantity” to “monetary quantity” for the next draft. Thanks.
> The notes for the CashOrderQty field tag 152 states:
>
> Specifies the approximate “dollar quantity” for the order. Broker is responsible for converting and calculating OrderQty in shares for subsequent messages.
>
> Shouldn’t it be expressed in the currency of the order? Something like:
>
> Specifies the approximate “monetary quantity” for the order given in the currency of the order. Broker is responsible for converting and calculating OrderQty in shares for subsequent messages.
>
>
> /Michel
>
[ original email was from Roseate L. Wagner - roseate@exchange.ml.com ]
Hi,
The 4.2 spec for tag152-CashOrderQty indicates
’Broker is responsible for converting and calculating OrderQty in shares for subsequent messages.’
Does that imply that the orderqty shall only be converted at the beginning of the trading of the order? Or can the broker re-adjust the ordertqy base on the market price through the course of the order, esp for a GT cash base orders?
Thanks,
Roseate
[ original email was from John Prewett - jprewett@lavatrading.com ]
> Hi, The 4.2 spec for tag152-CashOrderQty indicates 'Broker is
responsible for converting and calculating OrderQty in shares for
subsequent messages.’Does that imply that the orderqty shall only be converted at the
beginning of the trading of the order? Or can the broker re-adjust the
ordertqy base on the market price through the course of the order, esp
for a GT cash base orders?Thanks, Roseate
Hi Roseate,
I like this question.
CashOrderQty must somehow be treated similar to a limit order. The order submitter has indicated that he/she is willing to accept a quantity of shares that is purchased for an amount that is less than or equal to the CashOrderQty but would be within his/her rights to refuse a quantity of shares that was purchased for more than CashOrderQty.
So if the sell-side is submitting a buy order to an execution venue, it should be done with a calculated OrderQty and a (Limit)Price based upon current market data information such that (OrderQty * Price <= CashOrderQty). You could even choose how aggressively to interpret the order when calculating the Price and OrderQty. The Price you use doesn’t necessarily have to be the Ask price. A more aggressive calculation could give better execution quality (lower purchase price and higher number of shares) while running the risk of not being filled.
Bear in mind that the customer may submit the order with a limit price. If the calculated price from market data is greater than the submitted limit price on the order, the submitted limit price must be used. Again, the formula must still be (OrderQty * Price <= CashOrderQty). If the submitted limit price is used because it is less than the current calculated price from market data, you may not get any fills at all unless the price dips. Perhaps this is how the buy-side indicates how aggressive the order should be.
So staying within the terms specified by the order submitter is clearly manageable and is of the primary importance.
The next issue is how often (or whether) you re-calculate the OrderQty based upon a moving price of the stock. If you never recalculate based upon shifting market data for volatile stock, the only thing you risk is a slightly unhappy customer. Nevertheless you have still stayed inside the parameters he/she specified. Going the extra mile is where we all add value, so the more often you recalculate for a volatile stock, the closer you will be to the CashOrderQty and the happier your customer will be. Insufficient recalculations and adjustments of the order will result in the cash equivalent of an underfill. If it resulted in a big enough underfill, you could even regard this as a partial fill and try for some more.
Please bear in mind that everything I mentioned above is using a buy order as an example. For a sell order, the user is still indicating a limit: I want to sell $1,000,000 worth of shares. You shouldn’t sell more than the amount the user is requesting, but you could sell less than that (or am I wrong? You should maybe try and sell as near as possible to $1,000,000 but it must be at least $1,000,000?).
Lastly, I wouldn’t like to handle this order type if it was submitted with all-or-none instructions…
I hope this rambling post helps.
JohnP
[ original email was from Roseate L. Wagner - roseate@exchange.ml.com ]
John,
Thanks for the nice response.
In case of re-calculate the orderqty due to the market movement base on CashOrderQty, which will result changing of tag38(orderqty) of the order as well as the subsequent leaveQty of the order, does the fix protocal support such change for an order? - considering tag38 as one of the basic order attribute of an order, I’m concerned if the change if this value value will break the chain of msg.
Is there any common practice for such scenario?
Thanks,
Roseate
Hi, The 4.2 spec for tag152-CashOrderQty indicates ‘Broker is
responsible for converting and calculating OrderQty in shares for
subsequent messages.’Does that imply that the orderqty shall only be converted at the
beginning of the trading of the order? Or can the broker re-adjust the
ordertqy base on the market price through the course of the order, esp
for a GT cash base orders?Thanks, Roseate
Hi Roseate,
I like this question.
CashOrderQty must somehow be treated similar to a limit order. The order
submitter has indicated that he/she is willing to accept a quantity of
shares that is purchased for an amount that is less than or equal to the
CashOrderQty but would be within his/her rights to refuse a quantity of
shares that was purchased for more than CashOrderQty.So if the sell-side is submitting a buy order to an execution venue, it
should be done with a calculated OrderQty and a (Limit)Price based upon
current market data information such that (OrderQty * Price <=
CashOrderQty). You could even choose how aggressively to interpret the
order when calculating the Price and OrderQty. The Price you use doesn’t
necessarily have to be the Ask price. A more aggressive calculation
could give better execution quality (lower purchase price and higher
number of shares) while running the risk of not being filled.Bear in mind that the customer may submit the order with a limit price.
If the calculated price from market data is greater than the submitted
limit price on the order, the submitted limit price must be used. Again,
the formula must still be (OrderQty * Price <= CashOrderQty). If the
submitted limit price is used because it is less than the current
calculated price from market data, you may not get any fills at all
unless the price dips. Perhaps this is how the buy-side indicates how
aggressive the order should be.So staying within the terms specified by the order submitter is clearly
manageable and is of the primary importance.The next issue is how often (or whether) you re-calculate the OrderQty
based upon a moving price of the stock. If you never recalculate based
upon shifting market data for volatile stock, the only thing you risk is
a slightly unhappy customer. Nevertheless you have still stayed inside
the parameters he/she specified. Going the extra mile is where we all
add value, so the more often you recalculate for a volatile stock, the
closer you will be to the CashOrderQty and the happier your customer
will be. Insufficient recalculations and adjustments of the order will
result in the cash equivalent of an underfill. If it resulted in a big
enough underfill, you could even regard this as a partial fill and try
for some more.Please bear in mind that everything I mentioned above is using a buy
order as an example. For a sell order, the user is still indicating a
limit: I want to sell $1,000,000 worth of shares. You shouldn’t sell
more than the amount the user is requesting, but you could sell less
than that (or am I wrong? You should maybe try and sell as near as
possible to $1,000,000 but it must be at least $1,000,000?).Lastly, I wouldn’t like to handle this order type if it was submitted
with all-or-none instructions…I hope this rambling post helps.
JohnP
[ original email was from John Prewett - jprewett@lavatrading.com ]
Hi Roseate,
Changing OrderQty and LeavesQty (as a result of changing OrderQty) on successive ExecReports doesn’t appear to break FIX protocol as far as I can see. Whether it will break the buy-side OMS that receives these ExecReports is another matter.
To avoid as many complications as possible with the buy-side OMS you could only calculate OrderQty one time when the NewOrderSingle is first received and thereafter keep it constant. Yet this could then exceed the CashOrderQty limitation were the price of the stock to rise during the life of the buy order!
You can’t win here.
In my humble opinion, if the buy-side wants clean predictable behavior, all they have to do is send you OrderQty. If they really, really want to use CashOrderQty (which seems somewhat bleeding edge to me) they had better be prepared to bleed a little.
My best advice is: Certification testing had better be extensive…
JohnP
John,
Thanks for the nice response.
In case of re-calculate the orderqty due to the market movement base on
CashOrderQty, which will result changing of tag38(orderqty) of the order
as well as the subsequent leaveQty of the order, does the fix protocal
support such change for an order? - considering tag38 as one of the
basic order attribute of an order, I’m concerned if the change if this
value value will break the chain of msg.Is there any common practice for such scenario?
Thanks, Roseate