What this chapter covers
Every vendor category in the BrokerageAtlas Phase 2 canon sits on top of a physical infrastructure layer. Liquidity connections run across network fabric. CRM databases live in a data centre. KYC document stores sit on servers subject to data-residency rules. This chapter covers that layer.
Brokerage hosting resolves into three distinct procurement decisions, each owned by a different buyer inside the broker organisation, each with its own vendor sub-market, and each with its own logic for what constitutes a good choice. The decisions are: where the broker hosts its own MT4/MT5/cTrader server cluster; what VPS partner the broker recommends or resells to retail clients running expert advisors; and what low-latency network connects deal-desk infrastructure across LD4, NY4, and TY3.
These decisions tend to produce the longest-tenure vendor relationships in the entire stack. Institutional colo contracts run three to seven years. Getting the selection wrong compounds across every other chapter in this canon: latency, data residency, and disaster recovery posture all inherit from hosting.
This is also the closing chapter of Phase 2. Fourteen chapters, 140 reviewed vendors, the founding canon of the brokerage tech stack.
The 3 procurement decisions
1. Hosting the broker’s own MT4/MT5 server cluster
This decision is owned by the infrastructure team or CTO. The question is not simply “which data centre is cheapest” but rather “which data centre minimises the latency path to our primary liquidity providers while satisfying our regulatory data-residency requirements and our operational resilience obligations.”
The dominant venue axis is LD4 vs NY4 vs TY3. LD4 is Equinix’s London campus in Slough, housing the largest concentration of FX liquidity venues, ECNs, and prime brokers in the world. Most tier-1 FX aggregation occurs here; a broker whose primary LP relationships run through London gains the most from LD4 presence. NY4 in Secaucus, New Jersey is the equivalent concentration for US equity and multi-asset execution. TY3 is Equinix’s Tokyo facility, relevant for brokers with significant APAC client flows or LP relationships through Tokyo.
Three main paths exist:
Colocating directly with Equinix gives a broker the most control over configuration, network fabric, and cross-connect choices. Equinix operates at LD4, NY4, TY3, and dozens of other global locations, providing a consistent carrier-neutral framework. The tradeoff is operational overhead: the broker must manage its own server fleet, cross-connect ordering, and network configuration internally or through a managed service on top.
Beeks Group (LSE AIM: BKS) operates what it describes as Proximity Cloud, a managed hosting environment built inside Equinix facilities at LD4, NY4, TY3, FR2, HK1, SY3, and ZH4. The managed layer handles provisioning, monitoring, and MT4/MT5-specific configuration while the broker retains the latency benefit of genuine proximity. Beeks is a public company; its AIM filings disclose revenue, customer concentration, and churn metrics, which gives brokers a financial-stability verification path not available with private vendors.
CNS (Commercial Network Services) is the third path: a specialist managed hosting provider for MT4/MT5 operators. CNS publishes pricing, with tiers beginning around $35/month for a Value Edition through Standard and above. This makes CNS the most accessible institutional option on a per-line-item basis, though it is a single-region managed service and requires explicit DR contract terms to satisfy FCA SYSC or MiFID II Article 16 operational resilience expectations.
For UK-regulated brokers with FCA authorisation or data-residency commitments to UK-incorporated subjects, Pulsant operates 12 UK data centres with a specific positioning on UK sovereign data residency. Pulsant is a regional option, not a global PoP provider, but it covers the UK sovereignty use case in a way that LD4-centric providers do not emphasise.
Regulatory data-residency requirements vary by authorisation. CySEC-authorised Cyprus Investment Firms operating under MiFID II must keep in-scope client data within the EU (Cyprus or another EU member state satisfies this; LD4 UK-hosted data does not post-Brexit without appropriate safeguards). FCA-authorised firms have a UK preference in practice even though the UK GDPR does not categorically prohibit EU hosting. DMCC and VARA-regulated firms operating in the UAE face onshore data requirements for in-scope crypto-asset activities. ASIC-authorised Australian firms face residency rules for client data under the Australian Privacy Act. A broker with multiple regulatory authorisations may need hosting presence across multiple venues simultaneously.
2. VPS partner for retail clients running expert advisors
This decision is owned by retention and marketing. The question is which VPS vendor the broker recommends - formally or informally - to its retail clients running MT4/MT5 expert advisors around the clock.
The economics of this decision are asymmetric. Clients who run EAs on VPS adjacent to the broker’s own server gain lower latency and fewer disconnection events. They tend to be higher-value accounts. A broker who steers clients toward a VPS with a partnership programme can receive revenue share, co-marketing, or free-tier-for-deposit-threshold arrangements. A broker who ignores this decision leaves both retention and economics on the table.
Three vendors dominate:
ForexVPS.net has the most extensive broker integration list in the retail VPS market, with over 40 broker integrations at time of writing. The integration list itself is the product moat: clients already tied to a particular broker-server host face switching costs. ForexVPS.net operates a formal broker partnership programme through which brokers can sponsor it as the recommended VPS to their client base. Pricing runs from approximately EUR 22.40/month for a Core tier through EUR 44/month for the Prime tier, with dedicated options from approximately EUR 232/month. The operating entity is registered in Wyoming, USA. ForexVPS.net is therefore subject to GDPR Article 46 standard contractual clauses (SCCs) requirements for EU-regulated brokers entering a partnership. The US adequacy framework was affected by the Schrems II ruling; SCCs remain the operative mechanism.
ChartVPS is a smaller operation with a differentiated compliance posture: it holds SOC 2 Type I attestation, which is unusual for a retail-facing VPS provider and is directly relevant to broker compliance teams conducting vendor due diligence. Pricing runs from $50 to $180/month for Alpha through intermediate tiers, and $250 to $450/month for the Delta tier. ChartVPS is UK-registered, meaning the UK adequacy decision (currently valid post-Brexit as of 2026) applies to data transfers from EU brokers partnering with ChartVPS, removing the SCC requirement that applies to US and HK entities.
FXVM is operated by ThinkHuge Ltd, a Hong Kong-registered entity. Pricing is the lowest in this sub-market, from approximately EUR 13/month through EUR 43/month, with a EUR 1 trial entry point. For EU-regulated brokers considering a partnership with FXVM, GDPR Article 46 SCCs are a legal requirement for the data transfer to a Hong Kong entity. This is not prohibitive, but it is an administrative and legal overhead that brokers should factor into the partnership assessment. Brokers operating under FCA authorisation should confirm their own GDPR transfer mechanism requirements.
3. Low-latency network across LD4/NY4/TY3
This decision is owned by trading infrastructure and, in larger broker organisations, the quant or execution team. It is relevant for brokers running cross-region arbitrage, multi-venue execution, or real-time deal-desk infrastructure spanning multiple geographic PoPs.
Three vendors operate in this segment:
Avelacom is a low-latency network provider with presence at over 100 exchange and venue PoPs globally. It positions itself primarily toward institutional trading firms rather than retail broker operators, but any broker running significant cross-venue execution or managing LP relationships across LD4 and TY3 simultaneously will encounter it in an RFP process.
Lucera is wholly owned by BGC Group (NASDAQ: BGC) and uses a software-defined networking architecture. The SDN approach enables API-driven provisioning, which matters for brokers whose deal-desk configurations change frequently or who need to add new LP connections programmatically rather than through a six-week cross-connect order process.
TNS Financial Markets has merged with Radianz (formerly a BT unit) to form Waypoint Trading Solutions. The combined entity inherits the Radianz network’s legacy of serving sell-side banks and ECNs. Brokers who contracted with TNS before the Waypoint transition should verify whether their existing contract terms transfer cleanly into the combined entity’s terms, including SLA structures and venue-specific commitments. Waypoint is a legacy network player with real coverage depth; the transition question is operational, not a question of coverage.
5 selection axes for institutional hosting
1. Latency to your LP, not headline latency numbers
Hosting vendors quote inter-DC latency figures that measure the hop between specific pairs of data centres under controlled conditions. These numbers are accurate for what they measure but irrelevant as a primary selection criterion. What matters is the round-trip latency from your trading server to your specific LP’s order management system endpoint.
LPs do not all host at LD4. Some primary LP relationships run through NY4. Some via private cross-connects at facilities not on the standard venue list. Before signing any hosting contract, request your LP’s hosting locations and cross-connect options, then test the actual latency from your proposed broker-server location to those endpoints. The vendor’s headline number tells you about the DC fabric; it does not tell you about your specific LP path.
Avelacom and Lucera provide network-layer views into multi-venue latency in a way that bare-colo vendors typically do not. If cross-venue execution latency is a primary driver, a network provider’s measurement tooling is more useful than a colo provider’s marketing materials.
2. Regulatory data residency by authorisation map
The regulatory data-residency question is not abstract compliance overhead. It is a precondition for signing the hosting contract.
CySEC-authorised Cyprus Investment Firms operating under MiFID II and GDPR must keep in-scope client personal data within the EU. Cyprus, Ireland, Germany, and other EU member states satisfy this. LD4 in the UK does not, post-Brexit, without a UK adequacy decision or Article 46 mechanism. CySEC has not issued blanket permission for UK hosting of client data.
FCA-authorised UK firms are subject to the UK GDPR. In-scope data hosted in EU data centres requires a UK adequacy decision or Article 46 mechanism. As of 2026 the UK has granted EU adequacy, so EU hosting is workable for UK firms, but FCA-supervised firms with operational-resilience programmes should document the hosting jurisdiction explicitly.
DMCC and VARA-regulated entities in the UAE face onshore data requirements for in-scope crypto-asset firm activities under UAE data protection law. This is particularly relevant for white-label crypto exchange operators covered in the preceding chapter of this canon.
ASIC-authorised Australian firms face client data obligations under the Australian Privacy Act that effectively require AU-based hosting or explicit consent mechanisms for cross-border transfers. Equinix operates SY3 (Sydney); Beeks Group has SY3 presence.
Equinix is the only single vendor in this market with direct DC presence across all four major regulatory jurisdictions (EU, UK, UAE, AU). A multi-authorised broker running CySEC plus FCA plus ASIC should model the cross-connect architecture across all three venues before selecting a colo strategy.
3. DR and business continuity under FCA SYSC and MiFID II Article 16
FCA SYSC 6.1 and MiFID II Article 16(5) impose operational resilience and business continuity obligations. The standard is not “we have a backup server somewhere.” It is demonstrable failover capability with Recovery Time Objective and Recovery Point Objective documented and tested.
Beeks Proximity Cloud’s multi-DC architecture makes multi-region failover a standard feature of the product rather than a custom contract add-on. An active-passive or active-active configuration across LD4 and NY4, for instance, can be built into the initial architecture rather than retro-fitted after a regulator inquiry.
Equinix multi-DC colocations allow equivalent architectures but require the broker to design and operate the failover logic itself or contract with a managed service layer.
CNS single-region managed hosting requires explicit DR contract terms. Brokers using CNS and holding FCA or CySEC authorisation should have the DR architecture in writing, including what CNS’s RPO/RTO commitments are and what the broker’s obligations are on the other side of a failover event.
One area that is under-specified in most broker RFPs: the LP connection failover. When the primary DC goes down, what happens to the LP connections? The answer needs to be in the hosting contract, not left implicit.
4. Certifications as table stakes vs differentiator
ISO 27001 is held by every serious vendor in this market. It is necessary but not sufficient for differentiation in an RFP. Asking whether a vendor holds ISO 27001 identifies floor-level competence, not relative quality.
SOC 2 Type II is the differentiator at the institutional layer. It tests the operating effectiveness of controls over a 12-month period, not just their design. Beeks Group, Equinix, and Pulsant all have disclosed SOC 2 Type II or equivalent audit reports. CNS’s certification posture should be confirmed directly; the published pricing pages do not disclose audit coverage.
SOC 2 Type I - which tests design but not operating effectiveness - is meaningfully weaker than Type II. In the retail VPS space, ChartVPS holds Type I, which is still unusual for a retail-facing VPS vendor and signals above-average compliance investment for that sub-market. It is not the same bar as institutional hosting.
CSA STAR (Cloud Security Alliance Security, Trust, Assurance, and Risk) is relevant for broker stacks where the hosting abstraction is cloud-native rather than bare-metal colo. Equinix has CSA STAR registration. Brokers running cloud-hosted components on top of colo (for example, a cloud-based back-office or CRM that connects to an on-premises MT5 server) should check CSA STAR coverage for the cloud layer.
5. Public vs private company financial stability
Hosting contracts at the institutional colo level run three to seven years. At the retail VPS partnership level, typical terms are one to three years. The vendor must remain financially viable for the duration of the contract; switching mid-contract is operationally disruptive and, for regulated brokers, potentially creates a regulatory notification obligation.
Public companies provide external verification of financial health that private vendors cannot match without a formal diligence process. Beeks Group (LSE AIM: BKS) publishes annual reports, interim results, customer concentration disclosures, and churn data. These filings give a broker’s finance or compliance team a repeatable audit trail for counterparty financial assessment. Equinix (NASDAQ: EQIX) is similarly transparent. Lucera is private but wholly owned by BGC Group (NASDAQ: BGC); BGC’s filings provide an indirect financial-stability signal.
TNS, Avelacom, CNS, ForexVPS.net, ChartVPS, and FXVM are all private. For each, the broker should request: revenue trend for the last two fiscal years, customer concentration (what percentage of revenue comes from the top three clients), and whether the company has raised external capital in the last 24 months or is running on operating cash flow. These questions are not hostile; they are standard in any institutional vendor assessment.
3 selection axes for retail VPS partnerships
1. Broker integration list quality (depth over breadth)
ForexVPS.net’s 40-plus broker integrations represent the most extensive integration footprint in the retail VPS sub-market. The signal is not the number itself; it is the moat it creates. Retail clients who run EAs at a VPS that has a dedicated integration with their broker’s server - meaning optimised latency, broker-specific network path, and potentially co-branded experience - face meaningful switching costs. The broker whose server is already integrated into ForexVPS.net’s fabric has an easier retention conversation than the broker whose server is not.
A broker evaluating a VPS partnership should ask the candidate vendor to share which specific broker servers the integration list includes, whether those integrations are active (tested against current server configurations), and how new broker integrations are added and maintained. An outdated integration list that includes decommissioned server addresses is worse than no list.
2. Partnership economics and sponsorship structures
ForexVPS.net operates a broker partnership programme that allows a broker to sponsor ForexVPS.net as the recommended VPS to its client base. The commercial structures in this programme vary but can include revenue-share on referred VPS subscriptions, co-branded landing pages, and free-tier-for-deposit-threshold arrangements where a client meeting a deposit condition receives a complimentary or subsidised VPS subscription as a retention incentive.
ChartVPS partner terms are less publicly documented. Brokers interested in a ChartVPS partnership should initiate direct commercial conversations; the terms are negotiated rather than published.
FXVM’s structure is primarily a reseller VPS at the low-cost end of the market. The depth of broker partnership infrastructure is lower than ForexVPS.net. For brokers whose primary objective is a formal co-marketing and revenue-share structure, FXVM is a weaker fit; for brokers who simply want to point clients toward an affordable VPS option, FXVM’s EUR 13 entry tier and EUR 1 trial are client-facing advantages.
3. Data governance (entity geography matters for EU brokers)
FXVM is operated by ThinkHuge Ltd, a Hong Kong entity. EU-regulated brokers entering a formal partnership with FXVM, where client personal data flows from the broker’s systems to FXVM’s infrastructure, require GDPR Article 46 standard contractual clauses. Hong Kong is not an EU adequacy country. The SCCs requirement is manageable but adds legal overhead and a compliance sign-off step before the partnership can go live.
ForexVPS.net’s primary operating entity is Wyoming-registered. The US adequacy framework (EU-US Data Privacy Framework) applies to US entities that have self-certified under the framework. Brokers partnering with ForexVPS.net should confirm whether it holds DPF self-certification, which would remove the SCC requirement, or whether SCCs remain necessary. As of 2026 DPF remains valid but faces continued legal challenge; an SCC backup is prudent even where DPF certification exists.
ChartVPS is UK-registered. The UK adequacy decision, currently valid as of 2026, means that data transfers from EU controllers to UK processors do not require SCCs. This is the cleanest data-transfer posture of the three vendors for EU-regulated brokers.
Cost of ownership
Institutional colo costs at LD4 or NY4 are quoted per cabinet. Market rates for a half-cabinet at a primary financial exchange campus run roughly $1,500 to $3,500 per month for the cabinet itself, plus cross-connect fees of $300 to $800 per connection per month, plus power draw. A broker running four LP cross-connects at LD4 faces a monthly line-item of $3,000 to $6,000 before server hardware amortisation.
Beeks Group’s Proximity Cloud and Avelacom’s managed network contracts abstract cabinet and cross-connect costs into annual managed service agreements. These typically have five-figure annual minimums for an entry broker configuration and six-figure minimums for configurations that include dedicated network capacity. The abstraction simplifies budget planning but reduces cost transparency - the broker loses visibility into which cost components are driving the total.
CNS publishes pricing in a way that most institutional hosting vendors do not. A Value Edition tier starts at approximately $35/month; Standard and above are also listed publicly. This makes CNS the most accessible entry point for smaller brokers who need managed MT4/MT5 hosting but are not at the scale where per-cabinet colo economics make sense.
Retail VPS pricing: ForexVPS.net’s Core tier is approximately EUR 22.40/month, Prime approximately EUR 44/month, dedicated from approximately EUR 232/month. ChartVPS runs from $50 to $180/month for Alpha through intermediate tiers and $250 to $450/month for the Delta tier. FXVM’s range is EUR 13 to EUR 43/month with a EUR 1 trial entry.
One consideration that is frequently ignored in multi-currency broker finance: ForexVPS.net and FXVM quote in EUR; ChartVPS quotes in USD. For a broker whose reporting currency differs from both, the effective cost in the accounting currency fluctuates with exchange rates. Brokers should request stable currency quotes or index clauses in annual partnership contracts.
The “vendor financial stability matters more here than elsewhere” principle
A CRM vendor whose product becomes unusable can be replaced in three to four months - painful, but recoverable. A hosting vendor who exits the market takes the physical infrastructure with it. Server migration from one colo to another requires physical hardware relocation, LP cross-connect reordering, IP address transitions, and in some cases regulatory notification. The operational disruption of a colo vendor failure is an order of magnitude higher than most other vendor failures in the broker stack.
This asymmetry means that financial stability carries more weight in the hosting decision than in any other chapter of this canon.
Public-company vendors provide the clearest stability signal. Beeks Group’s AIM filings disclose revenue trend, customer concentration, and churn. Equinix’s NASDAQ filings are among the most detailed in the data centre sector. Both companies have multi-year track records of disclosed financials. Lucera, as a wholly-owned subsidiary of BGC Group (NASDAQ: BGC), inherits financial stability from a public parent even though Lucera itself does not publish separate accounts.
The Waypoint transition is the most operationally significant change in this vendor segment entering 2026. TNS Financial Markets combined with Radianz (formerly owned by BT) to form Waypoint Trading Solutions. Brokers who signed contracts with TNS before the Waypoint rebranding should request written confirmation that existing SLA terms, venue commitments, and commercial rates transfer unmodified into the new entity’s contract framework. A rebrand without a formal novation or assignment creates ambiguity about which entity bears the contractual obligation.
3 RFP questions every broker should ask
Question 1: “Show us your last 12 months of unplanned downtime broken down by DC and incident type.”
This question separates vendors with genuine operational data from vendors with marketing uptime claims. A quoted uptime figure of 99.99% means at most 52 minutes of downtime per year. Whether that downtime occurred as one four-hour incident on a Tuesday morning or as 52 one-minute disconnections distributed across the year makes an enormous difference to a broker running live client positions. The incident log tells you which; the uptime percentage does not.
Vendors who cannot provide a per-DC incident log either lack the monitoring granularity to produce one (a significant operational concern) or are declining to share it (which requires an explanation). Either outcome is material in an RFP scoring exercise.
Specifically request the incident log broken down by: DC location, incident start and end time, affected services, root cause classification, and whether the incident was internally detected or reported by a customer. The last item reveals whether the vendor’s monitoring is proactive or reactive.
Question 2: “What is your incident response process when one of our LP connections goes down at your DC?”
This question tests whether the hosting vendor will engage actively in cross-vendor incident triage or whether it will treat an LP connection failure as the LP’s problem and hand you off immediately.
The correct answer includes: a named escalation path within the hosting vendor’s NOC; a commitment to provide real-time diagnostic data (packet capture, interface counters, BGP route table snapshots) to the broker and LP simultaneously; and a documented protocol for the three-party call (broker, hosting vendor, LP) that typically occurs during a production incident affecting LP connectivity.
Vendors who answer this question with “we’d refer you to your LP” have defined their support boundary in a way that leaves the broker without an infrastructure partner during the incidents that matter most.
Question 3: “How do you handle a regulator request for data hosted in your DC?”
This question covers data residency enforcement in practice, not in theory. The hosting vendor’s DC holds server hardware that runs client trade data, account records, and potentially personal data subject to GDPR, FCA data-protection rules, CySEC obligations, or equivalent. When a regulator issues a data access request, the sequence of events at the DC level matters.
The correct answer includes: the vendor’s written data retrieval process; the chain-of-custody documentation they can produce; the timeline for providing data access (regulators impose tight response windows); whether the vendor has handled regulator requests before and in which jurisdictions; and whether the vendor notifies the broker before responding to a regulator request or responds directly.
This question also surfaces whether the vendor’s legal team understands the regulatory environment its clients operate in. A hosting vendor whose data-request process assumes a generic commercial context rather than a regulated financial services context is a risk in a CySEC or FCA-supervised operation.
Cross-pillar interactions
Brokerage hosting is the substrate that the entire BrokerageAtlas Phase 2 canon sits on.
The liquidity providers chapter identified LP connection latency as a primary economic variable. That latency is determined at the hosting layer: whether the broker’s MT5 server is at LD4 with cross-connect to the LP’s LD4 presence, or whether it is in a remote DC with an internet-routed connection to the LP’s endpoint, is a hosting decision with liquidity economics consequences.
The broker CRM chapter covered where CRM database servers live. CRM data includes personal data for purposes of GDPR and equivalent frameworks. Data residency for the CRM is a hosting decision; CRM vendors who offer cloud-hosted SaaS deployments may not give the broker granular control over which jurisdiction the data sits in.
The KYC/AML + RegTech chapter covered the document and biometric data stack for client onboarding. That data is typically the most sensitive personal data in the broker’s infrastructure from a regulatory standpoint. Where it is hosted, and under whose physical control, is a hosting decision with direct data-residency compliance consequences.
The crypto exchange white-label chapter noted that VARA and MiCAR impose different data-residency rules than FCA/CySEC for crypto-asset activities. A multi-authorised broker running both a securities brokerage and a crypto-asset operation may face hosting architectures that cannot be unified under a single DC strategy - the regulatory jurisdictions make different demands of the same infrastructure.
Editorial close (Phase 2 final chapter)
Brokerage hosting is the layer brokers regret last and choose first. The selection happens early in the business setup sequence, often before the authorisation is granted and before the full regulatory data-residency picture is clear. Contracts are signed, hardware is placed, cross-connects are ordered - and two years later the compliance team discovers that the hosting jurisdiction is incompatible with the data-residency obligation attached to the second-market authorisation.
The remediation is expensive. Physical migration from one colo to another during live operations costs time, money, and operational risk. The correct approach is to map all anticipated authorisation requirements to their data-residency obligations before signing the first hosting contract, not after.
Never select on price alone. CNS’s $35/month Value Edition is a correct entry point for a pre-launch configuration running in test mode. It is not a correct long-term architecture for a CySEC-authorised firm with FCA permission expansion on the roadmap. The hosting decision compounds.
Never accept generic uptime claims without per-DC incident logs. The RFP question in the prior section is not optional due diligence; it is the minimum test that separates marketing collateral from operational accountability.
This closes the BrokerageAtlas Phase 2 canon. Fourteen chapters covering the founding stack: turnkey broker solutions, alternative white-label platforms, liquidity, risk management, CRM, IB management, payment infrastructure, RegTech/KYC-AML, copy trading, broker analytics, prop firm technology, crypto exchange white-label, CySEC AML compliance, and hosting infrastructure. The synthesis question across all 14 is not which vendor is best in any single category. It is which combinations work for which authorisation map - CySEC, FCA, ASIC, DMCC, VARA - at what client scale, with what DR posture, across what geographic distribution of clients. The stack is modular but not independent; decisions in one chapter propagate into constraints in others. Hosting is where the propagation bottoms out.