The Information You Are Already Generating
Every time your routing engine sends an order and receives an acknowledgment or a fill, it generates a data point. The order went to venue X at time T with venue score S. The fill came back at price P, T+delta milliseconds later. The fill was partial or complete. The post-fill market moved in a direction that can be assessed a few seconds later.
Most trading infrastructure captures this data for post-trade reporting and compliance. Very few feed it back into the routing model while trading is still active. The gap between "capturing execution outcomes" and "using execution outcomes to improve future decisions" is where a significant amount of execution quality improvement gets left on the table.
What Execution Outcomes Actually Tell You About Feed Quality
The connection between fill quality and feed quality is indirect but real. When your routing engine routes to venue X based on a market data picture that shows X as having the best price and depth, the quality of that picture determines the quality of the routing decision. If venue X's feed is consistently delivering slightly stale data, you will route to it and find that the price has moved by the time your order arrives. The fill comes back at a different price than quoted, or the order does not fill at all because the liquidity at that level has vanished.
This adverse selection pattern, where you consistently fill worse at certain venues than their quoted prices suggest you should, is a diagnostic signal about the feed, not just about the venue itself. A venue with a reliable, low-latency feed will show a tighter distribution between expected fill price (based on the quote at routing time) and actual fill price. A venue whose feed runs 20-30 milliseconds behind the market will show a wider, systematically-biased distribution.
Separating venue execution quality from venue data quality requires comparing fill slippage against feed lag metrics simultaneously. If slippage and feed lag are correlated, the feed is the problem. If slippage exists without feed lag, the venue itself has quality issues (high adverse selection, poor matching logic, stale depth levels in the book). The distinction matters for how you respond.
Building the Feedback Mechanism
The feedback loop has three components: a post-trade analytics pipeline, a score update mechanism in the routing engine, and a safeguard against overfitting.
The post-trade analytics pipeline runs continuously, not just at end of day. For each completed order, it computes: realized slippage versus quoted price at routing time, fill latency (time from order submission to fill acknowledgment), and post-fill price drift at 1-second and 5-second intervals. The drift measure tells you whether you were filling into adverse flow or whether the market moved against you after a clean fill, which is a separate issue.
These metrics feed into a rolling score update for each venue. The rolling window matters: you want to react to genuine degradation in venue quality without thrashing scores based on a few bad fills during a temporarily volatile period. In our current testbed setup, we use an exponentially weighted moving average with a half-life of approximately 30 minutes. Recent fills have more weight, but a streak of bad fills from a single unusual event does not immediately tank a venue's score.
The safeguard against overfitting is the most important part. If your feedback loop causes you to route all traffic away from venues with temporarily poor fill quality and toward venues with recent good fill quality, you create a concentration risk: now all your orders go to one or two venues, their liquidity and queue dynamics change in response to your order flow, and your fill quality metrics degrade there too. The feedback loop has chased itself into a bad equilibrium.
The correct design is to maintain minimum order flow to all connected venues. Floor each venue's weight at some fraction of its default allocation, regardless of how poor its recent metrics are. This keeps the feedback loop's data fresh and prevents you from losing visibility into venue conditions simply because you stopped routing there.
Prioritizing Feed Subscriptions Based on Execution Value
A less obvious application of execution feedback is in data feed subscription management. Trading firms often subscribe to more data feeds than they route orders to, on the assumption that broader market data improves routing decisions. But not every feed contributes equally to routing outcomes.
If you track which venues' market data most strongly predicts favorable fill conditions at other venues (cross-venue leading indicators), you can prioritize the feeds that actually improve your routing quality. A feed that arrives late and whose data does not correlate with better fills at any venue is consuming processing capacity without contributing value. In a high-throughput environment, reducing the number of feeds you normalize and distribute reduces latency in the normalization pipeline.
This is a more advanced application of the feedback loop concept, and it requires enough execution history to compute cross-venue predictive relationships. For a system that has been running for several months across a reasonable symbol universe, the signal is usually detectable. For a new system, start with the simpler per-venue slippage feedback and add this layer once the basic loop is validated.
The Calibration Problem
Any feedback mechanism requires calibration: how aggressively should execution outcomes change routing weights, and how much history is enough to trust the signal? There is no universal answer because the right parameters depend on your symbol universe, your order size distribution, and your trading frequency.
The practical approach is to run the feedback loop in shadow mode first: compute what the adjusted weights would be without actually applying them, and evaluate whether the simulated routing outcomes would have been better or worse than actual outcomes. If the shadow routing consistently improves over actual routing in backtesting, the parameters are probably right. If it creates more variance without improving the mean, the feedback loop is reacting to noise rather than signal.
Shadow mode evaluation requires a realistic counterfactual, which is hard to construct. You cannot know what your fill would have been at a venue you did not route to. The usual approach is to use a limited period of deliberate randomization, where a small fraction of orders are routed randomly regardless of venue scores, to generate a baseline for comparison. The randomization fraction should be small enough not to hurt overall execution quality but large enough to generate statistically significant data within a reasonable timeframe.