Short answer: it was almost certainly detected and filtered by the broker, not broken in the code.
Arbitrage strategies have a recognizable signature. A risk desk watches for accounts that win consistently in ways that suggest a speed or information advantage, and once yours is flagged, the countermeasures begin. None of them touch your code. They all change your fills.
The classic timeline is the giveaway: perfect execution on demo, clean fills through the first weeks live, then a sharp degradation exactly as the account turns consistently profitable. That is not coincidence and it is not a bug. It is the account being moved behind an execution filter. We describe the full mechanism in how brokers really fill your orders and the specific tools in anti-arbitrage plugins.
Work through these in order. The first four are broker-side and account for the large majority of cases.
| Check | What a problem looks like |
|---|---|
| Execution latency | Average send-to-fill time stepped up, especially right after you became profitable |
| Slippage symmetry | Slippage turned one-directional: negative on your winners, rarely positive |
| Rejections and requotes | New rejects or requotes appearing mostly on trades that would have won |
| Your spread | Account-specific widening that does not match the broker’s public quotes |
| Your price feed | Feed slowed, disconnected, or lost its lead over the broker’s quote |
| Market conditions | Volatility or liquidity shifted enough to compress the gap you traded |
Do not argue about intentions, measure. Pull your trade log and compare a profitable early period against the period where performance collapsed. If execution latency rose, slippage became one-sided, and rejects concentrated on your winning trades, the broker is the answer, and no change to the strategy will fix it. If instead your fills are still clean and symmetric but the price gaps you used to capture simply are not there anymore, the edge itself has decayed and the fix is a different feed, a different instrument, or a different strategy.
Once you know which of the two it is, the path is clear. If the broker detected and filtered you, the options are execution masking so the flow survives longer, moving to a venue that tolerates the flow, or accepting that this broker is closed to you for this strategy. If the edge decayed, the answer is to find a fresh source of advantage rather than to keep tuning parameters against a gap that no longer exists. In both cases, the durable lesson is the same: test any strategy under realistic execution before you rely on it, so you are never surprised by production. Backtesting on real tick data with modeled latency and spread is how you separate a real edge from one that only exists with perfect fills.
Not the code, but very likely your fills. Brokers apply delay, asymmetric slippage, and rejection to flow they classify as toxic. The strategy still runs, but the execution it depends on has been quietly degraded.
Demo servers are almost always unfiltered and simulate near-perfect fills. A strategy that works on demo while failing on your funded account is strong evidence that your live flow is being filtered.
Sometimes, through execution masking so the flow is less recognizable, or by moving to a broker that tolerates it. But you cannot fix hostile execution by editing the strategy code alone.
New articles, research papers, and product releases, delivered when we publish them.
Learn exactly how brokers detect and filter arbitrage flow, and audit your own execution to find the real cause.