CME DMA Problems to Know Before Buying

Every platform has trade-offs, and Nanoconda is no exception. These are the things we typically discuss during a sales call, but we believe you should know them before deciding whether we're the right fit.

What are Nanoconda's limitations?

Nanoconda covers CME Group markets only, and its native API is C++, with WebAssembly plugins for Rust and other languages; the points below cover scope, latency, hardware and support.

Product Scope

The first set of limits decides whether your strategy can run on Nanoconda at all, and in which form.

Nanoconda is designed for low-latency trading on CME Group markets. Here are the main considerations when deciding whether the platform fits your trading strategy.

Exchange Coverage. Nanoconda currently supports CME Group exchanges only. Connectivity to Eurex, ICE, equities, and cryptocurrency venues is not yet available. Firms trading across multiple venues will need additional connectivity for markets outside CME Group.

Development Languages. Nanoconda's native trading API is written in C++ and uses shared memory for low-latency communication. We also support WebAssembly plugins, allowing strategies written in Rust, C++, and other languages that compile to WebAssembly. Build guides are available for C++ and Rust.

Strategies written in Python or other languages without a supported native integration can use our FIX API without rewriting their trading logic, although network-based order submission introduces additional latency compared to colocated execution.

Remote Trading. Nanoconda offers remote trading through FIX, allowing clients to connect from their own infrastructure without colocating their strategies. This can significantly reduce trading costs for higher-volume strategies, since Nanoconda does not charge per-contract routing fees.

Remote trading does introduce additional network latency compared to colocated execution. Our gateway-to-CME matching engine path is under 10 µs, excluding the network latency between the client's server and Nanoconda. Colocated strategies benefit from approximately 1 µs order-to-wire latency.

Remote market data provides ten levels of market depth (L10), while full Market by Order (MBO) data is available on colocated tiers.

Latency and the Hardware

Latency Transparency. Nanoconda publishes typical latency figures, including approximately 1 µs from order submission to wire and single-digit microsecond round-trip latency to CME. Real-time latency histograms are available through our web portal.

Actual latency depends on the strategy, system configuration, traded instruments, and market conditions. Nanoconda provides detailed timestamps on messages, allowing clients to measure latency directly with their own strategies and evaluate performance under real trading conditions.

Hardware Isolation. On managed tiers, clients receive dedicated, isolated CPU cores with private L1 and L2 caches. Certain hardware resources, including L3 cache, memory controllers, PCIe, and network interfaces, remain shared.

To minimize contention, Nanoconda uses Solarflare's low-latency networking technologies, including EFVI and TCPDirect, with dedicated virtual interfaces and user-space networking that avoid much of the overhead associated with traditional kernel networking. While contention for shared hardware resources is theoretically possible, our architecture is designed to minimize its impact on latency and jitter.

Clients requiring complete hardware control can deploy the Nanoconda DMA Software Suite on their own dedicated servers.

Compute Resources. Nanoconda offers several colocated tiers with different resource allocations. Essentials provides one core and browser-based GUI access without SSH. Professional includes three dedicated cores, 24 GB of RAM, and 64 GB of storage, while Elite provides seven hyperthreaded cores.

Market data feed handlers and gateways run on separate Nanoconda-managed cores and do not consume the cores allocated to client strategies. Resource-intensive applications or strategies running multiple processes may require a higher tier, so we recommend selecting a configuration based on expected CPU and memory requirements.

Operational Considerations

Infrastructure and Isolation. Nanoconda operates and maintains the underlying infrastructure, while each client receives an isolated, dedicated trading environment. Clients deploy their compiled applications and are not required to share their source code. This managed approach eliminates the need to maintain exchange connectivity, gateways, and underlying infrastructure. Access, responsibilities, and protections are defined in our service agreement.

Simulation Accuracy. Nanoconda's simulator supports PCAP captures and Databento DBN files. Exchange matching latency is modeled on a best-effort basis using timestamps from market data. While we aim to reproduce realistic trading conditions, simulated latency and execution behavior may differ from live production.

Engineering and Support. Nanoconda is a small, engineering-focused company. Our platform is built around stable, thoroughly tested code, extensive automation, and self-service tools that minimize the need for manual intervention. This approach keeps our operations efficient and costs low, allowing us to offer competitive pricing. Clients also benefit from direct access to the engineers who build and maintain the platform, although our support capacity is smaller than that of larger vendors.

