
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Metatrader has a significant limitation, you cannot place a limit at a price worse than the current price. This prevents many strategies from being implemented in Metatrader.
For example, you want to be able to sell when the Bid price reaches a price level, but with a negative slippage not exceeding N pips. This is very necessary when there is not enough volume at the best price to fill the volume you need, but it is necessary to execute, because the strategy logic is so set up (in the tester, for example).
In that case, as soon as the Bid price you need appears, you set the SellLimit at the Bid-N price, i.e. by N pips worse than the current price. By doing so, you will get a larger filling of your limit at the weighted average price, the worst of which will not be less than N pips from the current Bid price.
This is actually an archival thing. And competent brokers have such conditional limit orders with an additional parameter - the worst price among those forming the weighted average price. Such conditional limits are not able to worsen the broker's execution speed, because they are stored in the same table as the classic limits.
Read more carefully: on pure ECN and ECN/STP.
Reject and positive limit slippage:
On STP, your limit order will be sent if the price from it is better or equal to the limit order. Moreover, while your order is going to STP, the price can change in any direction: still improve (positive slippage), go out of the limit area (re-jct).
There are many stakes: internal (ECN) and external (each connected liquidity provider). There is no common betting market.
Some brokers make so called snapshots to more or less guarantee the execution of limiters without redirecting them. For example, a price only gets into the feed if it is available from three liquidity providers at once.
Also, ECNs have almost nothing to do with DCs, they are not dealing. Transparent brokers return positive slippage to the trader. Moreover, if you put a limit at a price worse than the current one, there will always be a positive slippage. And it would be quite unseemly if the broker did not give it back. There are, of course, some brokers who will only give part of the positive slippage. But it is better to stay away from them.
There are many stakes: internal (ECN) and external (each connected liquidity provider). There is no common rate book.
Thank you. Then why can't the aggregators aggregate all the providers into one common "own" cup, picking only the best price? Isn't that what they do?
You seem to see some tricky market laws, when in fact everything is very simple.
When they say that a brokerage house is not market-oriented it is almost a lie. If a brokerage company executes almost no positions - this does not mean that it is not engaged in market activities. It is not so.
Not to withdraw and keep risks on your own, while still being market maker, or to withdraw - all this is the market. Both schemes are used by virtually all offices, from small retailers to large institutional ones.
An aggregator is simply an aggregation of trading conditions by someone at a number of offices at the same time. Usually these companies do not even know that someone is aggregating them somewhere. For example, you can easily combine many brokers on Metatrader using MQL+WinAPI. You will have a kind of a marketplace. But the problem will be that brokers themselves are not clients of this your system. They do not send orders to your market, but you form a virtual marketplace for your own needs - either for trading or for broking.
Therefore, the real ECN market may be not a virtual marketplace (STP), but a real marketplace only from those orders that are sent to it. In case of broker it can be only own clients' orders, which are not so many.
There are advantages and disadvantages. For example, the advantage is that nobody from the outside world sees your Limits. Therefore your strategy cannot be understood and manipulated. And your limits are in the pile of other clients' limits, so there is nothing to see on the outside world.
hrenfx:
This has advantages and disadvantages. On the plus side, for example, no one from the outside world can see your pre-set limiters. Consequently, no one can figure out your strategy to manipulate you. In addition, your limits are in the pile of other clients' limits, so there is nothing to see on the outside world.
Still, from this explanation I don't understand the next point about the liquidity aggregator, no matter who it is. Suppose there are several liquidity providers with their own stakes, which I want to merge in my house as a new aggregator. To make this merging fully equivalent without worsening of market conditions with an error of access time to the external market stack, which is a fraction of a second, then apparently it is enough only to merge the stacks to a sufficient depth, and the limiters and generally any pending orders, which are in external stacks, will automatically appear in external stack and as a consequence, in internal, merged stack because the pending orders and form any stack.
But since the pending orders are usually set in advance, i.e. much longer than the time of binding between the glasses, there can't be any forecasting here in principle, because they are all already aggregated in the internal glass from the external one.
Roughly, the scheme is as follows:
As a result, in the ECN/STP scheme there are more favourable prices due to internal ECN and benefit from double commission to the broker, and there are more favourable prices when aggregating (STP) multiple liquidity providers, while giving the possibility to camouflage your strategy to them and potential positive slippage (and redirects).
P.S. For the sake of interest, you can try writing your own MT aggregator. It's really very simple. But when you start trading through it, you will see a huge number of pitfalls, which in the rough scheme above, of course, are not specified.
Roughly the scheme is as follows
Thank you for the scheme, but there are still questions that have been raised before.
1. is this the only scheme to implement the aggregation scheme?
2. Why is it impossible to aggregate the tumblers into a single tumbler as I described? After all, in it the interaction with an external stack is continuous to form a single stack, not only at the time of request triggering, which introduces an unnecessary delay that must inevitably worsen the conditions of execution? Moreover, according to your scheme, there is no difference between a pending order and a market order, as everything is executed only at the last moment and it makes no sense to send a pending order in advance, because it will get into the external market only at the very last moment.
1. is this the only scheme to implement an aggregation scheme?
Roughly, yes.
2. Why is it impossible to implement the aggregation scheme I described?
Because all liquidity providers have to become clients of your ECN-system. There is such a broker - LMAX. It is practically a pure ECN (MTF-bearer), in it the liquidity providers are clients of the created system. I.e. there are some kind of agreements signed with some banks that they accept such conditions. I already mentioned LastLook above, besides that there are other reasons why many banks do not go for such terms.
After all, in it, the interaction with the external betting market takes place continuously to form a single betting market, not just at the moment the order is triggered, which introduces an unnecessary lag that should inevitably worsen the terms of execution?
Yes, there is no guaranteed execution with aggregation. There are various ways to improve execution through snapshots (filter), but this is one side of the coin. The pros of aggregation have already been voiced many times above.
Moreover, according to your scheme, there is no difference between a pending order and a market order, because everything is executed only at the last moment and it makes no sense to send a pending order in advance, because it will get to the outer glass only at the very last moment.