Posted: Jan 08, 2014 @ 04:49 AM             Msg. 1 of 5

According to the API doc "First order in a list is main order, which triggers the other (child) ones when it filled/completed".

There may be a problem with the execution of the second legs of OSO orders. The following describes a situation, along with fix messages where a OSO leg1 is filled but leg2 is neither filled nor rejected.

My comments in <brackets>.
<Client send NewOrderList message of type OSO with CLOrd ID of 1401071547220000 for leg 1 and 1401071547220001 for leg 2. Leg1 is a limit order, leg2 is a market order which should be placed when leg1 is filled.>

8=FIX.4.4
9=333
35=E
34=2
49=MHall4001
52=20140107-15:47:35.475
56=OEC_TEST
66=OSO Order 2 Legs
68=2
69=OSO
394=3
73=2
11=1401071547220000
67=1
1=API002218
55=LE
461=FXXXXS
200=201412
54=1
60=20140107-15:47:35.474
38=5
40=2
44=132.25
11=1401071547220001
67=2
1=API002218
55=LE
461=FXXXXS
200=201406
54=2
60=20140107-15:47:35.475
38=5
40=1
44=132.25
10=233


<Order is accepted by server, server assigns the following order numbers leg1 = 202867343, leg2 = 202867344.>

8=FIX.4.4
9=215
35=8
34=5
49=OEC_TEST
52=20140107-15:47:45.993
56=MHall4001
1=API002218
6=0.000
11=1401071547220000
14=0
17=5223787
37=202867343
38=5
39=0
44=132.25
54=1
55=LE
60=20140107-15:47:45
150=0
151=5
200=201412
461=FXXXXS
10=169


8=FIX.4.4
9=231
35=8
34=4
49=OEC_TEST
52=20140107-15:47:45.993
56=MHall4001
1=API002218
6=0.000
11=1401071547220001
14=0
17=5223786
37=202867344
38=5
39=9
44=132.25
54=2
55=LE
58=Auto-Execute
60=20140107-15:47:45
150=9
151=5
200=201406
461=FXXXXS
10=001


<Leg1 of order is updated several times using OrderCancelReplaceReject messages, acceptance of which is confirmed by the server. An example ...>

8=FIX.4.4
9=192
35=G
34=115
49=MHall4001
52=20140107-16:07:25.517
56=OEC_TEST
1=API002218
11=1401071547220023
38=5
40=2
41=1401071547220022
44=132.35
54=1
55=LE
60=20140107-15:47:35.474
200=201412
461=FXXXXS
10=208


8=FIX.4.4
9=256
35=8
34=88
49=OEC_TEST
52=20140107-16:07:26.899
56=MHall4001
1=API002218
6=0.000
11=1401071547220023
14=0
17=OECFIX:635245560331309946:1385
37=202867343
38=5
39=E
41=1401071547220022
44=132
54=1
55=LE
60=20140107-16:07:26
150=E
151=5
200=201412
461=FXXXXS
10=132


8=FIX.4.4
9=273
35=8
34=89
49=OEC_TEST
52=20140107-16:07:26.915
56=MHall4001
1=API002218
6=0.000
11=1401071547220023
14=0
17=OECFIX:635245560331309946:1386
37=202867343
38=5
39=0
41=1401071547220022
44=132.35
54=1
55=LE
60=20140107-16:07:26
150=5
151=5
198=202867370
200=201412
461=FXXXXS
10=158


<Just before the first leg is filled....>
<Latest ClOrderId number is 1401071547220023>

8=FIX.4.4
9=256
35=8
34=88
49=OEC_TEST
52=20140107-16:07:26.899
56=MHall4001
1=API002218
6=0.000
11=1401071547220023
14=0
17=OECFIX:635245560331309946:1385
37=202867343
38=5
39=E
41=1401071547220022
44=132
54=1
55=LE
60=20140107-16:07:26
150=E
151=5
200=201412
461=FXXXXS
10=132


<<On Message ClOrderId 1401071547220023 status = E > Pending replace
8=FIX.4.4
9=273
35=8
34=89
49=OEC_TEST
52=20140107-16:07:26.915
56=MHall4001
1=API002218
6=0.000
11=1401071547220023
14=0
17=OECFIX:635245560331309946:1386
37=202867343
38=5
39=0
41=1401071547220022
44=132.35
54=1
55=LE
60=20140107-16:07:26
150=5
151=5
198=202867370
200=201412
461=FXXXXS
10=158


<For ClOrderId 1401071547220023 status = 0 means the order change has been accepted by server>

<Client lowers price of ClOrderId 1401071547220023 by order sending following message. New order number is 1401071547220024>

8=FIX.4.4
9=192
35=G
34=118
49=MHall4001
52=20140107-16:07:49.399
56=OEC_TEST
1=API002218
11=1401071547220024
38=5
40=2
41=1401071547220023
44=131.95
54=1
55=LE
60=20140107-15:47:35.474
200=201412
461=FXXXXS
10=232


<Order server updates client with ex rep of partial fill (3 of 5 for ClOrderId ending in 1401071547220023)>