What problems does every CME DMA vendor share?

Four problems apply to every vendor, us included: latency claims that can't be compared, a single CME data center, the exchange's own speed, and hidden pricing.

Latency claims. They are hard to compare: every vendor publishes a number, but the method behind it is rarely spelled out. Where in the path it was measured, under what load, at which percentile. One figure may be order-to-wire inside a server, another a round trip over a wide-area network, a third a marketing average. Until the methods are published alongside the numbers, the only comparison that holds up is the one you run yourself, on your own strategy, in both environments.

A single data center. CME’s matching engines run from one facility, and every participant depends on it. On November 28, 2025, a cooling failure there halted Globex futures and options for hours, and trade press reported the same cause. Colocated clients, remote clients, vendor clients and self-built gateways all went dark together. No connectivity vendor can protect you from that. Colocation puts your server closer to the matching engine, and in the same building as any outage.

The exchange’s own speed. It is slower than your infrastructure: in our production measurements, CME’s matching step takes anywhere from 50 µs to 2 ms depending on conditions, and for many strategies that variance swamps any difference between vendors. The best public measurement of speed races, a study of London Stock Exchange data, found the most common race was won by 5 to 10 microseconds, with a median of 46. That is an equities result from one exchange, and to the best of our knowledge, nobody has published the equivalent for CME.

Hidden pricing. Infrastructure prices are often not published, and clearing commissions are usually negotiated case by case. Exchange data licensing distinguishes display from non-display use, and individuals from firms, and the distinctions are easy to get wrong when budgeting; CME’s own guidance is the place to check. Alongside any vendor, you will need a clearing firm and, in most cases, your own CME market-data license; both typically take three to four weeks to set up, and neither is billed by us. We set out the license cases in the cost post.

What can you verify before you buy?

Certification. CME keeps a public directory of technology vendors, and any connecting software has to pass the exchange's AutoCert+ conformance testing. Passing means the software passed CME's order entry and market data tests.

Custody. We never hold your trading capital: your margin sits with your registered clearing firm, and the CFTC advises you to check any firm in the NFA's BASIC database before sending it anything.

Test in simulation. Our simulator uses the same API as production and needs no clearing firm or data license. If the API, the documentation or our support turn out to be less than we claim, you will find out before you sign for a live server.

What can go wrong once you're live?

Your code misbehaves. The standard cautionary tale is Knight Capital, which in 2012 sent more than four million unintended orders in 45 minutes and lost over $460 million after a faulty deployment. That was equities under a different rule, but a production bug can happen anywhere. Our pre-trade risk checks cap net position, order size, daily volume, message rate, and capital use; they also block orders outside price bands, and you and your clearing firm have a kill switch.

Your process or server fails. CME’s Cancel on Disconnect cancels resting day orders when the session drops, and it is on by default for new sessions, so a crash does not leave orders working unattended. Beyond that, everything runs on one machine: feed handler, risk checks, your strategy, order gateway. That is where the latency comes from, and it also means a hardware fault takes all of it down at once. Recovery isn’t standardised across clients; it depends on your tier and how your strategy holds state, so reach out, and we will walk through it for your setup before you sign.

Market data gaps. The feed handler recovers from packet loss using the exchange's snapshot channels, but between the gap and the recovery your book is unreliable.

The exchange stops. As it did on November 28. What to do on that day is a risk question, not an infrastructure one. Know what your positions look like if you can't trade for ten hours.

The regulator's controls aren't yours. Since 2021, the CFTC's Electronic Trading Risk Principles have required exchanges to keep their own pre-trade controls against disruptive trading. Those controls protect the market, not your account.

Who should not buy Nanoconda?

This isn’t for you if you trade by hand, need several exchange groups from one vendor, or wouldn’t notice ten milliseconds of extra execution delay. When latency isn’t deciding your fills, per-contract pricing costs less.

The colocated fast path also needs someone on your team who writes C++ or Rust. Remote Trading doesn’t, but it is slower and carries no order-by-order data.

We are the wrong vendor for funded-trader evaluation programs, for manual or GUI traders that don't benefit from lower latency.

If you recognized yourself above, we have saved each other a call. If not, the simulator is the cheapest way to start testing. Let the first conversation be about your requirements rather than our features.