Orders accepted and cancelled right away

Back to topics list To post a new topic, please log in or register
avatar
49
gadget 2015.01.26 17:12
 
I am encountering the following problem while trading with Oanda through MT4 using an MQL4 EA. Now after 3 days of error tracing, debugging, monitoring, watching prices live, re-reading all the MQL book etc... my modest brain is near burning out due to effort plus frustration.

Pointless to use the broker's support, as nowadays retail brokers only have salesmen as point of contacts.

It's a trend detection agent that I have modified, to use Buy Limit and Sell Limit orders instead of straight Buys and Sells. I've been running it on several currency pairs with a Test account to validate it.

The issue is that most of the pending orders that the agent sends to the broker are closed by the broker right away (within milliseconds). The EA would keep trying ordering and the broker would keep closing, which also causes thousands of tickets being created. An EA that generates lots of orders but not very useful ones! ;)

Example of this as in attached screenshot of transactions

1) the order has been sent and is accepted

2) right after, it is cancelled, but not by me!


Sometimes however.... the order is at last not closed and then converted to a market one.

The values passed to OrderSend are calculated as follows (I am giving rules for Buy Limits).

- Price:

buyPrice = High[3] + MarketInfo (Symbol(), MODE_TICKSIZE) * getPointValue() * DistanceMultiplier;
minPrice = Ask + MarketInfo (Symbol(), MODE_STOPLEVEL) * getPointValue ();
if (buyPrice < minPrice) { // for a buy-stop order, minimum buy price must always be >= Ask + minimum distance
    Print ("Buy price corrected");
    buyPrice = minPrice;
}


Which means that the buy price target is the High 3 candles ago, plus 1 tick.
getPointValue() returns the point's precision, e.g. 0.00001 for a symbol quoted with 5 digits, i.e. value of smallest market movement.
DistanceMultiplier is just a parameter to magnify the distance, currently 1.
Anyway, if the desired price is lower than the minimum price to be accepted by the broker, it is set to this minimum price.

- SL:

SL = Low[3] - MarketInfo (Symbol(), MODE_TICKSIZE) * getPointValue();
maxSLPrice = buyPrice - MarketInfo (Symbol(), MODE_STOPLEVEL) * getPointValue () ;
if (SL > maxSLPrice) {
    Print ("Stop Loss corrected");
    SL = maxSLPrice;
}


Which means that the SL price is set to the Low 3 candles ago, minus 1 tick.
Anyway, the SL price should be as a maximum the acceptable price from the broker.

- TP: none (it is managed manually as a system rule)

OrderSend carries a minimum slippage of 1 point (since I believe it should be fulfilled whenever the market price reaches the asked price), and a timeout of 30 minutes.

Before you ask, I catch all OrderSend's errors and there's no 103 error, in fact there's never any error so Oanda always accepts the order.

The log never contain any of the above correction messages.

I tried removing the SL which didn't make any difference, which suggest the problem is with the price.

However the prices shown on the above transactions seem all right, and the orders would not be accepted if the price wasn't in an acceptable range.

Would someone have an idea!?

avatar
13006
WHRoeder 2015.01.26 18:30 #
 
I'd guess, you're using a US broker and opposite pending orders. No hedging rules dictate when one order opens the opposite must be canceled.
avatar
49
gadget 2015.01.26 20:08 #
 

Thanks WHR, but no I'm not in the US, I'm in the UK. My broker doesn't allow hedging, and my trading system doesn't consider hedging anyway.

The agent uses long term indicators to find long term trends, so you wouldn't expect an EA decision to say Buy and Sell like a "yo-yo".

avatar
Moderator
3419
GumRai 2015.01.27 00:13 #
 

You are trading pairs with relatively low liquidity and many brokers have fluctuating spreads and jumps in prices from one tick to the next.

Is it actually possible that the broker is respecting the slippage that you set? 

avatar
Moderator
3206
angevoyageur 2015.01.27 00:52 #
 
gadget:
...

It's a trend detection agent that I have modified, to use Buy Limit and Sell Limit orders instead of straight Buys and Sells. I've been running it on several currency pairs with a Test account to validate it.

What you show us is Buy Stop and Sell stop, not limit orders.

The issue is that most of the pending orders that the agent sends to the broker are closed by the broker right away (within milliseconds). The EA would keep trying ordering and the broker would keep closing, which also causes thousands of tickets being created. An EA that generates lots of orders but not very useful ones! ;)
....
It seems your USDSEK are all cancelled after 10 seconds, don't you set an expiration time ?
avatar
49
gadget 2015.01.27 14:32 #
 
GumRai:

You are trading pairs with relatively low liquidity and many brokers have fluctuating spreads and jumps in prices from one tick to the next.

Is it actually possible that the broker is respecting the slippage that you set? 

In fact, the slippage is supposed not to be processed for stop orders as per MQL documentation, it is ignored.
avatar
49
gadget 2015.01.27 14:47 #
 
angevoyageur:
What you show us is Buy Stop and Sell stop, not limit orders.

It seems your USDSEK are all cancelled after 10 seconds, don't you set an expiration time ?

My apologies for the terminology error. I indeed pass Buy Stops and Sell Stops. I think my brain was nearer burn out than what I thought...

The expiration time is set to 30 minutes.


Thanks both for your replies.

Yesterday after analysing samples of operations and comparing to MT figures, I had an idea... I came from the comment on fluctuating prices from GumRai, even if it's not the source of the problem. I modified the above script to always set a SL to the tighest possible. So basically when it's a Buy Stop, the asked price takes:

Ask + MarketInfo (Symbol(), MODE_STOPLEVEL) * getPointValue ()

Which is I believe the tightest thing a broker can offer, right? Since it uses the minimum distance.

Can you believe that now:

a) the pending orders and not moved to the "Order Cancelled" status anymore!

b) however, from time to time the order is automatically closed as "Order Cancelled (BV:SL)" !!

Welcome to the fabulous world of modern Retail Forex Brokers. A recent history of transparency, truthworthyness.



avatar
1211
deysmacro 2015.01.27 14:57 #
 
It is actually how you do the coding for the logic. Nothing more nothing less.
avatar
49
gadget 2015.01.28 15:26 #
 

I would hardly imagine a simpler coding for a simpler logic.

When the price sent with the Buy Stop order is Ask + minimum distance, the broker always takes it. When the price sent with the order was Ask + more than minimum distance, then most of the time the broker was closing the order, with a Close Trade transaction (meaning "You closed a trade." as per Oanda's specifications). From that the conclusion, nothing more nothing less.

avatar
1211
deysmacro 2015.01.28 17:38 #
 
Well, ever try other broker? Sometimes it is always broker specific event. So, different broker different results, every time.
avatar
49
gadget 2015.02.06 11:52 #
 
deysmacro:
Well, ever try other broker? Sometimes it is always broker specific event. So, different broker different results, every time.

Deysmacro, sorry my last response was slightly unpleasant. I am sorry. You are right, trying with a different broker is wise.

Around 6 months ago I tried several including Alpari, FXCM, FXCC (and lots of FX-something!), I was applying the same system (i.e. the full set of experts, instruments, hours etc etc) and was getting quite different results, both in terms of market entries and balances. One factor to the balance was the actual spread, the observed one being sometimes quite different from the one advertised by the salesman (including when I was actualling speaking to the Alpari salesman and comparing with the real data!).

As I didn't find better I stayed with Oanda.

The next step however will be an ECN one....

Back to topics list  

To add comments, please log in or register