ExecType in Bust Execution

[eltonmelo_x]

Imported from previous forum

[eltonmelo_x]

Dears, I would like your help about tag 150 (ExecType) when busting an execution. Let’s say:

1

• Client sends a new order for 5000
• Exchange executes 5000 (fill)
• Exchange busts 5000, they won’t be opened again (i.e. order is cancelled, LeavesQty=0)

• Question: how should be tag 150 (ExecType) in this “bust execution”?

…

2

• Client sends a new order for 6000
• Exchange executes 2000 (partial fill)
• Exchange busts 2000, they won’t be opened again (i.e. LeavesQty will be 4000, not 6000)

• Question: how should be tag 150 (ExecType) in this “bust execution”?

…

3

• Client sends a new order for 7000
• Exchange executes 3000 (partial fill)
• Exchange cancels the balance of 4000
• Exchange busts 3000, they won’t be opened again (i.e. LeavesQty will be 0, not 3000)

• Question: how should be tag 150 (ExecType) in this “bust execution”?

…

4

• Client sends a new order for 8000
• Exchange executes 2000 (partial fill)
• Exchange executes 6000 (fill)
• Exchange busts 2000, they won’t be opened again (i.e., LeavesQty will be 0, not 2000)

• Question: how should be tag 150 (ExecType) in this “bust execution”?

• Exchange busts 6000, they won’t be opened again (i.e., LeavesQty will be 0, not 6000)

• Question: how should be tag 150 (ExecType) in this “bust execution”?

[erickou_x]

Tag 20 and tag 38 should also be taken into account in your cases.
See D19, D20 and D21 for examples on unsolicited cancel, replace and reduction.

Dears, I would like your help about tag 150 (ExecType) when busting an
execution. Let’s say:

1

• Client sends a new order for 5000
• Exchange executes 5000 (fill)
• Exchange busts 5000, they won’t be opened again (i.e. order is
  cancelled, LeavesQty=0)

• Question: how should be tag 150 (ExecType) in this “bust execution”?

…

2

• Client sends a new order for 6000
• Exchange executes 2000 (partial fill)
• Exchange busts 2000, they won’t be opened again (i.e. LeavesQty will
  be 4000, not 6000)

• Question: how should be tag 150 (ExecType) in this “bust execution”?

…

3

• Client sends a new order for 7000
• Exchange executes 3000 (partial fill)
• Exchange cancels the balance of 4000
• Exchange busts 3000, they won’t be opened again (i.e. LeavesQty will
  be 0, not 3000)

• Question: how should be tag 150 (ExecType) in this “bust execution”?

…

4

• Client sends a new order for 8000
• Exchange executes 2000 (partial fill)
• Exchange executes 6000 (fill)
• Exchange busts 2000, they won’t be opened again (i.e., LeavesQty will
  be 0, not 2000)

• Question: how should be tag 150 (ExecType) in this “bust execution”?

• Exchange busts 6000, they won’t be opened again (i.e., LeavesQty will
  be 0, not 6000)

• Question: how should be tag 150 (ExecType) in this “bust execution”?

[eltonmelo_x]

Hello Kou,

Tag 20 and tag 38 should also be taken into account in your cases.

Ok, no problem with these tags when busting an execution.

See D19, D20 and D21 for examples on unsolicited cancel, replace and
and reduction.

Ok, but these examples don’t have “busted executions”. They appear in D34 and D35, where tag 150 (ExecType) seems to follow the same value of tag 39 (OrderStatus).

One of our FIX partners told me that ExecType would be aways 150=4 when the Execution Report is busting an execution – but I’m not sure about that.

Could anyone help?

[erickou_x]

The key is to have 20 = cancellation or correction.
151 is populated with “Restated”, “rejected” or “cancelled”
and 39 will be filled with what the order status are at the time the message is generated.

Hello Kou,

Tag 20 and tag 38 should also be taken into account in your cases.

Ok, no problem with these tags when busting an execution.

See D19, D20 and D21 for examples on unsolicited cancel, replace and
and reduction.

Ok, but these examples don’t have “busted executions”. They appear in
D34 and D35, where tag 150 (ExecType) seems to follow the same value of
tag 39 (OrderStatus).

One of our FIX partners told me that ExecType would be aways 150=4
when the Execution Report is busting an execution – but I’m not sure
about that.

Could anyone help?

[erickou_x]

The value of tag 14, 151 will also play a key in the correction and cancellation message.

The key is to have 20 = cancellation or correction. 151 is populated
with “Restated”, “rejected” or “cancelled” and 39 will be filled with
what the order status are at the time the message is generated.

Hello Kou,

Tag 20 and tag 38 should also be taken into account in your cases.

Ok, no problem with these tags when busting an execution.

See D19, D20 and D21 for examples on unsolicited cancel, replace and
and reduction.

Ok, but these examples don’t have “busted executions”. They appear in
D34 and D35, where tag 150 (ExecType) seems to follow the same value
of tag 39 (OrderStatus).

One of our FIX partners told me that ExecType would be aways 150=4
when the Execution Report is busting an execution – but I’m not sure
about that.

Could anyone help?

[eltonmelo_x]

Hello,

Thanks, but my question is: when an ExecutionReport is busting an execution (20=1), what value should I use in tag 150? Does it have the same value of tag 39?

[fplpo_x]

[ original email was from Greg Wood - gregjwood@hotmail.com ]
Hi Elton,

Tag 150 should reflect the status of the order once the bust has been taken into account. So if the bust is the only trade of a fully filled order then the message would be 150=0/20=1. A bust on the last fill of an order filled in several clips should go back as 150=1/20=1.

Tag 39 could be different. A busted fill on a partially filled and cancelled order should generate 39=4/150=1/20=1 as per line 7 of example D35 in Appendix D.

The comment below made in an earlier post is interesting, especially since I heard something similar recently -

“One of our FIX partners told me that ExecType would be always 150=4 when the Execution Report is busting an execution – but I’m not sure about that.”

• I personally do not understand the logic of this. 150=4 (Cancelled) refers to the order not the fill, and does not follow the logic behind tag 20 in 4.2 to denote the transction type being reported (new, cancel, correct or status). 4.3 and later deprecate tag 20 and put the values into tag 150, but a cancelled order and a trade cancel are still distinct values (150=4 and 150=H respectively).

A question for a wider audience - is there a common deviation from the spec with regards to reporting busts as 150=4 ?

Regards,

• Greg

Hello,

Thanks, but my question is: when an ExecutionReport is busting an
execution (20=1), what value should I use in tag 150? Does it have the
same value of tag 39?

[jaydeyoung_x]

Tag 150 should refer to the “reason for” the execution report, so in a bust situation, it should be 4.
Tag 39 OrdStatus reflects the status of the order. Busted fills generally won’t change the status of the order.

