Low-Latency Binance Market Data: What the One-Way Numbers Mean

"Low latency" is the most-used and least-defined phrase in market data. Every vendor claims it, almost none say what they measured, from where to where, and against which clock. This guide takes one concrete product — self-serve realtime access to Binance USDT-M and Binance Spot — and spells out exactly what its latency figures are: Binance market data arrives at ~70.4 ms in London, ~69.3 ms in Frankfurt, ~68.5 ms in Ashburn and ~65.0 ms in Ohio. What the one-way number includes, why it is quoted against the venue's transaction timestamp, how it relates to the venue-side delay you can measure in any tick file, and how to check all of it yourself before paying for a second day.

Everything below runs on the CryptoStruct archive: every message Kalshi, Polymarket and 35+ crypto venues publish — every Level-2 snapshot and update at full depth, every trade, every contract, every day since we added the venue — captured co-located with nanosecond venue and receive timestamps and a gap-audited event-id chain, in one normalized schema. It is the same capture our own trading engine and enterprise feeds run on, sold as €1 day bundles you buy as a guest in the Data Shop with instant download — no subscription, no minimum, no sales call. Free full-day samples let you run every command in this guide before paying.

Two latencies, not one

A market-data path has two latencies worth separating. The first is the venue's own publication delay: the time between a trade matching inside Binance and the message leaving the exchange — nobody downstream can shorten it. The second is delivery: the time from the venue to the socket your process reads from. Most "low-latency" claims quietly measure only a part of the second one ("to our data centre"), which flatters the number and tells you nothing about what your strategy actually sees.

The self-serve feed quotes the second latency end to end: from the venue to your client. Captured at the venue in Tokyo and delivered at our London, Frankfurt, Ashburn or Ohio endpoints over dedicated lines. London, Frankfurt, Ashburn and Ohio are delivery endpoints, not sources — every message is captured next to the exchange in Tokyo and carried over a dedicated route to the endpoint you buy. That is also why the price is per UTC day rather than per message: the dedicated path is what you are paying for.

Measured one-way paths: London, Frankfurt, Ashburn and Ohio

The table lists every delivery endpoint on sale today with its one-way figure. The figures are the same for Binance USDT-M and Binance Spot at an endpoint — both markets ride the same line; only the port differs (Binance USDT-M on port 14004, Binance Spot on port 14003).

Ohio is the shortest path at ~65.0 ms one-way on the basis stated under the table; the spread between the endpoints is a few milliseconds, which is to say: pick the endpoint by where your strategy runs, not by the smallest number. A process in Frankfurt reading from Ohio adds a transatlantic hop that no line figure accounts for. London, Frankfurt, Ashburn and Ohio are the self-serve locations today; more will follow.

What the one-way figure includes — and the two Binance clocks

Three things make the figure honest. First, it is end to end: it starts at the venue and ends at your client in the endpoint's cloud region, so it already contains Binance's own exchange latency and the cloud on-ramp behind our endpoint. A "to our edge" number would be smaller and useless. Second, it is one-way, not a round trip — market data only flows in one direction, so a round-trip figure would be a marketing choice. Third, and this is the part most comparisons get wrong: it is measured against the venue's transaction timestamp "T", not the event timestamp "E".

Binance stamps every trade twice. "T" is the time the trade matched; "E" is the time the exchange emitted the event that carries it, which is later — sometimes by a lot under load. A latency measured against "E" ignores the venue's own queueing and looks better than it is. Measuring against "T" charges the venue's publication delay to the figure, which is what you experience: your strategy cares about when the trade happened, not when the exchange got round to telling you. Whenever you compare feeds, ask which clock the number is quoted against; a figure without that answer is not comparable to anything.

The venue-side delay you can measure yourself

The delivery figure sits on top of a delay you can observe directly: how long after a trade matched the exchange actually publishes it. Every CryptoStruct tick file carries two clocks per event — the venue's timestamp and the moment our co-located recorder received the message, both integer nanoseconds UTC. The difference is the exchange-to-capture delta, measured from a machine in the venue's own region, so it is close to the best case any client can see. For Binance USDⓈ-M BTCUSDT trades on one UTC day we measured a 1.45 ms median with a 3.45 ms p99 — the script, the full table and the tails for Kalshi and Polymarket are in Where to run your prediction-market trading bot.

Why this matters for the live feed: the historical files in the shop are recordings of exactly the stream the realtime endpoints deliver — same topics, same normalized schema, same two clocks. A backtest on a €1 day file therefore sees the venue-side delay your production system will see, and the one-way delivery figure above is the only number you add on top.

One connection per host — the feed arbitrage is ours

Take all your instruments on one connection. Racing several connections to the same host against each other (feed arbitrage) gains nothing: they are served by the same host from the same feed, so no copy arrives earlier, and the duplicate traffic tends to slow your connection down rather than speed it up. That optimization is already done for you: we run feed arbitrage internally, before the data reaches your endpoint, so every connection delivers the fastest copy we have. Use further connections for independent processes only. A second socket from the same host to the same endpoint receives the same messages a few microseconds apart and competes with the first one for the same NIC and the same CPU; it adds jitter, never information. Independent processes on different hosts are the legitimate reason for further connections, and extra connections are sold for exactly that.

Which endpoint to connect to

• Run in or near the endpoint's region: London, Frankfurt, Ashburn and Ohio are AWS or data-centre sites, and the figure in the table ends at a client in that region. The hop from your host to the endpoint is yours to measure.
• Trading Kalshi? Its trading API runs in AWS us-east-2 — the region of the Ohio endpoint, which delivers the Binance feed next to it (see the Ohio endpoint post). Ohio never carries Kalshi data; it carries Binance data to where Kalshi strategies live.
• European execution venues or research desks: London or Frankfurt, whichever is closer to the machine that consumes the stream.
• Need both markets? Buy Binance USDT-M and Binance Spot at the same endpoint — Binance USDT-M adds mark price, index price, funding rate, liquidations, which do not exist on Binance Spot.

Verify it before you buy a second day

1. Baseline the venue-side delay from a tick file: a free full-day sample or a €1 day of the instrument you trade — the two clocks are in every event, the Python snippet is in the latency guide.
2. Buy one UTC day at the endpoint nearest to your host (paid days start at the next 00:00 UTC and the rest of the purchase day is included free, so the first evening is free).
3. Log the receive time of every trade against its "T" timestamp on your own host. The distribution you get is the table figure plus your host's distance to the endpoint, plus the venue-side delay — compare medians and p99, never a single reading.
4. Only then decide on a longer run: longer runs cost less per day: −3 % from 7 days, −5 % from 14, −10 % from 30. Extend from your account; nothing renews on its own.

How to connect

1. Pick the endpoint and the market in the shop — a single instrument or the whole market; €39.20 per instrument-day or €79.20 per market-day (public-beta price, 20 % off the list price of €49 / €99 for every day bought during the beta).
2. Your API key is created with the first purchase and shown in your account next to the endpoint addresses; keep it in the CRYPTOSTRUCT_REALTIME_API_KEY environment variable, never in a prompt or a repo.
3. Connect over a plain WebSocket (JSON or SBE) — the port selects the market (Binance USDT-M on port 14004, Binance Spot on port 14003 at every endpoint).
4. Follow the connection guide for login, subscribe and keep-alive, or hand a coding agent the machine-readable spec and let it write the client.

Limitations

The self-serve feed covers Binance USDT-M and Binance Spot at the endpoints listed above; enterprise subscriptions already cover further locations and venues. The one-way figures are our line measurements on the stated basis, quoted as approximate values — they are not an SLA, they vary with venue load, and what your process observes also depends on the path from your host to the endpoint and on your own stack. The venue-side delay figure is one UTC day of one instrument and shows a shape, not a guarantee. Market data only: there is no order entry on this product, and nothing here is investment advice.