tar
Legendary member
- Messages
- 10,443
- Likes
- 1,314
Dear Traders,
We would like to thank everyone who has contributed their comments to this thread regarding Alpari (UK). We are keen to hear what all of you have to say but we think this thread is not complete without our response to your questions and opinions. As a result we have compiled a comprehensive response to all the points made with respect to Alpari (UK).
Slippage
In accordance with our Terms of Business, under normal market conditions all orders are executed at the price requested by the client:
5.26. Under Normal Market Conditions the Company executes an Order at the Order Level
Under abnormal market conditions or when market gaps occur, at market open on Monday (00:00 CET) for example, trades are executed at the best current market price.
5.27. When the Order Level falls within the Price Gap on the Market Opening, the Order is executed by the Company at the Quote which is presented in the Quotes Flow during the process of Order execution. Buy Stop, Sell Stop or Stop Loss is executed at the level less profitable for the Customer; Buy Limit, Sell Limit or Take Profit is executed at the level more profitable for the Customer.
5.28. Under Abnormal Market Conditions the Order is executed by the Company at the Quote which is presented in the Quotes Flow during the process of Order execution.
The policy outlined above is normal market practise and is a regular feature of the FX market.
Our quotes and ‘stop-hunting’
Alpari UK has decided to implement a prime brokerage model. Amongst our liquidity providers are 8 top tier European/American institutions such as UBS, Deutsche Bank, Barclays Capital, JP Morgan, Goldman Sachs, Lava and Currenex. We are currently in the final stages of introducing 5 more liquidity providers that our clients can utilise to attain the best market prices.
Our Research & Development (R&D) team has created a multi-bank feed that captures pricing from our liquidity providers via FIX API and selects the best bid and ask prices available for the particular volume being traded in ‘Instant Execution’ mode. We then widen the spread symmetrically to the spread we would like to offer our clients.
Last year, before we introduced fractional pip (5 decimal) pricing it was often impossible to set our spreads symmetrically because we receive a 5 decimal price feed from our liquidity providers but must offer 4 decimal pricing to our clients. For example, if the best price is 1.27013/1.27031, we could only offer 1.2701/1.2703 or 1.2702/1.2704 to our clients. If we provide 1.2701/1.2703 and a client executes a very large buy order at 1.2703, then we cannot hedge this trade without making a loss (the best ask price available to us is 1.27031). If we provide 1.2702/1.2704 then we cannot hedge a short trade because the best bid price available to us is 1.27013.
For these reasons we introduced a 5 decimal pricing system: to provide the most accurate pricing for our clients and to be able to hedge client trades without risking financial loss for Alpari (UK) as a company.
Regarding your concerns about us “stop-hunting”; we would like to categorically deny such accusations. We always reflect the real market as quoted by our liquidity providers and in turn offer the best available price to our clients. Our prices are always within a 0.1 pip of the real market price which we never manipulate under any circumstances. If your stop loss/take profit order has been executed, it is because the market price has reached your set level and not because we have artificially altered something to our advantage.
Unfortunately, on rare occasions there can be instances of price ‘spikes’ being fed through to us by our liquidity providers leading to stop losses and take profit orders being executed at incorrect prices. On these occasions, we take action as quickly as possible to correct the situation rather than waiting for correspondence from the affected client. We either reopen the spike affected trade(s) or compensate the affected trading account appropriately.
This scenario is detailed in our Terms of Business:
9.24. If a Dealer erroneously executes a Stop Loss or a Take Profit:
(a) at an Error Quote (Spike); or
(b) because the Company makes a Manifest Error and clause 5.23 is breached; or
(c) because of failure, malfunction or misuse of the Trading Platform software and clause 5.23 is breached,
and the Company initiates a Dispute resolution in accordance with clause 9.1 or the Customer lodges a complaint which is recognised by the Company as reasonable, the Company has the right to reopen the erroneously closed position within 15 minutes from the moment the Dispute arises. If within this time the erroneously closed position has not been reopened by the Company, the Company will pay the Customer the difference between the value of the actual closing position and the value of the closing position at the best Quote which is registered in the Quotes Flow between the moment the Dispute arises and the moment of the indemnification.
Execution time
We are proud to say that 99.67% (in Jan 09), 99.59% (in Feb 09) and 99.54% (in Mar 09) of all orders with us were executed in under 1 second. In actual fact, execution times are measured in milliseconds but because MetaTrader logs are recorded to the nearest second your log files will show trades being executed at the same second as the order was placed or the second after. Only a small amount of orders are executed in 5-10 seconds.
In the near future we will be offering a full Non-Dealing Desk solution for ALL orders which means that all transactions will be executed within milliseconds.
One post on this thread referred to an instance of a trade being executed after 3 minutes. This is clear evidence that for some reason the order was not successfully placed on our server to be executed because the timeout period on our server is 3 minutes. As the timeout time was reached, a second attempt to place the order was made. In other words, it didn’t take us 3 minutes to execute the trade but rather, it took our server 3 minutes to receive the order.
It is a reasonable question to ask why some orders take longer than others to reach us. A definitive answer can only be given after examining a MetaTrader log file that was recording events at the time of the order being placed. For this, we need the client to provide the relevant ticket number(s) so that we can investigate.
It is true that we have had some capacity issues in the past where we received extremely large amounts of orders within a very short period of time making it very difficult for our server to queue all order requests efficiently. This issue has now been fully resolved as we have taken steps to improve the efficiency of our service by adding server capacity and separating account types into Micro and Classic.
To some degree we have been victims of our own success because our favourable trading terms and funds segregation policy has spurred over 40,000 new traders to use our services in the past 18 months.
Our tight spreads, fast execution and solid segregation policy are just a few examples of our attempts to provide a professional service. Some of our other benefits can be found here.
We would like to take this opportunity to announce that from 18th March 2009, we began to offer 100% segregation for all clients. The only condition is that only free margin will be segregated. Essentially this means that if you are not in a trade, 100% of your capital will be segregated as client funds making it completely safe in case of Alpari’s bankruptcy.
In addition to this, our clients are free to apply for the Financial Services Compensation Scheme (FSCS) which is an independent scheme designed to pay back clients of FSA regulated firms up to £48,000 in case of financial difficulties.
We see ourselves as a dynamic, technology driven company so our experiences over the past few months have given us a good insight into how to prevent our growing client base and trade turnover from having a detrimental impact on your trading experience. We now know the limitations of MetaTrader and thus we are able to plan ahead accordingly in terms of how much server capacity is required to ensure a constantly high level of performance for all clients, all of the time.
Demo server
We periodically use our demo server to test new features before launching them on the live platform. New features can contain bugs in their initial stages of testing which has at times led to uptime problems and forced us to restart our demo server. We are sure that you will all agree that testing features on the demo platform is a sensible thing to do before applying anything to the live servers. Conducting tests in a secure testing environment without using demo or live servers is also done but the best way to test new features is to expose them to the stresses of mass use without the risk of affecting live clients – only the demo platform offers this compromise.
Re-quotes
Firstly, let us go through why re-quotes occur and how they can be avoided as much as possible. As we have mentioned previously, we are using a Prime Brokerage model by working with 8 liquidity providers including banks and ECN’s. As a result, we receive hundreds of price quotes per second from banks and even thousands from ECN’s.
Below is a small illustration of how many quotes we receive per second from Lava only:
08.04.2009 17:16:13 3890 ticks
08.04.2009 17:16:14 1001 ticks
08.04.2009 17:16:15 1211 ticks
08.04.2009 17:16:16 1368 ticks
08.04.2009 17:16:17 3124 ticks
08.04.2009 17:16:18 1610 ticks
08.04.2009 17:16:19 1297 ticks
08.04.2009 17:16:20 985 ticks
08.04.2009 17:16:21 2751 ticks
08.04.2009 17:16:22 1263 ticks
08.04.2009 17:16:23 1322 ticks
08.04.2009 17:16:24 1175 ticks
08.04.2009 17:16:25 2447 ticks
08.04.2009 17:16:26 1522 ticks
08.04.2009 17:16:27 986 ticks
08.04.2009 17:16:28 1523 ticks
08.04.2009 17:16:29 3243 ticks
The total amount of quotes we receive per second from each bank/ECN can easily reach 6,000-7,000. On average we receive 200-240 quotes per currency pair per second.
If we stream all quotes we receive onto our clients you would see a drastic increase in the amount of traffic, bandwidth required and re-quotes. For this reason we are using so-called ‘market snapshots’ of current market prices several times a second in order to avoid unnecessary allocation of bandwidth and ensure the accuracy of our pricing is maintained.
Now we will look at the causes of re-quotes and how to deal with them if they occur.
Let’s assume the following:
‘Market snapshots’ taken every 100 milliseconds (0.1 seconds)
2 pip spread
Client latency is 80 milliseconds (amount of time it takes for client requests to reach our server and vice versa). 80 milliseconds equates to an adequate internet connection.
We are receiving the following stream of quotes from our liquidity providers (and we pick the best bid/ask prices automatically):
Code:Date | Time Best Bid / Best Ask Retail price Retail price (4 digits) (5 digits) 10.04.09 13:47:00:000 1.27110 / 1.27119 1.2710/1.2712 1.27105 / 1.27125 10.04.09 13:47:00:100 1.27111 / 1.27115 1.2710/1.2712 1.27103 / 1.27123 10.04.09 13:47:00:200 1.27109 / 1.27114 1.2710/1.2712 1.27102 / 1.27122
Case 1: Currency pair with 4 decimal pricing; Maximum deviation = 0
Let’s assume the first quote of 1.2710/1.2712 encouraged the client to sell. The quote will take 80 milliseconds to reach the client so if we received the quote at 13:47:00:000, the quote will reach the client at 13:47:00:080. The client then presses SELL to sell at 1.2710 and the order goes back to our server.
The earliest possible time we could have received this order is 13:47:00:160. According to our example price feed, the price of 1.2710 is still the current market price so the order is executed at 1.2710 without a re-quote.
Case 2: Currency pair with 5 decimal pricing; Maximum deviation = 0
Let’s assume the first quote of 1.27105/1.27125 encouraged the client to sell. The quote will take 80 milliseconds to reach the client so if we received the quote at 13:47:00:000, the quote will reach the client at 13:47:00:080. The client then presses SELL to sell at 1.27105 and the order goes back to our server.
The earliest possible time we could have received this order is 13:47:00:160. According to our example price feed, the current market price is now 1.27103/1.27123 which is different from the price requested by the client initially. In this case our server is forced to offer the client a re-quote of 1.27103/1.27123 which can be accepted or rejected by the client. If the re-quoted price is accepted by the client, the order is sent back to our server for confirmation. Another re-quote could occur if the re-quoted price has changed within the time it took for the order to reach the client and for the client to accept. This is where some of you have had problems because a rapidly changing market will tend to generate many re-quotes unless maximum deviation is used.
Please note than in this case, a re-quote was necessary because the price had changed so the broker cannot be at fault whatsoever.
Case 3: Currency pair with 5 decimal pricing; Maximum deviation = 5 (0.5 pips)
Let’s assume the first quote of 1.27105/1.27125 encouraged the client to sell. The quote will take 80 milliseconds to reach the client so if we received the quote at 13:47:00:000, the quote will reach the client at 13:47:00:080. The client then presses SELL to sell at 1.27105 and the order goes back to our server.
The earliest possible time we could have received this order is 13:47:00:160. According to our example price feed, the current market price is now 1.27103/1.27123 which is different from the price requested by the client initially. However, due to maximum deviation being set to 5 a re-quote is not required because the trading platform has accepted the new quote on the client’s behalf; the trade is executed at 1.27103.
As you can see, the vast majority of re-quotes are due to rapid changes in market prices combined with maximum deviation being set to zero (asking the platform to ONLY execute at the price requested with no alternative) and not because of a desire to prevent a trade from being opened/closed.
Taking the above examples into account we can deduce the following solutions:
1. To reduce the amount of re-quotes by increasing the time gap between snapshots. This increase cannot be excessive because that would give the opportunity for clients with excellent connections to trade at old prices, thus giving them an unfair advantage.
2. The client can set maximum deviation to something other than zero which would reduce re-quotes drastically.
3. The client can obtain a professional internet connection that reduces client latency to <10 milliseconds (this is very expensive and unlikely to be a realistic solution).
4. Return to the 4 decimal pricing system. In this case the client would have sold at 1.2710 whereas under the 5 decimal system (with maximum deviation set), the client could have sold at 1.27103 which is a better price. With this solution, Alpari (UK) may face problems in hedging its clients’ exposure as explained earlier.
Hedging of client trades
Somewhere in this thread we noticed a comment which claims that we hedge all our client trades. This is not true. We are able to hedge reasonably large orders only because our institutional counterparties do not accept very small volumes. We have an agreement with our liquidity providers for us to only place orders above 0.5M at any one time. This means that any one order below 0.5M (5 lots) that we receive from a client is not able to be hedged although our overall exposure is monitored. The vast majority of trades are netted off amongst our client base (approximately 75%) so our clients are essentially taking positions against each other, not against us. Very large trade volumes are hedged as appropriate depending on our risk management model which takes into account our regulatory requirements, market volatility and overall market exposure.
Alpari (UK) hedges the following:
All orders higher than a particular level but no less than 0.5m. The ‘particular level’ is flexible and dependent on the currency pair being traded, the volatility of the FX market, the amount of exposure already taken and regulatory obligations. This number rarely falls below 1M (10 lots).
Unhedged client positions once they have reached a particular level. The ‘particular level’ is flexible and dependent on the currency pair being traded, the volatility of the FX market, the amount of exposure already taken and regulatory obligations. We have strict risk management rules which have a profound influence on this level. For example, a company’s solvency ratio should never fall below 200%. For those who are interested in how the size of unhedged positions affects the solvency ratio please refer to the appropriate FSA rule.
We hedge selected large clients on every order and trade they make because of the volume traded and potential risks involved.
If you have doubts regarding Alpari UK’s actions in this matter please view our FSA permissions: FSA Register
Activity Name: Dealing in investments as principal
Investment Instrument
Contract for Differences (excluding a spread bet and a rolling spot forex contract)
Rolling spot Forex contract
Customer type
Eligible Counterparty
Professional
Retail (Investment)
Limitation
Rights to or interests in (both).
In our Client Agreement it is stated:
5.1. In relation to any Transaction the Company acts as principal to principal and not as agent on the Customer’s behalf.
We hope our response answered your questions and helped you understand our perspective on these matters. As always, our Client Services team is ready to answer your questions and help you with your concerns so feel free to contact us at your convenience.
Kind Regards,
Andrey Vedikhin
Chief Executive Officer
Alpari (UK)
Forex trading with Alpari. Real time foreign exchange trading services. Free forex news, forex charts, analysis.
from forexfactory
