Re-Quotes in Online Trading: Execution Mechanics, Slippage, Broker Controls, and Trader Defenses
A re-quote occurs when a broker cannot execute an order at the exact price specified when the order was submitted and therefore offers the trader a new price instead. Being offered a new price is what distinguishes a re-quote from slippage. With slippage, the order is executed automatically at the next available price without asking the trader for confirmation.
Example:
Suppose you click Buy EUR/USD at 1.1000. By the time your order reaches the broker, the market has moved to 1.1003. Instead of filling your order at 1.1000, the broker sends back a message like:
“The requested price is no longer available. New price: 1.1003. Do you accept?” That’s a re-quote.
Re-quotes are common in fast-moving markets, periods of high volatility, conditions of low liquidity at the requested price, and with brokers that use instant execution rather than market execution. However, if a broker frequently issues re-quotes during normal market conditions, they risk developing a reputation for poor execution quality, and traders may begin looking for alternatives. Scalpers are particularly sensitive to re-quotes because even a few pips can significantly affect profitability.
To reduce the likelihood of re-quotes, traders can use limit orders when appropriate, avoid trading during periods of low liquidity, avoid placing orders around major economic releases or significant geopolitical events, and choose a broker that offers market execution rather than instant execution. Traders should match execution type and policy to strategy, and reduce latency with proper infrastructure.
A re-quote is not just a bad fill. It is an execution failure under a price-committed order model. The trader requests execution at one price. By the time the request reaches the broker’s server, that price is no longer valid under the broker’s permitted deviation rules. The broker then returns a new executable price and asks the trader to accept or reject it. The critical distinction is execution type. Re-quotes belong to Instant Execution and Request Execution environments. They do not belong to true Market Execution in the same way. Under Market Execution, the trader does not demand a fixed price. The trader submits an order to be filled at the next available market level. If the price has moved, the result is slippage, not a re-quote. The order may fill worse, fill better, partially fill, or fail under liquidity rules, but the platform does not normally return a fresh price for manual confirmation.
While brokers often use re-quotes legitimately to manage stale-price risk, it is also possible for a broker to manipulate execution by selectively issuing re-quotes through asymmetric execution settings, virtual dealing plug-ins, or selective rejection logic. When discussing re-quotes, it is important to remember that a re-quote is not automatically proof of broker misconduct. In most cases, it is the normal result of a fixed price execution request failing a server-side price validity check.
- In Instant Execution, re-quotes are part of the design.
- In Market Execution, the same price movement usually appears as slippage instead.
The serious issue is instead asymmetry. If re-quotes block client-favorable fills while client-adverse fills execute freely, the broker is not simply managing stale price risk.
The Anatomy of a Re-Quote
The Technical Handshake
The trading platform the trader is using, e.g. MetaTrader 5, receives a bid and ask from the broker’s trading server. The quote may already be a few milliseconds old by the time it reaches the trader’s device. The trader clicks buy or sell, or an automated system sends an order. The order packet contains the requested symbol, direction, volume, account ID, order type, requested price, maximum allowed deviation, and other execution parameters.
When the order has been sent from the trader’s trading platform, it travels to the broker for execution. Exactly how fast the journey from the trading platform interface to the point where the order can be executed will depend on several factors, e.g. the trader’s device, a local router, the internet service provider, cross-border network hops, the broker access server, the platform server, the bridge, the dealing module, the risk engine, and the matching or routing layer. Despite all these stages, the journey is usually fast enough in calm markets, and the requested price remains valid. In a fast market, however, the quote may have become stale before the order reaches its destination.
Under the Instant Execution model, the requested price is central. The client is asking the broker to execute this order at this price, or within this permitted deviation band. The price is not just a reference; it is part of the execution instruction.
If we look at the documentation for MetaTrader 4, we see how Instant Execution is described as follows: “In this mode, the order is executed at the price offered to the broker. When sending the order to be executed, the terminal sets the current prices in the order. If the broker accepts the prices, the order will be executed. If not, the so-called “Requote” will occur: Broker returns prices at which the order can be executed.”
That is the core handshake. The trader signs price A. The broker server checks whether price A is still valid. If it is valid, the order is executed. If it is not valid, the broker offers price B. The trader or the trader’s automated system must decide whether to accept price B or not.
The Timeline of an Order
This is what the timeline can look like for a typical order from a retail trader who is using MetaTrader 4 from home:
- At time zero, the trader sees EUR/USD at 1.10000/1.10002. The trader clicks buy at 1.10002. The platform packages the order with the requested ask price. If the trader has allowed one pip of deviation, the broker can execute within that band. If the trader has allowed zero deviation, the broker must adhere to that.
- At around one to five milliseconds, the order leaves the trader’s terminal. A low-latency VPS located near the broker’s infrastructure may reach the broker’s server very quickly. A home connection across continents may take 80 milliseconds or more. Mobile connections can be even less stable, especially under packet loss or poor routing conditions.
- At roughly five to 100 milliseconds, the broker’s server receives the order. The trading system verifies account permissions, available margin, symbol availability, trading session status, order size, and price validity. The price validity check compares the requested price against the current executable market quote on the broker’s server. At that moment, the server may no longer show 1.10002. If the new ask is 1.10003 and the allowed deviation is one pip, the order is allowed to execute. If the new ask is 1.10015 and the allowed deviation is one pip, the order fails the price check, and a re-quote is returned.
The Price Validity Formula
The re-quote boundary can be expressed simply.
Let:
Requested Price = the price attached to the client’s order request
Server Price = the broker server’s live executable quote when the order arrives
Allowed Deviation = the maximum difference the client permits
ΔP = the absolute price difference
The price difference is:
ΔP = |Server Price − Requested Price|
The re-quote condition is:
If ΔP > Allowed Deviation, then re-quote
The new quote offered to the client is:
New Price = Server Price
or, in some broker systems:
New Price = Server Price + Broker Markup
The second version matters because the quote shown to the client may not be a raw external market price. It can include broker markup, spread controls, liquidity provider selection, internal pricing rules, or symbol-level execution settings.
A worked example makes the mechanics clean. A trader sends a buy order at 1.25000 with an allowed deviation of 0.00005, or 0.5 pips on a five-digit quote. The order reaches the server when the live ask is 1.25009.
The difference is:
ΔP = |1.25009 − 1.25000| = 0.00009
The allowed deviation is:
Allowed Deviation = 0.00005
Because:
0.00009 > 0.00005
The order fails the validity check. The broker returns a re-quote at 1.25009, or another updated executable price.
If the trader widens the allowed deviation to 0.00010, the same order may execute without a re-quote. The cost is that the trader has accepted more slippage. This is the trade-off. Narrow deviation protects price but increases re-quotes. Wide deviation reduces re-quotes but allows worse fills.
Execution Type
As mentioned above, the re-quote occurs in the Instant Execution environment. This is a model where the trader requests a price, i.e. the price is fixed first. If the price is no longer available, the broker asks for confirmation at a new price. That is a re-quote.
If you instead trade in a Market Execution environment, the execution intention is fixed first. The trader essentially tells the broker to execute at the available market price. The price is not fixed. If the market moves, the order fills at the next available liquidity tier. This can result in slippage, but not a re-quote. It is called negative slippage if the fill is worse than expected. It is called positive slippage if the fill is better than expected. It can also be a rejection if no liquidity exists or the order fails execution rules.
This matters for strategy suitability. Instant Execution can be acceptable for slower discretionary trading where price certainty matters more than immediate fill certainty. Market Execution is usually more suitable for news scalpers, automated systems, and strategies that cannot pause for manual price confirmation. A trader cannot sensibly complain that Market Execution produced slippage. That is the mechanism. The better question is whether the slippage distribution is fair, whether positive slippage is passed on, whether rejection rates are disclosed, and whether execution quality matches the broker’s policy.
The Structural Drivers Behind Re-Quotes
Network Latency and Stale Price Exposure
Latency is the first structural driver. The retail platform is not inside the market. It receives prices, displays them, accepts orders, and sends those orders back to the broker. Every part of that loop takes time.
A trader in London connected to a broker server in London may have a round-trip time of a few milliseconds if using a good VPS. A trader in London connected to an offshore server in the Bahamas, Seychelles, Mauritius, or a distant cloud region may see much higher latency. A trader in South America using a broker server in Europe may face 150 milliseconds or more. A mobile trader on a weak connection may see variable latency, which can be even worse than stable latency because execution becomes unpredictable.
The price feed also has its own tick rate. In a fast market, EUR/USD may update dozens or hundreds of times per second. The trader’s terminal may display one tick while the server has already processed the next. If the order is based on the displayed tick, but the server validates against the newer executable tick, the order may fail.
Cross-border routing makes this worse. A trader may be physically in London, the broker’s trading server may be in New York, the liquidity hub may be Equinix NY4 in New Jersey, the liquidity provider may validate flow through another system, and the broker’s risk engine may apply additional checks. Each hop adds time.
To reduce latency, many traders use VPS hosting close to broker servers or liquidity hubs. It does not remove all re-quotes, but it reduces the chance that the requested price is stale by the time it reaches the execution engine.
Asymmetric Tick Rate During Fast Markets
Markets do not move at a constant speed, and the re-quote rate that looks acceptable during quiet hours can become unusable during macro releases. Before US Non-Farm Payrolls, CPI, Federal Reserve decisions, Bank of England announcements, ECB rate decisions, and similar headlines, liquidity providers often widen spreads or reduce size. At the release moment, prices can jump through several levels. The visible quote on the terminal is often a poor guide to executable liquidity.
A trader clicks buy at the old ask. By the time the order reaches the server, the ask has jumped five pips. If the allowed deviation is small, the order is re-quoted. If the trader accepts the new quote, the market may have moved again. Another re-quote may appear. This is the beginning of the re-quote lock-up loop.
For many traders, this is especially painful when it impacts losing positions they want to close. If the trader’s account is in Instant Execution mode and price confirmation keeps failing, the platform can trap the trader in repeated decision cycles while the market keeps moving.
This does not mean Instant Execution is bad, scammy, or useless. It means the execution type must match the strategy, and the trader must adjust accordingly.
Liquidity Providers and Last Look
Last look is another structural driver. A liquidity provider shows a price, and a trader sends an order to trade at that price. With last look, the liquidity provider now gets a brief period (typically a few milliseconds) to decide if they want to honor the price or reject the trade. This means that even when a trader is effectively hitting a quoted price, execution is not guaranteed. In last-look venues, quotes are not firm, as they may be rejected if the market has moved or the price is no longer favorable to the liquidity provider.
Last look was designed to protect liquidity providers from stale pricing, rapid market moves, and latency arbitrage. If conditions change significantly between the quote and execution, the provider may reject the trade. Critics argue this reduces execution certainty, while supporters say it allows tighter spreads by lowering risk for liquidity providers.
Last look is most closely associated with FX markets, but the underlying concept exists in other markets as well. Last look has become especially associated with spot FX trading since there is no single central exchange on the forex market. Instead, liquidity providers (banks and non-bank market makers) stream quotes to clients and venues. Because FX is decentralized and quote-driven, last look has become a major market structure issue.
The Global FX Code, a set of global principles of good practice in the foreign exchange market, describes last look as a practice utilized in Electronic Trading Activities whereby a Market Participant receiving a trade request has a final opportunity to accept or reject the request against its quoted price. The code also says that firms using last look should have governance and controls consistent with disclosed terms. The Market Participant should disclose, at a minimum, explanations regarding whether, and if so how, changes to price in either direction may impact the decision to accept or reject the trade, the expected or typical period of time for making that decision, and more broadly, the purpose for using last look.
Last look exists partly because FX is fragmented and fast. Liquidity providers (LPs) stream prices to many venues and clients. A quote can become stale within milliseconds. The liquidity provider wants protection against latency arbitrage, stale price picking, and toxic flow. The LP wants flexibility, while the trader wants certainty, and therein lies the tension.
The Global Foreign Exchange Committee’s (GFXC) Group Report on Last Look warns that inappropriate last look usage may be indicated by low acceptance rates, differences in time taken to accept or reject, or significant market movement against the liquidity consumer when a request is rejected. It also states that LPs should not conduct trading activity during the last look window using information from the client’s trade request.
For retail traders, the last look chain is usually indirect. The trader sends an order to the broker. The broker may route or hedge the order through an aggregator, prime of prime, or liquidity provider. If the LP rejects the trade during the last look window, the broker must either fill the client internally, reroute the order, reject it, or re-quote it, depending on execution type and contract terms. The time window can be small, often discussed in milliseconds, but the impact can be large during volatility. If the market moves adversely to the LP during last look, the LP may reject. The broker may then return a new price to the client. From the trader’s view, this feels like the broker moved the goalposts. From the LP’s view, it refused to be picked off at a stale price.
Fast Markets and Liquidity Vacuums
A re-quote is most likely to happen when the quote stream cannot keep up with executable liquidity. This is common during fast markets. A fast market is not just a market moving quickly. It is a market where depth disappears, spreads widen, and the next executable price may be far from the last visible quote. In equity index CFDs, this can, for instance, happen at cash market open or during circuit breaker risk. In FX, it sometimes happens during macro releases or central bank surprises. In commodities, it is typically associated with inventory data releases, OPEC headlines, contract expiry, or geopolitical shocks.
Order book behavior changes under stress. Resting orders are cancelled, market makers widen quotes, liquidity providers reduce size, and internal broker risk engines tighten execution rules. Under such circumstances, it is not uncommon for last look rejection rates to rise. The quote you see on screen may still update, but the amount of size available at that quote may be tiny or effectively gone. This is where re-quotes, slippage, and rejects are all symptoms of the same condition: execution uncertainty. Instant Execution expresses that uncertainty as price renegotiation, while Market Execution expresses it as slippage or rejection. Neither model can create liquidity out of thin air.
Compliance Warnings, Asymmetry, and Virtual Dealing Plug-Ins
Asymmetric Re-Quoting
The central trader risk in this context is not the existence of re-quotes; it is the presence of asymmetric re-quoting. What you want is an Instant Execution setup that applies price validity rules consistently. If the price moves beyond the permitted deviation in either direction, the order is re-quoted. If the price moves within tolerance, it will execute. That is the clean model.
A predatory setup behaves differently. If the price moves in the broker’s favor, the order executes. If the price moves in the client’s favor, the order is re-quoted or rejected. The trader receives bad fills but not good fills.
In jurisdictions with a high degree of trader protection, applicable laws and regulations will address unfair execution practices, such as asymmetric re-quoting. One example is the United Kingdom, where the FCA’s COBS 11.2A best execution rules require firms to take sufficient steps to obtain the best possible result for clients and maintain execution policies covering execution venues and execution factors. Within the European Union, the MiFID II Article 27 (obligation to execute orders on terms most favourable to the client) focuses on achieving the best possible result across factors such as price, costs, speed, likelihood of execution and settlement, size, and order nature. For more information, see the ESMA Single Rulebook.
None of this means that a broker is required to guarantee perfect fills. It simply needs to stay away from unfair execution arrangements, such as asymmetrical re-quoting.
Virtual Dealing Plug-Ins
Execution systems in FX and CFD brokerage infrastructure can apply automated rules that control how orders are handled after a price is requested. In dealing-desk or hybrid execution models, these systems can influence whether a trade is filled at the originally requested price, requoted, or rejected.
In particular, they may trigger requotes when the price is no longer available at the moment the order reaches the broker or liquidity provider. This typically occurs in non-firm pricing environments, where the quoted price is indicative rather than guaranteed. When market conditions move quickly, the system may return a new price instead of executing the original request.
These systems can also apply risk filters that reject trades under certain conditions, such as excessive volatility, stale pricing, or latency between client and server. Depending on the broker’s model, execution rules may also differ across client groups or strategies, and orders may be routed to different liquidity sources or internalized.
The existence of such software is not inherently improper. Brokers need infrastructure to manage pricing validity, latency, liquidity provider responses, and market risk. However, in models where requotes are used, concerns arise when pricing is not consistently firm or when clients are repeatedly requoted in fast-moving markets, leading to potential execution asymmetry.
From the trader’s perspective, requotes can indicate that displayed prices are not fully executable, especially if they occur frequently during volatile conditions or affect certain trading styles more than others. Since execution systems are not transparent to end users, patterns in requote frequency and conditions are often used as indicators of execution quality.
Manifest Error and Trade Invalidation Discretion
Brokers typically reserve the right to cancel or amend trades executed at invalid prices. The basic need for this is real. If a quote feed breaks or a platform prints an impossible price, the broker cannot be expected to honor every fill. So, the problem is not that these rights exist. The problem is that some brokers do not use their rights in a fair manner.
A common issue in FX and CFD trading agreements is the use of broad clauses in the client terms or execution policy. Brokers may define concepts such as invalid pricing, manifest error, arbitrage, latency exploitation, or abnormal market conditions in deliberately wide terms, and reserve the right to determine unilaterally when these provisions apply. This can give the broker significant discretion to amend or cancel trades after execution, particularly where they believe pricing was distorted or trading activity was outside expected parameters.
An example of vague terms can be seen in OANDA’s Singapore client agreement, where sub-clause (iii) below essentially gives the broker the right to cancel a trade if the client exploited a “temporal and/or minor inaccuracy” or “delay in the display”. Yet because price updates often involve display delays of milliseconds, they could, in theory, argue that any profitable, fast-paced order took advantage of a “temporal inaccuracy”.
The extent to which such clauses are enforceable depends heavily on the jurisdiction, the client classification (retail versus professional), and the applicable regulatory framework. In more strictly regulated markets, such as major ‘green tier’ jurisdictions in our regulator bandings, brokers are generally required to apply these rights in a fair, consistent, and transparent manner, and their decisions may be subject to review by national regulators or financial ombudsman schemes where applicable. However, enforcement typically focuses on whether the broker acted within its disclosed policies and regulatory obligations, rather than replacing the broker’s commercial judgment.
A broker’s right to cancel or amend trades can be especially problematic for algorithmic traders. Strategies that compare multiple feeds, trade news spikes, or submit orders during price dislocations can trigger these clauses. A system that wins by hitting stale quotes is not the same as a system that wins by forecasting direction. Brokers know the difference, and so do regulators.
The trader should read all the fine print pertaining to this before running any latency-sensitive system. The existence of re-quotes may be the least of the risks. The larger risk is that the broker allows the trade, then later cancels or amends it as an error.
The Re-Quote Lock-Up Loop
As discussed above, a re-quote lock-up loop can occur when a trader tries to close a position in a fast market, but the price changes faster than the platform handshake can complete.
The trader clicks close at 1.20000. The server receives the request at 1.19980 and returns a re-quote. The trader accepts. The server receives the acceptance at 1.19950 and returns another re-quote. The trader accepts again. The server receives it at 1.19910. Another re-quote.
This loop is not just annoying. It can increase loss. During the loop, the trader remains exposed. If the position is leveraged, the account equity may deteriorate quickly. If the account is near margin close-out, repeated re-quotes can turn a controlled exit into forced liquidation. The lock-up risk is why Instant Execution is structurally poor for certain strategies, e.g. news scalpers. It makes emergency exits more unreliable during fast markets. Market Execution may produce ugly slippage, but it usually gives the trader a cleaner path to exit. A slipped exit is often better than no exit.
Practical Auditing and Operational Defense for Traders
Execution Type Suitability
For a trader, the first defense is choosing the correct execution type. For many strategies, Instant Execution is not the best choice. If your strategy cannot survive re-confirmation delay, do not run it in a re-quote environment.
As an example, news scalpers and algorithmic traders are generally not well-suited to Instant Execution models. These execution types typically rely on a price confirmation step, where orders may be requoted or rejected if the market has moved. This creates execution uncertainty during fast market conditions, which is structurally incompatible with strategies that depend on immediate and deterministic fills. Such strategies are usually better aligned with Market Execution models, raw spread or ECN-style accounts, or direct market access via APIs, where orders are filled against available liquidity and execution quality is reflected in slippage rather than requotes. However, even in these models, execution is not guaranteed and may still be affected by liquidity depth, volatility, and liquidity provider risk controls.
This does not mean Market Execution is always better. It only means it is cleaner for speed-dependent strategies. The trader receives the market result, good or bad, rather than being trapped in repeated quote confirmations. Slower discretionary traders may prefer Instant Execution because it gives another type of price control. If the broker cannot fill within the allowed deviation, the trader can reject the new quote. This is useful when entry precision matters more than certainty of execution. A trader placing one or two swing trades a week may tolerate occasional re-quotes. A CPI scalper firing 40 orders in three seconds cannot.
The Slippage and Re-Quote Log Audit
One way to stay on top of the re-quote situation and detect issues early on is to keep execution logs. Not simple screenshots, but actual logs that you continuously analyze. Screenshots can be handy as evidence, but how will you find out there is even something to prove if you don’t analyze the execution quality?
Examples: MT4 and MT5 journal files can show order submission times, server responses, errors, and trade confirmations. FIX API streams can show timestamps, reject codes, execution reports, last liquidity, and partial fills. cTrader and broker APIs may provide their own records.
The goal is to reconstruct the order lifecycle. A good audit tracks the ratio of re-quotes to total orders, re-quotes by symbol, re-quotes by time of day, re-quotes during news, re-quotes by trade direction, and re-quotes by account profitability. It should also compare the requested price, final fill, market spread, and independent reference prices.
The most important metric is not total re-quotes. It is asymmetry. If re-quotes cluster when the price moves in the client’s favor, but not when the price moves against the client, the trader has a serious execution concern. If positive slippage is absent while negative slippage is common, the trader should investigate.
A crude but useful measure is:
Positive Slippage Ratio = Positive Slippage Events / Total Slippage Events
and:
Requote Bias = Client-Favorable Requotes / Client-Adverse Requotes
The expected ratio depends on strategy, instrument, volatility, and order type. It will not be perfectly balanced. But a long sample with almost no client-favorable execution deserves attention.
Deviation Settings In Automated Trading Scripts
Deviation (slippage tolerance) in automated trading scripts should not be treated as a fixed constant across all market conditions. A static deviation value can lead to suboptimal execution, either by rejecting acceptable fills in volatile conditions or by allowing excessive slippage in stable markets.
A more robust implementation uses dynamic deviation scaling, where the maximum allowed price deviation is adjusted based on real-time market conditions. Key inputs typically include spread level, short-term volatility, instrument characteristics, trading session liquidity, and proximity to scheduled economic events.
For example, in low-volatility conditions such as EUR/USD during the London session, a tight deviation threshold may be appropriate to ensure execution quality. In contrast, during high-impact events such as CPI releases or when trading high-volatility instruments like XAU/USD, a wider deviation range may be necessary to maintain execution continuity.
Execution logic should also distinguish between entry and exit orders. Entry orders can tolerate stricter deviation rules, as missed entries generally have limited downside. Exit orders, particularly stop-loss or emergency risk-reduction executions, should allow wider deviation to prioritize execution certainty over price precision.
Automated systems that rely on fixed deviation values regardless of market regime often fail to account for liquidity fragmentation and volatility spikes. As a result, execution should be treated as a dynamic variable rather than a static parameter. When spread expansion exceeds predefined thresholds, or volatility moves outside the strategy’s design envelope, the system should reduce trading frequency or temporarily suspend order submission until market conditions stabilize.
A simple model is:
Allowed Deviation = Base Deviation + Volatility Adjustment + Spread Adjustment
Infrastructure Efficiency
Latency-driven re-quotes and execution problems cannot be eliminated entirely, especially during fast-moving markets, but they can often be reduced through better infrastructure design. The goal is not necessarily to achieve the lowest possible latency, but to achieve latency that is sufficiently low, stable, and predictable for the trading strategy being used. Improved infrastructure is not free, so there will always be trade-offs to consider.
Physical Distance
The first consideration is the physical distance between the trading system and the broker’s execution servers. Every network hop adds delay. If a trader operates an MT Expert Advisor (EA), algorithm, or API-based system from a home computer thousands of kilometers away from the broker’s servers, the resulting latency may be significantly higher than necessary.
For this reason, many traders use Virtual Private Servers (VPSs) located near major financial data centers. If a broker hosts its servers in London, a VPS located in or near the Equinix LD4 data center may reduce network latency substantially. (Equinix LD4 is located in Slough, Berkshire, England, just west of London.) If execution is primarily routed through New York liquidity venues, infrastructure near Equinix NY4 in New Jersey may offer similar advantages. For brokers connected heavily to Asia-Pacific liquidity providers, Tokyo’s Equinix TY3 facility is often an important financial networking hub.
Retail traders should understand, however, that these data center names are often discussed in trading communities with more enthusiasm than context. Simply renting a VPS near LD4, NY4, or TY3 does not automatically create institutional-grade execution. The trader’s order must still travel through the broker’s infrastructure, risk controls, liquidity bridges, and liquidity providers before reaching the market. Reducing latency helps, but it cannot eliminate execution risks created elsewhere in the chain.
It is also important to distinguish between a broker’s legal domicile and its trading infrastructure. Many traders mistakenly assume that a broker regulated in one country necessarily hosts its trading systems there. In reality, these are separate issues. A broker incorporated in Seychelles may operate trading servers in London, and a broker regulated in Cyprus may execute through New York-based liquidity providers. A broker can also use data centers spread across different parts of the world, e.g. Europe, North America, and Asia. Traders should therefore ask where the trading servers are physically located and where liquidity is sourced, rather than relying solely on the broker’s corporate address.
If you decide to use a VPS, the VPS should be evaluated carefully. Some VPS providers oversubscribe their hardware, causing unpredictable performance degradation during busy periods. CPU contention, insufficient memory allocation, overloaded storage systems, and unstable virtualization environments can all affect trading performance. As a result, a trading platform running on the VPS may occasionally freeze or become unresponsive during periods of high market activity. During a major news release, even a brief interruption can cause missed entries, delayed exits, or unintended order modifications.
Network Quality
Network stability can matter just as much as raw latency. A stable 40-millisecond connection is often preferable to a 10-millisecond connection that periodically spikes to several hundred milliseconds. Short bursts of packet loss, route instability, or server congestion can create execution delays that are far more damaging than a consistently moderate latency. It is also more difficult to adjust a trading strategy to an unpredictable network.
For this reason, traders should not get obsessed with ping time. To make a proper evaluation, you need to monitor several other metrics alongside ping time, such as average latency, latency variance (jitter), packet loss, disconnect frequency, server response times, and order acknowledgment times. A system that reports a low average ping but suffers intermittent packet loss may perform significantly worse than one with a slightly higher average ping but better stability.
Broker Infrastructure
Traders should also pay attention to the quality of their broker’s infrastructure. Some brokers maintain multiple trading servers, backup routes, and redundant network connections. Others operate on much more limited infrastructure. During periods of market stress, these differences can become apparent. A broker whose servers do not remain responsive during major news events makes the trading experience worse, even if it offers good nominal spreads or commissions.
Algorithmic Software
Trading bot developers should remember that latency is not solely a network problem. Software design can introduce significant delays as well. An MT Expert Advisor that performs excessive calculations before submitting an order can add measurable execution lag. Poorly optimized code may consume CPU resources unnecessarily, particularly when multiple symbols or timeframes are processed simultaneously.
Efficient automated systems generally follow several principles. Computationally intensive calculations should be minimized during execution-critical moments. When possible, values should be calculated in advance. It is also necessary to carefully manage database operations, file access, and external API requests.
Order management logic deserves particular attention. Some inexperienced developers implement aggressive retry mechanisms that repeatedly resend failed orders without understanding the reason for rejection. During a fast-moving market, this can create a series of progressively worse fills as prices continue to move away from the original entry point. In extreme cases, poorly designed retry logic may even create duplicate positions or unintended exposure.
A more robust approach is to classify execution failures and respond accordingly. A temporary connection issue may justify a retry. A requote during a volatile market may require recalculation of trade parameters. A spread spike may indicate that trading should be suspended temporarily. Automated systems should distinguish between these scenarios rather than treating all failures identically.
Professional vs. Retail
Professional trading firms tend to take infrastructure optimization much further than most retail traders can realistically justify. High-frequency trading firms often colocate their servers inside the same data centers as exchanges and liquidity venues. They may invest heavily in optimized networking equipment, dedicated fiber routes, microwave transmission networks, and custom hardware designed to reduce latency by microseconds.
For most retail traders, such measures are neither practical nor economically defensible. The costs involved can be substantial, and the potential benefits are often outweighed by the limitations of retail brokerage execution models. A trader running a swing strategy with holding periods measured in days gains little from reducing latency from 20 milliseconds to 2 milliseconds. Even many intraday traders will see far greater performance improvements from better risk management, execution controls, and broker selection than from pursuing institutional-grade infrastructure.
The objective for retail traders should therefore be reasonable optimization rather than extreme optimization. A reliable VPS near the broker’s infrastructure, a stable internet connection, efficient algorithm design, and ongoing monitoring of execution quality will usually deliver the majority of available benefits. Beyond that point, improvements become increasingly expensive while producing diminishing returns.
The Timeline Of An Order, When We Take Infrastructure Into Account
When we take infrastructure into account, it becomes clearer how the speed and timeline of two seemingly similar orders can vary significantly due to a variety of underlying factors.
Let’s look at a hypothetical retail trader using a MetaTrader trading platform from their home computer and sending orders through their standard consumer internet connection.
- At time zero, the trader sees EUR/USD quoted at 1.10000/1.10002 and clicks Buy at 1.10002. The trading platform creates an order message containing the order type, volume, account information, and requested price. If the trader has configured a maximum deviation setting, that value is included as part of the execution request.
- Within the next few milliseconds, the MetaTrader terminal processes the request locally. Under normal conditions, this is almost instantaneous, but local factors can introduce delay. A heavily loaded computer, antivirus scans, disk activity, insufficient memory, or an Expert Advisor performing complex calculations can add latency before the order even leaves the machine.
- The order is then transmitted across the trader’s local network. On a wired connection, this delay is usually negligible. On Wi-Fi networks, interference, congestion, or weak signal quality can introduce additional latency and occasional packet retransmissions. Mobile connections may be even more variable, particularly during periods of network congestion.
- Typically, between 5 and 100 milliseconds after the click, the order enters the public internet. It traverses multiple routers owned by internet service providers and backbone carriers. Each network hop adds a small amount of latency. Congested routes, packet loss, and suboptimal routing can add significantly more. A trader located in Germany connecting to a broker server in London may experience only a few milliseconds of network delay. A trader in Australia connecting to London may experience well over 200 milliseconds. If the trader uses a VPS located near the broker’s infrastructure, much of this geographic latency can be eliminated. Instead of the order traveling from the trader’s home to London, it may only need to travel a few kilometers between servers located within the same data center region.
- At approximately 10 to 150 milliseconds, the order reaches the broker’s trading server. The server validates the request by checking account permissions, available margin, symbol status, trading session availability, order size restrictions, and other risk controls. During periods of high market activity, thousands of orders may arrive simultaneously, creating processing queues that add additional delay. At this stage, the broker also performs a price validation check. The price displayed to the trader may already be outdated. The broker compares the requested price against the current executable quote available on the server. If the new market price remains within the trader’s allowed deviation range, execution may proceed. If not, the order may be rejected or requoted, depending on the broker’s execution model.
- For dealing-desk or market-maker brokers, an additional internal processing layer may exist. The broker may decide whether to internalize the trade, offset the exposure elsewhere, or apply additional risk-management rules. This process is usually automated, but still consumes time.
- For brokers using external liquidity providers, the order may next pass through a bridge or gateway system. The bridge translates the MetaTrader order into a format compatible with the broker’s liquidity infrastructure. Additional validation and routing logic may be applied here. Depending on the broker’s architecture, the order may be sent to a single liquidity provider or to an aggregator connected to multiple banks and market makers.
- At roughly 20 to 250 milliseconds after the original click, the order reaches the liquidity venue. The liquidity provider evaluates whether the quoted price remains available. In a true market execution environment, the order may simply execute at the best available price. In other environments, the liquidity provider may apply last-look logic, allowing a brief period to determine whether the trade will be accepted or rejected. If multiple liquidity providers are connected, the broker’s aggregator may compare available prices and select the best available source of liquidity. While this process is highly automated and extremely fast, it is not instantaneous. Additional microseconds or milliseconds may be consumed as quotes are collected and evaluated.
- Assuming execution is approved, the trade is filled, and an execution confirmation is generated. The confirmation then begins the return journey. The fill information travels from the liquidity provider back through the broker’s bridge, risk systems, and trading servers. The broker updates the account balance, margin calculations, open position records, and transaction logs. During busy market periods, these post-trade operations can contribute additional latency.
- The execution confirmation is then transmitted across the internet back to the trader’s platform. Once again, the quality of the network path matters. Packet loss, route instability, or congestion can delay the confirmation message.
- Finally, typically somewhere between 30 and 500 milliseconds after the original click, though sometimes longer during volatile market conditions, the trader sees the position appear in the trading platform. In extremely fast markets, the market may have moved substantially during this period.
Note: For most retail traders, the largest delays are often not network latency but broker-side processing, liquidity-provider response times, and execution-model decisions. A trader may spend money reducing latency from 40 ms to 5 ms while their broker routinely spends 100–300 ms performing risk checks and routing orders. That is one reason why broker selection often has a larger impact than VPS optimization alone.
Broker Selection For Re-Quote-Sensitive Strategies
A trader with a re-quote-sensitive trading strategy should ask specific questions before funding.
- Does the account use Instant Execution or Market Execution?
- Does the broker return re-quotes or fill with slippage?
- Does the broker pass positive slippage to clients?
- Does it publish execution quality statistics?
- Does it disclose rejection rates? Does it use last look liquidity?
- Does it internalize flow?
- Does it permit news scalping?
- Does it define latency arbitrage broadly?
- Does it reserve the right to cancel trades after execution?
The answers should come from the order execution policy and client agreement, not only live chat. If you do consult the customer service staff, make sure you do it in writing (not phone calls) and save all communication independently of the platform. We also know from our own customer support tests that live chat agents are rarely able to answer such technical questions sufficiently – expect boilerplate answers or to be directed to email support.
Typically, jurisdictions with strong trader protection rules require the broker to have a firm order execution policy and share it with clients and prospective clients. A brokerage company licensed by a more lax jurisdiction may have looser disclosure. That does not automatically make it bad, but it makes it more difficult to evaluate, and successfully challenging the broker’s decisions after the fact will also be difficult. It therefore becomes even more important for the trader to carefully test and evaluate the broker using micro-sized trades and comparing fills with independent data.
Handling Re-Quotes In Live Operation
- A discretionary trader should not chase every re-quote. If the market has moved beyond the original trade thesis, rejecting the re-quote may be the correct decision.
- An algorithm should have re-quote logic. It should know when to retry, when to widen deviation, when to abandon entry, and when to prioritize exit. The retry loop should have a maximum count and time limit. Infinite retry logic during fast markets is how a small error becomes a large position at a stupid price.
- A useful rule is to separate entry and exit logic. Entry re-quotes should usually be treated conservatively. If the price has moved too far, skip the trade. Exit re-quotes should be handled more aggressively, especially if risk is rising. The cost of a worse exit may be lower than the cost of staying exposed.
What To Do When Execution Looks Abusive
If execution appears abusive, the trader should preserve evidence before confronting the broker. Export account history, platform journal logs, Expert logs, VPS timestamps, screenshots, independent tick references, order IDs, and broker server times. Then submit a formal complaint using the broker’s complaint process. The complaint should avoid drama. It should state the facts: order ID, requested price, server time, fill or re-quote price, market reference, expected treatment under the execution policy, and the remedy requested.
If the broker is regulated in a jurisdiction with strong trader protection, the trader may escalate to the relevant ombudsman or regulator if the complaint is not resolved. If the account is in a lax jurisdiction, the available route may be weaker. Execution-sensitive traders, like many day traders are, should evaluate legal recourse before picking a brokerage company.
Why Do Traders Pick The Instant Execution Model, Despite The Risk Of Requotes?
For many trading strategies, Market Execution is a better pick, but Instant Execution does have its legitimate uses, and Market Execution is not without drawbacks. The key trade-off is that Market Execution exchanges requote risk for slippage risk.
With Instant Execution, the trader attempts to trade at the price currently quoted by the broker’s platform. When the trader clicks Buy or Sell, the order is submitted at the displayed price. If the price is still available when the order reaches the broker, the trade is executed at that price. If the price is no longer available, the broker may reject the order and return a requote with a new price.
This can be attractive for traders who are highly sensitive to the entry price. For example, a short-term range trader aiming for 5–10 pips may prefer a requote over being filled several pips away from the intended entry. In such cases, execution certainty is less important than price certainty.
Another reason is psychological. Many retail traders dislike seeing negative slippage because it is immediately visible in the trading record. A requote may feel less painful than being filled at a worse price, even though both outcomes ultimately reflect the same market reality: the requested price was unavailable.
Historically, Instant Execution was the dominant execution model among retail forex brokers because many operated dealing-desk models where quotes were not fully firm. While it remains available at some brokers, it has become less common as Market Execution and liquidity-based execution models have gained retail market share.
Instant Execution can work reasonably well in stable markets, and this can lull inexperienced traders into a false sense of security. During liquid periods with low volatility, requotes may be relatively rare, allowing traders to obtain exact prices most of the time. In these conditions, the disadvantages of the model are less noticeable. The key is to develop a working strategy for how to stay out of trading when conditions are no longer likely to favor the Instant Execution model. The drawbacks of Instant Execution can quickly become apparent when the market starts moving fast.
A simple way to think about the trade-off is:
- Instant Execution: prioritizes price certainty, but sacrifices execution certainty.
- Market Execution: prioritizes execution certainty, but sacrifices price certainty.
Neither model is inherently better. The choice depends on whether the trader is more concerned about receiving the requested price or about ensuring that the order is executed immediately. For most modern automated and high-speed trading strategies, execution certainty is usually the more important requirement, which is why Market Execution has become the dominant model in institutional and algorithmic trading.