How I built an FVG trading bot for OKX and made 99% of its signals useless on purpose

Introduction

Fair Value Gaps (FVG) are a widely discussed price action pattern in algorithmic trading. The concept tracks a three-candle sequence where the high of the first candle and the low of the third candle do not overlap, leaving a theoretical imbalance zone in the middle candle. Retail implementations typically trigger a trade the moment the gap forms. In practice, that approach burns capital.

I built an OKX trading bot that detects FVGs in real-time, then immediately discards 99% of them. This was not a bug. It was an architectural requirement. Crypto markets operate continuously with fragmented liquidity, aggressive volatility, and non-trivial fee structures. Raw pattern detection generates noise. By treating signal generation as a high-throughput stream and applying deterministic rejection gates, the system only executes when microstructure conditions, volatility regimes, and break-even thresholds align. The result is a lean, risk-aware execution pipeline that mirrors institutional signal-processing architecture.

Why This Matters

Engineers building automated trading systems face a distributed systems problem disguised as a financial one. You are ingesting high-frequency market data, transforming it into stateful signals, routing orders through a third-party API, and maintaining accurate position ledgers under network jitter and exchange rate limits.

Naive bots fail because they optimize for signal velocity instead of signal quality. Every false trigger costs maker/taker fees, consumes API quota, and increases slippage risk. In production, this creates a compounding drag on expectancy. By intentionally filtering 99% of raw signals, you solve three engineering problems:

1. Backpressure Management: Reducing execution load prevents WebSocket callback blocking and API throttling.
2. Deterministic Risk Control: Forces the system to validate break-even conditions before order submission.
3. Alpha Preservation: Concentrates capital on high-probability microstructure setups instead of gambling on statistical noise.

This architecture applies to any event-driven automation system where signal-to-noise ratio dictates long-term viability.

How It Works

The system operates as an asynchronous, event-driven pipeline. Market data arrives via OKX WebSocket streams, gets buffered into rolling OHLCV windows, and passes through a multi-stage filter chain. Only signals that survive every gate reach the execution engine. The architecture enforces idempotency, circuit-breaking, and strict position tracking.

flowchart TD
    A[OKX WebSocket Stream] --> B[Rolling OHLCV Buffer]
    B --> C[FVG Detector Engine]
    C --> D{Raw Signal Generated?}
    D -->|Yes| E[Signal Buffer Queue]
    D -->|No| A
    E --> F[Regime Filter Volatility / Trend]
    F --> G{Pass?}
    G -->|Yes| H[Liquidity Sweep Validator]
    G -->|No| I[Drop Signal Log]
    H --> J{Pass?}
    J -->|Yes| K[Fee & Slippage Gate]
    J -->|No| I
    K --> L{Break-Even Valid?}
    L -->|Yes| M[OKX Execution Router]
    L -->|No| I
    M --> N[Idempotency Check & Order Submit]
    N --> O[Position Ledger & Telemetry]
    O --> P[Live Monitoring Dashboard]

Step-by-step flow:

1. Data Ingestion: OKX WebSocket feeds tick-level trades and order book snapshots. A ring buffer aggregates them into configurable timeframe candles.
2. FVG Detection: The engine evaluates the three-candle gap condition. If satisfied, it emits a raw signal struct containing entry zone, direction, and timestamp.
3. Regime Filter: Measures current volatility against a rolling ATR baseline. Rejects signals during low-liquidity chop or extreme volatility spikes where slippage exceeds tolerance.
4. Liquidity Sweep Validator: Checks if price recently swept a nearby liquidity pool before forming the gap. FVGs without prior liquidity interaction historically underperform.
5. Fee & Slippage Gate: Calculates exact maker/taker fees, estimated slippage from order book depth, and minimum move required to break even. Drops the signal if the required move exceeds statistical probability.
6. Execution Router: Submits the order via OKX REST API with a unique idempotency key. A circuit breaker halts submissions if consecutive failures or rate limits trigger.
7. Ledger & Telemetry: Records position state, updates PnL, and pushes metrics to a monitoring stack for drift analysis.

