Imported from previous forum
Hi,
Apologies if you already saw this in the ‘4.2 changes’ list.
Should tag 32 (LastShares) on an execution bust be zero, or the number of shares being busted?
I always thought the latter, but matrix D35 in the 4.2 spec says zero (step 7 - I would put 5000 in, spec says 0). Which is correct?
Thanks, Peter
[ original email was from John Prewett - jprewett@lavatrading.com ]
The current usage of LastShares/LastPx is that they both contain zero except on an actual trade (ExecType=Stopped is the only deviation to this rule).
The recipient of a bust is responsible for using the ExecRefID and doing a lookup into their execution history to determine the number of shares and price of what is actually being busted.
This is consistent with a correction where LastShares/LastPx contains the amended details of the fill that is being corrected and again it is up to the recipient to use ExecRefID to lookup the original LastShares/LastPx.
Consistent or not, I think it would be a very handy feature if the sender of a bust or correction was able to send the number of shares and price of the trade that is being busted/corrected. For systems that have no ability to do a lookup using ExecRefID, this would enable them to fully automate busts/corrections. For systems that already had the capability to lookup using ExecRefID and process a bust or correction, this would add the ability to verify what is being busted/corrected against the execution venue’s perception. This proposal would need to use additional fields to contain the original LastShares/LastPx. It would also be fully backwards compatible as older systems could simply ignore the newly added fields and continue with their current capabilities.
JohnP
> Hi,
> Apologies if you already saw this in the ‘4.2 changes’ list.
> Should tag 32 (LastShares) on an execution bust be zero, or the number of shares being busted?
> I always thought the latter, but matrix D35 in the 4.2 spec says zero (step 7 - I would put 5000 in, spec says 0). Which is correct?
> Thanks, Peter
>
>
[ original email was from Jim Northey - jnorthey@lasalletech.com ]
John,
Strongly agree with you on this point - we should be able to provide the number of shares and price for the correction/bust. This has been a problem for listed options market participants whose systems do not support looking up previous executions.
We should add this to the list of proposed changes for the next version of FIX. As you say using optional fields for this purpose will prevent breaking existing applications that are enabled to reference previous executions.
Jim
> The current usage of LastShares/LastPx is that they both contain zero except on an actual trade (ExecType=Stopped is the only deviation to this rule).
>
> The recipient of a bust is responsible for using the ExecRefID and doing a lookup into their execution history to determine the number of shares and price of what is actually being busted.
>
> This is consistent with a correction where LastShares/LastPx contains the amended details of the fill that is being corrected and again it is up to the recipient to use ExecRefID to lookup the original LastShares/LastPx.
>
> Consistent or not, I think it would be a very handy feature if the sender of a bust or correction was able to send the number of shares and price of the trade that is being busted/corrected. For systems that have no ability to do a lookup using ExecRefID, this would enable them to fully automate busts/corrections. For systems that already had the capability to lookup using ExecRefID and process a bust or correction, this would add the ability to verify what is being busted/corrected against the execution venue’s perception. This proposal would need to use additional fields to contain the original LastShares/LastPx. It would also be fully backwards compatible as older systems could simply ignore the newly added fields and continue with their current capabilities.
>
> JohnP
>
> > Hi,
> > Apologies if you already saw this in the ‘4.2 changes’ list.
> > Should tag 32 (LastShares) on an execution bust be zero, or the number of shares being busted?
> > I always thought the latter, but matrix D35 in the 4.2 spec says zero (step 7 - I would put 5000 in, spec says 0). Which is correct?
> > Thanks, Peter
> >
> >
>
[ original email was from Mikhail Jirnov - mikhail.jirnov@ubsw.com ]
Hello Jim, John,
Then for the sake of consistency people might ask for original order details in Cancel and Cancel/Replace messages (Price, OrderQty, TimeInForce etc). This would greatly simplify conversion to those exchange protocols that require original price in the order modification and/or cancel requests (like in Japan) and also change of quantity (not new total quantity like in FIX). Thus there’s some risk of protocol overblow.
> John,
>
> Strongly agree with you on this point - we should be able to provide the number of shares and price for the correction/bust. This has been a problem for listed options market participants whose systems do not support looking up previous executions.
>
> We should add this to the list of proposed changes for the next version of FIX. As you say using optional fields for this purpose will prevent breaking existing applications that are enabled to reference previous executions.
>
> Jim
>
> > The current usage of LastShares/LastPx is that they both contain zero except on an actual trade (ExecType=Stopped is the only deviation to this rule).
> >
> > The recipient of a bust is responsible for using the ExecRefID and doing a lookup into their execution history to determine the number of shares and price of what is actually being busted.
> >
> > This is consistent with a correction where LastShares/LastPx contains the amended details of the fill that is being corrected and again it is up to the recipient to use ExecRefID to lookup the original LastShares/LastPx.
> >
> > Consistent or not, I think it would be a very handy feature if the sender of a bust or correction was able to send the number of shares and price of the trade that is being busted/corrected. For systems that have no ability to do a lookup using ExecRefID, this would enable them to fully automate busts/corrections. For systems that already had the capability to lookup using ExecRefID and process a bust or correction, this would add the ability to verify what is being busted/corrected against the execution venue’s perception. This proposal would need to use additional fields to contain the original LastShares/LastPx. It would also be fully backwards compatible as older systems could simply ignore the newly added fields and continue with their current capabilities.
> >
> > JohnP
> >
> > > Hi,
> > > Apologies if you already saw this in the ‘4.2 changes’ list.
> > > Should tag 32 (LastShares) on an execution bust be zero, or the number of shares being busted?
> > > I always thought the latter, but matrix D35 in the 4.2 spec says zero (step 7 - I would put 5000 in, spec says 0). Which is correct?
> > > Thanks, Peter
> > >
> > >
> >
>