Latency is the most-claimed and least-evidenced metric in retail trading infrastructure. Almost every broker, bridge, and copy-trading service publishes a single number — "under 50 ms" — without saying where it was measured, against what, or under which load. We're trying to build a different habit.
What "latency" even means
There are at least five clocks ticking between a Telegram message arriving and a broker confirming a fill: ingest, parse, risk-check, route, and broker acknowledgement. Each is its own distribution. A meaningful latency number names which segment it covers and the percentile (the median lies about tail behaviour; the 99th percentile is what hurts you in news minutes).
Our internal segmentation
- ingest — message hits our Telegram listener and gets a workspace-scoped ID.
- parse — AI parser returns a structured order (or rejects it with a reason).
- risk — server-side risk engine evaluates per-trade and basket-level rules.
- route — order is handed to the broker bridge and an outbound request is on the wire.
- ack — broker returns a ticket ID or rejection reason.
Where we measure from
Production runs in Nuremberg (Hetzner nbg1) because that's where the majority of European brokers (Tickmill, Pepperstone, IC Markets) have their MT4/MT5 datacentres. The single-digit-millisecond pings are real but only matter for the last segment — broker ack — and only after every prior segment has held its budget. Putting a synthetic generator in the same datacentre and naming the result "our latency" would be misleading.
Telemetry we require before publishing
Three things have to be true before a latency claim goes on the website: the segment must be named, the percentile must be named, and the underlying time-series must be queryable by an external auditor for at least 30 days. The status surface tracks all five segments per broker, per workspace, in continuous histograms. Until the production environment is plugged into that telemetry, the site says "Measured" and links to the status page — never a number.