 Posted 1/25/2009 03:51:15
|
|
|
|
A quick question. What would happen in the following scenario:
1. Buy Limit order placed with broker and RightEdge is waiting to submit the stop-loss order as soon as the limit is filled.
2. Internet connection goes down (or machine crashes).
3. Limit order is filled at broker.
4. Price drops below the stop-price (although no stop-order has been submitted because connection has been down).
5. Internet connection restored. RightEdge is notified of limit order fill.
Would RightEdge now try to submit the old stop-loss order or would it recognize that price is now below stop-loss price and instead close the order? If it tries to do the former, the stop-loss order might be rejected because it is above the current market price.
|
|
|
Posted 1/25/2009 05:04:36
|
|
|
|
Hi Freload,
I'm currently trying to work out how to deal with this very issue. I have a high frequency system that occasionally has stops/targets rejected due to fast market conditions pushing the price out of range during the lag time between the limit fill (or a stop/target cancel) and stop/target (re)submission. I don't know if RE's behavior would be different when a disconnect / reconnect is involved, but I would guess it's the same.
I've just started testing this so I may be incorrect, but the real difficulty is that SetStopLoss() / SetProfitTarget() don't appear to fire the OrderUpdated event in the case of a rejection. If I can figure out how to trap the rejection, then at least some logic could be coded in the trading system to recover from the error.
I think your comment 'Update limit orders without canceling them first' in the suggestion box is a great one. Eliminating the time delay between order actions would remove the exposure risk altogether, as well as the need for a trading system to cope with the error.
Cheers!
Mark
|
|
|
|