Hi Elton,

Tag 150 should reflect the status of the order once the bust has been
taken into account. So if the bust is the only trade of a fully filled
order then the message would be 150=0/20=1. A bust on the last fill of
an order filled in several clips should go back as 150=1/20=1.

Tag 39 could be different. A busted fill on a partially filled and
cancelled order should generate 39=4/150=1/20=1 as per line 7 of example
D35 in Appendix D.

The comment below made in an earlier post is interesting, especially
since I heard something similar recently -

“One of our FIX partners told me that ExecType would be always 150=4
when the Execution Report is busting an execution – but I’m not sure
about that.”

• I personally do not understand the logic of this. 150=4 (Cancelled)
  refers to the order not the fill, and does not follow the logic behind
  tag 20 in 4.2 to denote the transction type being reported (new,
  cancel, correct or status). 4.3 and later deprecate tag 20 and put the
  values into tag 150, but a cancelled order and a trade cancel are
  still distinct values (150=4 and 150=H respectively).

A question for a wider audience - is there a common deviation from the
spec with regards to reporting busts as 150=4 ?

Regards,

• Greg

Hello,

Thanks, but my question is: when an ExecutionReport is busting an
execution (20=1), what value should I use in tag 150? Does it have the
same value of tag 39?

[erickou_x]

We felt a little bit in-convenient when we saw tag 20 was removed in FIX4.3. We like it so we still implement it in our 4.4.
Our logic is that tag 20 still tells what the “execution message” is for. Tag 150 tells what your action is pertaining to the order.
Tag 39 gives you the status of the order.
We sent the following “bust” message back to our clients:
20=1, 2; 150=D (for partial), 4 (for a single full exec); 39=(for whatever is appropriate), 151=(for whatever is appropriate); 14=(for whatever is appropriate).

Tag 150 should refer to the “reason for” the execution report, so in a
bust situation, it should be 4. Tag 39 OrdStatus reflects the status of
the order. Busted fills generally won’t change the status of the order.

Hi Elton,

Tag 150 should reflect the status of the order once the bust has been
taken into account. So if the bust is the only trade of a fully filled
order then the message would be 150=0/20=1. A bust on the last fill of
an order filled in several clips should go back as 150=1/20=1.

Tag 39 could be different. A busted fill on a partially filled and
cancelled order should generate 39=4/150=1/20=1 as per line 7 of
example D35 in Appendix D.

The comment below made in an earlier post is interesting, especially
since I heard something similar recently -

“One of our FIX partners told me that ExecType would be always 150=4
when the Execution Report is busting an execution – but I’m not sure
about that.”

• I personally do not understand the logic of this. 150=4 (Cancelled)
  refers to the order not the fill, and does not follow the logic
  behind tag 20 in 4.2 to denote the transction type being reported
  (new, cancel, correct or status). 4.3 and later deprecate tag 20 and
  put the values into tag 150, but a cancelled order and a trade
  cancel are still distinct values (150=4 and 150=H respectively).

A question for a wider audience - is there a common deviation from the
spec with regards to reporting busts as 150=4 ?

Regards,

• Greg

Hello,

Thanks, but my question is: when an ExecutionReport is busting an
execution (20=1), what value should I use in tag 150? Does it have
the same value of tag 39?

[fplpo_x]

[ original email was from John Greenan - john.greenan@alignment-systems.com ]
Interesting…

There is at least one global Investment Bank that does not get 39/150 right when busting full fills.

See below example. The full fill is bust but the bust has 30=2 (Filled)

This is live and in production today.

Outbound Message 2009-04-27 16:09:05,192 INFO out.ORDERROUTINGHUB_BUYSIDE_COMPID - >297 OrderSingle (8=FIX.4.2
9=281
35=D
49=BUYSIDE_COMPID
56=ORDERROUTINGHUB
34=297
52=20090427-14:09:05
97=N
128=SELLSIDE_COMPID
50=BuySideDealerName
11=LZR1010570-1!FUT
21=3
100=XLIF
207=XLIF
54=1
60=20090427-14:09:05
38=5
40=1
15=GBP
59=0
439=JPMCLR
440=89567
107=90 DAY STERLING FUTURE 0609
200=200906
55=L M9
22=5
48=L M9
167=FUT
1=BOOKING_ACCOUNT
10=237
)

pending new
Inbound Message 2009-04-27 16:09:05,582 INFO in.ORDERROUTINGHUB_BUYSIDE_COMPID - <370 ExecutionReport (8=FIX.4.2
9=361
35=8
49=ORDERROUTINGHUB
56=BUYSIDE_COMPID
115=SELLSIDE_COMPID
34=370
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-14:09:05
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-1!FUT
109=BUYSIDE_COMPID
76=SELLSIDE_COMPID
17=12408316147001560
20=0
150=A
39=A
1=BOOKING_ACCOUNT
55=L M9
48=L M9
22=5
167=FUT
200=200906
207=XLIF
54=1
38=5.0
40=1
15=GBP
59=0
32=0.0
31=0.0
151=5.0
14=0.0
6=0.0
60=20090427-14:09:05.000
10=191
)

new
Inbound Message 2009-04-27 16:09:09,317 INFO in.ORDERROUTINGHUB_BUYSIDE_COMPID - <371 ExecutionReport (8=FIX.4.2
9=361
35=8
49=ORDERROUTINGHUB
56=BUYSIDE_COMPID
115=SELLSIDE_COMPID
34=371
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-14:09:08
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-1!FUT
109=BUYSIDE_COMPID
76=SELLSIDE_COMPID
17=12408316147001570
20=0
150=0
39=0
1=BOOKING_ACCOUNT
55=L M9
48=L M9
22=5
167=FUT
200=200906
207=XLIF
54=1
38=5.0
40=1
15=GBP
59=0
32=0.0
31=0.0
151=5.0
14=0.0
6=0.0
60=20090427-14:09:09.000
10=166
)

fill
Inbound Message 2009-04-27 16:09:30,145 INFO in.ORDERROUTINGHUB_BUYSIDE_COMPID - <372 ExecutionReport (8=FIX.4.2
9=385
35=8
49=ORDERROUTINGHUB
56=BUYSIDE_COMPID
115=SELLSIDE_COMPID
34=372
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-14:09:29
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-1!FUT
109=BUYSIDE_COMPID
76=SELLSIDE_COMPID
17=96283.LN24:090427:49107
20=0
150=2
39=2
1=BOOKING_ACCOUNT
55=L M9
48=L M9
22=5
167=FUT
200=200906
207=XLIF
54=1
38=5.0
40=1
15=GBP
59=0
32=5.0
31=2365.0
151=0.0
14=5.0
6=2365.0
75=20090427
60=20090427-14:09:29.000
10=196
)

