Real work on MT5 NDD - page 10

 

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.

 
hrenfx:

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).

Thank you. But the following point is not clear. From your description it follows that ECN does not have a common internal and external market stack and the external market does not always have a limit slip and if it does it is at the last moment when the price can slip somewhere and it may even lead to a re-ject, even if the Limit order was sent by the trader beforehand and the price hit it correctly. Is this description really true, because it seems unlikely that the limit order sent in advance will not be executed because the ECN did not manage to place it in the general pool at the last moment. Even more surprising is the explanation about possible positive slippage at this moment, which the ECN will return to the trader.
 

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.

 
Developers: I wonder if we can count on the development of the platform in this regard (problems voiced in the thread, expansion of limiters, etc...)?
 
hrenfx:

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, selecting only the best price? Isn't that what they do?
 
Andrei01:
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:

  1. You place an order in advance, it goes into the internal marketplace from the orders of the clients of your ECN broker.
  2. Your broker, however, shows you the virtual stack = internal stack (ECN) + external stacks (STP).
  3. If the opposite order appears in the internal ECN, both are almost instantly guaranteed to be executed on volume min(Limit1, Limit2) (matched without any slippage), and the broker receives double commission (from each order).
  4. If a price that satisfies your order comes from the outside (for example from a third liquidity provider - LP3), then
  5. Your order is deleted (frozen) from the internal ECN-Stack.
  6. Sent to LP3 with a specific LiveTime (usually a few tens or hundreds of milliseconds).
  7. Your order, when received in LP3, usually comes at a worse price than the current price in LP3. Therefore, there will be a corresponding positive slippage.
  8. If your bid price is better than the current price at LP3 (it might have changed during the dispatch-delivery period), there will be a rebate if the LiveTime price is not satisfactory.
  9. Through LiveTime, the balance (in partial execution) of your order is removed from LP3 and it is placed (unfrozen) in the internal ECN.
  10. With external execution, the broker gets the same commission minus LP3's commission (the broker for LP3 is simply a client acting on behalf of his clients). And you get a potential positive slippage or rebate.

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.

 
hrenfx:

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.

 
Andrei01:

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.

There is a big difference: a market order will be executed with slippage in both directions, a limit order - only in the positive direction, or it will be missed. Setting a pending order in advance (at least one second beforehand) allows us to avoid dependence on the terminal<->trading server<->aggregator, respectively reducing the time spent on the execution and thus improving the execution itself.
Reason: