IC Markets Asia vs London server: which for Tokyo session scalps?

[LondonScalper]

Tokyo session on a London VPS used to feel like a clever shortcut until I measured it.

I run IC Markets. For a while I assumed one London server was "fine" for everything, including the quiet AUD and JPY pairs I sometimes scalp before Europe wakes. The fills were acceptable on paper, but the spread-at-click vs fill gap on Tokyo morning was noisier than the same pairs after 07:00 London. Latency is not just ping — it is how often the quote you clicked is already gone.

What I compare now

• Median round-trip from click to ack on Tokyo hours vs London cash open
• Reject / requote count on USDJPY and AUDUSD before 05:00 London
• Whether Asia server actually tightens the live spread or only the ping number

I am not chasing microseconds. I am asking whether the desk I use for London should also host the overnight book. If the Asia server wins on rejects but loses on swap or symbol mapping quirks, that goes in the broker scorecard too.

Has anyone here kept both an Asia and London IC (or similar) path and actually logged which one earns its keep for Tokyo scalps?

I also watch whether symbol mapping and swap show any oddities on the Asia path — a faster ping is worthless if the contract I think I am trading is not the one in the ticket. Once a month I re-run the same three-check sample so summer liquidity shifts do not silently rewrite the conclusion.

[PTScalper]

Tokyo session on a London VPS used to feel like a clever shortcut until I measured it.

I run IC Markets. For a while I assumed one London server was "fine" for everything, including the quiet AUD and JPY pairs I sometimes scalp before Europe wakes. The fills were acceptable on paper, but the spread-at-click vs fill gap on Tokyo morning was noisier than the same pairs after 07:00 London. Latency is not just ping — it is how often the quote you clicked is already gone.

What I compare now

• Median round-trip from click to ack on Tokyo hours vs London cash open
• Reject / requote count on USDJPY and AUDUSD before 05:00 London
• Whether Asia server actually tightens the live spread or only the ping number

I am not chasing microseconds. I am asking whether the desk I use for London should also host the overnight book. If the Asia server wins on rejects but loses on swap or symbol mapping quirks, that goes in the broker scorecard too.

Has anyone here kept both an Asia and London IC (or similar) path and actually logged which one earns its keep for Tokyo scalps?

I also watch whether symbol mapping and swap show any oddities on the Asia path — a faster ping is worthless if the contract I think I am trading is not the one in the ticket. Once a month I re-run the same three-check sample so summer liquidity shifts do not silently rewrite the conclusion.

Hi LondonScalper,

The discrepancy you are logging between the terminal ping and the actual click-to-ack round trip is the classic access-point illusion. The ping number in the terminal footer measures the distance to the nearest proxy server, while the journal logs the brutal reality of physical distance to the matching engine.

With IC Markets, the infrastructure is heavily centralized:

MT4 / MT5 Matching Engines: Anchored in Equinix NY4 (New York).
cTrader Engines: Anchored in Equinix LD5 (London).

Here is how the Equinix Forex Triangle (NY4, LD4, TY3) actually behaves when you measure the microstructure of a Tokyo session scalp.

[PTScalper]

The Proxy Ping Trap

If you move your VPS to Equinix TY3 (Tokyo) or SG1 (Singapore) assuming it will tighten the Asian session spread, you step into a geographic trap. The platform will show a beautiful <2ms vanity ping because you are connecting to a local Asian access proxy. However, an MQL OrderSend or cAlgo execution must still traverse the Pacific to reach the NY4 or LD5 matching engine, and then travel back. Your terminal ping looks elite, but your true click-to-ack round trip jumps to 150–200ms+. You gain zero actual spread tightening and effectively guarantee worse execution on fast price action.

Why Quote Decay Bites Harder in Tokyo

The spread-at-click vs. fill gap you are experiencing is purely a function of top-of-book depth colliding with latency.

During the London cash open, a 35ms transatlantic delay (an LD4 London VPS routing to an NY4 MT4 server) is largely masked. The liquidity pool is deep enough that even if you are 35ms late to the quote, there are enough lots remaining at that price to fill you. During the Tokyo morning, top-of-book liquidity on AUDUSD and USDJPY is microscopic. When a 1-minute or 5-minute liquidity sweep occurs, market makers yank quotes in milliseconds. That same 35ms delay means the 2-lot quote you clicked is already gone. The result is exactly what you logged: higher reject counts, max-deviation failures, and nasty negative slippage.

[PTScalper]

Symbol Mapping and Swap Oddities

Your instinct to watch for contract and swap anomalies on different servers is spot on. When you test an "Asia" setup and are assigned a different Live server number (e.g., one provisioned for APAC clients), you are not just taking a different network route. You are often placed on a completely different PrimeXM or OneZero liquidity bridge. Because the server has a distinct risk configuration, its overnight swap rates, spread markup logic, and even symbol suffixes (like AUDUSD.a) can differ silently from the primary London/NY servers. A faster ping is worthless if the new bridge configuration actively bleeds your swap or alters the symbol execution logic.

The Verdict for the Overnight Book

If you are scalping raw price action where grabbing the exact quote matters, optimize strictly for the broker's matching engine, not the time zone of the session you are trading.

If you trade MT4/MT5: Migrate your VPS to NY4 (New York). This cuts the 35ms transatlantic lag down to <2ms, giving you the best possible chance of securing thin Tokyo liquidity before it decays.

If you trade cTrader: Stay in LD4/LD5 (London). You are already sitting directly on top of the matching engine.

