Exchange Co-Location, Data Centers, and Direct Market Access: The Infrastructure Behind Every Futures Fill
Overview #
Every order you send hits a matching engine somewhere. The question is how far away you are from it — and that distance shapes every fill you get.
Exchange co-location is the practice of placing trading servers inside or adjacent to the exchange's own data center, connected by dedicated fiber to the matching engine. Direct Market Access (DMA) is the protocol that lets qualified firms bypass broker front-ends entirely, routing orders straight to the exchange gateway. Together, they form the plumbing that every institutional futures order flows through.
Here's what matters: co-located firms operate at 30-45 microsecond latency. Retail traders through a standard broker connection sit at 150-300+ microseconds. That 100-250 microsecond gap is invisible for swing traders and irrelevant for anyone holding positions for hours. But for market makers, latency arbitrage desks, and anyone competing for queue position on the bid or offer, it's everything.
This article breaks down how co-location programs work at the major exchanges, what the data centers actually are, how DMA functions end-to-end, and what it all means for your trading.
Key Concepts #
Co-location: Renting rack space inside an exchange's data center (or an adjacent facility with direct fiber) to minimize physical distance between your servers and the matching engine. You're literally placing hardware in the same building where trades get matched.
Direct Market Access (DMA): A direct TCP/IP connection from a trader's order-entry system to the exchange's matching engine, bypassing broker front-ends and order routing layers. DMA requires exchange membership or a sponsored arrangement through a clearing member.
Matching Engine: The exchange's core software that takes incoming orders, applies price-time priority (or pro-rata, depending on the product), and generates fills. Every futures trade on CME, ICE, and Eurex passes through a matching engine.
The Data Centers: Aurora, Mahwah, Basildon #
Three names come up constantly in exchange infrastructure discussions. They're not mysterious — they're just buildings with very expensive network equipment inside.
Aurora, Illinois #
CME Group's primary data center. This is where the Globex matching engine lives. Every ES, NQ, CL, ZB, and 6E contract matches here. CME Group's official co-location program offers GLink connectivity at 10 Gbps with equidistant, low-latency access to Globex in the 428,000-square-foot facility. When NexusFi members discuss co-location for CME products, Aurora is the destination.
As @SMCJB explains on NexusFi [1]: "When your software generates an order it sends it to the broker's gateway which could be in Cermak or Aurora. After a quick credit check your broker sends the order to the exchange matching engine in Aurora."
That "quick credit check" at the broker gateway is one of the latency components co-located firms improve around. If your server sits in the same facility as the matching engine, the physical distance drops to meters instead of miles.
Mahwah, New Jersey #
The northeast corridor hub for both CME and ICE connectivity. ICE Futures operates significant infrastructure here, and CME maintains connectivity points. Mahwah serves firms that need access to multiple exchanges from a single location without maintaining separate infrastructure at each exchange's facility.
The Mahwah facility is part of the broader NY/NJ data center ecosystem (including Equinix NY facilities and carrier hotels) that form the backbone of US financial infrastructure.
Basildon, United Kingdom #
The European low-latency hub, primarily serving Eurex and ICE Futures Europe. ICE operates the European Liquidity Center (EULC) here — a purpose-built tier 4 facility spanning 30,000 square meters with redundant fiber diversely routed into central London. Eurex's matching infrastructure also connects through this corridor, and firms trading Euro Stoxx, Bund, Bobl, and Schatz futures co-locate here.
Frankfurt also hosts Eurex connectivity, but Basildon is the primary proximity hosting destination for UK-based participants and international firms needing European exchange access.
What These Names Really Mean #
These aren't exclusive clubs. They're engineered network environments — purpose-built to house the hardware that matches every trade.
How Co-Location Programs Work #
The operational model is similar across CME, ICE, and Eurex. Here's what a firm actually buys:
What You're Purchasing #
| Component | What It Is | Typical Cost Range |
|---|---|---|
| Rack space | Physical server housing in the exchange facility | $2,000-5,000 per rack unit per month |
| Network ports | 10 GbE connections to exchange switch fabric | $400-1,200 per port per month |
| Ultra-low-latency upgrade | Priority access to market data and order entry | $1,000-2,000 per month add-on |
| Cross-connects | Dedicated fiber linking your rack to exchange infrastructure | Varies by distance and provider |
The total operational cost for a full co-location setup runs $30,000-60,000 per month, plus $30,000-150,000 in upfront hardware (low-latency servers, FPGA-accelerated NICs, SSDs for order book caching).
The Technical Stack #
A co-located setup connects through sub-microsecond switch fabric (0.2 microsecond switching latency) via dark fiber or dedicated fiber loops leased from telecoms. The exchange enforces VLAN isolation between participants — your traffic never touches another firm's network.
The key infrastructure features:
- Dedicated fiber: Not shared internet — dedicated point-to-point fiber with nobody else on the line. The same data feed infrastructure that delivers market data to retail platforms gets a radically different implementation at the co-location level.
- Kernel-bypass NICs: Network cards that skip the operating system's network stack entirely (using DPDK or Solarflare technology), shaving 5-15 microseconds
- FPGA acceleration: Field-Programmable Gate Arrays that process market data and generate orders in hardware, not software
- Separate data paths: Market data arrives on one NIC, orders go out on another — separating the data paths kills contention.
The Compliance Layer #
Exchanges don't just sell rack space. They enforce Straight-Through Processing (STP) requirements, meaning every co-located participant must demonstrate their order flow meets exchange rules. This includes pre-trade risk checks, order throttling limits, and ongoing audit rights. The exchange can physically inspect your servers and review network logs.
Direct Market Access: What It Actually Means #
DMA in futures means your order-entry system sends orders directly to the exchange gateway — no broker middleware sitting between you and the matching engine.
With DMA: Your server → Exchange gateway → Matching engine
Without DMA (retail): Your platform → Broker's server → Broker's risk check → Broker's gateway → Exchange gateway → Matching engine
Each step in the retail chain adds latency. As @SMCJB describes the institutional execution path [4]: "Every one of these additional steps creates software latency. Lesser software even has throttling limits built into the software." The broker's risk check alone can add 10-50 microseconds depending on the firm's infrastructure.
The DMA Architecture #
A clean DMA setup runs five components:
- Trading engine (C++, Java, or FPGA)
- Pre-trade risk engine
- Order routing gateway
- Exchange gateway
- Market data handler
Who Can Get DMA #
DMA isn't available to everyone. You need to be one of:
- Exchange member: Direct membership with CME, ICE, or Eurex
- Clearing member: Entity that settles trades and manages margin (often the same firm as the exchange member)
- Sponsored participant: A firm that accesses DMA through a clearing member's "sponsored access" arrangement
- Introducing broker with DMA partnership: An IB that routes orders through a clearing member's infrastructure
Retail traders cannot establish direct DMA. Full stop. As @ChrisK5 learned researching CME Aurora co-location [3]: "If you want to go direct market, you need at least half a million to a million in capital at most brokers."
Latency: The Real Numbers #
Here's what the latency environment actually looks like:
| Access Tier | One-Way Latency | Jitter (Variance) | Key Driver |
|---|---|---|---|
| Co-located (exchange facility) | 30-45 microseconds | Very low | Exchange switch fabric, equidistant cabling |
| Proximity hosted (near facility) | 60-90 microseconds | Low | Carrier fiber, dedicated cross-connects |
| Retail (broker to exchange) | 150-300 microseconds | High | Internet routing, broker middleware stack |
| Mobile/consumer broadband | 300-500+ microseconds | Very high | Consumer broadband, cellular network hops |
Why Jitter Matters More Than Average Latency #
The real differentiator isn't median latency — it's the worst-case spikes.
As @hyperscalper explains the practical impact [5]: "If you are 100 msecs ping time from the exchange versus 1 millisecond ping time from the exchange, there will be much more network congestion and delays." That two-order-of-magnitude gap is the whole game for speed-sensitive strategies.
For high-frequency market making and latency arbitrage, the p95/p99 latency (the worst 5% or 1% of order times) determines profitability, not the average. A single delayed order during a volatile spike can wipe out hours of spread capture.
Academic research confirms the stakes. Brogaard et al. (2015), studying a colocation upgrade at NASDAQ OMX Stockholm, found that firms purchasing faster connectivity were overwhelmingly market makers — and that the speed upgrade improved liquidity for the entire market, including non-colocated participants. The mechanism: faster market makers cancel stale quotes before getting picked off during price moves, reducing their adverse selection costs and allowing tighter spreads.
Where Latency Doesn't Matter #
For traders operating on 1-second to multi-minute horizons, none of this matters.
@Fat Tails lays out the practical routing [6]: "If you use stop or limit orders, these are residing at the exchange." Once your order is resting on the exchange's book, the latency of your connection is irrelevant — the exchange holds your order regardless of how fast your next message arrives.
Market Access Tiers: The Hierarchy #
The futures market access structure is a strict hierarchy. Where you sit determines your technical capabilities, cost structure, and regulatory obligations.
Tier 1: Exchange Member #
The entity with direct trading rights at the exchange. Exchange members can submit orders directly to the matching engine under their own identifiers. They post collateral, meet net-capital requirements, maintain clearing accounts, and bear regulatory obligations.
Technical capability: Full DMA with dedicated ports, co-location access, ultra-low-latency market data feeds. Sub-45 microsecond execution achievable.
Cost to enter: $10,000-50,000 one-time membership fees, plus ongoing capital requirements and compliance infrastructure. Application process takes 4-12 weeks.
Tier 2: Clearing Member #
The entity responsible for clearing and settlement — they guarantee both sides of every trade get paid.
Technical capability: Same as exchange members. Clearing members additionally run the risk infrastructure that guarantees trades.
Tier 3: Introducing Broker (IB) #
A non-clearing entity that introduces client orders to a clearing member. IBs can offer "sponsored DMA" to their clients — routing orders through the clearing member's pipes under a formal arrangement.
Technical capability: DMA possible through sponsored access arrangements, typically via shared port pools. Latency of 50-100 microseconds achievable depending on the clearing member's infrastructure.
This is where most professional non-HFT firms operate. An IB relationship provides institutional-grade execution without the capital and compliance burden of direct membership.
Tier 4: Retail Trader #
Individual or small-business traders accessing the market through a broker's front-end (web platform, API, desktop software). No direct exchange connectivity — every order passes through at least one intermediary before hitting the matching engine.
Technical capability: Latency of 150-500+ microseconds depending on broker, internet connection, and platform. No control over network path, timestamping, or message sequencing.
This tier still supports profitable trading. Most successful futures traders in history operated without co-location. The edge at this tier comes from strategy, discipline, and risk management — not from shaving microseconds.
Proximity Hosting: The Middle Ground #
Not every firm needs or can justify full exchange co-location. Proximity hosting bridges the gap — institutional-grade latency without the six-figure monthly commitment.
What Proximity Providers Offer #
All proximity options fall within or near the 60-90 microsecond proximity tier detailed in the Latency section above — specialist hosts can push below 60 microseconds while cloud-edge options may range up to 120 microseconds.
| Provider Type | Services | Cost vs Full Co-Lo |
|---|---|---|
| Carrier-level (Equinix, Telehouse) | Rack space 5-10 km from exchange, cross-connects | 40-60% of full co-lo cost |
| Specialist low-latency hosts | Pre-installed servers, FPGA cards, managed DMA | 50-70% of full co-lo cost |
| Cloud-edge (AWS Local Zones) | Virtual machines in carrier hotels near exchange | Pay-per-use, lowest entry cost |
As @Nicolas11 covers in the HFT co-location discussion [7]: "The first step in HFT is to place the systems where the exchanges are. Light passing through fiber takes 49 microseconds" per 10 km. Each additional 0.5 km of fiber between your server and the exchange adds 2-3 microseconds.
@artemiso provides the key insight [8]: "It is better to colo near the broker server" — because for most non-HFT strategies, the bottleneck is the broker gateway, not the exchange.
When Proximity Hosting Makes Sense #
Proximity hosting works for:
- Medium-frequency algorithmic strategies: Operating on second-to-minute horizons where 60-90 microseconds is fast enough
- Multi-exchange operations: Firms needing connectivity to CME, ICE, and other venues from a single location
- Cost-sensitive operations: The $30-60k monthly overhead of full co-location doesn't pencil for smaller operations
It doesn't work for:
- Latency arbitrage: Sub-50 microsecond execution requires true co-location
- High-frequency market making: Queue position competition demands the tightest possible latency
The Cost-Benefit Reality #
The infrastructure investment must justify itself through trading P&L. Here's the honest math:
Full Co-Location Setup #
| Expense | Monthly Cost | One-Time Cost |
|---|---|---|
| Rack space (1-2 RU) | $2,000-5,000 | |
| Network ports (2x 10GbE) | $1,000-2,400 | |
| Ultra-low-latency add-on | $1,000-2,000 | |
| Hardware (servers, FPGA NICs) | -- | $30,000-150,000 |
| Software development | -- | $10,000-50,000 |
| Exchange membership | -- | $10,000-50,000 |
| Ongoing operations (staff, monitoring) | $5,000-15,000 | |
| Total | $9,000-24,400/month | $40,000-200,000 |
A firm spending $15,000/month on infrastructure needs to generate at least $15,000/month in alpha attributable to that infrastructure just to break even. For a market-making desk capturing 0.1 ticks per round-turn on ES with 1,000 daily round-turns, that's $1,250/day or ~$25,000/month — which works, but margins are razor-thin and competition is relentless.
The Honest Assessment #
Most futures traders don't need co-location. Most don't need proximity hosting. Most don't even need a especially fast internet connection. The strategies that benefit from sub-100 microsecond latency are:
- High-frequency market making (capturing bid-ask spread)
- Statistical arbitrage between correlated instruments
- Latency arbitrage between exchanges
- Event-driven strategies that race to react to news feeds
Everything else — swing strategies, mean reversion, trend following, options — operates on horizons where the difference between 50 and 300 microseconds is noise.
Practical Takeaways #
If you're a retail trader: Your broker's execution infrastructure matters more than your proximity to the exchange. Choose a broker with fast gateway routing and direct exchange connectivity. Don't waste money on VPS co-location unless your strategy specifically requires it.
If you're building an algorithmic system: Start with a VPS in Chicago (for CME products) or the relevant financial corridor. Measure your actual latency end-to-end before deciding whether proximity hosting adds value. Most algorithmic strategies that operate on minute-plus horizons don't benefit from sub-100 microsecond execution.
If you're a professional firm: The decision between proximity hosting and full co-location comes down to strategy sensitivity. Market making and latency arbitrage require true co-location. Everything else can work from proximity hosting or a well-connected Chicago data center.
If you're curious about the infrastructure: Understanding how the plumbing works makes you a better trader even if you never co-locate. Knowing that stop orders reside at the exchange, that broker gateways add latency, and that matching engines use price-time priority helps you anticipate how your orders interact with the market. That understanding is free.
See Also #
- Latency and Infrastructure for Automated Futures Trading — The companion article covering the physics of execution speed and infrastructure decisions for automated systems.
- Futures Data Feed Technologies — How CQG, Rithmic, and other feed technologies deliver tick data from exchange to trader.
- Trading System Architecture — How professional futures systems are actually built, from market data ingestion to order management.
- Execution Algorithms — TWAP, VWAP, iceberg orders, and smart order routing for minimizing market impact.
- Automated Order Execution — Getting filled without giving away the trade — the practical side of order management.
- Futures Trading APIs — Connecting your code directly to the exchange through broker and exchange APIs.
- Futures Order Routing and Execution Quality — What happens between your click and your fill at the broker level.
- Futures Exchange Matching Algorithms — How the exchange decides who gets filled first — price-time priority vs pro-rata.
Knowledge Map
Go Deeper
Build on this knowledgeReferences This Article
Articles that build on this topicCitations
- — NexusFi Discussion (2022) 👍 8“Order routing through Aurora matching engine”
- — NexusFi Discussion (2013) 👍 4“True co-location vs WAN connection in same data center”
- — NexusFi Discussion (2017) 👍 2“Capital requirements for direct market access”
- — NexusFi Discussion (2022) 👍 5“Broker gateway latency and throttling”
- — NexusFi Discussion (2021) 👍 2“Latency impact at 100ms vs 1ms ping”
- — NexusFi Discussion (2013) 👍 8“Exchange-resident stop and limit orders”
- — NexusFi Discussion (2013) 👍 13“Co-location and fiber optic latency fundamentals”
- — NexusFi Discussion (2016) 👍 2“Co-locate near broker server vs exchange”
- — Cmegroup.com (2026)
- — Ssrn.com (2015)
- — Cashmarket.deutsche-boerse.com (2026)