fill - busted
Inbound Message 2009-04-27 16:09:36,145 INFO in.ORDERROUTINGHUB_BUYSIDE_COMPID - <373 ExecutionReport (8=FIX.4.2
9=400
35=8
49=ORDERROUTINGHUB
56=BUYSIDE_COMPID
115=SELLSIDE_COMPID
34=373
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-14:09:35
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-1!FUT
109=BUYSIDE_COMPID
76=SELLSIDE_COMPID
17=12408316147001580
20=1
19=96283.LN24:090427:49107
150=0
39=2
1=BOOKING_ACCOUNT
55=L M9
48=L M9
22=5
167=FUT
200=200906
207=XLIF
54=1
38=5.0
40=1
15=GBP
59=0
32=0.0
31=0.0
151=5.0
14=0.0
6=0.0
75=20090427
60=20090427-14:09:35.000
10=120
)

Hi Elton,

Tag 150 should reflect the status of the order once the bust has been
taken into account. So if the bust is the only trade of a fully filled
order then the message would be 150=0/20=1. A bust on the last fill of
an order filled in several clips should go back as 150=1/20=1.

Tag 39 could be different. A busted fill on a partially filled and
cancelled order should generate 39=4/150=1/20=1 as per line 7 of example
D35 in Appendix D.

The comment below made in an earlier post is interesting, especially
since I heard something similar recently -

“One of our FIX partners told me that ExecType would be always 150=4
when the Execution Report is busting an execution – but I’m not sure
about that.”

• I personally do not understand the logic of this. 150=4 (Cancelled)
  refers to the order not the fill, and does not follow the logic behind
  tag 20 in 4.2 to denote the transction type being reported (new,
  cancel, correct or status). 4.3 and later deprecate tag 20 and put the
  values into tag 150, but a cancelled order and a trade cancel are
  still distinct values (150=4 and 150=H respectively).

A question for a wider audience - is there a common deviation from the
spec with regards to reporting busts as 150=4 ?

Regards,

• Greg

Hello,

Thanks, but my question is: when an ExecutionReport is busting an
execution (20=1), what value should I use in tag 150? Does it have the
same value of tag 39?

[anandpandey32_x]

Hi John, I have not read the whole thread here but i checked your case and i see that in Bust message it has 39=2( showing you have busted a fully filled order ) and 150=0 ( showing that its going to be new order).
Its the correct behaviour.
Interesting…

There is at least one global Investment Bank that does not get 39/150
right when busting full fills.

See below example. The full fill is bust but the bust has 30=2 (Filled)

This is live and in production today.

Outbound Message 2009-04-27 16:09:05,192 INFO
out.ORDERROUTINGHUB_BUYSIDE_COMPID - >297 OrderSingle.4.2
9=281
35=D
49=BUYSIDE_COMPID
56=ORDERROUTINGHUB
34=297
52=20090427-
14:09:05
97=N
128=SELLSIDE_COMPID
50=BuySideDealerName
11=LZR1010570-
1!FUT
21=3
100=XLIF
207=XLIF
54=1
60=20090427-
14:09:05
38=5
40=1
15=GBP
59=0
439=JPMCLR
440=89567
107=90 DAY STERLING
FUTURE 0609
200=200906
55=L M9
22=5
48=L
M9
167=FUT
1=BOOKING_ACCOUNT
10=237
)

pending new Inbound Message 2009-04-27 16:09:05,582 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID - <370 ExecutionReport_COMPID
34=370
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:05
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-
1!FUT
109=BUYSIDE_COMPID
76=SELLSIDE_COMPID
17=12408316147001560
20=0
1-
50=A
39=A
1=BOOKING_ACCOUNT
55=L M9
48=L
38=5.0
40=1
15=GBP
59=0
32=0.0
31=0.0
151=5.0
14=0.0
6=0.0
60=20090427-
14:09:05.000
10=191
)

new Inbound Message 2009-04-27 16:09:09,317 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID - <371 ExecutionReport_COMPID
34=371
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:08
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-
1!FUT
109=BUYSIDE_COMPID
76=SELLSIDE_COMPID
17=12408316147001570
20=0
1-
50=0
39=0
1=BOOKING_ACCOUNT
55=L M9
48=L
38=5.0
40=1
15=GBP
59=0
32=0.0
31=0.0
151=5.0
14=0.0
6=0.0
60=20090427-
14:09:09.000
10=166
)

fill Inbound Message 2009-04-27 16:09:30,145 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID - <372 ExecutionReport_COMPID
34=372
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:29
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-
1!FUT
109=BUYSIDE_COMPID
76=SELLSIDE_COMPID
17=96283.LN24:090427:49107
-
20=0
150=2
39=2
1=BOOKING_ACCOUNT
55=L M9
48=LP
59=0
32=5.0
31=2365.0
151=0.0
14=5.0
6=2365.0
75=20090427
60=20090427-
14:09:29.000
10=196
)

fill - busted Inbound Message 2009-04-27 16:09:36,145 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID - <373 ExecutionReport_COMPID
34=373
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:35
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-
1!FUT
109=BUYSIDE_COMPID
76=SELLSIDE_COMPID
17=12408316147001580
20=1
1-
9=96283.LN24:090427:49107
150=0
39=2
1=BOOKING_ACCOUNT
55=L M9
48=L
15=GBP
59=0
32=0.0
31=0.0
151=5.0
14=0.0
6=0.0
75=20090427
60=20090427-
14:09:35.000
10=120
)

Hi Elton,

Tag 150 should reflect the status of the order once the bust has been
taken into account. So if the bust is the only trade of a fully filled
order then the message would be 150=0/20=1. A bust on the last fill of
an order filled in several clips should go back as 150=1/20=1.

Tag 39 could be different. A busted fill on a partially filled and
cancelled order should generate 39=4/150=1/20=1 as per line 7 of
example D35 in Appendix D.

The comment below made in an earlier post is interesting, especially
since I heard something similar recently -

“One of our FIX partners told me that ExecType would be always 150=4
when the Execution Report is busting an execution – but I’m not sure
about that.”

• I personally do not understand the logic of this. 150=4 (Cancelled)
  refers to the order not the fill, and does not follow the logic
  behind tag 20 in 4.2 to denote the transction type being reported
  (new, cancel, correct or status). 4.3 and later deprecate tag 20 and
  put the values into tag 150, but a cancelled order and a trade
  cancel are still distinct values (150=4 and 150=H respectively).

A question for a wider audience - is there a common deviation from the
spec with regards to reporting busts as 150=4 ?

Regards,

• Greg

Hello,

Thanks, but my question is: when an ExecutionReport is busting an
execution (20=1), what value should I use in tag 150? Does it have
the same value of tag 39?

[fplpo_x]

[ original email was from John Greenan - john.greenan@alignment-systems.com ]
Anand,

Forgive me - but why should the order status be shown as “Filled” when the order status is “New”? Surely the order status tells us what the order should look like after the payload of the message has been processed?

If you bust a full fill then the order is now zero filled and ready to trade, so in practical terms is just as if the order is “New”.

Let’s look at the spec for guidance:
I think that the nearest order state change matrix is D35 but it’s not an exact fit for this scenario.

The specific issue is around the interpretation of the statement:

“In an execution report the OrdStatus is used to convey the current state of the order. If an order simultaneously exists in more than one order state, the value with highest precedence is the value that is reported in the OrdStatus field.” - quote from “fix-42-with_errata_20010501.doc” page 92

I suggest that this order does not exist in more than one state - it’s simply a new order now that the old full fill was busted.

If you take the view that the order exists in two states - filled and new then since Filled (8) is a higher precendence than New (2) then indeed it should be shown as as Filled.

But then I refer you to page 93
“The ExecType is used to identify the purpose of the execution report message. To transmit a change in OrdStatus for an order, the broker(sell side) should send an Execution Report with the new OrdStatus value in both the ExecType AND the OrdStatus fields to signify this message is changing the state of the order.”

Now, what else is a bust doing but changing the state of an order? And so in that case the message should surely be 39=0 / 150=0

What do you say?

Anyone else care to comment?

John

Hi John, I have not read the whole thread here but i checked your
case and i see that in Bust message it has 39=2( showing you have
busted a fully filled order ) and 150=0 ( showing that its going to
be new order).
Its the correct behaviour. Interesting…

There is at least one global Investment Bank that does not get 39/150
right when busting full fills.

See below example. The full fill is bust but the bust has 39=2
(Filled)

This is live and in production today.

Outbound Message 2009-04-27 16:09:05,192 INFO
out.ORDERROUTINGHUB_BUYSIDE_COMPID - >297.2
9=281
35=D
49=BUYSIDE_COMPID
56=ORDERROUTINGHUB
34=297
52=20090427-
14:09:05
97=N
128=SELLSIDE_COMPID
50=BuySideDealerName
11=LZR1010570-
1!FUT
21=3
100=XLIF
207=XLIF
54=1
60=20090427-
14:09:05
38=5
40=1
15=GBP
59=0
439=JPMCLR
440=89567
107=90 DAY
STERLING FUTURE 0609
200=200906
55=L M9
22=5
48=L
M9
167=FUT
1=BOOKING_ACCOUNT
10=237
)

pending new Inbound Message 2009-04-27 16:09:05,582 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID - <370ID
34=370
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:05
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-9=BUYSIDE_COMPID
76=SELLSIDE_COMPID
17=12408316147001560
20=0
1-
50=A
39=A
1=BOOKING_ACCOUNT
55=L40=1
15=GBP
59=0
32=0.0
31=0.0
151=5.0
14=0.0
6=0.0
60=20090427-
14:09:05.000
10=191
)

new Inbound Message 2009-04-27 16:09:09,317 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID - <371ID
34=371
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:08
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-9=BUYSIDE_COMPID
76=SELLSIDE_COMPID
17=12408316147001570
20=0
1-
50=0
39=0
1=BOOKING_ACCOUNT
55=L40=1
15=GBP
59=0
32=0.0
31=0.0
151=5.0
14=0.0
6=0.0
60=20090427-
14:09:09.000
10=166
)

fill Inbound Message 2009-04-27 16:09:30,145 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID - <372ID
34=372
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:29
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-9=BUYSIDE_COMPID
76=SELLSIDE_COMPID
17=96283.LN24:090427:49107
-
20=0
150=2
39=2
1=BOOKING_ACCOUNT
55=L2=5.0
31=2365.0
151=0.0
14=5.0
6=2365.0
75=20090427
60=20090427-
14:09:29.000
10=196
)

fill - busted Inbound Message 2009-04-27 16:09:36,145 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID - <373ID
34=373
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:35
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-9=BUYSIDE_COMPID
76=SELLSIDE_COMPID
17=12408316147001580
20=1
1-
9=96283.LN24:090427:49107
150=0
39=2
1=BOOKING_ACCOUNT
55=L59=0
32=0.0
31=0.0
151=5.0
14=0.0
6=0.0
75=20090427
60=20090427-
14:09:35.000
10=120
)

Hi Elton,

Tag 150 should reflect the status of the order once the bust has
been taken into account. So if the bust is the only trade of a fully
filled order then the message would be 150=0/20=1. A bust on the
last fill of an order filled in several clips should go back as
150=1/20=1.

Tag 39 could be different. A busted fill on a partially filled and
cancelled order should generate 39=4/150=1/20=1 as per line 7 of
example D35 in Appendix D.

The comment below made in an earlier post is interesting, especially
since I heard something similar recently -

“One of our FIX partners told me that ExecType would be always
150=4 when the Execution Report is busting an execution – but I’m
not sure about that.”

• I personally do not understand the logic of this. 150=4
  (Cancelled) refers to the order not the fill, and does not follow
  the logic behind tag 20 in 4.2 to denote the transction type being
  reported (new, cancel, correct or status). 4.3 and later deprecate
  tag 20 and put the values into tag 150, but a cancelled order and
  a trade cancel are still distinct values (150=4 and 150=H
  respectively).

A question for a wider audience - is there a common deviation from
the spec with regards to reporting busts as 150=4 ?

Regards,

• Greg

Hello,

Thanks, but my question is: when an ExecutionReport is busting an
execution (20=1), what value should I use in tag 150? Does it have
the same value of tag 39?

[fplpo_x]

[ original email was from Greg Wood - gregjwood@hotmail.com ]
It’s amazing how much difference of opinion there has been on this post regarding a relatively straightforward operation such as busting a trade that has been previous reported.

John and myself did actually discuss this offline and we both agree that that it makes more sense for OrdStatus to reflect the status after the effect of the trade cancel rather than the status prior to the trade cancel. That’s what an OMS or EMS is typically going to key off so as to set the status of the order in the system. Leaving the OrdStatus as Fully Filled in this case implies that another fill is going to come - something that is not necessarily guaranteed.

I think that so far in this post we have had the following combinations put forward for a complete bust of a fully filled order -

39=2/150=0/20=1
39=0/150=0/20=1
39=0/150=4/20=1

There’s obviously a wide difference in opinion.

My approach to this is to clearly detail our implementation for busts in our rules of engagement, and if a client or vendor requires something different then we will manipulate tags 39 and 150 accordingly based on the presence of tag 20=1. Not ideal, but it allows us to flexibly work around these differences in opinion.