8=FIX.4.4
9=234
35=8
34=91
49=OEC_TEST
52=20140107-16:07:50.767
56=MHall4001
1=API002218
6=132.350
11=1401071547220023
14=3
17=5223802
31=132.350
32=3
37=202867343
38=5
39=1
44=132.35
54=1
55=LE
60=20140107-16:07:50
150=F
151=2
200=201412
461=FXXXXS
10=035


<Order server then sends a pending replace messsge for the new ClOrderId 1401071547220024. >

8=FIX.4.4
9=261
35=8
34=92
49=OEC_TEST
52=20140107-16:07:50.783
56=MHall4001
1=API002218
6=132.350
11=1401071547220024
14=3
17=OECFIX:635245560331309946:1387
37=202867343
38=5
39=E
41=1401071547220023
44=132.35
54=1
55=LE
60=20140107-16:07:50
150=E
151=2
200=201412
461=FXXXXS
10=117


<Order server then sends a pending replace ex rep for the ClOrderId 1401071547220023 but the order 202867343 has actually been filled (tag 150=F (filled) tag 151=0 (remaining quantity of zero)). >

8=FIX.4.4
9=234
35=8
34=93
49=OEC_TEST
52=20140107-16:07:50.783
56=MHall4001
1=API002218
6=132.350
11=1401071547220023
14=5
17=5223804
31=132.350
32=2
37=202867343
38=5
39=E
44=132.35
54=1
55=LE
60=20140107-16:07:50
150=F
151=0
200=201412
461=FXXXXS
10=056


<Order server then sends an order cancel reject for ClOrderIdr 1401071547220024 as the order 202867343 to which the ClOrderId has been filled>

8=FIX.4.4
9=171
35=9
34=94
49=OEC_TEST
52=20140107-16:07:50.799
56=MHall4001
11=1401071547220024
37=202867343
39=2
41=1401071547220023
58=Order Completed
60=20140107-16:07:50
102=2
434=2
10=192


<Order server then sends details of execution for ClOrderId 1401071547220023>
8=FIX.4.4
9=241
35=8
34=95
49=OEC_TEST
52=20140107-16:07:50.799
56=MHall4001
1=API002218
6=132.350
11=1401071547220023
14=5
17=OECFIX:635245560331309946:1388
37=202867343
38=5
39=B
44=132.35
54=1
55=LE
60=20140107-16:07:50
150=B
151=0
200=201412
461=FXXXXS
10=173


<So far so good. But now one would expect the other leg of the OSO to go from status 9 (Suspended), through statuses , A, 0 and 2 as it is a market order. But no. There is no further communication from the order server. Order 202867344 has been lost.

Edited by MHall4001 on Jan 8, 2014 at 05:19:16

Posted: Jan 08, 2014 @ 05:32 AM             Msg. 2 of 5

After some further searching through the Fix logs I discovered what is happening. The order server does process the second leg of the OSO but the Execution reports it sends out change the ClOrdID to a server derived value - that looks like a new order number for the server and it adds an extra tag (12073) which contains the ClOrdID. This isn't in my FIX DD so I reject the message (This tag isn't in your API doc either!).

Can you put the ClOrdID in the ClOrdID field and the server's additional order number in the 12073 tag?
Fix messages:
Exec reports...
8=FIX.4.4
9=241
35=8
34=96
49=OEC_TEST
52=20140107-16:07:50.799
56=MHall4001
1=API002218
6=0.000
11=OECFIX:202867371
14=0
17=5223806
37=202867344
38=3
39=0
54=2
55=LE
60=20140107-16:07:50
150=0
151=3
200=201406
325=Y
377=N
461=FXXXXS
12073=1401071547220001
10=102


8=FIX.4.4
9=259
35=8
34=97
49=OEC_TEST
52=20140107-16:07:50.799
56=MHall4001
1=API002218
6=129.925
11=OECFIX:202867371
14=3
17=5223807
31=129.925
32=3
37=202867344
38=3
39=E
54=2
55=LE
60=20140107-16:07:50
150=F
151=0
200=201406
325=Y
377=N
461=FXXXXS
12073=1401071547220001
10=250


8=FIX.4.4
9=280
35=8
34=98
49=OEC_TEST
52=20140107-16:07:50.799
56=MHall4001
1=API002218
6=129.925
11=OECFIX:202867373
14=3
17=OECFIX:635245560331309946:1389
37=202867344
38=5
39=1
54=2
55=LE
60=20140107-16:07:50
150=5
151=2
198=202867373
200=201406
325=Y
377=N
461=FXXXXS
12073=1401071547220001
10=240


Rejects...
8=FIX.4.4
9=129
35=3
34=119
49=MHall4001
52=20140107-16:07:49.556
56=OEC_TEST
45=96
58=Tag not defined for this message type
371=325
372=8
373=2
10=125


8=FIX.4.4
9=129
35=3
34=120
49=MHall4001
52=20140107-16:07:49.558
56=OEC_TEST
45=97
58=Tag not defined for this message type
371=325
372=8
373=2
10=120


