Re: AvgPrice and CumQty
Mahesh Kumaraguru <>
25 Jun 2008 10:49PM ETAvgPrice and CumQty serve as a kind of checksum in the chain of executions.
When the nth partial execution is received, the buy side would calculate the cumilative quantity and average price based on execution quantities and execution prices from all previous executions including the last one.
If the cumilative quantity calculated does not match the cumilative quantity in the last exec report, flag error (show red in GUI, send email alerts). If the average price calculated and rounded differs from the average price in the last exec report by 0.0001 cents, flag error. (0.0001 is a small random decimal number just quoted here for example.)
These checksums would be lost if AvgPrice and CumQty are absent.
[start question]would it make sense to make these two fields non mandatory for exchanges? [end question]
Then would two FIX specs exist - one for exchanges and another for non-exchanges?
[start question]Would it make sense for fast paced systems to loosen this requirement? [end question]
Speed should be improved without loss of reliability ( reliability is a functional requirement).
[start question]How many have gone with a stop gap solution and provide value "Zero" (0)? Is this a norm? [end question]
This beats the purpose of the tags. Its better to remove the tags than send junk values.
To take another example,
In Order Cancel Request ^35=F^,
1. why is OrderQty a required field upto 4.2 (Either CashOrderQty or OrderQty is required.) or 4.3 upwards OrderQtyData component block is required?
2. Why is Symbol a required field upto 4.2 / Instrument component block 4.3 onwards?
As the party placing and order with ^35=D^55=MK^11=1^38=1000^, should I not be able to cancel it a ^35=F^41=1^, why do I have to state the quantity information and security identification in my cancel request? I tell broker, Whatever was my order with ClOrdID=1, just cancel it, don't waste my time by asking me quantity, ticker etc.
In the same logic I would ask "why is Tag 11 ClOrdID a required field in Order Cancel Request?" because after cancellation, there would be no order, so why do I have to assign an ID to an order which does not exist?
But FIX has these fields as mandatory because at the broker's end, the Order Cancel Request in verbose reads as
"Please cancel my Order with order id = 1 for security MK for quantity of 1000 and I would like to call this cancellation request 2"
Production FIX messages are not just two computers communicating, they are two organizations doing business with each other. Anything that improves speed at the cost of Reliability should be avoided. I believe there are ways to improve speed without loss of Reliability.
Regards,
K. Mahesh
> I would like to know if many exchanges provide support for both AvgPrice
> and CumQty in execution reports and would it make sense to make these
> two fields non mandatory for exchanges? Would it make sense for fast
> paced systems to loosen this requirement? How many have gone with a stop
> gap solution and provide value "Zero" (0)? Is this a norm? I thank you
> in advance. Natan