Core Concepts

Three-Candle Gap Logic: An FVG exists when candle[0].high < candle[2].low (bullish) or candle[0].low > candle[2].high (bearish). The gap zone sits between the overlapping extremes. The engine normalizes timestamps and handles missing ticks gracefully.

Chain-of-Responsibility Filtering: Each filter stage is an independent, stateless validator. They execute sequentially and short-circuit on failure. This design allows hot-swapping filters without modifying core detection logic.

Idempotent Execution: OKX supports idempotency keys for order creation. The bot generates a deterministic hash from signal metadata. Network retries never duplicate orders.

Position Ledger & State Machine: Instead of relying on exchange webhooks alone, the bot maintains a local authoritative ledger. It reconciles with OKX periodically and flags drift. State transitions follow strict enums: PENDING, OPEN, PARTIAL_CLOSE, CLOSED, ERROR.

Circuit Breaking: The execution router tracks consecutive failures and latency percentiles. If thresholds breach, the router enters a half-open state, attempts a single probe order, and either restores or resumes cooldown.

Examples & Code Walkthrough

The following Python implementation demonstrates the detection engine, filter pipeline, and execution router. It uses asyncio, type hints, and defensive error handling.

import asyncio
import hashlib
import logging
from dataclasses import dataclass, field
from enum import Enum
from typing import List, Optional

from okx import AsyncClient  # Hypothetical wrapper matching OKX SDK

logger = logging.getLogger("fvg_bot")

class Direction(Enum):
    LONG = "long"
    SHORT = "short"

@dataclass
class Candle:
    timestamp: float
    open: float
    high: float
    low: float
    close: float
    volume: float

@dataclass
class Signal:
    id: str
    direction: Direction
    entry_low: float
    entry_high: float
    timestamp: float
    pair: str
    metadata: dict = field(default_factory=dict)

class FVGDetector:
    def __init__(self, window_size: int = 3):
        self.window: List[Candle] = []
        self.window_size = window_size

    def update(self, candle: Candle) -> Optional[Signal]:
        self.window.append(candle)
        if len(self.window) > self.window_size:
            self.window.pop(0)

        if len(self.window) < self.window_size:
            return None

        c0, c1, c2 = self.window
        # Bullish FVG: c0.high < c2.low
        if c0.high < c2.low:
            return Signal(
                id=self._generate_id(c2.timestamp, "LONG"),
                direction=Direction.LONG,
                entry_low=c0.high,
                entry_high=c2.low,
                timestamp=c2.timestamp,
                pair="BTC-USDT-SWAP"
            )
        # Bearish FVG: c0.low > c2.high
        if c0.low > c2.high:
            return Signal(
                id=self._generate_id(c2.timestamp, "SHORT"),
                direction=Direction.SHORT,
                entry_low=c2.high,
                entry_high=c0.low,
                timestamp=c2.timestamp,
                pair="BTC-USDT-SWAP"
            )
        return None

    @staticmethod
    def _generate_id(ts: float, direction: str) -> str:
        raw = f"{ts}_{direction}_v1"
        return hashlib.sha256(raw.encode()).hexdigest()[:16]

class FilterPipeline:
    def __init__(self, max_slippage_bps: float = 15.0, fee_bps: float = 5.0):
        self.max_slippage_bps = max_slippage_bps
        self.fee_bps = fee_bps

    def validate(self, signal: Signal) -> bool:
        # Regime filter: skip if volatility is too low or too high
        if not self._check_regime(signal):
            logger.info("Dropped: regime filter failed")
            return False

        # Liquidity sweep check: requires prior liquidity interaction
        if not self._check_liquidity_sweep(signal):
            logger.info("Dropped: no liquidity sweep confirmation")
            return False

        # Fee & slippage gate: ensure break-even is statistically viable
        if not self._check_fees_and_slippage(signal):
            logger.info("Dropped: break-even threshold exceeded")
            return False

        return True

    def _check_regime(self, signal: Signal) -> bool: