Deutsch
日本語
العربية
한국어
Español
Português
Indonesia
Tiếng Việt
中文
In a two-broker hedge arbitrage setup, 60–80% of detected discrepancies are latency artifacts — not genuine LP pricing differences. Executing on these signals loses money on each trade and produces toxic order flow that brokers classify and restrict. This guide covers both filter levels: the simple difference-to-open threshold and the advanced fast feed reference architecture that eliminates latency contamination almost completely.
When hedge arbitrage software detects a discrepancy between two broker quotes, that discrepancy can arise from one of two fundamentally different causes. The first is a genuine pricing difference between the brokers’ liquidity providers — a tradeable opportunity. The second is a feed latency artifact: one broker received a global market event faster than the other, and the apparent discrepancy exists only because the slower broker’s quote has not yet updated. These two cases are indistinguishable from the raw quote comparison alone — but they produce completely opposite outcomes on execution.
| Signal type | Cause | Persistence | On execution |
|---|---|---|---|
| Genuine LP discrepancy | Broker A’s LP is pricing differently to Broker B’s LP — independent of market event timing | 200ms to 2,000ms | Fills at quoted prices — net profit as expected |
| Latency-induced artifact | Broker A’s feed received a market event faster. Apparent discrepancy = price move, not LP difference | 30ms to 150ms | Broker B has already updated by fill time — loss or requote |
Without filtering, the ratio of latency-induced signals to genuine LP discrepancy signals in a typical two-broker setup is 60–80% latency artifacts. Market events — price ticks, economic releases, liquidity shifts — happen continuously and each creates a transient latency-induced discrepancy as the faster broker’s feed updates first. The ratio depends heavily on the feed speed differential between the two brokers: a broker pair where one feed is consistently 100ms faster than the other generates far more artifacts than a pair within 10ms of each other.
Executing on latency artifacts is unprofitable at the individual trade level. But the problem extends further — it creates a specific order flow pattern that brokers classify as technically toxic.
Latency-induced signals fire precisely when a price event occurs — because that is when the fast broker’s feed updates while the slow broker’s has not. Unfiltered hedge arb places a disproportionate share of orders at the exact moments of price movement events. Broker risk systems that correlate order timestamps with price event timestamps identify this concentration as technical flow.
Latency-induced trades consistently fill at unfavourable prices relative to the market a few hundred milliseconds later. Broker risk systems track short-term price trajectory after each fill. A high percentage of fills immediately followed by adverse price movement — the signature of orders arriving at the moment the market moved against the fill direction — flags the account for adverse selection review.
A system executing on latency artifacts is profitable during low-volatility periods (genuine LP discrepancies dominate) and unprofitable during high-volatility periods (latency artifacts multiply). This inverse correlation between P&L and volatility — inconsistent with legitimate technical trading — is a recognisable toxic flow signature.
When a latency-induced trade fills at the wrong price, the system exits within seconds. This pattern — profitable trades holding longer, losing trades closing fast — produces an asymmetric hold-time distribution that risk systems flag as automated technical exploitation.
Once classified as toxic flow, the account receives degraded execution — requotes, spread widening, or internal routing to the broker’s own book. This also degrades the profitable genuine LP discrepancy trades. The filter problem is not just about individual trade profitability — it determines whether the account remains viable for arbitrage at all.
The simplest filter is a minimum price discrepancy threshold — difference-to-open — below which no order is placed. Latency-induced discrepancies tend to be smaller on average than genuine LP discrepancies: feed latency artifacts reflect only the speed differential between two feeds receiving the same event, while genuine LP discrepancies reflect actual LP-level pricing differences which can be larger and more persistent. Setting a minimum threshold cuts the smaller latency-induced signals while retaining the larger genuine ones.
| Step | Action | Output |
|---|---|---|
| Step 1 | Run in monitoring-only mode for 5–10 trading days. Log every detected discrepancy with: timestamp, magnitude (pips), duration before collapse, and price movement in the 200ms following detection. | Raw signal dataset |
| Step 2 | Post-hoc classify each signal: genuine (persists over 150ms, reference feed quiescent) or latency-induced (collapses under 100ms, preceded by directional price event). | Classified dataset |
| Step 3 | Plot magnitude distribution of genuine vs latency signals. Find the threshold at which 80%+ of signals above it are genuine LP discrepancies. | Optimal threshold value |
| Step 4 | Set difference-to-open at identified threshold. Recalibrate quarterly — the optimal threshold shifts as broker LP relationships and market volatility regimes change. | Deployed filter parameter |
High-volatility periods create large price movements. A feed latency artifact during a 10-pip move can appear as a 4–5 pip discrepancy between brokers. A 3-pip threshold does not catch this. Large latency events are the most damaging — largest losses and most visible toxic flow pattern.
The optimal threshold varies with market conditions. During Asian session quiet periods, a 1.5-pip threshold may filter adequately. During London open, the same threshold passes a high proportion of latency artifacts. A fixed threshold is always a compromise.
The simple filter treats all discrepancies above the threshold identically regardless of market context at the moment of signal detection. It cannot distinguish a 3-pip genuine LP discrepancy from a 3-pip latency artifact produced by a rapid price event.
The fast feed filter introduces a third independent data source — faster than either execution broker — as the classification mechanism for each detected discrepancy. Instead of filtering by magnitude alone, the system uses the fast feed to determine whether a detected discrepancy coincides with a price movement event on the reference feed. If it does, the signal is latency-induced and discarded. If the reference feed is quiescent, the discrepancy is classified as a genuine LP difference and execution proceeds.
The classification logic at each signal detection event:
(1) FastFeed.RateOfChange(last 100ms) < MovementThreshold
— Reference feed has not moved significantly in the preceding window
— No directional price event currently propagating through the market
(2) FastFeed.LastTickAge < StalenessThreshold
— Reference feed is actively updating (not stale or disconnected)
— Ensures classification check is based on live data
(3) Discrepancy.Persistence > MinPersistenceWindow
— Discrepancy has existed for at least N milliseconds
— Genuine LP discrepancies persist; latency artifacts collapse in 30–100ms
Signal classified as LATENCY-INDUCED if ANY condition fails → order discarded.
This is the primary classification condition. The fast reference feed is faster than both execution brokers — it receives global market events before either broker’s quote updates. If the reference feed shows significant price movement in the window preceding signal detection, this movement is the probable cause of the apparent discrepancy: one execution broker’s feed updated from the event, the other has not yet.
| Parameter | Typical value | Note |
|---|---|---|
| MovementThreshold | 0.5–1.5 pips per 100ms for major pairs; 1.5–3.0 pips for volatile pairs | Set by measuring typical pip movement per 100ms in normal vs event conditions for the specific instrument |
| Lookback window | 50–200ms | Must capture the movement event but not mask genuine discrepancies following a movement event with a delay. Calibrated from measured feed latency differential. |
| Staleness threshold | 500ms–2,000ms | If the reference feed has not updated within this window, it may be stalled. Treat signals during staleness events conservatively — discard or hold until feed resumes. |
A 5-pip latency artifact during a major price event is classified as latency-induced by the fast feed filter — regardless of magnitude. The simple threshold would pass it if set below 5 pips. The fast feed filter classifies based on market state, not discrepancy size.
During quiet periods, the reference feed shows low rate-of-change and classification rarely triggers. During volatile periods, the reference feed is active and classifies latency artifacts continuously. The filter automatically tightens during high-risk periods without manual adjustment.
A genuine 0.8-pip LP discrepancy that the simple threshold would block passes the fast feed filter if the reference feed is quiescent. The filter does not sacrifice small genuine signals to avoid small latency signals — each signal is classified independently on market context.
In well-calibrated deployments, the fast feed filter reduces latency-induced contamination from 60–80% of unfiltered signals to under 5%. The remaining contamination consists of edge cases where a price event is slow enough not to trigger the rate-of-change threshold but fast enough to create a feed differential.
| Filter | Latency rejection | Genuine retention | Complexity | Best for |
|---|---|---|---|---|
| No filter | 0% — all pass | 100% | None | Not viable — toxic flow guaranteed |
| Difference-to-open only | 40–60% | 80–90% | Low | Initial setups, closely-matched broker feed speeds |
| Difference-to-open + persistence | 60–75% | 75–85% | Low | Improved baseline, still misses large latency events |
| Fast feed filter (full) | 90–97% | 85–95% | High | Production arbitrage, hostile broker environments |
A genuine LP discrepancy exists because two brokers’ liquidity providers are pricing the same instrument differently — a structural difference in how each LP models the market or manages inventory. A latency-induced discrepancy exists because one broker’s feed received a market event faster than the other. Genuine discrepancies are tradeable and persist for 200ms to 2,000ms. Latency artifacts collapse within 30–150ms as the slower feed catches up — typically before orders can arrive at the slower broker.
Difference-to-open is a configurable minimum price discrepancy — in pips — that must exist between two broker quotes before any order is placed. It filters latency-induced signals by exploiting the tendency for feed-latency artifacts to be smaller on average than genuine LP discrepancies. It is effective at eliminating small latency signals but does not catch large latency events during high-volatility periods where a fast price movement creates a large apparent discrepancy between feeds with different update speeds.
The fast feed filter uses a third reference price feed — faster than both execution brokers — to classify each detected discrepancy before placing an order. If the reference feed shows significant price movement in the window preceding signal detection, the discrepancy is classified as latency-induced and discarded. If the reference feed is quiescent, the discrepancy is classified as a potential genuine LP difference and execution proceeds. This classifies signals based on market state rather than magnitude alone, catching large latency events that the simple threshold misses.
Latency-induced signals produce orders at the exact moment of price movement events. Broker risk systems detect this concentration as a technical flow pattern. Additionally, latency-induced trades consistently produce adverse fills and fast exits at small losses, creating an asymmetric hold-time and P&L distribution that further identifies the account as technical exploitation. Once classified, the account receives degraded execution that also affects the profitable genuine LP discrepancy trades.
A third price data source demonstrably faster than both execution brokers at receiving global market events. This can be a dedicated market data provider, a co-located price feed service, or a third broker account used as a reference feed only (no orders placed through it). The reference feed runs on a separate monitoring thread with hardware-level timestamps at socket receipt. No orders are ever placed through the reference feed — it is a classification input only.
Quarterly minimum. The optimal parameters shift as broker LP relationships evolve, feed infrastructure changes, and market volatility regimes shift. Immediate recalibration is warranted when: a broker changes its LP or pricing engine; VPS provider or network routing changes affect feed latencies; or sustained changes in instrument volatility occur. SharpTrader’s per-signal attribution logging provides the data needed for ongoing calibration without a separate offline mode.
Difference-to-open · Fast reference feed filter · Per-signal attribution logging · FIX API compatible · 25 years of arbitrage development