A faster Treasury venue was the more expensive choice in Parmar's simulation. Parmar reports the loss in his abstract, and its size deserves more attention than its direction.
The latency-aware router selected venues averaging 47.6 ms, compared with 49.9 ms for a router guided only by quoted spread. Its effective cost was 6.561 bp, against 6.548 bp for the spread router: a −0.013 bp gap per trade against the latency-aware choice. The paired t is −3.86 (p = 0.0001), and the Wilcoxon p is 0.0001. The model beat the baseline on 2.2% of held-out rows. A 32nd is roughly 3.1 bp of a par bond's price. This loss comes to under half a percent of a 32nd.
The statistical result is loud. The trading result is tiny.
How the router gets its answer
A tight quote can fade while an order travels to it. Parmar's premise is that the spread saved at a slow venue may be lost to slippage, leaving a faster venue with a wider quote cheaper overall. The paper frames venue choice as classification. For each tenor and decision round, it labels the cheapest of six venues using effective cost: half the quoted spread plus the absolute bp move between the decision-time mid and the price after that venue's latency. Each label thus looks ahead by the delay of the venue it describes.
The data mix observed yields with generated trading conditions. Dealer-to-customer Treasury trading offers no free order-book feed. Daily constant-maturity yields for the 2-, 5-, 10- and 30-year come from the St. Louis Fed's FRED database; a first-order duration approximation turns them into a price index. Daily price volatility from that index runs from about 0.10% (2Y) to 1.08% (30Y). The generator supplies the rest: six venues, lognormal latencies, best bid and ask in 32nds, five levels of depth a side, and an imbalance measure.
The grid covers 4 tenors × 6 venues × 60 snapshots × 40 days, yielding 57,600 rows. A random forest (300 trees, depth 8, class-balanced weights) uses spread, depth, imbalance, raw latency, a 5-snapshot rolling latency and rolling mid volatility. It trains on the first 75% of rounds and tests on the last 25%. Orders go to the venue with the highest predicted probability. Parmar presents the tightest-spread baseline as the choice most production routers still make.
What did the simulation route?
Only daily volatility is observed; every quote, delay and fill is generated. Parmar acknowledges the limit. A real feed, he writes, would establish whether the negative result "is an artefact of the construction of the simulation or something true about the structure of the Treasury market." For now, the 0.013 bp belongs to the simulator.
The timing raises further questions. We did not find the spacing between snapshots or the method used to scale daily volatility to millisecond price moves. The paper has 60 snapshots per trading day but describes the look-ahead price as arriving a few milliseconds later. It takes the first later snapshot at least one latency ahead. Were those 60 snapshots spread through a session, a 47 ms venue and a 50 ms venue would reach the same next snapshot. Favourable price moves count as costs too, because slippage enters in absolute value.
We could not check those choices ourselves. We have the same FRED yields, but no venue-level, sub-second quotes, latencies or fills. Rebuilding the books would amount to comparing our simulator with Parmar's.
The threshold fix misses the routing rule
Parmar attributes the loss to the classifier's minority class. Recall for the best-venue class is 0.86, while precision is 0.45. The paper cites the "default 0.5 probability threshold" and proposes threshold tuning as its first remedy.
Yet Parmar's stated router chooses the highest predicted probability across six venues, the argmax. It never uses that cutoff. Changing a threshold, or monotonically recalibrating the scores, preserves the venue ranking. The 0.45 precision measures binary calls at 0.5, which the routing rule leaves unused. We did not find the more relevant figure: how often the top-scored venue was cheapest within its round. The headline 80.1% accuracy offers little guidance. Label every venue non-best and accuracy reaches 83.3%, because five of six entries are zeros in each round.
Parmar calls the finding "right on latency, wrong on cost" and argues that locating the classifier's failure helps practitioners more than a clean win. The proposed diagnosis misses the rule that actually sends the order. A version worth testing would use the model only when its top probability clears a bar, then fall back to the tightest spread. Such a hybrid could work. No result for it is reported here.
The information available to the model merits scrutiny as well. Raw per-snapshot latency is a feature, and that same realised latency determines the label's look-ahead horizon. A live router sees only a venue's recent average delay. Even with the extra information, this model lost.
Six rows for each routing decision
The held-out set contains 14,400 rows: 600 rounds × 4 tenors × 6 venues, or 2,400 routing decisions. Parmar describes the paired comparison across all 14,400 rows, although a decision selects one venue for each tenor-round. Counting each choice six times inflates the reported t by √6. That alone would bring it below conventional significance, before accounting for serial dependence from rolling features. The 2.2% hit rate uses the same row denominator; we did not find a breakdown of the remaining rows into ties and losses.
The references warrant care too. Works cited in the text as finance papers, including [1], [2], [3], [7], [12], [14] and [15], appear in the bibliography as SDN, wireless, VANET, smart-city or blockchain papers. The cited bandit-routing work behind the proposed sequential-learning remedy leads to a smart-city optimisation paper. Gousgounis et al. also have a 2025 date attached to a 2024 issue.
Parmar deserves credit for reporting the loss. He also names the test that matters: a Tradeweb or BrokerTec feed, scored per decision on top-1 hit rate, to see whether the argmax router can beat the tightest spread.