I guess that a lot of the ambiguity comes from the evolutionary nature of tag 150 from its first inclusion in 4.1 through to a slightly more rounded definition in 4.4 and later. I would also suggest that this difference of opinion has arisen due to the lack of a simple New Order->Acked->Fully Filled->Fully Busted scenario in Appendix D.

Is this something that the GTC should consider revisiting, perhaps by offering best practice guidelines for busts on versions of FIX prior to 5.0 ?

• Greg

Anand,

Forgive me - but why should the order status be shown as “Filled” when
the order status is “New”? Surely the order status tells us what the
order should look like after the payload of the message has been
processed?

If you bust a full fill then the order is now zero filled and ready to
trade, so in practical terms is just as if the order is “New”.

Let’s look at the spec for guidance: I think that the nearest order
state change matrix is D35 but it’s not an exact fit for this scenario.

The specific issue is around the interpretation of the statement:

“In an execution report the OrdStatus is used to convey the current
state of the order. If an order simultaneously exists in more than one
order state, the value with highest precedence is the value that is
reported in the OrdStatus field.” - quote from “fix-42-
with_errata_20010501.doc” page 92

I suggest that this order does not exist in more than one state - it’s
simply a new order now that the old full fill was busted.

If you take the view that the order exists in two states - filled and
new then since Filled (8) is a higher precendence than New (2) then
indeed it should be shown as as Filled.

But then I refer you to page 93 “The ExecType is used to identify the
purpose of the execution report message. To transmit a change in
OrdStatus for an order, the broker(sell side) should send an
Execution Report with the new OrdStatus value in both the ExecType
AND the OrdStatus fields to signify this message is changing the
state of the order.”

Now, what else is a bust doing but changing the state of an order? And
so in that case the message should surely be 39=0 / 150=0

What do you say?

Anyone else care to comment?

John

Hi John, I have not read the whole thread here but i checked your
case and i see that in Bust message it has 39=2( showing you have
busted a fully filled order ) and 150=0 ( showing that its going to
be new order).
Its the correct behaviour. Interesting…

There is at least one global Investment Bank that does not get
39/150 right when busting full fills.

See below example. The full fill is bust but the bust has 39=2
(Filled)

This is live and in production today.

Outbound Message 2009-04-27 16:09:05,192 INFO
out.ORDERROUTINGHUB_BUYSIDE_COMPID -
9=281
35=D
49=BUYSIDE_COMPID
56=ORDERROUTINGHUB
34=297
52=20090427-
14:09:5
97=N
128=SELLSIDE_COMPID
50=BuySideDealerName
11=LZR1010570-
1!FUT
21=3
100=XLIF
207=XLIF
54=1
60=20090427-
14:09:05
38=5
40=1
15=GBP
59=0
439=JPMCLR
440=89567
107=90 DAY
STERLING FUTURE 0609
200=200906
55=L M9
22=5
48=L
M9
167=FUT
1=BOOKING_ACCOUNT
10=237
)

pending new Inbound Message 2009-04-27 16:09:05,582 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID -
34=370
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:05
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-
BUYSIDE_COMPID
76=SELLSIDE_COMPID
17=12408316147001560
20=0
1-
=1
15=GBP
59=0
32=0.0
31=0.0
151=5.0
14=0.0
6=0.0
60=20090427-
14:09:05.000
10=191
)

new Inbound Message 2009-04-27 16:09:09,317 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID -
34=371
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:08
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-
BUYSIDE_COMPID
76=SELLSIDE_COMPID
17=12408316147001570
20=0
1-
=1
15=GBP
59=0
32=0.0
31=0.0
151=5.0
14=0.0
6=0.0
60=20090427-
14:09:09.000
10=166
)

fill Inbound Message 2009-04-27 16:09:30,145 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID -
34=372
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:29
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-
BUYSIDE_COMPID
76=SELLSIDE_COMPID
17=96283.LN24:090427:49107
-
5.0
31=2365.0
151=0.0
14=5.0
6=2365.0
75=20090427
60=20090427-
14:09:29.000
10=196
)

fill - busted Inbound Message 2009-04-27 16:09:36,145 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID -
34=373
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:35
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-
BUYSIDE_COMPID
76=SELLSIDE_COMPID
17=12408316147001580
20=1
1-
=0
32=0.0
31=0.0
151=5.0
14=0.0
6=0.0
75=20090427
60=20090427-
14:09:35.000
10=120
)

Hi Elton,

Tag 150 should reflect the status of the order once the bust has
been taken into account. So if the bust is the only trade of a
fully filled order then the message would be 150=0/20=1. A bust on
the last fill of an order filled in several clips should go back
as 150=1/20=1.

Tag 39 could be different. A busted fill on a partially filled and
cancelled order should generate 39=4/150=1/20=1 as per line 7 of
example D35 in Appendix D.

The comment below made in an earlier post is interesting,
especially since I heard something similar recently -

“One of our FIX partners told me that ExecType would be always
150=4 when the Execution Report is busting an execution – but I’m
not sure about that.”

• I personally do not understand the logic of this. 150=4
  (Cancelled) refers to the order not the fill, and does not
  follow the logic behind tag 20 in 4.2 to denote the transction
  type being reported (new, cancel, correct or status). 4.3 and
  later deprecate tag 20 and put the values into tag 150, but a
  cancelled order and a trade cancel are still distinct values
  (150=4 and 150=H respectively).

A question for a wider audience - is there a common deviation from
the spec with regards to reporting busts as 150=4 ?

Regards,

• Greg

Hello,

Thanks, but my question is: when an ExecutionReport is busting
an execution (20=1), what value should I use in tag 150? Does it
have the same value of tag 39?

[eltonmelo_x]

Hello everyone,

It’s amazing how much difference of opinion there has been on this post
regarding a relatively straightforward operation such as busting a trade
that has been previous reported.

John and myself did actually discuss this offline

Wow, I couldn’t imagine that my question would have cause all that. Sorry guys!

My approach to this is to clearly detail our implementation for busts in
our rules of engagement, and if a client or vendor requires something
different then we will manipulate tags 39 and 150 accordingly based on
the presence of tag 20=1. Not ideal, but it allows us to flexibly work
around these differences in opinion.

Meanwhile, I asked my FIX-partner to tell me what they want to receive in a busted execution. By now, their answer is: “please check at www.fixprotocol.org”…

I guess that a lot of the ambiguity comes from the evolutionary nature
of tag 150 from its first inclusion in 4.1 through to a slightly more
rounded definition in 4.4 and later. I would also suggest that this
difference of opinion has arisen due to the lack of a simple New Order->Acked-

Fully Filled->Fully Busted scenario in Appendix D.

Is this something that the GTC should consider revisiting, perhaps by
offering best practice guidelines for busts on versions of FIX
prior to 5.0 ?

This is a good idea. An important remark:

