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 checks evaluate per-trade sizing and account-level limits.
- 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 reproducible by someone other than the person who wants the number to look good. The status page shows component health only; it does not show latency histograms. Until a sample is defensible, the site says "Measured" and links to the status page — never a number.