| FIX Support » Spread Execution report bugs May 15, 2017 @ 03:39 PM (Total replies: 4) | |||||
|
Also can you please let us know if we should always receive groups of 3 messages for every spread partial fill, or only 2 messages are sent for the individual legs? (since we're unable to test Iceberg at this point as you suggested see the previous message with the reject we're receiving), I understand that the order enters 39=B state when the whole quantity is filled, but shouldn't we receive any 150=F for each partial fill on the spread symbol with updated LeavesQty (tag 151 until it reaches 0)? |
|||||
| FIX Support » Spread Execution report bugs May 15, 2017 @ 09:52 AM (Total replies: 4) | |||||
|
Thank you. Indeed I confirm all the issues are now fixed. However looks like your simulated matching engine does not support Icebergs for spreads? It's accepted by your gateway as pending new, but rejected at exchange level. <- 8=FIX.4.4|9=181|35=D|34=174|49=PSturm|52=20170515-14:33:16.420|56=OEC_TEST|1=API003095| 11=CVS_88|38=4|40=2|44=-0.08|54=1|55=ZC FTS +N7,-U7|59=0|60=20170515-14:33:16.400| 111=2|200=201707|461=FMXXXN|10=209| -> 8=FIX.4.4|9=251|35=8|34=234|49=OEC_TEST|52=20170515-14:33:15|56=PSturm|1=API003095| 6=0.0000|11=CVS_88|14=0|17=OECFIX:204674902:156|37=204674902|38=4|39=A|40=2|44=-0.08|54=1| 55=ZC FTS +N7,-U7|59=0|60=20170515-14:33:15.325|111=2|150=A|151=4|200=201707|442=3| 461=FMXXXN|10=057| -> 8=FIX.4.4|9=293|35=8|34=235|49=OEC_TEST|52=20170515-14:33:15|56=PSturm|1=API003095| 6=0.0000|11=CVS_88|14=0|17=OECFIX:204674902:157|37=204674902|38=4|39=8|40=2|41=CVS_88| 44=-0.08|54=1|55=ZC FTS +N7,-U7|58=Unsupported order type|59=0|60=20170515-14:33:15.340|103=0| 111=2|150=8|151=4|200=201707|442=3|461=FMXXXN|10=254| Can you please advise? |
|||||
| FIX Support » Spread Execution report bugs Apr 26, 2017 @ 07:52 AM (Total replies: 4) | |||||
|
There's a couple of problems that we've come across while implementing support for your spread fills on your FIX API. Here is a sequence of Fix Messages for filling a BUY 1 ES FTS -M7,+U7 @MKT order: MESSAGE 1 -> 8=FIX.4.4|9=250|35=8|34=294|49=OEC_TEST|52=20170426-12:27:54|56=PSturm|1=API003095|6=0.00| 11=CVS_56|14=0|17=OECFIX:204630687:407|31=2383.75|32=1|37=204630687|38=1|39=2|40=1|54=2| 55=ES FTS -M7,+U7|59=0|60=20170426-12:27:54.208|150=F|151=1|200=201706|442=3|461=FMXXXN| 10=019| MESSAGE 2 -> 8=FIX.4.4|9=250|35=8|34=295|49=OEC_TEST|52=20170426-12:27:54|56=PSturm|1=API003095|6=0.00| 11=CVS_56|14=0|17=OECFIX:204630687:408|31=2381.25|32=1|37=204630687|38=1|39=0|40=1|54=1| 55=ES FTS -M7,+U7|59=0|60=20170426-12:27:54.224|150=F|151=1|200=201706|442=3|461=FMXXXN| 10=009| MESSAGE 3 -> 8=FIX.4.4|9=236|35=8|34=296|49=OEC_TEST|52=20170426-12:27:54|56=PSturm|1=API003095| 6=-2.50|11=CVS_56|14=1|17=OECFIX:204630687:409|37=204630687|38=1|39=B|40=1|54=1| 55=ES FTS -M7,+U7|59=0|60=20170426-12:27:54.224|150=B|151=-1|200=201706|442=3|461=FMXXXN| 10=166| MESSAGE1 + MESSAGE2 issues: * 14=0 => This cumulative quantity should be 1 for each of the legs, not 0. * 151=1 => LeavesQty should be 0 in this case, since legs are already filled * 39=2 seems correct for MESSAGE1, however 39=0 for MESSAGE2 seems off (means new order), should also be 39=2 (or for larger lots/partial fills 39=1) * 442=3 => seems incorrect should be 442=2, as far as we've discovered the first 2 messages are for individual legs (based on 31=2383.75 last price of ESM7) MESSAGE3 issues: * 151=-1 => LeavesQty should be 0 for filled order, not -1 Can you please advise? Should we ALWAYS expect 3 messages for any other partial fills on spread orders as well, and receive the last message only when the order is complete 150=B and 39=B? We tried to get partial fills in your demo environment but whatever large orders we placed we got an instant fill for the order, no partial fills. Please let us know if you confirm these problems with FIX tag values on your end? Edited by PSturm on Apr 26, 2017 07:53 AM |
|||||
| FIX Support » Front-month Eurodollars LMT/STP price modified in FIX ExecRpt Apr 18, 2017 @ 02:27 AM (Total replies: 5) | |||||
|
Thank you for the update. |
|||||
| FIX Support » 'Unknown Contract' for Packs/Bundles orders Apr 13, 2017 @ 02:28 PM (Total replies: 3) | |||||
|
Thanks Chris, now it makes sense why OEC GW returns that error for bundle/pack spreads. We will only implement support for FTS, FTSRTS and CS spreads at this point. Edited by PSturm on Apr 13, 2017 02:38 PM |
|||||
| FIX Support » Front-month Eurodollars LMT/STP price modified in FIX ExecRpt Apr 13, 2017 @ 02:11 PM (Total replies: 5) | |||||
|
Thanks Chris, What about the OEC FIX GW accepting the half-tick order and rounding it up to the nearest 0.005 tick? I think this order should be rejected with an invalid price in this case when it's not supported by OEC. Is this happening only in your demo environment, or would this also happen in a live-trading environment? It's a bit concerning us, because the price in the Execution report is also a valid price in this case, furthermore if you send over this price to CME's iLink GW, they would also accept it as a valid price. From the NewOrderSingle message it's clear that the client intended to enter a different price in this case and ended up with a working order 1 tick above his desired LMT price. Can you please give us an update/confirmation on this issue? Edited by PSturm on Apr 13, 2017 02:11 PM |
|||||
| User Interface » 'System Error: Too many requests' in OEC Trader Devel 3.5 Apr 13, 2017 @ 06:24 AM (Total replies: 0) | |||||
|
I'm running the latest OEC Trader Developer version 3.5.15.272. So far I encountered this problem serveral times: the GUI becomes unresponsive, and the only options is to kill the process from the task manager. Upon a restart and fresh login I'm encountering a bunch of 'System Error: Too many requests' errors, and nothing seems to work, nor can I receive any qoutes in GUI or initiate actions on my existing orders (quote boards are empty). After some time the problem seems to be fixed by itself. It happens to me almost on a daily basis. Multiple successive fresh logins to OEC trader don't seem to fix this problem either. Is this something you are aware of and that's being fixed? Let me know if you need further information or if I can provide you any client-side log files for fixing this issue. |
|||||
| FIX Support » Front-month Eurodollars LMT/STP price modified in FIX ExecRpt Apr 13, 2017 @ 06:03 AM (Total replies: 5) | |||||
|
We've just found a problem in your OECFIX demo environment: 8=FIX.4.4|9=166|35=D|34=3297|49=PSturm|52=20170413-09:56:37.982|56=OEC_TEST|1=API003095| 11=CVS_23|38=1|40=2|44=97.1075|54=1|55=GE|59=1|60=20170413-09:56:37.895| 200=201704|461=FXXXXS|10=224| 8=FIX.4.4|9=228|35=8|34=3374|49=OEC_TEST|52=20170413-09:56:37|56=PSturm|1=API003095|6=0.0000| 11=CVS_23|14=0|17=OECFIX:204553213:355|37=204553213|38=1|39=A|40=2|44=97.11|54=1|55=GE|59=1|60=20170413-09:56:37.418| 150=A|151=1|200=201704|461=FXXXXS|10=164| The price sent in our initial order is a correct/valid price as Eurodollars front-month is always trading in half-tick (0.0025 increments), but OEC GW is rounding the price up to the nearest full tick 0.005 (which is incorrect as you end up with an order at an incorrect LMT/STP price which doesn't match what the user requested). If your environment doesn't support trades in reduced ticks on the outright you should definitely reject the order with incorrect price message instead of modifying the requested limit price in the Execution report. Can you please fix this? Also noticed that I'm not allowed to place half-tick orders on GEJ4 symbol from within OEC Trader, as the price increments in 0.005 instead of 0.0025. Seems like the minimum tick on your GE symbol is incorrect there as well. |
|||||
| FIX Support » SecurityListRequest - MaxRecords tag not working Apr 13, 2017 @ 04:05 AM (Total replies: 3) | |||||
|
Thank you. |
|||||
| FIX Support » Legs order question in strategy symbols (tag-55) on FIX API Apr 12, 2017 @ 08:52 AM (Total replies: 0) | |||||
|
We've noticed there's no consistency for spread symbols within your API, in this case the legs are not listed in chronological order of their maturity or by respecting the leg/ratio formula CME lists for exchange recognized spread types. I was wondering if you accept the same legs listed in any order for a certain instrument? For example: Your symbol: GE PACK U7,Z7,M7,H8 Would this be the same ? GE PACK M7,U7,Z7,H8 (the logical order in which we expect these bundles to be written according to CME's specs), Is this: GE PACK H8,M7,U7,Z7 or any other combination of these 4 legs also accepted for the same spread? Also noticed that the order of legs for butterflies also varies by instrument OEC Trader, and we're trying to set up some rules for translating these spreads from our internal structures (which respects the legs order and ratio in CME's security definition messages) into OEC format, but we've encountered the following problem: GE FB -2 U7,+1 Z7,+1 M7 - ratio -2:+1:+1 GE FB +1 M7,+1 M9,-2 M8 - ratio +1:+1:-2 GE FB +1 U7,-2 H8,+1 U8 - ratio +1:-2:+1 (this is the formula for Futures Butterfly, what we would expect in all cases for any butterfly spread) Is this a bug in developer API, shall we expect this inconsistency in the production environment as well? Is this something that can be/will be fixed any time soon? Please advise. |
|||||
| FIX Support » 'Unknown Contract' for Packs/Bundles orders Apr 12, 2017 @ 08:41 AM (Total replies: 3) | |||||
|
Can you please let me know why the OEC server is rejecting the following order with 'Unknown contract' error message: OUT <- 8=FIX.4.4|9=182|35=D|34=2899|49=PSturm|52=20170412-11:58:40.210|56=OEC_TEST|1=API003095| 11=CVS_37|38=1|40=2|44=1.0075|54=2|55=GE PACK U7,Z7,M7,H8|59=0|60=20170412-11:58:40.193| 200=201706|461=FMXXXN|10=111| IN -> 8=FIX.4.4|9=271|35=8|34=2904|49=OEC_TEST|52=20170412-11:58:39|56=PSturm|1=API003095|6=0| 11=CVS_37|14=0|17=OECFIX:636273705020241625:178|37=NONE|38=0|39=8|40=2|44=1.0075|54=2| 55=GE PACK U7,Z7,M7,H8|58=Unknown contract|59=0|60=20170412-11:58:39.944|103=1| 150=8|151=0| 200=201706|461=FMXXXN|10=026| Checked, the symbol is the same in OEC trader, also placing orders on this spread from within OEC trader, and catching the Execution Report within my app contains the same tags that define the instrument : 55, 200 and 461 matches exactly what we are sending from our app. Here's the sample Exec rpt from our logfiles for an order that was placed from within OEC Trader: IN -> 8=FIX.4.4|9=288|35=8|34=2867|49=OEC_TEST|52=20170412-11:39:28|56=PSturm|1=API003095|6=0.0000| 11=OECFIX:204540666|14=0|17=OECFIX:204540666:176|37=204540666|38=1|39=0|40=2|44=-0.0125|54=1| 55=GE PACK U7,Z7,M7,H8|59=0|60=20170412-11:39:28.175|150=0|151=0| 200=201706|325=Y|377=N|432=99981231|442=3|461=FMXXXN|10=219| What are we missing here? Also noticed that on FIX you expect the spread symbols to be formatted with upper-case? A small note that in OEC trader the symbol are somewhat different, with mixed/camel case: 'GE Bundle' for example. Also in the Security list response containing all securities we're receiving 'GE Bundle' and 'GE Pack' as product simbols, not upper-case as it appears in the FIX messages. Please advise. |
|||||
| FIX Support » SecurityListRequest - MaxRecords tag not working Apr 12, 2017 @ 06:15 AM (Total replies: 3) | |||||
|
The MaxRecords tag available in the SecurityListRequest message does not seem to limit the number of security definitions that are returned in the response. In the example below, although the request is made with MaxRecords (tag 12051) set to 3, the response still lists all the instruments that match the search condition: 8=FIX.4.4|9=117|35=x|34=2|49=PSturm|52=20170406-08:52:05.044|56=OEC_TEST|55=ES FTS|58=ES FTS|320=SEARCH_ES FTS|559=2|12051=3|12052=1|10=063| 8=FIX.4.4|9=4179|35=y|34=2|49=OEC_TEST|52=20170406-08:52:04|56=PSturm|320=SEARCH_ES FTS|322=OECFIX:636267657038016901:1016|560=0|146=10| 55=ES FTS|461=FMXXXN|762=FutureTimeSpread|200=201706|228=50|207=CME|107=E-Mini S&P Future Time Spread|15=USD|555=2|600=ES|608=FXXXXS|610=201706|253=50|623=1|624=2|12061=ESM7|600=ES|608=FXXXXS|610=201709|253=50|623=1|624=1|12061=ESU7|126=20170616-21:29:00.000|341=00010101-22:00:00.000|344=00010101-21:15:00.000|345=00010101-21:15:00.000|969=0.05|12054=Indices|12055=0|12059=ES FTS -M7,+U7|12063=2|12071=06| 55=ES FTS|461=FMXXXN|762=FutureTimeSpread|200=201709|228=50|207=CME|107=E-Mini S&P Future Time Spread|15=USD|555=2|600=ES|608=FXXXXS|610=201709|253=50|623=1|624=2|12061=ESU7|600=ES|608=FXXXXS|610=201712|253=50|623=1|624=1|12061=ESZ7|126=20170915-21:29:00.000|341=00010101-22:00:00.000|344=00010101-21:15:00.000|345=00010101-21:15:00.000|969=0.05|12054=Indices|12055=0|12059=ES FTS -U7,+Z7|12063=2|12071=06| 55=ES FTS|461=FMXXXN|762=FutureTimeSpread|200=201706|228=50|207=CME|107=E-Mini S&P Future Time Spread|15=USD|555=2|600=ES|608=FXXXXS|610=201706|253=50|623=1|624=2|12061=ESM7|600=ES|608=FXXXXS|610=201712|253=50|623=1|624=1|12061=ESZ7|126=20170616-21:29:00.000|341=00010101-22:00:00.000|344=00010101-21:15:00.000|345=00010101-21:15:00.000|969=0.05|12054=Indices|12055=0|12059=ES FTS -M7,+Z7|12063=2|12071=06| 55=ES FTS|461=FMXXXN|762=FutureTimeSpread|200=201706|228=50|207=CME|107=E-Mini S&P Future Time Spread|15=USD|555=2|600=ES|608=FXXXXS|610=201706|253=50|623=1|624=2|12061=ESM7|600=ES|608=FXXXXS|610=201803|253=50|623=1|624=1|12061=ESH8|126=20170616-21:29:00.000|341=00010101-22:00:00.000|344=00010101-21:15:00.000|345=00010101-21:15:00.000|969=0.05|12054=Indices|12055=0|12059=ES FTS -M7,+H8|12063=2|12071=06| 55=ES FTS|461=FMXXXN|762=FutureTimeSpread|200=201712|228=50|207=CME|107=E-Mini S&P Future Time Spread|15=USD|555=2|600=ES|608=FXXXXS|610=201712|253=50|623=1|624=2|12061=ESZ7|600=ES|608=FXXXXS|610=201803|253=50|623=1|624=1|12061=ESH8|126=20171215-22:29:00.000|341=00010101-22:00:00.000|344=00010101-21:15:00.000|345=00010101-21:15:00.000|969=0.05|12054=Indices|12055=0|12059=ES FTS -Z7,+H8|12063=2|12071=06| 55=ES FTS|461=FMXXXN|762=FutureTimeSpread|200=201709|228=50|207=CME|107=E-Mini S&P Future Time Spread|15=USD|555=2|600=ES|608=FXXXXS|610=201709|253=50|623=1|624=2|12061=ESU7|600=ES|608=FXXXXS|610=201803|253=50|623=1|624=1|12061=ESH8|126=20170915-21:29:00.000|341=00010101-22:00:00.000|344=00010101-21:15:00.000|345=00010101-21:15:00.000|969=0.05|12054=Indices|12055=0|12059=ES FTS -U7,+H8|12063=2|12071=06| 55=ES FTS|461=FMXXXN|762=FutureTimeSpread|200=201709|228=50|207=CME|107=E-Mini S&P Future Time Spread|15=USD|555=2|600=ES|608=FXXXXS|610=201709|253=50|623=1|624=2|12061=ESU7|600=ES|608=FXXXXS|610=201806|253=50|623=1|624=1|12061=ESM8|126=20170915-21:29:00.000|341=00010101-22:00:00.000|344=00010101-21:15:00.000|345=00010101-21:15:00.000|969=0.05|12054=Indices|12055=0|12059=ES FTS -U7,+M8|12063=2|12071=06| 55=ES FTS|461=FMXXXN|762=FutureTimeSpread|200=201706|228=50|207=CME|107=E-Mini S&P Future Time Spread|15=USD|555=2|600=ES|608=FXXXXS|610=201706|253=50|623=1|624=2|12061=ESM7|600=ES|608=FXXXXS|610=201806|253=50|623=1|624=1|12061=ESM8|126=20170616-21:29:00.000|341=00010101-22:00:00.000|344=00010101-21:15:00.000|345=00010101-21:15:00.000|969=0.05|12054=Indices|12055=0|12059=ES FTS -M7,+M8|12063=2|12071=06| 55=ES FTS|461=FMXXXN|762=FutureTimeSpread|200=201803|228=50|207=CME|107=E-Mini S&P Future Time Spread|15=USD|555=2|600=ES|608=FXXXXS|610=201803|253=50|623=1|624=2|12061=ESH8|600=ES|608=FXXXXS|610=201806|253=50|623=1|624=1|12061=ESM8|126=20180316-21:29:00.000|341=00010101-22:00:00.000|344=00010101-21:15:00.000|345=00010101-21:15:00.000|969=0.05|12054=Indices|12055=0|12059=ES FTS -H8,+M8|12063=2|12071=06| 55=ES FTS|461=FMXXXN|762=FutureTimeSpread|200=201712|228=50|207=CME|107=E-Mini S&P Future Time Spread|15=USD|555=2|600=ES|608=FXXXXS|610=201712|253=50|623=1|624=2|12061=ESZ7|600=ES|608=FXXXXS|610=201806|253=50|623=1|624=1|12061=ESM8|126=20171215-22:29:00.000|341=00010101-22:00:00.000|344=00010101-21:15:00.000|345=00010101-21:15:00.000|969=0.05|12054=Indices|12055=0|12059=ES FTS -Z7,+M8|12063=2|12071=06| 10=193| |
|||||