• Some exchange houses return the “busted quantity” to the trading floor. In this case, the order returns to a “new” or “partially filled” status.
• Other exchange houses don’t return the “busted quantity” to the trading floor. A “full-fill” > “full-bust” would set the order status to “canceled” in this case.

…

Besides that, I also observed some divergences on tags 31 and 32 when busting an execution. The FIX specs tell us to send both tags with 0; but I have one FIX-partner who asked me to send the “busted quantity” in LastShare, and the “busted price” in LastPx.

Thank you all.

[fplpo_x]

[ original email was from John Greenan - john.greenan@alignment-systems.com ]
Further to Greg’s comments I suggest that there are two broad options:

1. GTC issue guidance for this.
2. Systems vendors and others stop looking at the meta-data tags and derive order state from the tags that relate to order state. This will not work in all cases, but 31,32,38,152,151,14,6 will show a lot of state value for equity orders (add in other tags for f/x and other asset classes).

In essence - move some of the logic for deriving order state from the sender of the execution report to the recipient of the execution report.

In discussions with a number of firms on this issue it is clear that there are a number of approaches in use today. At least one EMS vendor takes the path of determining order state dynamically from the tags listed in option 2 above. Some brokers invoke different configuration for different buy-sides dependent on which OMS the buy-side uses.

Many buy-sides and buy-side vendors take a path of least resistance and simply offload the problem to the broker and request that the broker resolves by sending a specific set of tags on the FIX message. The problem with this approach is simple - we move from a universal langauge of FIX to vendor specific implementations. While perhaps the path of least resistance it’s also, in my view, the wrong way to go.

As such I back the request from Greg for the GTC to issue guidance. Let’s come together, determine the right way and standardise on that.

It’s amazing how much difference of opinion there has been on this post
regarding a relatively straightforward operation such as busting a trade
that has been previous reported.

John and myself did actually discuss this offline and we both agree that
that it makes more sense for OrdStatus to reflect the status after the
effect of the trade cancel rather than the status prior to the trade
cancel. That’s what an OMS or EMS is typically going to key off so as to
set the status of the order in the system. Leaving the OrdStatus as
Fully Filled in this case implies that another fill is going to come -
something that is not necessarily guaranteed.

I think that so far in this post we have had the following combinations
put forward for a complete bust of a fully filled order -

39=2/150=0/20=1 39=0/150=0/20=1 39=0/150=4/20=1

There’s obviously a wide difference in opinion.

My approach to this is to clearly detail our implementation for busts in
our rules of engagement, and if a client or vendor requires something
different then we will manipulate tags 39 and 150 accordingly based on
the presence of tag 20=1. Not ideal, but it allows us to flexibly work
around these differences in opinion.

I guess that a lot of the ambiguity comes from the evolutionary nature
of tag 150 from its first inclusion in 4.1 through to a slightly more
rounded definition in 4.4 and later. I would also suggest that this
difference of opinion has arisen due to the lack of a simple New Order->Acked-

Fully Filled->Fully Busted scenario in Appendix D.

Is this something that the GTC should consider revisiting, perhaps by
offering best practice guidelines for busts on versions of FIX
prior to 5.0 ?

• Greg

Anand,

Forgive me - but why should the order status be shown as “Filled” when
the order status is “New”? Surely the order status tells us what the
order should look like after the payload of the message has been
processed?

If you bust a full fill then the order is now zero filled and ready to
trade, so in practical terms is just as if the order is “New”.

Let’s look at the spec for guidance: I think that the nearest order
state change matrix is D35 but it’s not an exact fit for this
scenario.

The specific issue is around the interpretation of the statement:

“In an execution report the OrdStatus is used to convey the current
state of the order. If an order simultaneously exists in more than one
order state, the value with highest precedence is the value that is
reported in the OrdStatus field.” - quote from “fix-42-
with_errata_20010501.doc” page 92

I suggest that this order does not exist in more than one state - it’s
simply a new order now that the old full fill was busted.

If you take the view that the order exists in two states - filled and
new then since Filled (8) is a higher precendence than New (2) then
indeed it should be shown as as Filled.

But then I refer you to page 93 “The ExecType is used to identify the
purpose of the execution report message. To transmit a change in
OrdStatus for an order, the broker(sell side) should send an
Execution Report with the new OrdStatus value in both the ExecType
AND the OrdStatus fields to signify this message is changing the
state of the order.”

Now, what else is a bust doing but changing the state of an order? And
so in that case the message should surely be 39=0 / 150=0

What do you say?

Anyone else care to comment?

John

Hi John, I have not read the whole thread here but i checked your
case and i see that in Bust message it has 39=2( showing you have
busted a fully filled order ) and 150=0 ( showing that its going to
be new order).
Its the correct behaviour. Interesting…

There is at least one global Investment Bank that does not get
39/150 right when busting full fills.

See below example. The full fill is bust but the bust has 39=2
(Filled)

This is live and in production today.

Outbound Message 2009-04-27 16:09:05,192 INFO
out.ORDERROUTINGHUB_BUYSIDE_COMPID -
=281
35=D
49=BUYSIDE_COMPID
56=ORDERROUTINGHUB
34=297
52=20090427-
14:09:97=N
128=SELLSIDE_COMPID
50=BuySideDealerName
11=LZR1010570-
1!FUT
21=3
100=XLIF
207=XLIF
54=1
60=20090427-
14:09:05
38=5
40=1
15=GBP
59=0
439=JPMCLR
440=89567
107=90 DAY
STERLING FUTURE 0609
200=200906
55=L M9
22=5
48=L
M9
167=FUT
1=BOOKING_ACCOUNT
10=237
)

pending new Inbound Message 2009-04-27 16:09:05,582 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID -
4=370
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:05
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-YSIDE_COMPID
76=SELLSIDE_COMPID
17=12408316147001560
20=0
1-
=15=GBP
59=0
32=0.0
31=0.0
151=5.0
14=0.0
6=0.0
60=20090427-
14:09:05.000
10=191
)

new Inbound Message 2009-04-27 16:09:09,317 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID -
4=371
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:08
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-YSIDE_COMPID
76=SELLSIDE_COMPID
17=12408316147001570
20=0
1-
=15=GBP
59=0
32=0.0
31=0.0
151=5.0
14=0.0
6=0.0
60=20090427-
14:09:09.000
10=166
)

fill Inbound Message 2009-04-27 16:09:30,145 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID -
4=372
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:29
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-YSIDE_COMPID
76=SELLSIDE_COMPID
17=96283.LN24:090427:49107
-
5.31=2365.0
151=0.0
14=5.0
6=2365.0
75=20090427
60=20090427-
14:09:29.000
10=196
)

