Low-Latency News Trading: From Economic Release to Broker Fill

Our recorded gold trade around the July 2026 US CPI release had a broker ping of 1 ms and a measured execution latency of 153 ms. The record also contains spread and slippage. Each number describes a different part of the same execution.

This article starts with our current execution sample, explains the measured boundary, then examines that CPI trade. The full release-to-fill chain provides context; the published latency distribution covers the client-observed submission-to-confirmation interval.

What our current execution data shows

Read the median as the middle recorded observation. P90 and P99 are the latency thresholds at or below which about 90% and 99% of eligible observations fall. A low median alongside a much higher P99 points to execution variability worth investigating. The panel shows its sample period, included measurements and exclusions so those numbers can be interpreted together.

The outcome counts answer a separate question: what happened to the recorded attempts? Rejected / blocked / failed includes broker refusals, local pre-send guards and client errors. It must not be read as a count of broker rejections alone. An execution percentage also says nothing about whether the resulting trades made money.

Where the measurement starts and ends

Execution latency is measured on the execution client from the start of order submission until a fill is confirmed. It includes local preparation, SDK processing, communication with the broker and handling of the confirmation. Some records can also include delay while a result is recovered after an interrupted response.

Feed acquisition, parsing, validation and signal generation are outside that interval. Their independent timestamps are not yet available as public distributions. The separate scheduled-release-to-signal field remains unavailable when no recorded measurement exists; the release time on a calendar cannot fill that gap.

An official release timestamp and a broker's displayed clock can also belong to different time zones. Subtracting them without a verified clock relationship would produce an unreliable end-to-end number. For local intervals, the client uses a monotonic timer rather than the displayed wall clock.

Network ping remains useful for checking a route. Order submission adds application work and execution handling that ping does not capture. For host placement and route testing, see How to Choose a VPS for Low-Latency News Trading.

Case study: the 14 July 2026 CPI gold trade

At 12:30 UTC on 14 July, the US published CPI figures for June 2026. Seasonally adjusted headline CPI fell 0.4% month on month, following a 0.5% increase in May. The forecast stored with this trade was −0.1%, giving a surprise of −0.3 percentage points. The official BLS release confirms the actual and prior readings; the forecast comes from the matched calendar record.

The stored execution is a BUY in GOLD#. The panel below pairs its entry and exit with the recorded market window and available telemetry.

The trade opened at 4034.62 and closed at 4057.68, a price increase of 23.06. At 0.95 lots, the broker-history snapshot records +2,190.70 USD net, with zero commission, swap and fee recorded for this trade. That is the outcome of this particular position.

The useful latency comparison is 1 ms ping versus 153 ms execution latency. The latter is the separate client timer described above. It is not the total time since CPI publication, and subtracting ping from it would not isolate the broker's internal processing time.

The same entry has 96 broker points of recorded slippage and 45 points of recorded spread. These price measurements belong beside the timing measurement: a quick confirmation can still arrive at a changed price. Point sizes depend on the broker's instrument specification, so they should not be compared blindly across symbols or converted into an account return.

The chart uses the last stored bid and ask observation in each second. It helps inspect the price move around entry and exit; it cannot resolve a 153 ms interval. The saved opening and closing timestamps are 15:30:02 and 15:30:03 in broker server time, with whole-second precision. Exact holding duration, release-to-fill delay and a confirmed exit reason are unavailable in this public record. A stored stop level alone does not establish why the trade closed.

Explore the CPI report and its release history, or open the full recorded GOLD# execution case. This selected case shows how to read the evidence; the broader sample above is needed to study the distribution of recorded executions.

How we select and interpret the sample

The panel uses recorded news-execution outcomes linked to a fixed cohort of three selected production users. Unattributed records and users outside that cohort are excluded. It is our own operating sample, not a representative survey of every broker, account or release.

The rules are:

• Outcome totals include the scoped records, including failures and unresolved outcomes. Some unsuccessful records originate from local checks before an order reaches the broker.
• Execution-latency percentiles use records classified as filled, with a positive measurement no greater than 10,000 ms. Failure timings are not mixed into that distribution.
• Missing, non-positive and stored above-limit values are disclosed. Earlier writes can already have replaced an above-limit timing with a missing value, so the missing count may include discarded legacy measurements.
• Percentiles use linear interpolation between ordered observations. If the eligible population exceeds 100,000, the most recent 100,000 measurements are used; the panel identifies when that cap applies.
• An explicitly recorded partial outcome remains separate. Legacy producers can classify a reduced-volume execution as filled, so a zero partial count does not prove that every position received its full requested volume.

Based on my 14 years of trading and review of earlier test runs, I retain the 10-second data-quality cutoff for this historical sample. It guards against anomalous readings associated with demo tests and defects in earlier timing code. The displayed maximum and percentiles describe the sample admitted by that rule.

Broker, instrument, event conditions and instrumentation coverage can change as the sample grows. Read latency alongside spread, slippage and execution outcomes, and compare like-for-like conditions when investigating a change. The research methodology explains the broader evidence and matching rules used across the site.

Follow the next release

Before a release, use Economic Reports to understand the indicator and its recent readings. During a scheduled broadcast, follow Live for incoming release values, strategy decisions and selected executions. Afterwards, explore published Results to inspect recorded fills, available execution telemetry and the surrounding market data.

Live shows selected configured sessions, and Results contains selected published cases; an individual broadcast is not automatically a permanent case study. Together with the measurement boundaries above, these views let you examine what was released, what the system displayed and what the recorded execution confirms.