DEV Community: Boris Fesenko

Retail Forex Brokers Don't Publish Execution Data — So I Open-Sourced a Way to Measure It

Boris Fesenko — Tue, 11 Aug 2026 19:18:15 +0000

BEQI: an open, standardized Broker Execution Quality Index across five dimensions — plus a public benchmark anyone can contribute to.

Ask a retail forex trader how good their broker's execution is and you'll get a feeling, not a number. "Feels fast." "Spreads look tight." "I get slipped on news." The problem is structural: retail brokers don't publish execution-quality data, and the one dataset that would let you compare them — how they actually fill orders — doesn't exist in the open.

So I built a tool to measure it, and made both the method and the benchmark open source. It's called BEQI — the Broker Execution Quality Index — and this post is about why execution quality is measurable at all, the five dimensions it breaks down into, and how you can audit your own broker in about half an hour.

Why spread is a terrible proxy for execution quality

Spread is the number brokers compete on because it's the number you can see. But the cost that actually shows up in your P&L is mostly invisible: how long the broker takes to fill you, whether slippage is symmetric or quietly biased against you, whether the spread you're quoted at the moment of a signal is the spread you actually trade, and how often you get requoted or held. None of that is on the marketing page.

Two brokers with an identical advertised spread can have completely different real execution. The only way to tell them apart is to measure the fills — which requires (a) a standard set of metrics and (b) data you already have: your own trading statements.

The five dimensions of execution quality

BEQI decomposes "execution quality" into five measurable dimensions:

Dimension	Unit	What it captures
Matching latency (median)	ms	Time from order send to fill, from statement timestamps
Slippage asymmetry	ratio (1.0 = symmetric)	Whether slippage is even, or quietly biased against you
Spread widening factor	multiplier	Baseline spread vs. the spread at the moment of your signal
Last-look hold time	ms	The delay before an order is accepted or rejected
Requote rate	per 100 orders	How often orders are requoted

Each of these is a place where execution cost hides. Slippage asymmetry is the sneaky one: a broker can show "normal" average slippage while systematically giving you negative slippage on your best fills and neutral on the rest. Spread widening is the other — the charted spread looks fine, but the spread you're actually quoted when you try to trade a move is wider.

Rolling it into one score (carefully)

Each dimension is scored 0–100, then combined into a composite BEQI using a weighted geometric mean:

Matching latency — 30%
Slippage asymmetry — 25%
Spread widening — 20%
Last-look hold time — 15%
Requote rate — 10%

The geometric mean is deliberate. With a plain weighted average, a broker could paper over one terrible dimension with strong performance elsewhere. A geometric mean punishes a single very-low sub-score much harder — which is the right behaviour, because one broken dimension (say, brutal slippage asymmetry) can wreck a strategy no matter how good the other four look.

How you audit your own broker

The tool is a CLI. It reads the data you already have and outputs a JSON report:

git clone https://github.com/bjftradinggroup-inc/forex-broker-audit-toolkit
cd forex-broker-audit-toolkit
pip install -r requirements.txt

# HTML statement (most common)
python beqi.py --input statement.htm --output report.json

# CSV log + tick data (enables the spread-widening dimension)
python beqi.py --input trades.csv --tick-data eurusd_ticks.csv --output report.json

# FIX 4.4 log (richest — measures all five dimensions)
python beqi.py --input fix_session.log --output report.json

Input formats:

HTML statements exported from your trading platform — the easiest, works out of the box.
CSV logs with order_id, send_time, fill_time, requested_price, filled_price, side, volume.
FIX 4.4 logs — the richest source; measures all five dimensions including last-look.
Tick data (optional) to compute spread widening.

The report gives you the audit period, pairs tested, sample size and confidence, all five dimension scores with their sub-metrics, the composite BEQI, and a tier classification. About 30 minutes end to end.

The part that makes it useful: a public benchmark

A score for your own broker is interesting. A score you can compare is the point. The toolkit ships with a public benchmark — you can submit your report (broker name optional, anonymity is the default) via a form or a PR to the data folder, and over time that builds the open dataset retail forex has never had: standardized execution-quality numbers across brokers, methodology fully in the open.

That's the real ambition here — not another broker "review" site driven by affiliate deals, but a community-run, reproducible benchmark where the methodology is code you can read and criticize.

Methodology critique welcomed

I want to be honest about the limits. Statement timestamps aren't tick-to-trade truth (see the clock-discipline problem — you really want FIX logs for latency). A measured number from one account over one period is a sample, not a verdict. And any composite score compresses information — the sub-metrics matter more than the headline. All of that is why the methodology is open: the fastest way to make a benchmark like this trustworthy is to let people poke holes in it.

Get the code

MIT licensed, Python 3.10+, on GitHub:

→ github.com/bjftradinggroup-inc/forex-broker-audit-toolkit

If you trade retail forex, run it on a statement you already have and see where your broker lands. If you find a flaw in the methodology, open an issue — that's the point.

Educational content, not financial advice. Execution-quality measurements are samples from specific accounts and periods and are not guarantees of future execution or profitability.

Measuring broker latency: building a tick-divergence detector for latency arbitrage

Boris Fesenko — Tue, 11 Aug 2026 14:12:17 +0000

Most write-ups about latency arbitrage stop at the idea: a fast reference price moves, your broker's quote lags for a moment, you trade the stale price. True — but useless on its own, because whether there's any edge at all depends entirely on your specific broker, and that is a measurable property, not a vibe.

So let's build the thing that measures it: a small tick-divergence detector that compares two price feeds and records every moment they disagree — the size of the gap, its direction, and how long it lasts. It's ~60 lines of Python, it runs, and it's the same core idea behind any serious broker-latency tool.

The one number that matters

A latency-arbitrage system is only interesting if you can answer three questions about a broker:

How large are the gaps between the broker's quote and the true market? (magnitude)
How long do they persist? (duration — do you have time to act?)
When do they happen? (session/timing)

Everything else — the VPS, the execution stack, the strategy code — is downstream of those numbers. If the gaps are tiny and vanish in single-digit milliseconds, no infrastructure will manufacture an edge. If they're wide and last 100+ ms during liquid hours, you have something. You cannot know which world you're in without measuring.

Modelling a "divergence"

Two feeds:

a reference feed — a fast, aggregated view of the market's true price, with minimal delay;
a broker feed — the quote you can actually trade, which lags because of aggregation delay, network distance, or deliberate throttling.

At any instant, define the gap as reference_mid - broker_mid. When the reference jumps and the broker hasn't caught up, that gap exceeds some threshold and a divergence window opens. It stays open until the broker catches up and the gap collapses back under the threshold. For each window we record:

max_gap — the largest absolute gap seen (your theoretical edge)
direction — buy the broker when it's stale-low (ref > broker), sell when stale-high
duration — how long the window stayed open

Here are the data structures:

from dataclasses import dataclass

PIP = 0.0001  # 5-digit FX symbol, e.g. EUR/USD

@dataclass
class Divergence:
    start: float          # arrival time (s) the gap opened
    end: float            # arrival time (s) the gap closed
    max_gap: float        # largest |ref - broker| during the window (price units)
    direction: str        # 'buy' broker (ref above) or 'sell' broker (ref below)

    @property
    def duration_ms(self):
        return (self.end - self.start) * 1000

    @property
    def gap_pips(self):
        return self.max_gap / PIP

The detector

The detector is a tiny state machine. It remembers the latest reference mid, and on every incoming tick it re-evaluates the gap. Above threshold → a window is open (and we keep the running max). Back below threshold → close the window and emit an event.

class DivergenceDetector:
    """Feed it interleaved reference/broker ticks in arrival-time order."""

    def __init__(self, threshold_pips=0.8):
        self.threshold = threshold_pips * PIP
        self.ref_mid = None
        self._open = None          # currently open divergence
        self.events = []

    def on_reference(self, t, mid):
        self.ref_mid = mid
        self._reevaluate(t)

    def on_broker(self, t, mid):
        self.broker_mid = mid
        self._reevaluate(t, broker=mid)

    def _reevaluate(self, t, broker=None):
        if self.ref_mid is None or not hasattr(self, "broker_mid"):
            return
        b = broker if broker is not None else self.broker_mid
        gap = self.ref_mid - b                 # >0 => broker stale-low => buy broker
        if abs(gap) >= self.threshold:
            direction = "buy" if gap > 0 else "sell"
            if self._open is None:
                self._open = {"start": t, "max": abs(gap), "dir": direction}
            else:
                self._open["max"] = max(self._open["max"], abs(gap))
        elif self._open is not None:
            o = self._open
            self.events.append(Divergence(o["start"], t, o["max"], o["dir"]))
            self._open = None

Note the important detail: ticks are processed in arrival-time order, not in the order the market produced them. The whole point is that the broker's tick for a given price arrives later than the reference's. That ordering is the phenomenon.

A runnable simulation

To exercise it without a live feed, simulate one true price (a random walk) observed by two feeds with different delays — a ~5 ms reference and a ~150 ms broker. Merge both streams by arrival time and push them through the detector.

import random, statistics

def simulate(n=20000, ref_delay=0.005, broker_delay=0.150, seed=42):
    rnd = random.Random(seed)
    t, price = 0.0, 1.1000
    arrivals = []
    for _ in range(n):
        t += rnd.expovariate(1 / 0.05)             # ~20 ticks/sec avg
        price += rnd.gauss(0, 0.6) * PIP           # small random step
        arrivals.append((t + ref_delay,    "ref",    price))
        arrivals.append((t + broker_delay, "broker", price))
    arrivals.sort(key=lambda a: a[0])              # merge by ARRIVAL time

    det = DivergenceDetector(threshold_pips=0.8)
    for at, kind, mid in arrivals:
        (det.on_reference if kind == "ref" else det.on_broker)(at, mid)
    return det.events

