AvgPrice and CumQty

, ,
1

Imported from previous forum

2

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

3

AvgPrice 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

4

Natan,

many (I would claim most) exchanges do not provide average price calculaton. It is a service mainly relevant for brokers when they work client orders. As of FIX 5.0 the AvgPx field is made optional in the Execution Report. There are various solutions used to signify that the average price is not calculated, zero is probably the most common one - although I would note that zero is a perfectly valid price in some cases (combinations / multilegs e.g.). I’ve also seen “999999” used.

I think Mahesh provided insightful information on why fields are required in FIX. Regarding the AvgPx, I would however say that it should be part of any pre-5.0 message as it is requeired by the standard - but that you clearly define that you are not calculating it and provide a defined “null” value.

CumQty remains required in later FIX-versions and should be specified as defined (LeavesQty = OrderQty - CumQty.).

Regards

Rikard

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