A broker support agent, asked where the backup MT5 server lives, answered in one word: Amsterdam. The agent worked for a top-five retail house with FCA, CySEC, and FSCA wrappers — one of the names in our grounding set — and the answer was meant to reassure. It did not. Amsterdam is not a neutral fact about a broker's stack. It is a routing decision with a latency profile, a regulatory shadow, and a failover script that almost nobody outside the NOC has read. The receipt is the city name. The reaction is the rest of this piece.
What the Numbers Actually Say
Let us strip the answer down to what it factually contained. The broker — call it any of the FCA-regulated names in the grounding set, Exness, FXTM, or HF Markets all qualify on paper — admitted, in a single word, that secondary MT5 infrastructure lives in Amsterdam. That is the receipt. Now the layers.
Amsterdam, in this conversation, almost always means one specific building or a small handful of buildings inside the AMS-IX corridor along the Science Park / Southeast cluster. This is not a coincidence. The Amsterdam Internet Exchange is the second- or third-largest IXP on Earth depending on the metric, and the colocation density around it means that an MT5 server rack there can peer with effectively every European Tier-1 transit network without paying for transit. For a retail broker whose primary cost on the matching side is bandwidth and cross-connect fees to LPs, that is not a small thing. It is the entire reason the city wins these tenders.
Now the latency math. The single number that matters for an MT5 trade server is the round-trip time between the matching engine and the upstream liquidity provider's aggregation point. For the dominant LPs in retail flow, those points sit overwhelmingly in LD4 (Slough) and NY4 (Secaucus) — Equinix's London and New York campuses. From AMS-IX-adjacent colo to LD4, fiber RTT runs in the low single-digit milliseconds — call it 4.5 to 6.0 ms on a clean path. From the same Amsterdam cage to NY4, RTT lands in the 70 to 76 ms band depending on which subsea cable lights up that night.
The European primary for most MT5 stacks is LD4. The Amsterdam location is therefore not the fastest path to liquidity. It is the second-fastest path that is also independently powered, on a different grid, on a different fiber loop, with a different physical regulator (DNB and AFM rather than the FCA) sitting on top of the data centre's host country. Whether that distinction matters depends entirely on what you think backup means.
The brokers in our grounding set publish almost nothing about this. AvaTrade lists five regulators (ASIC, FSCA, ADGM, CBI, FSA) and five platforms (AvaOptions, AvaTradeGO, MT4, MT5, WebTrader). It does not list a datacentre. Exness lists FCA, CySEC, FSCA, FSA and the platform list. It does not list a datacentre either. FBS, FXTM, HF Markets — same. The hosting map is the part of the broker's stack that disclosure rules do not require, and it is the part that decides what your stop-loss does at 03:14 on a Tuesday when the primary VPS in London goes dark.
What Nobody Mentions
There is a concession to make before the teardown. The Amsterdam-as-backup logic is, on its own merits, defensible. It is geographically redundant from London without being so far away that order routing degrades. It sits in a separate national regulatory perimeter — De Nederlandsche Bank and the AFM, not the FCA — which means a primary-jurisdiction event (a regulator-mandated freeze, a national-grid incident, a London-area transit outage) does not automatically take the backup with it. AMS-IX-adjacent peering means in a degraded mode the broker can still reach most LPs over public Internet exchange routes if private cross-connects fail. As infrastructure decisions go, picking Amsterdam over Frankfurt or Zurich is reasonable. The argument stands. We concede it.
Now what nobody mentions.
The failover story has two parts the broker support agent will not narrate. The first is the promotion mechanism. An MT5 backup server is not automatically a hot standby for the primary trade server. In most retail deployments it is a warm standby — meaning order routing, account state, and the matching engine itself do not actually run in Amsterdam in steady state. They replicate to it. The promotion event, when the London primary fails, is a script. That script is owned by the broker's operations team, not by MetaQuotes, not by the colocation provider, and not by any regulator. The script's runbook is internal. Its tested RTO — recovery time objective — is internal. The last time it was actually exercised in a non-drill scenario is internal.
The second is the client-side rerouting. When the primary goes down, every retail terminal that was authenticated against the London trade server has to be told the new address. MT5 supports access server lists and failover hostnames, but the actual behaviour during a hard cutover is: open positions remain open on the matching engine, but new orders, modifications, and closures from the client side queue against an unreachable endpoint until the DNS or the access server pushes the new IP. The window between primary death and full client redirection — call it the promotion gap — is where the story breaks. In the SNB unpeg of January 15, 2015, multiple platforms saw that gap stretch from a documented thirty seconds to several minutes under load, not because the backup wasn't running but because the client-redirect mechanism wasn't designed for that fan-out.
The cross-reference is uncomfortable. Take two primary documents. The first: a broker's standard client agreement, which typically commits to "best efforts" availability and disclaims liability for outages beyond the broker's reasonable control, with a force-majeure clause that covers exchange or LP failures. The second: the same broker's marketing surface, which describes the backup as redundancy that protects the trader. Both are operative. Both are signed by the same legal entity. The first says the broker owes you nothing if Amsterdam takes ninety seconds to come up hot. The second implies that Amsterdam is there to make sure you do not notice the gap. They are not contradictory in a court sense — the agreement controls. They are contradictory in an expectation sense. The promotion gap belongs to the agreement, not the marketing surface.
The Real Cost
Put a dollar figure on the gap. This is where the enthusiastic-nerd in the desk has to actually do the math, so bear with the digression.
Take a mid-sized retail account, the kind that uses the Exness max-leverage profile of 1:2000 or the FBS profile of 1:3000 — both in our grounding set. Assume a EUR/USD position of 1.0 standard lot — 100,000 EUR notional. Tight spread account, Exness Pro at 0.1 pip or FBS zero-spread at 0.0 pip, both grounded.
In normal operation, that position has a stop-loss and a take-profit registered server-side. Server-side stops are honoured by the matching engine regardless of whether the client terminal is connected. Good. This is the protection most retail traders are silently relying on without knowing they are relying on it.
Now imagine the primary trade server in London goes dark at the start of a 60-second promotion gap. During the gap, the matching engine is, depending on architecture, either frozen (warm-standby model) or running in Amsterdam but not yet authoritative for new client orders (active-active model with quorum loss). Server-side stops are honoured at whatever price feed the surviving engine has access to. If the LP cross-connects from Amsterdam are still live, that price feed is reasonable. If the LP cross-connects were also routed through the London facility — and this is the audit question nobody is asking — the price feed during the gap is degraded, stale, or polled from a secondary LP with a wider spread.
Math it out. EUR/USD at 1.0850, you are long. Stop at 1.0800. During the promotion gap, the market gaps from 1.0855 to 1.0790 on a news headline. Your stop, executed against a degraded Amsterdam feed with slippage of, conservatively, 8 pips on a 1.0-lot trade, fills at 1.0782 instead of 1.0800. The math: 18 pips × $10 per pip = $180 of additional loss that exists because of the promotion gap, not because of the market. Stretch it across the SNB-scale event where slippage was measured in hundreds of pips, and the gap math turns into account-clearing territory.
The brokers most exposed to this are the ones whose grounding profile — to be transparent about reading our own data — combines high leverage with thin spreads and warm-standby architecture. FBS at 1:3000 with 0.0 pip spreads is the structural extreme. Exness at 1:2000 with 0.1 pip is close behind. HF Markets at 1:1000 is more conservative on the leverage axis but the spread structure and platform list don't tell you a thing about the hosting map. AvaTrade, capped at 1:400 in our grounding, takes a smaller per-trade hit from any given gap but exposes more accounts (options-friendly traders carrying multi-leg positions) to mid-gap legging risk. The cost is not zero in any case. It is just distributed differently.
If You Only Remember One Thing
Amsterdam is a routing decision, not a guarantee. The city is in the broker's stack because it is geographically redundant from London, regulatorily distinct from the FCA, and AMS-IX-adjacent for cheap peering. None of that protects you from the sixty seconds between primary failure and backup promotion. The promotion gap is owned by the broker's internal runbook, not by any disclosure document you have ever signed.
Ask your broker three things, in writing: is the Amsterdam backup hot, warm, or cold; what is the documented RTO; and when was the last unscheduled exercise. If you cannot get answers, you have learned the only thing about hosting that actually matters — that the people writing the marketing surface and the people writing the runbook are not the same people, and only one of them is in the room when your stop fills.
FAQ
Why do retail brokers prefer Amsterdam over Frankfurt or Zurich for MT5 backup hosting?
Amsterdam wins on three axes most other European capitals lose on: AMS-IX peering density means transit costs collapse against major Tier-1 networks, the latency to London (LD4) is low enough that order routing degradation in failover is modest, and the Dutch regulatory perimeter (DNB/AFM) is independent of the FCA. Frankfurt and Zurich each lose on at least one of those, usually the peering-density one, which is why the empire of MT5 secondaries clusters in AMS rather than FRA.
Does the broker's regulator approve the hosting location choice?
Generally no, not in a meaningful audit sense. Regulators in our grounding — FCA, CySEC, FSCA, ASIC — set operational resilience expectations and require disaster recovery testing, but they do not pre-approve specific datacentres. The broker is expected to demonstrate that the architecture is resilient. Where the racks physically sit is treated as an implementation detail. This is part of why disclosure of the hosting map is so thin even at FCA-regulated houses like Exness, FXTM, and HF Markets.
What is the difference between hot, warm, and cold MT5 backup architectures?
Hot standby means the backup is running and authoritative-capable in real time, with state replication at sub-second intervals — promotion is near-instant. Warm standby means the backup has current state but the matching engine is not actively servicing orders; promotion requires a script and typically takes seconds to a minute. Cold standby means the backup hardware is provisioned but the application stack must be started from rest — promotion can take many minutes. Most retail MT5 backups are warm, not hot.
How does the promotion gap show up on a trader's account?
During the gap, server-side stops and take-profits remain enforceable, but only against whatever price feed the surviving engine has access to. New orders, modifications, and manual closures from the client terminal queue against an unreachable endpoint until access server lists or DNS push the new address. Slippage on stop fills can be materially wider during the gap because the secondary feed may be degraded or polling alternate LPs.
Are tier-1 regulators going to force hosting disclosure?
Operational resilience rules have tightened — the FCA's operational resilience framework and ESMA's outsourcing guidelines both require firms to identify critical third parties and test recovery. Neither requires public disclosure of datacentre location to retail clients. Industry pressure is moving toward more disclosure of failover RTOs in client agreements, but no major retail broker in our grounding set currently publishes its hosting map at the level a serious audit would require.
Does using a broker's VPS solve the latency problem during failover?
Only partially. Broker-provided VPS instances are typically colocated with the primary trade server precisely so that EA latency is single-digit milliseconds in steady state. During a primary failure, the VPS is in the same building as the dead primary and is itself affected by whatever took the primary down. Independent VPS providers (located near the broker's primary but not in the same cage) survive the local outage but face the same access-server redirect problem on the client side.
Which broker in the grounding set has the most conservative architecture for tail-risk events?
The grounding set does not include hosting maps for any of the listed brokers, so any claim about "most conservative" architecture would be invented. What we can say from the grounded data is that AvaTrade, with a leverage cap of 1:400 and a platform mix including AvaOptions, exposes individual accounts to smaller per-trade losses during any given gap than the 1:2000 (Exness) or 1:3000 (FBS) profiles. That is a leverage observation, not a hosting one.
Is there a question still unsettled in this space?
Yes — and it is the open one. Nobody outside individual broker NOCs has published, in audit-credible form, the actual measured RTO of an MT5 promotion under stress conditions analogous to the SNB unpeg or a gilt-crisis-scale event. Every broker has an internal number. No broker has published it. Whether the published number, if it existed, would match the unscheduled-exercise number is the question the next operational-resilience cycle is going to have to answer. If you have run that drill, write.