ev = simulate()
gaps = [e.gap_pips for e in ev]
durs = [e.duration_ms for e in ev]
buys = sum(e.direction == "buy" for e in ev)
print(f"divergences detected : {len(ev)}")
print(f"median gap (pips)    : {statistics.median(gaps):.2f}")
print(f"median duration (ms) : {statistics.median(durs):.0f}")
print(f"direction split      : {buys} buy / {len(ev) - buys} sell")

Output on my machine:

divergences detected : 5122
median gap (pips)    : 1.27
median duration (ms) : 54
direction split      : 2593 buy / 2529 sell

Play with broker_delay. Drop it to 0.02 (a fast broker) and the divergences mostly disappear — which is exactly the point: the edge is a function of the broker's lag, and nothing else. Widen it to 0.3 and both the gap size and duration grow. You've just built a knob that models "how exploitable is this broker."

The roughly even buy/sell split is a good sanity check too: a pure lag against a symmetric random walk shouldn't be directionally biased. A real broker feed that comes back skewed is telling you something about how it's quoting.

Get the code

The full, tested version — with a CLI, per-symbol pip sizes, an examples/ delay sweep and unit tests — is open-source (MIT) on GitHub:

→ github.com/bjftradinggroup-inc/forex-latency-divergence-detector

git clone https://github.com/bjftradinggroup-inc/forex-latency-divergence-detector
cd forex-latency-divergence-detector
python latency_detector.py --broker-delay 0.15

If it's useful, a ⭐ helps other people find it.

What the toy model conveniently ignores

This is where measurement stops being cute and starts being engineering. A production detector has to deal with:

Clock discipline. You're comparing timestamps from two sources. If their clocks drift, your "latency" is fiction. Real setups stamp events against a monotonic clock and, at the serious end, discipline the host clock with PTP. Never trust wall-clock datetime.now() for this.
Last look. A measured gap is a theoretical opportunity, not a fill. Many liquidity providers get a brief final window to reject an order after you send it — so the gaps you measure and the trades you actually get filled on are two different distributions. Measuring the first without modelling the second is how people overestimate an edge.
Per-symbol reality. PIP isn't a constant; gold, JPY crosses and majors all differ. Thresholds, spreads and tick rates are per-symbol. Gold (XAU/USD) in particular tends to show far larger gaps than EUR/USD because it's more volatile and more loosely quoted.
Spread and costs. A 1.3-pip gap on a 0.6-pip spread is not a 1.3-pip edge. The detector measures the raw divergence; the tradeable part is what's left after spread, commission and slippage.
Throughput. Real feeds are tens of thousands of messages per second. The hot path has to be allocation-light; the version above is for clarity, not for a colocated box.

The meta-point: a measured opportunity is not realized profit. The detector tells you whether a broker is even worth pursuing. It does not promise the money is capturable. That distinction is the difference between people who treat a backtest as a track record and people who don't.

From a detector to a decision

Scale this up — run it live against many brokers, across many symbols, for months — and the event stream becomes a dataset you can actually make decisions with: which brokers lag enough to matter, on which instruments, at which hours. That's the difference between choosing a broker on marketing and choosing one on evidence, and it's the single highest-value step before spending a cent on infrastructure.

If you'd rather not build and host the whole pipeline, this is exactly what a free forex arbitrage scanner does — it records real broker latency with open methodology so you can inspect the gap distributions directly. For the strategy context around it, see the deep dives on algorithmic & automated forex trading and latency arbitrage.

The takeaway for engineers: in this corner of trading, the interesting problem isn't "what's the strategy" — it's "how do I measure the market honestly enough to know whether a strategy can exist at all." Start there.

Educational content, not financial advice. Trading involves significant risk; measured theoretical opportunities do not guarantee tradable or profitable results.

Why crypto arbitrage windows close before your REST poll completes

Boris Fesenko — Tue, 02 Jun 2026 12:53:03 +0000

TL;DR: Crypto arbitrage windows on liquid pairs now close in under 100 ms. A REST polling loop typically takes 1–1.5 seconds round-trip. WebSocket delivers the same data in 20–100 ms. If you're still polling REST endpoints for orderbook data in 2026, you're missing the majority of opportunities — not because your strategy is wrong, but because your data plane is fundamentally too slow.

This post walks through the math, shows a benchmark I ran on a handful of major exchanges, and provides production-grade Python code for a WebSocket client that handles reconnects, heartbeats, and orderbook reconstruction.

1. The numbers that broke REST polling