fill - busted Inbound Message 2009-04-27 16:09:36,145 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID -
4=373
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:35
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-YSIDE_COMPID
76=SELLSIDE_COMPID
17=12408316147001580
20=1
1-
=32=0.0
31=0.0
151=5.0
14=0.0
6=0.0
75=20090427
60=20090427-
14:09:35.000
10=120
)

Hi Elton,

Tag 150 should reflect the status of the order once the bust has
been taken into account. So if the bust is the only trade of a
fully filled order then the message would be 150=0/20=1. A bust
on the last fill of an order filled in several clips should go
back as 150=1/20=1.

Tag 39 could be different. A busted fill on a partially filled
and cancelled order should generate 39=4/150=1/20=1 as per line
7 of example D35 in Appendix D.

The comment below made in an earlier post is interesting,
especially since I heard something similar recently -

“One of our FIX partners told me that ExecType would be always
150=4 when the Execution Report is busting an execution – but
I’m not sure about that.”

• I personally do not understand the logic of this. 150=4
  (Cancelled) refers to the order not the fill, and does not
  follow the logic behind tag 20 in 4.2 to denote the transction
  type being reported (new, cancel, correct or status). 4.3 and
  later deprecate tag 20 and put the values into tag 150, but a
  cancelled order and a trade cancel are still distinct values
  (150=4 and 150=H respectively).

A question for a wider audience - is there a common deviation
from the spec with regards to reporting busts as 150=4 ?

Regards,

• Greg

Hello,

Thanks, but my question is: when an ExecutionReport is busting
an execution (20=1), what value should I use in tag 150? Does
it have the same value of tag 39?

[mattsimpson74]

The GTC is happy to host a more formal discussion on this topic. If there is ambiguity in either the order state change matrices or the rules as stated in the spec then it should be clarified. This Thursday’s monthly GTC meeting would be a good opportunity. Otherwise, we could find another time that suits all parties.

Looking at both the 4.2 and 5.0 SP1 specs leads me to the conclusion that the intent is for ExecType to be set to a value indicating that the trade has been canceled (4 or H, depending on version) and that OrderStatus would be set to value determined by the order status priority matrix. In some cases this may simply be “New” if there is no preceding status that overrides this. Unfortunately there is not a bust example that clearly conveys this and we may want to consider providing such.

Further to Greg’s comments I suggest that there are two broad options:

1. GTC issue guidance for this. 2. Systems vendors and others stop
   looking at the meta-data tags and derive order state from the tags
   that relate to order state. This will not work in all cases, but
   31,32,38,152,151,14,6 will show a lot of state value for equity
   orders (add in other tags for f/x and other asset classes).

In essence - move some of the logic for deriving order state from the
sender of the execution report to the recipient of the execution report.

In discussions with a number of firms on this issue it is clear that
there are a number of approaches in use today. At least one EMS vendor
takes the path of determining order state dynamically from the tags
listed in option 2 above. Some brokers invoke different configuration
for different buy-sides dependent on which OMS the buy-side uses.

Many buy-sides and buy-side vendors take a path of least resistance and
simply offload the problem to the broker and request that the broker
resolves by sending a specific set of tags on the FIX message. The
problem with this approach is simple - we move from a universal langauge
of FIX to vendor specific implementations. While perhaps the path of
least resistance it’s also, in my view, the wrong way to go.

As such I back the request from Greg for the GTC to issue guidance.
Let’s come together, determine the right way and standardise on that.

It’s amazing how much difference of opinion there has been on this
post regarding a relatively straightforward operation such as busting
a trade that has been previous reported.

John and myself did actually discuss this offline and we both agree
that that it makes more sense for OrdStatus to reflect the status
after the effect of the trade cancel rather than the status prior
to the trade cancel. That’s what an OMS or EMS is typically going to
key off so as to set the status of the order in the system. Leaving
the OrdStatus as Fully Filled in this case implies that another fill
is going to come - something that is not necessarily guaranteed.

I think that so far in this post we have had the following
combinations put forward for a complete bust of a fully filled order -

39=2/150=0/20=1 39=0/150=0/20=1 39=0/150=4/20=1

There’s obviously a wide difference in opinion.

My approach to this is to clearly detail our implementation for busts
in our rules of engagement, and if a client or vendor requires
something different then we will manipulate tags 39 and 150
accordingly based on the presence of tag 20=1. Not ideal, but it
allows us to flexibly work around these differences in opinion.

I guess that a lot of the ambiguity comes from the evolutionary nature
of tag 150 from its first inclusion in 4.1 through to a slightly more
rounded definition in 4.4 and later. I would also suggest that this
difference of opinion has arisen due to the lack of a simple New Order->Acked-

Fully Filled->Fully Busted scenario in Appendix D.

Is this something that the GTC should consider revisiting, perhaps by
offering best practice guidelines for busts on versions of FIX prior
to 5.0 ?

• Greg

Anand,

Forgive me - but why should the order status be shown as “Filled”
when the order status is “New”? Surely the order status tells us
what the order should look like after the payload of the message has
been processed?

If you bust a full fill then the order is now zero filled and ready
to trade, so in practical terms is just as if the order is “New”.

Let’s look at the spec for guidance: I think that the nearest order
state change matrix is D35 but it’s not an exact fit for this
scenario.

The specific issue is around the interpretation of the statement:

“In an execution report the OrdStatus is used to convey the current
state of the order. If an order simultaneously exists in more than
one order state, the value with highest precedence is the value that
is reported in the OrdStatus field.” - quote from “fix-42-
with_errata_20010501.doc” page 92

I suggest that this order does not exist in more than one state -
it’s simply a new order now that the old full fill was busted.

If you take the view that the order exists in two states - filled
and new then since Filled (8) is a higher precendence than New (2)
then indeed it should be shown as as Filled.

But then I refer you to page 93 “The ExecType is used to identify
the purpose of the execution report message. To transmit a change in
OrdStatus for an order, the broker(sell side) should send an
Execution Report with the new OrdStatus value in both the ExecType
AND the OrdStatus fields to signify this message is changing the
state of the order.”

Now, what else is a bust doing but changing the state of an order?
And so in that case the message should surely be 39=0 / 150=0

What do you say?

Anyone else care to comment?

John

Hi John, I have not read the whole thread here but i checked your
case and i see that in Bust message it has 39=2( showing you have
busted a fully filled order ) and 150=0 ( showing that its going
to be new order).
Its the correct behaviour. Interesting…

There is at least one global Investment Bank that does not get
39/150 right when busting full fills.

See below example. The full fill is bust but the bust has 39=2
(Filled)

This is live and in production today.

Outbound Message 2009-04-27 16:09:05,192 INFO
out.ORDERROUTINGHUB_BUYSIDE_COMPID -
=1
35=D
49=BUYSIDE_COMPID
56=ORDERROUTINGHUB
34=297
52=20090427-
14:09:=N
128=SELLSIDE_COMPID
50=BuySideDealerName
11=LZR1010570-
1!FUT
21=3
100=XLIF
207=XLIF
54=1
60=20090427-
14:09:05
38=5
40=1
15=GBP
59=0
439=JPMCLR
440=89567
107=90 DAY
STERLING FUTURE 0609
200=200906
55=L M9
22=5
48=L
M9
167=FUT
1=BOOKING_ACCOUNT
10=237
)

pending new Inbound Message 2009-04-27 16:09:05,582 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID -370
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:05
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-
IDE_COMPID
76=SELLSIDE_COMPID
17=12408316147001560
20=0
1-
==GBP
59=0
32=0.0
31=0.0
151=5.0
14=0.0
6=0.0
60=20090427-
14:09:05.000
10=191
)

new Inbound Message 2009-04-27 16:09:09,317 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID -371
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:08
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-
IDE_COMPID
76=SELLSIDE_COMPID
17=12408316147001570
20=0
1-
==GBP
59=0
32=0.0
31=0.0
151=5.0
14=0.0
6=0.0
60=20090427-
14:09:09.000
10=166
)

fill Inbound Message 2009-04-27 16:09:30,145 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID -372
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:29
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-
IDE_COMPID
76=SELLSIDE_COMPID
17=96283.LN24:090427:49107
-
5.=2365.0
151=0.0
14=5.0
6=2365.0
75=20090427
60=20090427-
14:09:29.000
10=196
)

fill - busted Inbound Message 2009-04-27 16:09:36,145 INFO
in.ORDERROUTINGHUB_BUYSIDE_COMPID -373
50=SELLSIDE_COMPID
57=BuySideDealerName
43=N
52=20090427-
14:09:35
369=297
37=065867546-LN24:090427:96283
11=LZR1010570-
IDE_COMPID
76=SELLSIDE_COMPID
17=12408316147001580
20=1
1-
==0.0
31=0.0
151=5.0
14=0.0
6=0.0
75=20090427
60=20090427-
14:09:35.000
10=120
)

Hi Elton,

Tag 150 should reflect the status of the order once the bust
has been taken into account. So if the bust is the only trade
of a fully filled order then the message would be 150=0/20=1.
A bust on the last fill of an order filled in several clips
should go back as 150=1/20=1.

Tag 39 could be different. A busted fill on a partially filled
and cancelled order should generate 39=4/150=1/20=1 as per
line 7 of example D35 in Appendix D.

The comment below made in an earlier post is interesting,
especially since I heard something similar recently -

“One of our FIX partners told me that ExecType would be
always 150=4 when the Execution Report is busting an
execution – but I’m not sure about that.”

• I personally do not understand the logic of this. 150=4
  (Cancelled) refers to the order not the fill, and does not
  follow the logic behind tag 20 in 4.2 to denote the
  transction type being reported (new, cancel, correct or
  status). 4.3 and later deprecate tag 20 and put the values
  into tag 150, but a cancelled order and a trade cancel are
  still distinct values (150=4 and 150=H respectively).

A question for a wider audience - is there a common deviation
from the spec with regards to reporting busts as 150=4 ?

Regards,

• Greg

Hello,

Thanks, but my question is: when an ExecutionReport is
busting an execution (20=1), what value should I use in tag
150? Does it have the same value of tag 39?

[eltonmelo_x]

Hello,

The GTC is happy to host a more formal discussion on this topic. If
there is ambiguity in either the order state change matrices or the
rules as stated in the spec then it should be clarified. This Thursday’s
monthly GTC meeting would be a good opportunity. Otherwise, we could
find another time that suits all parties.

Please, do you have any news of GTC on this topic?

Looking at both the 4.2 and 5.0 SP1 specs leads me to the conclusion
that the intent is for ExecType to be set to a value indicating that
the trade has been canceled (4 or H, depending on version) and that
OrderStatus would be set to value determined by the order status
priority matrix. In some cases this may simply be “New” if there is no
preceding status that overrides this. Unfortunately there is not a
bust example that clearly conveys this and we may want to consider
providing such.

Will FPL add this “full bust” in the “D” appendix of FIX 4.2 specs?

At least, may I assume that ExecType=Cancel (150=4) when busting an execution?

Thanks,

Elton

[fplpo_x]

[ original email was from John Greenan - john.greenan@alignment-systems.com ]
Hi Elton,

A sub-group of the GTC is looking at this issue. I am working with Greg Wood of Credit Suisse and Jim Whitehead of Fidessa LatentZero on a proposal. This will be ready for review on 11th June.

Regards,

John

Hello,

The GTC is happy to host a more formal discussion on this topic. If
there is ambiguity in either the order state change matrices or the
rules as stated in the spec then it should be clarified. This
Thursday’s monthly GTC meeting would be a good opportunity. Otherwise,
we could find another time that suits all parties.

Please, do you have any news of GTC on this topic?

Looking at both the 4.2 and 5.0 SP1 specs leads me to the conclusion
that the intent is for ExecType to be set to a value indicating that
the trade has been canceled (4 or H, depending on version) and that
OrderStatus would be set to value determined by the order status
priority matrix. In some cases this may simply be “New” if there is no
preceding status that overrides this. Unfortunately there is not a
bust example that clearly conveys this and we may want to consider
providing such.

Will FPL add this “full bust” in the “D” appendix of FIX 4.2 specs?

At least, may I assume that ExecType=Cancel (150=4) when busting an
execution?

Thanks,

Elton

[kathrynhorton61_x]

Hello,

Please can someone let me know where do I can find the details of the proposal referred to below.

Hi Elton,

A sub-group of the GTC is looking at this issue. I am working with Greg
Wood of Credit Suisse and Jim Whitehead of Fidessa LatentZero on a
proposal. This will be ready for review on 11th June.

Regards,

John

Hello,

The GTC is happy to host a more formal discussion on this topic. If
there is ambiguity in either the order state change matrices or the
rules as stated in the spec then it should be clarified. This
Thursday’s monthly GTC meeting would be a good opportunity.
Otherwise, we could find another time that suits all parties.

Please, do you have any news of GTC on this topic?

Looking at both the 4.2 and 5.0 SP1 specs leads me to the conclusion
that the intent is for ExecType to be set to a value indicating that
the trade has been canceled (4 or H, depending on version) and that
OrderStatus would be set to value determined by the order status
priority matrix. In some cases this may simply be “New” if there is
no preceding status that overrides this. Unfortunately there is not
a bust example that clearly conveys this and we may want to consider
providing such.

Will FPL add this “full bust” in the “D” appendix of FIX 4.2 specs?

At least, may I assume that ExecType=Cancel (150=4) when busting an
execution?

Thanks,

Elton