FIX Trading Community

 

 Remember me

Register  |   Lost password?

FIX Semantics

Discussions > FIX Semantics > More on FillsGrp in execution reports

More on FillsGrp in execution reports

Complete message thread from old site

FIX Trading Community
16 March 2010 7:14pm

[ original email was from John Prewett - jprewett@lavatrading.com ]
An exchange is sending us an ExecutionReport with what I perceive to be a strange set of fields. I would appreciate clarification as to whether their usage is correct or incorrect.

The relevant fields in the only fill are as follows:
ExecType Trade
OrderQty 6000
CumQty 6000
OrdStatus Filled
LeavesQty 0
LastPx 148.25
LastQty 5703
NoFills 2
FillExecID 1234
FillPx 148.25
FillQty 297
FillExecID 5678
FillPx 148.25
FillQty 5703

Why isn't LastQty=6000?
I would have thought that LastQty should equal the sum of all the associated FillQty values. Or should I basically ignore LastQty when the FillsGrp component exists and just process the FillsGrp instead.

What should be in LastPx?
I would have thought it should be the average price of all the embedded partials. Or should I basically ignore LastPx when the FillsGrp component exists and process the FillsGrp instead?

More fundamentally, where can I read about valid usage of the FillsGrp component block? I scoured the 5.0SP1 & 5.0SP2 specifications without any success.

Thanks

JohnP

Hanno Klein
17 March 2010 7:52am

John,

thank you for raising this point. I am happy to see that multiple fills within a single execution report are being used. Main drivers were

a) the desire to reduce the overall number of messages required to convey fills
b) the need to allow the alignment of the transaction model of the exchange with FIX, i.e. an exchange conducting multiple fills in a single transaction should not communicate intermediate order states and remaining quantities that never exist from the viewpoint of the matching engine (the order might already be completely matched but you get a partial fill first and decide to delete the remainder which will fail)

You are right that the exact behaviour between LastPx/LastQty and FillsGrp has not been documented/prescribed, i.e. is left to bilateral agreement. However, the RoE of the exchange should clearly state their choice.

When this extension for FIX 5.0 SP1 was discussed, you interpretation was not one of the variations considered. LastPx and LastQty should always refer to a single fill as they always did. We did not want to change the semantics. We realized that LastPx and LastQty were actually redundant when using the FillsGrp. However, these are required fields for ExecType=Trade and we wanted to change as little as possible.

The variations relate to whether the last fill is in LastPx/LastQty as well as in the FillsGrp or not. In your case it is and you are right in that you can basically ignore LastPx/LastQty unless your algorithm uses the last fill and needs this information as quickly as possible. It saves you from going through the list of fills until you reach the last one.

Others might choose to omit the last fill from the FillsGrp to reduce message length. I think the slight redundancy of having the last fill twice is worth the reduction in processing complexity.

At the time, there was no requirement to provide the total qty and average price of just the fills in this one ExecutionReport. CumQty and AvgPx refer to the entire order and were deemed sufficient. If it had been a requirement, I guess we would have added two fields, e.g. FillsCumQty and FillsAvgPx, outside of FillsGrp.

Regards,
Hanno.

> An exchange is sending us an ExecutionReport with what I perceive to be
> a strange set of fields. I would appreciate clarification as to whether
> their usage is correct or incorrect.
>
> The relevant fields in the only fill are as follows: ExecType Trade
> OrderQty 6000 CumQty 6000 OrdStatus Filled LeavesQty 0 LastPx 148.25
> LastQty 5703 NoFills 2 FillExecID 1234 FillPx 148.25 FillQty 297
> FillExecID 5678 FillPx 148.25 FillQty 5703
>
> Why isn't LastQty=6000? I would have thought that LastQty should equal
> the sum of all the associated FillQty values. Or should I basically
> ignore LastQty when the FillsGrp component exists and just process the
> FillsGrp instead.
>
> What should be in LastPx? I would have thought it should be the average
> price of all the embedded partials. Or should I basically ignore LastPx
> when the FillsGrp component exists and process the FillsGrp instead?
>
> More fundamentally, where can I read about valid usage of the FillsGrp
> component block? I scoured the 5.0SP1 & 5.0SP2 specifications without
> any success.
>
> Thanks
>
> JohnP