When I started writing crypto arbitrage bots a few years ago, polling Binance's REST API every 500 ms was perfectly acceptable. Spreads were wide, arbitrage windows lasted multiple seconds, and the orderbook for BTCUSDT moved slowly enough that a half-second-old snapshot was still tradeable.

In 2026, the same approach doesn't work. Here are the numbers as they stand today:

Metric	Value
Median crypto arbitrage window on liquid pairs	30–80 ms
Window closes in under 100 ms	~90% of cases
REST round-trip latency (request → response → JSON parse)	1.0–1.5 seconds
WebSocket update delivery latency (push from exchange to client)	20–100 ms

The math is brutal. A 100 ms window cannot be caught by a 1500 ms poll. By the time your REST response arrives, the orderbook you're reading is 15 cycles stale. You're not "slow" — you're not even in the same temporal universe as the event you're trying to react to.

2. Why REST is fundamentally slow

REST APIs over HTTPS carry overhead that adds up:

TCP handshake — three packets to establish, typically 50–150 ms on intercontinental hops.
TLS handshake — another full round-trip, 30–100 ms.
HTTP request/response — the actual data exchange.
JSON parse — depending on payload size, 5–50 ms.
Rate-limit budget — most exchanges cap REST to 10–20 requests per second per IP. Polling faster gets you banned.

Yes, modern clients use HTTP keep-alive to avoid steps 1 and 2 on every request. But you still pay them periodically. And rate limits are the real killer — even if you could parse responses in 1 ms, the exchange will throttle you after 20 requests.

# This is what every REST polling loop looks like.
# Every. Single. Iteration. Pays full round-trip cost.

import time
import requests

def poll_orderbook(url, interval_ms=500):
    while True:
        start = time.perf_counter()
        response = requests.get(url, timeout=2)
        book = response.json()
        elapsed_ms = (time.perf_counter() - start) * 1000
        print(f"Got {len(book['bids'])} bids in {elapsed_ms:.0f} ms")
        time.sleep(max(0, interval_ms / 1000 - elapsed_ms / 1000))

Running this against https://api.binance.com/api/v3/depth?symbol=BTCUSDT&limit=20 from a typical residential or VPS connection produces round-trip times of 800–1500 ms consistently. Best case: maybe 600 ms from a co-located server. Still 6× too slow for a 100 ms window.

3. WebSocket: push, not poll

WebSocket inverts the model. Instead of the client asking "what's the orderbook now?" twice a second and accepting that the answer is already stale, the client opens one persistent connection and the exchange pushes updates the instant they happen.

Concretely:

One TCP/TLS handshake at connection time. Amortised across thousands of messages.
One subscription message declaring what streams you want.
A continuous stream of deltas flowing from server to client over the same connection.
No rate limit on inbound messages (the exchange controls the rate).

The delivery latency on a properly-configured WebSocket client to a major crypto exchange is 20–100 ms, depending on geographic distance. That's the time between the exchange's matching engine processing an event and your code receiving the update. There is no polling overhead because there is no polling.

Here's the bare-minimum Python client for Binance's depth stream:

import asyncio
import json
import websockets

async def stream_depth(symbol="btcusdt"):
    uri = f"wss://stream.binance.com:9443/ws/{symbol}@depth20@100ms"
    async with websockets.connect(uri) as ws:
        async for raw in ws:
            update = json.loads(raw)
            best_bid = float(update["bids"][0][0])
            best_ask = float(update["asks"][0][0])
            spread = best_ask - best_bid
            print(f"bid={best_bid:.2f} ask={best_ask:.2f} spread={spread:.2f}")

asyncio.run(stream_depth())

Run this and you'll get updates every 100 ms (the slowest tier — Binance offers @100ms, @1000ms, and unthrottled real-time streams). Each update arrives with the new top-of-book state. No polling. No rate-limit risk. The connection stays open as long as your process runs.

4. A simple benchmark

Here's a script that measures REST round-trip vs WebSocket inter-message arrival time for the same orderbook data. It's not a perfect apples-to-apples comparison (REST gives a full snapshot; WebSocket gives a stream of updates), but it makes the order-of-magnitude difference impossible to miss.

import asyncio
import json
import statistics
import time
import requests
import websockets

# ----------------------------------------------------------------
# REST: measure round-trip for orderbook snapshot
# ----------------------------------------------------------------
def benchmark_rest(url, samples=50):
    latencies = []
    for _ in range(samples):
        start = time.perf_counter()
        r = requests.get(url, timeout=5)
        r.json()
        elapsed_ms = (time.perf_counter() - start) * 1000
        latencies.append(elapsed_ms)
        time.sleep(0.1)  # respect rate limits
    return {
        "median_ms": round(statistics.median(latencies), 1),
        "p90_ms": round(statistics.quantiles(latencies, n=10)[8], 1),
        "p99_ms": round(max(latencies), 1),
    }