Do not split the book to an Asian VPS for this specific broker. You will only inherit the worst of both worlds: proxy-server latency masked by a fake ping, and completely variable bridge configurations.

[PTScalper]

The only way to measure true execution latency is to capture a high-resolution local timestamp the microsecond before the order payload leaves your machine, and another the microsecond the terminal receives the broker's acknowledgment.

If you rely on server time functions (like TimeCurrent() in MQL), you are measuring the broker's clock, not the network round-trip.

Here is how to build this locally in both MQL5 and cTrader (cAlgo).

[PTScalper]

MQL5 (MetaTrader 5) Implementation

In MQL5, GetMicrosecondCount() is the function required to retrieve local machine ticks independent of the broker's data feed.

Code: Select all

// Define the trade request and result structures
MqlTradeRequest request={0};
MqlTradeResult result={0};

// ... setup request parameters (symbol, volume, type, etc.) ...

// 1. Capture local microsecond timestamp BEFORE sending
ulong start_time = GetMicrosecondCount();

// 2. Execute the order
bool success = OrderSend(request, result);

// 3. Capture local timestamp IMMEDIATELY upon return
ulong end_time = GetMicrosecondCount();

// 4. Calculate true round-trip latency in milliseconds
double execution_ms = (end_time - start_time) / 1000.0;

// 5. Calculate slippage (difference between requested price and actual fill)
double slippage_points = MathAbs(request.price - result.price) / SymbolInfoDouble(request.symbol, SYMBOL_POINT);

// 6. Log the results
PrintFormat("EXECUTION LOG | Symbol: %s | Latency: %.2f ms | Slippage: %.1f points | Status: %s | Retcode: %d", 
            request.symbol, execution_ms, slippage_points, success ? "FILLED" : "REJECTED", result.retcode);

[PTScalper]

cTrader / cAlgo (C#) Implementation

Because cTrader is a .NET environment, you can bypass the trading API's internal time functions entirely and use the standard System.Diagnostics.Stopwatch for maximum thread-blocking precision.

Code: Select all

using System;
using System.Diagnostics;
using cAlgo.API;

[Robot(TimeZone = TimeZones.UTC, AccessRights = AccessRights.None)]
public class ExecutionLogger : Robot
{
    protected override void OnStart()
    {
        // Example execution trigger
        ExecuteTradeWithLogging(TradeType.Buy, SymbolName, 10000);
    }

    private void ExecuteTradeWithLogging(TradeType tradeType, string symbol, double volume)
    {
        // Capture the exact top-of-book quote at the moment of intent
        double requestedPrice = tradeType == TradeType.Buy ? Symbol.Ask : Symbol.Bid;
        
        Stopwatch stopwatch = new Stopwatch();
        
        // 1. Start the high-resolution timer
        stopwatch.Start();
        
        // 2. Send the synchronous execution request
        TradeResult result = ExecuteMarketOrder(tradeType, symbol, volume, "LatencyTest");
        
        // 3. Stop the timer the moment the thread unblocks
        stopwatch.Stop();
        
        // 4. Extract metrics
        long executionMs = stopwatch.ElapsedMilliseconds;
        
        if (result.IsSuccessful)
        {
            double slippagePips = Math.Abs(requestedPrice - result.Position.EntryPrice) / Symbol.PipSize;
            Print($"EXECUTION LOG | {symbol} | Latency: {executionMs} ms | Slippage: {slippagePips:F1} pips | FILLED");
        }
        else
        {
            Print($"EXECUTION LOG | {symbol} | Latency: {executionMs} ms | Status: REJECTED | Error: {result.Error}");
        }
    }
}

[PTScalper]

Analyzing the Output

Logging the latency is just the first step. To map exactly how the Tokyo session behaves compared to the London open, append this data to a local CSV file (using FileWrite in MQL5 or standard System.IO.File in C#) and track these three variables together:

Execution Latency (ms): The exact time the thread was blocked waiting for Equinix NY4/LD5. Spikes here correlate directly with the quote decay you observed.

Slippage (Points/Pips): The delta between your recorded requestedPrice and the fill. Tracking this reveals if the liquidity bridge is applying asymmetric slippage (holding your order to see if the price drops before filling you, which is common in thin Asian hours).

Local Time of Day: Essential for isolating the 00:00–05:00 UTC liquidity shifts vs. the 07:00 UTC London volume injection.

Run this side-by-side on your current VPS setups during the Tokyo open, and the CSV output will instantly show if an Asian server configuration is actually executing better, or just spinning its wheels on the backend.

[LondonScalper]

That matches what the journal was hinting at. The Asia path gave me a lovely number in the terminal corner and no improvement where it counts, which only makes sense if the order still has to travel to the same engine.

My London book is on cTrader, so the LD5 point is the reassuring half: I'm already sitting where the orders get matched and there's nothing to move. The overnight AUDUSD and USDJPY tickets go through the MT5 account, and that is where your NY4 suggestion bites. I'd been treating the London VPS as neutral for that account when it's really adding a transatlantic leg to every click.

Before I move anything I'll run the local-timestamp logger on both paths for two weeks of Tokyo mornings, midnight to 05:00 London, and compare the median and the 90th percentile rather than the average. If NY4 halves the reject count, the extra VPS bill is easy to justify. If it doesn't, the thin book is the real problem and no hosting choice fixes that.

The server-suffix warning I've met once already: a demo on a different server number quoted AUDUSD with a suffix and a different swap line. I read the contract spec on any new login now before the first ticket.