Trader's Handbook: orders, prices, stack, funds, currency - page 4
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
Manipulative use of signalling services.
I have mentioned above what costs are incurred by signal services, which are so fashionable nowadays, using a primitive classical synchronisation scheme: through market orders.
It is worth mentioning one more disadvantage of such synchronisation - the manipulation component. The technique described below may remind someone of layering (fomag.ru/Publications/Zapreschennyi+treiding/). But still it is different. Let me say up front that the following makes sense only for ECN (exchange) and ECN/STP-platforms.
Imagine that you are a signal provider (preferably free) and you have subscribers (there will be more of them then), whose traded size is higher than yours. Then from time to time you have the opportunity to include a simple transfer of money from your subscribers' accounts to your master account:
Putting a LARGE BuyLimit and SellLimit inside the spread and making a "trigger" - a small SELL (sell to yourself - BuyLimit). This causes an avalanche of SELL orders from your subscribers. Your BuyLimit starts to flood in, i.e. your BUY position starts to grow. This causes an avalanche of BUY orders from your subscribers again. I.e. your SellLimit starts to fill up.
As a result, by causing such recursive avalanches (the basis of which still lies in the latency of signalling services), you get an overflow of money from your subscribers to your master account. This improves the performance of your master account by attracting even more subscribers.
Of course, you don't have to set limits on your master account. You can do it on your personal other account. Then you will get an overflow to it. But the master account will have a small drawdown, which may discourage subscribers.
There can be other variants of such machinations, but their core idea will be the same, as I wrote above.
MM-algorithms are practically impossible to synchronise profitably through the classical scheme. Therefore it is expedient to address to the alternative scheme of synchronisation mentioned earlier.
Any trading action on ECN (exchanges) is always a spillover of money from one trading account to another. That is why it is just silly to demonise the technique of overflow. You just need to understand what is involved.
We should not forget that the task of almost any MM-algorithm is to create mutually favourable conditions for money spilling over from other people's accounts to one's own. The reciprocity is that those who drain money do it at a slower rate than they could do if the MM-algorithm did not exist. There are exceptions - there is no mutuality.
Original source: http: //www.forexfactory.com/showthread.php?p=7001359#post7001359
Organising the transition of an exchange to a new engine.
Every exchange operates on some trading engine. Let's assume that the owner of the exchange has realised a serious imperfection of the current engine that threatens (or hinders) the business. He is faced with the task of writing a new perfect exchange engine.
It may turn out that the new engine is incompatible (it happens) with the old one. How to transfer the exchange to the new engine?
The problem is that the old engine has all the current liquidity. And if the old one is simply switched off and given a new one. There will be practically no liquidity on the new one (killing the exchange) - they can't all instantly rearrange themselves.
That's why they make ECN/STP scheme of the new engine. When the old engine is connected by STP to the new one as the only LP. And the new engine gives its own internal ECN.
This allows you to trade through two engines at once.
After the more advanced engine starts to gain popularity (because it is more profitable to trade through it - trading costs are lower, opportunities are more), liquidity from the old engine starts to flow to it (gets into the internal ECN of the new engine).
As a result, almost all liquidity from the old engine is transferred to the new one. After that the old one closes completely. And only the new one remains without external LP. I.e. it turns out to be an updated exchange (ECN) - absolutely all on the new perfect engine.
It is important to understand that the exchange engine (or the engine of any other trading platform) has nothing in common with trading APIs. That is, no one, except the exchange itself, is able to influence the work of this internal engine directly. This can only be done indirectly.
For this purpose, the engine owner writes breeches between his internal engine and the external trading API. Most often they limit themselves to only one such real trading API - FIX API (almost mandatory - standard). But there are cases when there are several real trading APIs.
Trading platforms with their own trading APIs are not real trading API platforms, but their wrapper: sometimes more high-level, sometimes less functional, but easier to work with. For example, almost all trading platforms have trading APIs that are actually wrappers. Therefore, trading through them increases trading costs due to the latency of the wrapper.
Takeover of exchanges.
There are a lot of trading platforms. Some of them may not only trade cointegrated FIs, but the same FIs in general. That is, the same FI is traded on different platforms.
In order to absorb these venues (to pour all their liquidity to your own venue), you need to create an ECN/STP-aggregator, where all the victim venues act as LPs. This method creates a new trading platform with more favourable prices - price dumping.
Thanks also to competent marketing of promotion of the new site, first algo-takers, then algo-hyvers, then again takers, etc. move to it due to dumping. Overflowing liquidity like a snowball. At a certain point the process becomes irreversible. And the victim sites are completely absorbed.
On the examples above you can see the main historical significance of ECN/STP schemes. They serve the purpose of market centralisation, more efficient pricing, increased liquidity and better prices.
From here: http://www.forexfactory.com/showthread.php?p=7012180#post7012180
Matching is the previously described combination of two multidirectional trade orders within ECN. Note that STP-execution of orders is not matching.
Matching Classifier.
In any ECN (exchange) it is possible to statistically classify the executed matchings into groups of market participants, within which the highest matchings turnover occurs. For example, if two market participants, thanks to matchmaking, transfer money to each other through mutual matchmaking, such a classifier will separate them into a separate group.
Self-identification.
It is strategically advantageous for any ECN to have as many brokers (independent client databases) as possible. It is necessary to reduce the probability of creating a hypothetical competitor.
A competitor is born most often through self-identification of brokers, which occurs as follows. Relatively large brokers carry out classification matching of their client databases. If large-turnover groups of such clients within their databases can be identified, an obvious thought arises: why should these clients pay ECNs for matchmatching among themselves, when it occurs between the broker's clients anyway? It's a pragmatic question, of course.
Dark-pool.
The answer to it is to create your own ECN/STP-engine, where ECN is used for matching intra-broker's clients, and STP - for execution on external ECN (to avoid confusion further on in the text we will call external ECN an exchange (most often it is)). This solution has several advantages (and disadvantages) for both the broker and its clients.
The broker already has its own trading platform, which in relation to the exchange has its own name - dark-pool. Accordingly, the commission from the matching of its clients now goes to the owner of this platform, not to the owner of the exchange.
Broker's clients sometimes get better execution (than on the exchange) if it takes place inside ECN, because latency (technical/computational time delays) of the exchange for broker's clients is always higher than latency of the client database of broker's clients.
But there are also ambiguous moments for clients. If an STP-transaction is carried out, there is no guaranteed execution for clients. I.e. FillRate (execution quality) < 100%. As it has been discussed in detail before, this is a consequence of the fact that client orders in STP scheme are no longer visible in Level2 of the exchange. That is, exchange clients cannot respond to them. Roughly speaking, dark-pools clients become only PriceTakers (not PriceGivers) for the exchange.
However, they leave their PriceGivers right inside the dark-pool, and that is no small thing. Because we do not forget that before the creation (and its cause) of dark-pool there was an adequate above-described self-identification. It should also be said that dark-pool allows to give its clients anonymity before the exchange, because all STP-transactions go now only from one name - the name of dark-pool. Moreover, dark-pool because of its isolation from the exchange creates additional protection from particularly aggressive exchange PriceGivers (MM-algorithms and other HFT-algorithms of algo-trading), which not without reason attracts many market participants to switch from exchanges to dark-pools.
Development of dark-pools.
According to the previously described scheme of exchange takeover, a large dark-pool is able to take over an exchange and actually start fulfilling its role. In this case, the regulatory burden of the exchange does not concern dark-pools, as they are practically purely electronic (virtual) entities. Of course, the regulatory paw will not bypass them in the future, as it always happens when something new gains serious weight.
Centralisation vs Decentralisation.
As you can see, the creation of dark-pools is a natural evolutionary process taking place inside the market - its decentralisation. The non-zero probability of decentralisation forces centralised exchanges to improve their trading conditions. I.e. decentralisation for exchanges is a mechanism that increases the efficiency of this type of market. However, there are also negative sides of excessive decentralisation, which were shown on the example of FOREX. There the same ECN/STP-scheme, as it is not paradoxical, serves for centralisation of the market and corresponding improvement of trading conditions.
I.e. through ECN/STP-formations it is possible both to decentralise the market by creation of dark-pools and to centralise it - creation of high-level aggregation from the same dark-pools, in particular.
The best trading conditions are somewhere in the golden mean between the paradigms of dece ...
http://www.forexvonline.ru/2012/08/blog-post_31.html
Swap
In Forex, business hours last until 23:30 (GMT). Any positions opened before this time are automatically rolled over to the next day. This is to avoid the actual delivery of currency. Because, in fact, most market participants do not want this delivery. And brokers carry over positions automatically unless you notify them of your desire for the currency.
Prival-2: https: //www.mql5.com/ru/forum/42519/page3#comment_1481313
Front running
The idea is simple and clear. In principle, you all understand it, there is nothing complicated there. It was traded by hands until 2010, then this logic of work began to be realised in the form of robots (algorithms) and those who traded by hands were squeezed out.
Explanation of the principle of front-running in the video
Screenshot of the gasprom stack.
The moment was chosen when the bids were taken before the density and instantly rebounded by 15 points. Basically, everything is classical, minimal stop (risk), we get out of the market if anything goes wrong, profit/risk ratio is 3:1, commission is negligible less than 1 point.
Fundamentals of exchange pricing on the example of the derivatives section of the Moscow Exchange
How to protect yourself and your expert when trading on the Moscow Exchange
Market makers' tricks - short-term liquidity dips
According to exchange requirements, market makers can provide additional liquidity on some instruments. In return for lower commissions, a market maker is obliged to keep a certain volume of limit orders for selling or buying. However, the exchange does not regulate how the market maker is obliged to hold these orders. The market maker sometimes takes advantage of this by equipping his mm-algorithms with special tricks.
One of such tricks is the following: the market maker puts out a limit order to sell or buy, and then starts to move it to a worse position and back again at a certain interval (for example, once every 500 milliseconds). Since market makers work on insufficiently liquid markets, their limit orders are the best to execute anyway. A trader wishing to buy or sell in the market asks for the best price. After making sure that there is liquidity, the trader makes a trade, but by the time the trade is made, the market maker will be able to move the order to a worse price and execute the trader with a significant slippage, the downside of which is an increased profit for the market maker. The screenshot below shows this algorithm in action:
It is noteworthy that such a picture is difficult to see from trading platforms that do not support the display of Ask and Bid history on the chart. This is what is intended: a manual trader may notice short-term liquidity dips and buy or sell on the market, thinking that it will be executed at completely different prices.
I decided to share information about the real possible frequency of HFT on retail forex. I received a notice from one brokerage company about the change of client agreement. The newly introduced provisions are:
6.6.The trading account will be automatically switched to "Read Only" mode if the number of Client's orders
to the Server exceeds 1000 (one thousand) in 300 seconds if there are no free funds in the trading account.
6.6.1.The trading account will be switched off automatically if the number of Client's orders to the Server exceeds 10000
(ten thousand) in 3600 seconds.
End of quote. This brokerage centre has both MT4 and MT5, which of them caused this restriction is not clear. But it really comes into effect from 29 June 2021.
Thought I'd share some information about the actual possible frequency of HFT in retail forex.
Well, if pipsing on retail forex can be called HFT at all, the conditions are quite comfortable. In general, I can't imagine who needs such a frequency, except frontrunners
I can't imagine who needs such a frequency, except frontrunners.
I missed the news a few days ago. I definitely reached 10 000 trade orders in an hour, because volatility was decent (scalping) and did not calm down for a long time.
MT4 GUI was hanging for more than an hour (three terminals for one account, so that the number of trade streams would not reach the ceiling). At the same time, the Expert Advisors were ploughing on, missing ticks badly.
MT5 withstood, but it was impossible to switch on the table of orders - strong lags started on a powerful remote machine, as there is no video card on it, and it is difficult to pull hundreds of FPS.
I wrote details in my group in real-time. That is why it is better to switch from MT4 to MT5.