# ----------------------------------------------------------------
# WebSocket: measure time between pushed updates
# ----------------------------------------------------------------
async def benchmark_websocket(uri, samples=50):
    gaps = []
    async with websockets.connect(uri) as ws:
        last = time.perf_counter()
        for _ in range(samples + 1):  # +1 to discard the first
            await ws.recv()
            now = time.perf_counter()
            gaps.append((now - last) * 1000)
            last = now
    gaps = gaps[1:]  # discard first
    return {
        "median_ms": round(statistics.median(gaps), 1),
        "p90_ms": round(statistics.quantiles(gaps, n=10)[8], 1),
        "p99_ms": round(max(gaps), 1),
    }

# ----------------------------------------------------------------
# Run both
# ----------------------------------------------------------------
if __name__ == "__main__":
    rest_url = "https://api.binance.com/api/v3/depth?symbol=BTCUSDT&limit=20"
    ws_uri = "wss://stream.binance.com:9443/ws/btcusdt@depth20@100ms"

    print("REST:", benchmark_rest(rest_url, samples=50))
    print("WebSocket:", asyncio.run(benchmark_websocket(ws_uri, samples=50)))

A representative run from a European VPS to Binance:

REST:       {'median_ms': 920.4, 'p90_ms': 1180.5, 'p99_ms': 1485.2}
WebSocket:  {'median_ms': 100.2, 'p90_ms': 105.1, 'p99_ms': 142.8}

The WebSocket median is the throttle setting (@100ms), not the underlying delivery latency — that's faster. The REST median is genuine round-trip cost. A 9× gap on the median; closer to 12× on the p99.

Switching to Binance's unthrottled depth stream (btcusdt@depth) drops the WebSocket median below 50 ms, widening the gap further.

5. The architectural shift

Moving from REST polling to WebSocket isn't just changing a library — it changes the architecture of your bot.

Before (REST polling):

┌─────────────────┐    ┌──────────────────┐
│  Poll loop       │ ── │ Strategy engine │
│  every 500 ms    │    │ runs on snapshot │
└─────────────────┘    └──────────────────┘

A single thread asks for state on a timer, hands the snapshot to the strategy, repeats. The strategy is stateless between polls — it has no idea what happened in the gap.

After (WebSocket event-driven):

┌──────────────────┐    ┌──────────────────┐    ┌──────────────────┐
│  WS connection    │ ── │ Local orderbook │ ── │ Strategy engine │
│  pushes deltas    │    │ kept current    │    │ reacts to events│
└──────────────────┘    └──────────────────┘    └──────────────────┘

Now the client maintains a local replica of the orderbook, applying deltas as they arrive. The strategy engine reacts to specific events (a bid lifted, an ask hit, a spread widening past a threshold). State is continuous, not sampled.

This is more code. It's also the only way to react inside a 100 ms window.

6. Production-grade WebSocket client

The bare-minimum example earlier works for a demo. For a real arbitrage bot, you need:

Automatic reconnect on disconnect
Heartbeat / ping-pong to detect dead connections faster than the OS will
Sequence number validation to detect dropped messages (most exchanges include a sequence ID)
Local orderbook state that applies deltas correctly
Backoff on reconnects to avoid hammering the exchange after an outage

Here's a more robust skeleton (Binance-style stream, simplified):

import asyncio
import json
import logging
import random
import websockets

log = logging.getLogger("ws_client")

class CryptoOrderbookClient:
    def __init__(self, uri, on_update):
        self.uri = uri
        self.on_update = on_update
        self._stop = False
        self._backoff_s = 1

    async def run(self):
        while not self._stop:
            try:
                async with websockets.connect(
                    self.uri,
                    ping_interval=20,    # heartbeat every 20 s
                    ping_timeout=10,     # treat as dead after 10 s no pong
                    max_size=2**20,      # 1 MB message cap
                ) as ws:
                    self._backoff_s = 1  # reset on successful connect
                    log.info("WS connected to %s", self.uri)
                    await self._consume(ws)
            except (websockets.ConnectionClosed, OSError) as e:
                log.warning("WS disconnected: %s; backing off %ss", e, self._backoff_s)
                await asyncio.sleep(self._backoff_s + random.uniform(0, 1))
                self._backoff_s = min(self._backoff_s * 2, 30)  # exponential up to 30s

    async def _consume(self, ws):
        async for raw in ws:
            try:
                msg = json.loads(raw)
                await self.on_update(msg)
            except json.JSONDecodeError:
                log.warning("non-JSON message dropped")
            except Exception:
                log.exception("handler crashed; continuing")

    def stop(self):
        self._stop = True


async def my_handler(msg):
    bid = float(msg["bids"][0][0])
    ask = float(msg["asks"][0][0])
    # ... your strategy logic ...
    print(f"bid={bid:.2f} ask={ask:.2f}")


client = CryptoOrderbookClient(
    "wss://stream.binance.com:9443/ws/btcusdt@depth20@100ms",
    my_handler,
)
asyncio.run(client.run())