8=FIX.4.4
9=129
35=3
34=121
49=MHall4001
52=20140107-16:07:49.559
56=OEC_TEST
45=98
58=Tag not defined for this message type
371=325
372=8
373=2
10=123

---

Michael Hall

Posted: Jan 08, 2014 @ 09:48 AM             Msg. 3 of 5

On activation process an order are changing it's ClOrderID. For such cases you may check: UnsolicitedIndicator(325)=Y, SolicitedFlag(377)=N and LastSolicitedClOrdID(12073) custom field which is a reference to the original ClOrdID.
OrderID remains same.

We will update FIX API documentation shortly.

---

Vitaliy Pfau

Posted: Jan 08, 2014 @ 10:53 AM             Msg. 4 of 5

Thank you for your quick response. I understand what you're saying but I still think that only the client side should update the ClOrdId (Cl stands for Client) which how it works in other circumstances. But I can work around this.

Also while you're updating the documentation on OSOs you might want to change the part that says "OCO/OSO orders are sent using NewOrderList(MsgType=E) message, that's a set of orders is sent as a single
message, but processing of the orders is performed for each individual order. That means, if for example, one of list
orders is incorrect then all orders in the list will be rejected and for each order ExecutionReport message will be
responded." Currently if the first order in the list is incorrect and is rejected the next order in the list has a status of SUSPENDED. See Fix messages below:
8=FIX.4.4
9=335
35=E
34=2
49=MHall4001
52=20140108-15:37:34.286
56=OEC_TEST
66=OSO Order 2 Legs
68=2
69=OSO
394=3
73=2
11=1401081537210001
67=1
1=API002218
55=LE
461=FXXXXS
200=201412
54=1
60=20140108-15:37:34.276
38=1
40=2
44=132.175
11=1401081537210002
67=2
1=API002218
55=LE
461=FXXXXS
200=201406
54=2
60=20140108-15:37:34.276
38=1
40=1
44=132.175
10=075

8=FIX.4.4
9=239
35=8
34=2
49=OEC_TEST
52=20140108-15:37:45.990
56=MHall4001
1=API002218
6=0.000
11=1401081537210001
14=0
17=OECFIX:635245560331309946:2239
37=202868347
38=1
39=A
44=132.175
54=1
55=LE
60=20140108-15:37:45
150=A
151=0
200=201412
461=FXXXXS
10=055

8=FIX.4.4
9=239
35=8
34=3
49=OEC_TEST
52=20140108-15:37:45.990
56=MHall4001
1=API002218
6=0.000
11=1401081537210002
14=0
17=OECFIX:635245560331309946:2240
37=202868348
38=1
39=A
44=132.175
54=2
55=LE
60=20140108-15:37:45
150=A
151=0
200=201406
461=FXXXXS
10=054

202868348 status = SENT
8=FIX.4.4
9=242
35=8
34=4
49=OEC_TEST
52=20140108-15:37:45.990
56=MHall4001
1=API002218
6=0
11=1401081537210001
14=0
17=5225491
37=202868347
38=1
39=8
44=132.175
54=1
55=LE
58=Order breaks limits.
60=20140108-15:37:45
103=0
150=8
151=1
200=201412
461=FXXXXS
10=069

8=FIX.4.4
9=232
35=8
34=5
49=OEC_TEST
52=20140108-15:37:46.005
56=MHall4001
1=API002218
6=0.000
11=1401081537210002
14=0
17=5225492
37=202868348
38=1
39=9
44=132.175
54=2
55=LE
58=Auto-Execute
60=20140108-15:37:45
150=9
151=1
200=201406
461=FXXXXS
10=035

---

Michael Hall

Posted: Jan 08, 2014 @ 11:25 AM             Msg. 5 of 5

In case of OSO's reject the second order became SUSPENDED and CANCELED.

You rejected the Cancel status FIX message. See the log:

8=FIX.4.4|9=230|35=8|34=5|49=OEC_TEST|52=20140108-16:07:42.908|56=MHall4001|1=API002218|6=0.000|11=1401081607230002|14=0|17=5225497|37=202868351|38=1|39=9|44=132.1|54=2|55=LE|58=Auto-Execute|60=20140108-16:07:42|150=9|151=1|200=201406|461=FXXXXS|10=181|
8=FIX.4.4|9=310|35=8|34=6|49=OEC_TEST|52=20140108-16:07:42.924|56=MHall4001|1=API002218|6=0.000|11=OECFIX:202868352|14=0|17=OECFIX:635245560331309946:2244|37=202868351|38=1|39=4|41=1401081607230002|44=132.1|54=2|55=LE|58=Auto-cancelled|60=20140108-16:07:42|150=4|151=1|200=201406|325=Y|377=N|461=FXXXXS|12073=1401081607230002|10=210|
8=FIX.4.4|9=126|35=3|34=3|49=MHall4001|52=20140108-16:07:41.224|56=OEC_TEST|45=6|58=Tag not defined for this message type|371=325|372=8|373=2|10=202|

---

Vitaliy Pfau