Given the fairly low quality of their docs and support, there's a possibility that I don't have their latest package, or functionality may have changed, etc. We just funded our Live account, so we can probably request/demand a little bit more support attention toward the end of this migration development. On another subject, maybe there are some web protocol API possibilities or messages, which are not in the Java API and which we might be able to implement to do what you're suggesting. Anything's possible I guess, but I appreciate your expertise and willingness to lend a hand. I'm trying to avoid right now having to get to grips with FIX, as my experience so far indicates the Java API will be just fine for our needs right now. HyperScalper
Well, thanks. The Java API provide us with 5 levels of DOM either side of the market, and that's just fine. It's true that FIX would provide more levels but, for our needs, 5 levels is enough and the update rates are also fine for our needs right now. HyperScalper
Ok, here my finds: You were right, indeed there is no way to modify the limit price of an already submitted order. Limitation on LMAX's side I would say. At least the Java and .Net APIs both have this limitation. FIX of course will let you do a modify with one message but you asked for the Java API. Workaround: You submit your original limit order with your own custom ID. You then get back a confirm with your own ID plus LMAX's generated order ID. You store in a lookup table. You then cancel and re-submit the same order with changed limit price using the Lmax Order ID so that LMAX can identify which order you want to cancel. Make sure you update the Order ID after you get a confirm after the re-submit (map newly generated LMAX order ID to your original custom ID). You need to of course be careful in case you got a partial fill (mostly applicable for larger order sizes, but entirely valid consideration given LMAX's Retail order book is not very liquid), so that you do not resubmit the original order size but only the unfilled portion with adjusted limit price. Hope this helps. Actually I would strongly recommend to write a base class and interfaces that handle all that because most likely you will encounter the same at most other brokers. The interfaces and should expose basic functionality such as SubmitMarketOrder, SubmitLimitOrder, SubmitStopOrder, ModifyLimitOrder, CancelOrder, CancelAllOrders, .... You will see that if you develop several APIs this will be much better than your current approach, which seems to want to model things the Dukascopy way. Hope this helps. Do you mind PM me to chat a bit about your experience with Dukascopy? I am very interested in hearing about your fill quality, slippage, liquidity. I am happy to provide more details for LMAX in exchange. Thanks!
Thanks, man for confirming. Yep, I have "extremely advanced logic" like that. As far as Dukascopy is concerned, there is no better brokerage for strictly RETAIL trading. There is no slippage, repeat no slippage at Dukascopy, and facilities for controlling precision trading in the form of Strategies, is unrivalled. However, their promised liquidity inside the spread (for those of us who want it) is a not very funny joke..... HyperScalper
ok, what levels are we talking? Could you give some indications for EUR, AUD, GBP, and maybe some yen crosses during average typical trading hours for the top of the book (tightest spread)? How much is there to take?
Hey Volpunter, we don't have the results yet. But it will be highly dependent upon the technique used. In our case, we use an "incremental trading" approach where we will be continuously and persistently seeking "nibbles" on either side of the market. Results to come soon-ish. HyperScalper.
Apologies, still no results, but very early preliminary functionality illustrated by the uploaded chart. This is only illustrative of a particular micro scalping trading style, among many other possibilities, of course. This is shown only on a DEMO account so Price activity does not reflect a LIVE account, and DEMO fills are strictly RETAIL fills. Again, this is strictly preliminary, proof of concept. Coming soon will be the actual liquidity data, early next week. HyperScalper
Well I suppose you will fail with that strategy on demo. Inferior meaning is given to spreads, execution and other real trading features that change results substancially..
you mentioned you funded a real account. Executing and gauging true liquidity is very different from peeking at displayed size in a demo account. Any interesting findings or still in demo mode?