Notes on what this gives you:

ping_interval=20, ping_timeout=10 is the single most important pair of settings. Exchanges will silently drop your connection during network blips; the OS-level TCP timeout is minutes. Without explicit ping-pong, you'll think you're connected for ages while receiving nothing. With it, you detect the dead connection in ~30 s and reconnect.
Exponential backoff on reconnect prevents you from being the bot that DDoSes an exchange during their outage.
Catch all handler exceptions at the top level. A bug in your strategy code should not kill the WebSocket loop and lose minutes of market data.

For orderbook reconstruction with full delta application and sequence-number gap detection, see the Binance WebSocket reference implementation — every major exchange has a similar document, and following it exactly is the only way to avoid subtle desync bugs.

7. What still needs REST

WebSocket replaces REST for market data. It does not replace REST for everything. Things that still belong on REST:

Order placement and cancellation on most exchanges (some have WebSocket order entry; coverage is uneven).
Account balance queries, position queries, fee tier lookups — infrequent enough that polling cost is irrelevant.
Historical data fetches — REST is the right tool for "give me the last 1000 trades".
One-shot administrative calls — withdrawals, API key management, etc.

A real arbitrage bot in 2026 typically runs a WebSocket data plane and a REST control plane side by side. Market events arrive on WebSocket, orders go out on REST (or WebSocket order entry where available).

8. What happens to retail bots that don't make this transition

A polling-based crypto arbitrage bot in 2026 isn't broken — it just runs into a degraded version of the problem:

Signals fire slower because the bot only sees market state 2× per second.
Most opportunities have already closed by the time the strategy reacts.
Per-trade edge collapses as the bot consistently takes the worst price of the window.
Win rate drops to the point where execution costs (fees + spread + slippage) exceed gross edge.

The strategy logic might be perfect. The execution layer is what kills it.

This is the same dynamic that broke retail latency arbitrage on forex brokers a decade ago — except in crypto the resolution is happening over months, not years, because every major exchange now offers WebSocket and the technical bar is lower. The asymmetry will only get worse: traders running on WebSocket are pulling away from traders running on REST.

9. Where I came from on this

For context: I'm one of the developers behind BJF Trading Group's crypto arbitrage software. We migrated the entire market-data path from REST polling to WebSocket through late 2025 and Q1 2026. Internal measurements showed that signal-to-fill rate improved by roughly an order of magnitude on liquid pairs, and that strategies which had become marginal under polling (especially cross-exchange Hedge and intra-exchange Latency) were viable again under WebSocket.

We rolled the lessons into a focused product configuration — SharpTrader Crypto — built specifically around WebSocket-native execution for crypto exchanges, with Latency and Hedge strategy modules. It also integrates with US-accepting exchanges (Coinbase, Kraken, Gemini, Bitstamp), which mattered to us because most retail crypto arbitrage tools rely on Binance/Bybit and geo-block US residents.

If you're maintaining your own bot, the rest of this article is everything you need to do the transition yourself. If you'd rather skip the connection-management plumbing and use something off-the-shelf, that's what we built.

10. TL;DR for the impatient

Crypto arbitrage windows close in under 100 ms on liquid pairs.
REST polling takes 1–1.5 seconds round-trip. You will miss most opportunities.
WebSocket pushes updates in 20–100 ms. You will catch most opportunities.
Migration is not optional in 2026.
The minimum reliable client needs: ping_interval, ping_timeout, exponential backoff, exception isolation, sequence-number validation. Skip any of these and the bot will silently lose minutes of market data when the connection blips.
Keep REST for order placement, balances, history.
The strategy logic in your bot is probably fine. The data plane is what's killing it.

How Forex Brokers Detect Latency Arbitrage in 2026: A Technical Breakdown

Boris Fesenko — Fri, 10 Apr 2026 20:50:52 +0000

Latency arbitrage has existed as long as electronic forex trading has. The concept is straightforward: if you receive a price update faster than a broker reflects it, you can trade on the broker's stale quote before it catches up. For two decades, this was primarily an infrastructure problem — whoever had faster pipes won.

In 2026, the infrastructure gap has largely closed for retail participants. Co-location at LD4, NY4, or TY3 is accessible to anyone willing to pay $100–400/month. Sub-5ms round-trip to most retail brokers is achievable. The bottleneck has shifted from hardware to detection: brokers have deployed increasingly sophisticated AI systems to identify and neutralize arbitrage order flow.

This article breaks down exactly how those detection systems work — from simple heuristics to behavioral AI — and what the detection signature of latency arbitrage actually looks like from the broker's side.

Why brokers care: the conflict of interest

Before discussing detection mechanics, it's worth understanding the broker's incentive structure.

