| FIX Support » Price Conversion in ZC fill prices Jul 07, 2015 @ 11:27 AM (Total replies: 3) | |||||
|
Currently, ZCU15 is trading around 418. However, when I get filled in the market, the average trade price is 4.18. I see there's a field PriceFormat in the instrument block that would tell me to modify the price to the correct 418, but I'm not seeing it in the Execution Reports. How should I be handling this? Jeremy Jongsma |
|||||
| FIX Support » GTD order being converted to GTC in api gateway Mar 30, 2015 @ 11:35 AM (Total replies: 1) | |||||
|
When we enter in an order with GTD as the time in force, we get normal confirmation. But when we restart and are rebuilding our order state, the order is turned into a GTC. Not sure if this is a behavior specific to the api gateway. Is this intended behavior? Thanks Jeremy Jongsma |
|||||
| FIX Support » Fix fields 40 (OrdType) and 59 (TimeInForce) missing data Mar 24, 2015 @ 03:54 PM (Total replies: 1) | |||||
|
I'm reviewing the addition of the new FIX fields on the api gateway and I'm seeing the following: 8=FIX.4.4|9=244|35=8|34=14|49=OEC_TEST|52=20150324-19:42:04.145|56=JJongsma|1=API002527|6=0.00|11=b6c49d98-65ec-4506-8f62-35b26aae06b8~0|14=0|17=5618522|37=203131684|38=1|39=0|40=|44=2085.5|54=1|55=ES|59=|60=20150324-19:42:04|150=0|151=1|200=201506|461=FXXXXX|10=080| This is breaking the parser but I was able to grab the whole message from Wireshark. Fix fields 40 (OrdType) and 59 (TimeInForce) missing data. Note this is only for live Execution Reports. The fields are present and correct in the status messages I receive for the orders. Jeremy Jongsma |
|||||
| FIX Support » PegOffsetValue, Trailing order instructions Mar 04, 2015 @ 05:14 PM (Total replies: 7) | |||||
|
Thanks Evgeny, follow up question: If I have a live Iceberg order and I send an OrderStatusRequest, will the status message contain the MaxFloor field, so I can rebuild the order? Also, I assume that since I don't see the 211 PegOffsetValue field in ExecutionReport, that I won't have that info from an OrderStatusRequest as well. Can you confirm that? Thanks Jeremy Jongsma |
|||||
| FIX Support » PegOffsetValue, Trailing order instructions Mar 04, 2015 @ 02:34 PM (Total replies: 7) | |||||
|
Ok, thanks Evgeny. Where in the documentation is this outlined? Jeremy Jongsma |
|||||
| FIX Support » PegOffsetValue, Trailing order instructions Mar 04, 2015 @ 01:45 PM (Total replies: 7) | |||||
|
In our conformance test, we're asked to demonstrate our ability to submit both Trailing Stop Limit and Trailing Stop Loss orders, so I'm confused at your reply. The document says we need those fields to submit those order types, so do you not support those order types? I assume I'm missing something, just not sure how to connect the dots. Jeremy Jongsma |
|||||
| FIX Support » PegOffsetValue, Trailing order instructions Mar 04, 2015 @ 11:39 AM (Total replies: 7) | |||||
|
We're adding in the OEC supported order instructions to our application and had a few questions about fields. In this document: http://futures.gaincapital.com/includes/pdf/FIX.pdf at the bottom of page 7 3 fields are referenced, PegOffsetValue(211), TrailingAmountInPercents(12001), and TrailingTriggerType(12002). However in the spec online, in the NewOrderSingle message only has reference to the PegOffsetValue field. Are the other 2 fields not used in submitting a TrailingStopLimit and TrailingStopLoss orders? Also, if I place one of these orders, can I expect to see these fields in a ExecutionReport type status as a response to an OrderStatusRequest? Thanks for your help Jeremy Jongsma |
|||||
| FIX Support » Invalid username / password message? Feb 24, 2015 @ 01:45 PM (Total replies: 1) | |||||
|
One of the conformance test requirements is to show the user a message informing them of an invalid username or password on invalid login. However, when I attempt to connect with either, I'm initially connected, then disconnected without any messages from the gateway. Should I be seeing some kind of reject message with a description of the issue? Thanks Jeremy Jongsma |
|||||
| FIX Support » Stop Limit Order Entry Rejection Feb 23, 2015 @ 12:12 PM (Total replies: 1) | |||||
|
I'm attempting to place a stop limit order and getting rejected. I'm unsure what the error message means, Stop price maxi-mini must be >= trigger price. Here is my new order request: Type : D 11 : 2c5583dd-ed95-4291-bddc-934fc65a9002~0 1 : API002527 55 : ES 461 : FXXXXX 200 : 201503 54 : 1 60 : 20150223-11:56:40.615 38 : 1 40 : 4 44 : 2105.25 99 : 2107.25 59 : 0 And the OEC rejection: Type : 8 9 : 300 52 : 1424710603494 1 : API002527 6 : 0 11 : 2c5583dd-ed95-4291-bddc-934fc65a9002~0 14 : 0 17 : 5584022 37 : 203103405 38 : 1 39 : 8 44 : 2105.25 54 : 1 55 : ES 58 : Stop price maxi-mini must be >= trigger price 60 : 1424710603000 99 : 2107.25 103 : 0 150 : 8 151 : 1 200 : 201503 461 : FXXXXX Thank you for the help Jeremy Jongsma |
|||||
| FIX Support » OrderMassStatusRequest Feb 10, 2015 @ 10:40 AM (Total replies: 5) | |||||
|
Yes Evgeny, I've been looking at the execution reports. Both the ExecutionReports I see back from the gateway as well as the example from your docs I pasted above are missing the OrdType and TimeInForce fields. My question is if there's a way to get that info for an order, as it doesn't seem to be present in the Execution Report. Jeremy Jongsma |
|||||
| FIX Support » OrderMassStatusRequest Feb 09, 2015 @ 12:01 PM (Total replies: 5) | |||||
|
Thanks for the help Evgeny So when we send an OrderStatusRequest, is the status message guaranteed to have the order type and time in force? It seems odd that this info isn't in the original status execution report sent for the order from the mass order status request. In the example on your documentation site the responding status execution report is missing these fields as well. Request: 8=FIX.4.4|9=118|35=H|34=295|49=username|52=20140317-01:29:46|56=OEC_TEST|1=YRACCNT|11=635306165855435241|54=1|55=ES|200=201403|461=FXXXXS|10=055| Response: 8=FIX.4.4|9=226|35=8|34=299|49=OEC_TEST|52=20140317-01:29:45.068|56=username|1=YRACCNT|6=1841.00|11=635306165855435241|14=1|17=OECFIX:635305924334768863:825|37=202904994|38=1|39=B|54=1|55=ES|60=20140317-01:29:45|150=I|151=0|200=201403|461=FXXXXS|10=057| Thanks for your help Jeremy Jongsma Edited by JJongsma on Feb 9, 2015 at 12:07:27 |
|||||
| FIX Support » OrderMassStatusRequest Feb 05, 2015 @ 08:19 AM (Total replies: 5) | |||||
|
On start up we send an OrderMassStatusRequest to get the current order state. I am seeing 3 messages for each order, a Trade type, a Calculated type, and a Status type. My first question is how are these supposed to be interpreted. The Trade message has OrderStatus as filled, the other two have OrderStatus as Calculated. Is that the same as filled? Will there ever be any extra info in the Trade and Calculated messages or can I ignore them and just use the Status report to create the info for that order/fill. Also, none of these messages have OrderType, TimeInForce, and ExpireDate(assuming GTD). How am I supposed to get this info to recreate the order? Thanks Gavin Jeremy Jongsma |
|||||
| FIX Support » Question on OrderStatusRequest Oct 16, 2014 @ 04:03 PM (Total replies: 4) | |||||
|
Ahh, that link is also very useful. I was directed to a pdf entitled 'OEC FIX API Specification 11-06-13.pdf' where that message type is absent. Thanks again Jeremy Jongsma |
|||||
| FIX Support » Question on OrderStatusRequest Oct 16, 2014 @ 03:41 PM (Total replies: 4) | |||||
|
Cool, that's what I needed. Thanks for the help Note: that message isn't in your spec. Jeremy Jongsma |
|||||
| FIX Support » Question on OrderStatusRequest Oct 16, 2014 @ 02:54 PM (Total replies: 4) | |||||
|
On start up, our application will query the gateway to build the trader's order/position state. It seems like sending an OrderStatusRequest message is the way to get the live order statuses. However, the spec shows that an Instrument group is required, which makes it seem like we need to know what instruments the trader has orders in beforehand. How is this supposed to be handled? Thanks Jeremy Jongsma |
|||||