Most retail forex brokers operate as market makers — they take the opposite side of client trades. When a client executes a profitable trade, the broker loses that amount. Conventional retail traders are unprofitable maybe 70% of the time; the statistical edge favors the broker. A latency arbitrageur running a well-configured setup might be profitable 65–75% of the time on short-hold positions. Across hundreds of trades per day, this is directly and measurably expensive for a market maker.

ECN/STP brokers have less financial incentive to detect arbitrage — they earn commissions regardless of client P&L — but many still deploy detection systems due to pressure from liquidity providers who don't want to be the "fast feed" being arbitraged against their own retail distribution.

The result: detection is financially motivated and has been improving consistently since around 2018.

Generation 1: Simple heuristics (2010–2018)

Early detection systems were rule-based and relatively easy to circumvent. They looked for obvious patterns:

Short hold time filters. If an account's average position duration was below a threshold (e.g., 30 seconds), it was flagged. Solution: add a time filter to hold positions longer.

Win rate on short-duration trades. A 70%+ win rate on positions held under 60 seconds, sustained over weeks, has no non-arbitrage explanation. Brokers tracked this per-account.

Fixed lot size uniformity. Arbitrage bots often trade identical lot sizes across every signal. Statistical distribution of lot sizes across a genuine retail account looks nothing like this. Some brokers flagged accounts where 90%+ of trades were the same size.

IP-based correlation. Two accounts connecting from the same IP with mirrored P&L (one profits when the other loses) is the lock arbitrage signature. First-generation detection caught this at the network metadata level.

These heuristics were effective against unsophisticated setups but generated significant false positives — legitimate algorithmic traders were caught in the same nets. They were also easy to work around: vary lot sizes slightly, hold positions longer, use different IPs.

Generation 2: Statistical behavioral analysis (2018–2022)

The second generation moved from hard thresholds to statistical modeling. Instead of "flag if hold time < 30s," the system builds a statistical profile of each account and compares it against a population model.

Temporal correlation analysis. This is the most powerful single latency arbitrage signal. The detection system timestamps every price update on its feed and every incoming order. For a latency arbitrageur, there is a statistically significant correlation between moments when the fast feed diverges from the broker's own price and the moment orders arrive.

Specifically: if the broker measures the time delta between its own last price update and the arrival of an order, arbitrage accounts cluster orders at small deltas (they're trading the discrepancy). Normal retail accounts place orders without any correlation to the broker's internal price update timing.

This is difficult to fake. You cannot make your order arrival time uncorrelated with price events without destroying the arbitrage signal itself.

Position lifetime distribution analysis. A latency arbitrageur's position lifetime distribution is highly abnormal from a population perspective. The distribution is heavily skewed toward very short hold times (under 30 seconds) with a long tail. No conventional trading strategy produces this shape. The broker doesn't need a hard cutoff — they fit the distribution and flag accounts whose parameters fall outside the population's confidence interval.

Adverse selection measurement. For market makers, the key metric is how often the price moves against them after filling a client order. Latency arbitrage fills are almost always immediately followed by adverse price movement (that's the point — the price is about to move). A normal retail account generates adverse selection at roughly random rates. An arbitrage account's fills are systematically followed by price movement in one direction. This signal is robust and hard to fake.

Cross-account P&L correlation. For lock arbitrage, the detection signature is: Account A profits at roughly the same times Account B loses. The correlation is high. Second-generation systems tracked this at the broker's clearing level. Two accounts whose P&L streams are strongly negatively correlated are almost certainly running a lock strategy.

Generation 3: Machine learning behavioral clustering (2022–present)

The current generation uses machine learning to identify arbitrage accounts without relying on any single signal. The key innovation is clustering: rather than flagging accounts individually, the system builds behavioral feature vectors for every account and identifies clusters of accounts whose behavior is similar.

Feature vector construction. For each account, the system constructs a high-dimensional feature vector including:

Mean and variance of position hold time
Temporal correlation coefficient between orders and fast feed updates
Win rate conditioned on hold time
Lot size distribution (mean, variance, skewness)
Time-of-day trading density (arbitrageurs concentrate on high-volatility sessions)
Slippage distribution (positive vs negative slippage ratio)
Order-to-fill time (consistent fast fills suggest algorithmic execution)
IP metadata and session behavior

Clustering. Accounts are clustered by behavioral similarity. A cluster of accounts that all entered long EUR/USD positions within 200ms of each other on Tuesday at 13:47:23 UTC isn't coincidence — they're running the same software. The ML system doesn't need to know it's arbitrage software; it just knows these accounts are behaviorally correlated.

Continuous retraining. The system retrains on new data regularly. When arbitrage software adds new masking techniques, the behavioral fingerprint changes — and the detection system adapts. This is the arms race dynamic that makes the 2026 landscape fundamentally different from 2018.

Cross-broker data sharing. This is the most concerning development for arbitrage operators. There is no regulatory prohibition on brokers sharing behavioral metadata about client trading patterns. Some broker networks and shared liquidity arrangements informally share account flagging data. An account flagged at one broker in a network can be pre-flagged at another before any trades are placed.

What detection actually looks like from the trader's perspective

Detection rarely manifests as an immediate account closure. The typical progression:

Phase 1 — Monitoring. The account is flagged as potentially arbitrage. No action is taken. The broker accumulates data to confirm.

Phase 2 — Soft countermeasures. The broker introduces artificial execution delays specifically on this account — typically 30–150ms added to order processing. The trader sees execution times increasing gradually. Slippage becomes systematically negative. The arbitrage window closes before the order fills. Profitability drops without any visible restriction.

Phase 3 — Targeted spread widening. The broker applies per-account spread markup on instruments used most frequently for arbitrage. From the trader's perspective, spreads appear wider than published rates. This is applied at the server level and isn't visible in standard platform spread displays.

Phase 4 — Account action. Depending on the broker's ToS and appetite for risk: profit confiscation on flagged trades, account restriction, or closure with capital returned.

The gradient approach is deliberate: it makes it harder for the trader to identify exactly when detection occurred and allows the broker to extract more data before acting.

The detection-resistance problem

The fundamental challenge is that temporal correlation — the primary detection signal — is intrinsic to latency arbitrage. You cannot remove it without removing the strategy itself. Every order that is causally related to a fast-feed price event will be temporally correlated with that event.

The countermeasures that exist work by adding noise to the signal rather than eliminating it:

Behavioral blending. Running technical indicator-based entry triggers (RSI, candlestick patterns) in parallel with arbitrage execution creates an order history that partially resembles retail technical trading. The temporal correlation signal is diluted but not eliminated.

Virtual order systems. Decoupling re-entry timing from fast-feed events by using software-side virtual orders that execute based on price levels rather than signal timing. The broker sees an order placed when price reached a certain level — not when the fast feed moved.

Account rotation and profile separation. Maintaining multiple accounts with distinct behavioral profiles, IPs, and execution patterns to prevent clustering detection from linking them.

Noise trading. Adding deliberately unprofitable or breakeven trades to normalize the win rate distribution and adverse selection metrics.

None of these fully eliminate the detection signal — they reduce its statistical strength. The detection system needs sufficient signal strength to confidently flag an account; countermeasures aim to keep the signal below that threshold.

Conclusions

The 2026 broker detection landscape reflects a genuine technological arms race. The progression from simple hold-time heuristics to ML-based behavioral clustering represents a substantial increase in detection capability.

What hasn't changed: latency arbitrage remains legal in all major jurisdictions. No financial regulator has classified it as market manipulation or any prohibited activity. The detection and restriction that traders face is contractual — brokers enforcing terms of service — not legal.

What has changed: the infrastructure edge that defined latency arbitrage profitability for its first decade is now table stakes. The differentiating factors in 2026 are detection resistance, broker selection, and behavioral profile management.

For a more detailed technical breakdown of infrastructure requirements and masking strategy mechanics, see: Latency Arbitrage: Complete Guide 2026 — which covers VPS colocation benchmarks, fast feed architecture, and the specific masking strategies (Phantom Drift, BrightDuo) currently in production use.

The author develops arbitrage trading software at BJF Trading Group, a Canadian HFT software company active in the arbitrage space since 2000.

Tags: HFT algorithmic trading forex arbitrage market microstructure trading systems

DEV Community: Boris Fesenko

Retail Forex Brokers Don't Publish Execution Data — So I Open-Sourced a Way to Measure It

BEQI: an open, standardized Broker Execution Quality Index across five dimensions — plus a public benchmark anyone can contribute to.

Why spread is a terrible proxy for execution quality

The five dimensions of execution quality

Rolling it into one score (carefully)

How you audit your own broker

The part that makes it useful: a public benchmark

Methodology critique welcomed

Get the code

Measuring broker latency: building a tick-divergence detector for latency arbitrage

The one number that matters

Modelling a "divergence"

The detector

A runnable simulation

Get the code

What the toy model conveniently ignores

From a detector to a decision

Why crypto arbitrage windows close before your REST poll completes

1. The numbers that broke REST polling

2. Why REST is fundamentally slow

3. WebSocket: push, not poll

4. A simple benchmark

5. The architectural shift

6. Production-grade WebSocket client

7. What still needs REST

8. What happens to retail bots that don't make this transition

9. Where I came from on this

10. TL;DR for the impatient

Further reading

How Forex Brokers Detect Latency Arbitrage in 2026: A Technical Breakdown

Why brokers care: the conflict of interest

Generation 1: Simple heuristics (2010–2018)

Generation 2: Statistical behavioral analysis (2018–2022)

Generation 3: Machine learning behavioral clustering (2022–present)

What detection actually looks like from the trader's perspective

The detection-resistance problem

Conclusions