Очередь внутри стенки: анализ позиции ордера в плотности ордербука

Введение: почему агрегированный стакан врёт

Каждый трейдер, торгующий по стакану, видит одну и ту же картину: слева — bid, справа — ask, на каждом ценовом уровне — число, показывающее суммарный объём лимитных ордеров. Например:

Цена 10001  |  150 лотов
Цена 10000  |  2,400 лотов   ← стена
Цена  9999  |  80 лотов

2,400 лотов на уровне 10000 — это «стена» (wall, density, плотность). И здесь возникает критически важный вопрос, который большинство трейдеров игнорирует: где именно внутри этих 2,400 лотов находится наш ордер?

Цена 10000  [ 1,800 лотов ДО нас ][ НАШ ОРДЕР 10 лотов ][ 590 лотов ПОСЛЕ нас ]

Это не академическое любопытство. Это разница между исполненным и неисполненным ордером. Между прибылью и убытком. Между бэктестом, который показывает красивую эквити, и реальностью, в которой ваша стратегия не работает.

Что такое Queue Position и зачем его считать

Визуализация FIFO-очереди: позиция трейдера среди других ордеров на ценовом уровне

FIFO и реальность бирж

Подавляющее большинство бирж — как традиционных (CME, NASDAQ), так и криптовалютных (Binance, Bybit, OKX) — используют правило Price-Time Priority (FIFO). Это означает: при одинаковой цене первым исполняется тот ордер, который был выставлен раньше.

Когда приходит рыночный (маркет) ордер на продажу и «бьёт» по нашему ценовому уровню bid, он последовательно исполняет лимитные ордера от головы очереди к хвосту. Если рыночный ордер был недостаточно большим, чтобы дойти до нашей позиции в очереди — мы остаёмся неисполненными.

Два компонента стоимости позиции в очереди

Академические исследования (Moallemi & Yuan, Columbia Business School, 2017) выделяют два компонента ценности позиции в очереди:

1. Статический компонент — трейдофф между заработком на спреде и adverse selection. Чем дальше мы в очереди, тем выше вероятность, что нас исполнит именно крупный информированный ордер (а не шум). Проще говоря: если вас исполняют последним в очереди — скорее всего, цена уже идёт против вас.

2. Динамический компонент — опциональность, которую даёт улучшение позиции в очереди со временем. Когда ордера перед нами отменяются или исполняются, наша позиция улучшается без каких-либо действий с нашей стороны.

Эмпирические данные показывают, что для инструментов с крупным тиком стоимость позиции в очереди может быть сопоставима с размером спреда. Это огромная величина.

Как оценить свою позицию в очереди

Задача оценки

Мы выставляем лимитный ордер размером S по цене P. В момент выставления на этом ценовом уровне уже стоит Q лотов. Наша начальная оценка позиции:

V̂(t₀) = Q(t₀)     — количество лотов перед нами

Далее мы отслеживаем все изменения объёма на нашем ценовом уровне. Это ключевой алгоритм, описанный Erik Rigtorp и реализованный в продуктах Trading Technologies (TT), Bookmap и других.

Алгоритм обновления

При каждом уменьшении ΔQ на ценовом уровне нужно понять: это сработал ордер перед нами или после нас?

Если мы можем различить fills (исполнения) и cancellations (отмены):

• Fill (исполнение): однозначно уменьшает очередь перед нами → V̂ = max(V̂ + ΔQ, 0)
• Cancel (отмена): неопределённость — мог быть отменён ордер как до, так и после нас

Для отмен используется вероятностная модель:

V̂(n+1) = max(V̂(n) + p(n) × ΔQ(n), 0)

где p(n) — вероятность того, что отменённый ордер стоял перед нами. Одно семейство моделей:

p(n) = f(V̂(n)) / (f(V̂(n)) + f(max(Q(n) - S - V̂(n), 0)))

где f(x) — возрастающая функция, например ln(1+x) или тождественная. Интуиция: чем больше объём перед нами относительно объёма после, тем вероятнее, что отмена была именно перед нами.

Уровни данных и реальность крипторынков

Качество оценки напрямую зависит от детализации данных:

В крипте ситуация такова:

• Binance — предоставляет L2 depth stream с обновлениями каждые 100мс. L3 (MBO) данные недоступны публично.
• Coinbase — один из немногих CEX, дающий L3 поток через WebSocket с полными order-by-order данными.
• CME (фьючерсы на BTC/ETH) — полные MBO данные через ITCH feed.

Большинство крипто-трейдеров работают с L2, а значит — с вероятностными оценками. Но даже вероятностная оценка радикально лучше, чем никакая.

Визуализация: стена как внутренний стакан

Мы предлагаем визуализировать каждую значимую плотность (стену) как мини-стакан внутри стакана:

╔════════════════════════════════════════════════════════════════╗
║  Цена 10001  │  150 лотов                                    ║
╠════════════════════════════════════════════════════════════════╣
║  Цена 10000  │  [████████████░░░▓▓░░░░░░░]  2,400 лотов      ║
║              │   ↑ 1,800 до нас  ↑ мы  ↑ 590 после           ║
║              │   скорость расхода: ~120 лотов/сек             ║
║              │   ETA до исполнения: ~15 сек                   ║
╠════════════════════════════════════════════════════════════════╣
║  Цена  9999  │  80 лотов                                     ║
╚════════════════════════════════════════════════════════════════╝

Что рассчитывается в реальном времени

1. Лоты до нашего ордера — оценка количества объёма, которое должно быть исполнено или отменено, прежде чем дойдёт до нас.

2. Лоты после нашего ордера — объём, выставленный после нас. Если стена быстро «набухает» с хвоста — значит другие участники считают этот уровень привлекательным.

3. Скорость движения очереди — рассчитывается по фактическим trades (исполнениям) на этом ценовом уровне. Выражается в лотах/секунду.

4. Estimated Time to Fill (ETF) — прогноз времени до исполнения нашего ордера, рассчитанный как лоты_до_нас / скорость_расхода.

5. Несколько ордеров в одной плотности — бот может видеть позицию каждого своего ордера, если их несколько в одной стене.

Применение в скальпинге

Сравнение наивного и queue-aware бэктестинга: реальная вероятность исполнения vs оптимистичная оценка

Проблема бэктестинга на свечных данных

Классический бэктест по OHLCV-свечам работает так: если цена дошла до нашего лимитного ордера — считаем его исполненным. Но это грубейшая ошибка:

Пример. У нас стоит бай-лимит на 10000. В минутной свече low = 10000. Свечной бэктест засчитывает fill. Но в реальности:

• На уровне 10000 стояла стена в 5,000 лотов
• Наш ордер был в хвосте очереди (4,800-я позиция)
• За эту минуту по уровню прошло только 2,000 лотов
• В реальности наш ордер НЕ был бы исполнен

Queue-aware бэктест решает эту проблему: он моделирует позицию в очереди, считает объём trades на уровне по тиковым данным, и определяет, хватило ли проторгованного объёма, чтобы дойти до нашей позиции.

За одну минуту — больше одного исполнения

При активном скальпинге ордер может исполниться и быть переставлен несколько раз за одну минуту. Свечной бэктест в принципе не может это смоделировать. Только тиковый анализ с моделированием очереди позволяет:

• Определить точное время каждого fill
• Понять, успеваем ли мы переставить ордер
• Оценить, сколько раз стратегия реально сработала бы за интервал

Прогнозирование времени до исполнения

Бот, знающий свою позицию в очереди и текущую скорость «расхода» стены, может:

1. Рассчитать ETA — примерное время до исполнения
2. Соотнести ETA с прогнозом движения цены — если ETA = 30 секунд, а наша модель предсказывает разворот через 10 секунд, стоит отменить ордер
3. Адаптировать размер ордера — больший ордер ближе к голове очереди на про-рейт биржах (CME), но на FIFO-биржах размер не имеет значения для позиции

Сравнение скорости расхода со средней

Ценнейшая метрика для скальпера: текущая скорость расхода очереди vs средняя скорость за N свечей.

• Скорость выше средней → высокая агрессия маркет-ордеров → стена может «пробиться» → наш fill вероятнее
• Скорость ниже средней → рынок «замер» → стена устоит → ордер зависнет, а цена может уйти

Где это уже реализовано: обзор рынка

Trading Technologies (TT) — Position In Queue (PIQ)

Наиболее зрелая реализация. TT отображает PIQ для каждого ордера трейдера в колонке Floating Order Book. Для бирж, предоставляющих данные о позиции в очереди напрямую через фид (CME, ICE), показываются точные значения. Для остальных — консервативная оценка.

Bookmap Quant

Профессиональная версия Bookmap ($499/мес) включает визуализацию позиции ордеров в очереди и экспорт событий. Bookmap Quant использует MBO-данные и его L0 API позволяет строить кастомные адаптеры для любых данных.

CQG — Queue Position Estimation

CQG предоставляет оценку позиции в очереди для фьючерсных рынков. Платформа рассчитывает вероятностную оценку PIQ на основе L2/L3 данных и отображает её в интерфейсе DOMTrader.

Rithmic — Order Queue Data

Rithmic — провайдер рыночных данных, предоставляющий низколатентный доступ к данным для оценки позиции в очереди. Используется как инфраструктурный слой многими проп-трейдинговыми фирмами и алготрейдерами для построения собственных моделей PIQ.

Jigsaw Trading — Order Flow Visualization

Jigsaw Trading специализируется на визуализации потока ордеров (order flow) с оценкой позиции в очереди. Инструменты Depth & Sales и Reconstructed Tape помогают трейдерам видеть реальную картину исполнения на ценовых уровнях.

Академические модели

• Moallemi & Yuan (2017) — формальная модель оценки стоимости позиции в очереди на основе NASDAQ ITCH данных
• Cont, Stoikov & Talreja (2010) — модель limit order book как системы birth-death процессов
• Gould & Bonart (2015) — queue imbalance как предиктор движения mid-price
• Deep Learning подходы — RNN-модели (Columbia, 2022) для оценки fill probabilities и fill times

Чего НЕ существует на рынке

Ни один из существующих продуктов не предлагает визуализацию внутренней структуры стены для крипторынков в формате, заточенном под скальпинг-бота. Это и есть ниша, которую может занять Marketmaker.cc.

Противодействие стратегиям манипуляторов

Обнаружение фальшивых стен: настоящие ордера vs спуфинг-блоки с высоким cancel rate

Понимание внутренней структуры стены — это не только оптимизация собственного исполнения. Это инструмент защиты от манипуляций и, при грамотном использовании, инструмент чтения намерений крупных игроков.

Spoofing: фальшивые стены

Спуфинг — выставление крупных ордеров с намерением их отменить до исполнения. Цель — создать ложное впечатление спроса/предложения.

Как PIQ-анализ помогает:

• Скорость набора объёма стены. Настоящая стена набирается постепенно. Спуфинг-стена появляется мгновенно.
• Поведение при приближении цены. Настоящая стена остаётся. Спуф-стена «убегает».
• Cancel rate. Спуфер отменяет ордера до исполнения. Отслеживание соотношения placed/canceled позволяет детектировать спуф в реальном времени.
• Цикличность. Спуфинг часто демонстрирует повторяющиеся паттерны: появление → исчезновение → появление на новом уровне.

Layering: каскад фальшивых уровней

Layering — более сложная форма спуфинга, при которой фальшивые ордера выставляются на нескольких ценовых уровнях.

Как PIQ-анализ помогает:

• Коррелированные отмены. Если ордера на 5 последовательных уровнях отменяются одновременно — это почти наверняка layering одного участника.
• Асимметрия стакана. Настоящая ликвидность обычно распределена более-менее равномерно.
• Реакция на fills. Настоящие ордера исполняются и не «убегают».

Iceberg orders: скрытая ликвидность

Iceberg — это крупный ордер, разбитый на маленькие видимые части. После исполнения одной части автоматически появляется следующая.

Как PIQ-анализ помогает:

• Паттерн «бессмертного» уровня. Объём постоянно исполняется, но не уменьшается.
• Absorption analysis. Цена бьёт в стену, исполняет видимый объём, но стена восстанавливается.
• Поведение нашей очереди при абсорбции. Наша позиция «проскальзывает» вперёд каждый раз, когда кусок айсберга исполняется и перевыставляется в хвост очереди.

Маркетмейкер как «невидимый» участник стены

Профессиональные market makers используют несколько тактик:

1. Quote stuffing — массовое выставление и отмена ордеров для «замусоривания» данных конкурентов
2. Penny jumping — выставление ордера на 1 тик лучше конкурента для захвата приоритета
3. Dynamic quoting — адаптация ордеров в реальном времени при изменении queue imbalance
4. Защита уровня — добавление ликвидности при приближении цены

Реализация: архитектура модуля Queue Position Tracker

Входные данные

1. WebSocket поток ордербука (L2 depth):
   - Обновления best bid/ask
   - Обновления depth (объём на каждом ценовом уровне)

2. WebSocket поток trades:
   - Каждая сделка: цена, объём, сторона (buy/sell), timestamp

3. Собственные ордера (от торгового бота):
   - order_id, price, size, timestamp выставления

Ядро алгоритма (Python-like псевдокод)

class QueuePositionTracker:
    def __init__(self, order_price, order_size, initial_depth):
        self.price = order_price
        self.size = order_size
        self.queue_ahead = initial_depth  # V̂(t₀) = Q(t₀)
        self.queue_behind = 0
        self.fill_velocity = EMA(span=30)  # EMA скорости исполнения

    def on_trade(self, trade_price, trade_size):
        """Вызывается при каждом trade на нашем ценовом уровне"""
        if trade_price == self.price:
            self.queue_ahead = max(self.queue_ahead - trade_size, 0)
            self.fill_velocity.update(trade_size)

    def on_depth_change(self, new_depth, change_type):
        """Вызывается при изменении глубины на нашем ценовом уровне"""
        if change_type == 'cancel':
            total = self.queue_ahead + self.size + self.queue_behind
            p_ahead = log(1 + self.queue_ahead) / (
                log(1 + self.queue_ahead) + log(1 + self.queue_behind)
            )
            cancelled = abs(new_depth - total)
            self.queue_ahead = max(
                self.queue_ahead - p_ahead * cancelled, 0
            )
            self.queue_behind = max(
                self.queue_behind - (1 - p_ahead) * cancelled, 0
            )
        elif change_type == 'new_order':
            added = new_depth - (self.queue_ahead + self.size + self.queue_behind)
            self.queue_behind += added

    @property
    def estimated_time_to_fill(self):
        """Прогноз времени до исполнения в секундах"""
        if self.fill_velocity.value <= 0:
            return float('inf')
        return self.queue_ahead / self.fill_velocity.value

    @property
    def fill_probability(self, horizon_sec=60):
        """Вероятность исполнения за заданный горизонт"""
        expected_volume = self.fill_velocity.value * horizon_sec
        return min(expected_volume / max(self.queue_ahead, 1), 1.0)

Критические edge cases

1. Стена полностью «проедена» — если queue_ahead упал до 0, следующий маркет-ордер исполнит нас
2. Массовая отмена (wall pull) — стена резко исчезает, queue_ahead скачкообразно меняется
3. Наш ордер перемещён — при отмене и перевыставлении мы попадаем в хвост очереди
4. Множественные ордера в одной стене — каждый отслеживается независимо

Метрики для dashboard и бэктестинга

Для реального времени (скальпинг-терминал)

Для бэктеста (queue-aware simulation)

1. Queue-adjusted fill rate — процент ордеров, реально исполненных с учётом позиции в очереди
2. Effective fill latency — реальное время от выставления до исполнения
3. Adverse selection per fill — средний move цены против нас после исполнения
4. Queue velocity correlation — корреляция между скоростью расхода очереди и последующим движением цены

Социальный стакан: ордера команды внутри стены

Трёхуровневая модель видимости: личные ордера, подписки и командные позиции внутри стены

Уровень 1: Биржа или торговая платформа

Если вы — биржа или торговый терминал, вы обладаете абсолютным знанием о позиции каждого ордера каждого пользователя. Платформа может показать каждому пользователю: сколько «чужого» объёма стоит до и после его ордера, не раскрывая имена других участников.

Уровень 2: Платформа Marketmaker.cc — личные ордера + социальный слой

В Marketmaker.cc мы планируем реализовать трёхуровневую модель видимости ордеров внутри стены:

🔴 Личные ордера пользователя — базовый слой. Каждый трейдер видит все свои ордера с индивидуальными метриками.

🟡 Ордера подписок (signal providers) — трейдеры, которые делятся позициями по подписке. Opt-in механизм: лидер сам решает, показывать ли позиции.

🟢 Ордера команды (trading team / fund) — самый ценный слой для профессиональных групп. Решает проблемы: конфликт ордеров, распределение ликвидности, командный risk monitoring, обучение.

Модель разрешений

┌─────────────────────────────────────────────────────────────┐
│  Ордер трейдера                                             │
│                                                             │
│  Видим:                                                     │
│  ├── Самому трейдеру           → ВСЕГДА (🔴)               │
│  ├── Подписчикам               → если трейдер включил (🟡)  │
│  │   ├── Задержка отображения  → настраивается (0s–60s)    │
│  │   ├── Показывать размер     → да / скрыть / округлить   │
│  │   └── Показывать ETA        → да / нет                  │
│  └── Команде                   → если состоит в команде (🟢)│
│      ├── Задержка              → настраивается (0s–5s)     │
│      ├── Показывать размер     → да (для risk management)  │
│      └── Видимость для роли    → trader / manager / viewer │
└─────────────────────────────────────────────────────────────┘

Полная прозрачность: DEX-биржи и on-chain ордербук

На DEX-биржах с on-chain ордербуком — прежде всего Hyperliquid — каждый ордер привязан к конкретному адресу кошелька. Мы можем видеть не просто агрегированную стену, а каждый отдельный ордер каждого участника.

Однако для работы с этими данными в реальном времени необходимо поднять собственную ноду блокчейна Hyperliquid.

🤖 Автоматическое выделение ордеров манипуляторов

Четвёртый слой визуализации — алгоритмическая разметка ордеров по типу участника: маркетмейкеры, спуферы, retail. Алгоритмы классификации работают на нескольких уровнях: детекция спуфинга, классификация маркетмейкеров, детекция squeeze-сценариев, цифровой слепок трейдера.

Подробнее об этом — в следующей статье серии: «Цифровой слепок трейдера: как идентифицировать маркетмейкера по его поведению в ордербуке»

Заключение

Анализ позиции ордера внутри плотности ордербука — это следующий эволюционный шаг от «смотрю на стакан» к «понимаю микроструктуру рынка». Это территория, где пересекаются:

• Теория массового обслуживания (queueing theory) — для моделирования очередей
• Stochastic order flow models — для оценки fill probabilities
• Machine learning — для детекции спуфинга и прогнозирования поведения стен
• Инженерия низкой задержки — для получения и обработки данных в реальном времени

На сегодняшний день ни один продукт на крипторынке не предлагает полноценной визуализации «стены как мини-стакана» с позициями пользовательских ордеров, оценкой ETA, детекцией спуфинга и queue-aware бэктестингом в едином интерфейсе.

Мы в Marketmaker.cc работаем над тем, чтобы эта аналитика была доступна каждому трейдеру — от соло-скальпера до проп-команды.

Источники и дальнейшее чтение

• Moallemi C.C., Yuan K. — «A Model for Queue Position Valuation in a Limit Order Book» (Columbia Business School, 2017)
• Cont R., Stoikov S., Talreja R. — «A Stochastic Model for Order Book Dynamics» (2010)
• Gould M.D., Bonart J. — «Queue Imbalance as a One-Tick-Ahead Price Predictor» (2015)
• Rigtorp E. — «Estimating Order Queue Position» (rigtorp.se)
• Do B.L., Putniņš T.J. — «Detecting Layering and Spoofing in Markets» (SSRN, 2023)
• Trading Technologies — PIQ Documentation
• Bookmap — Iceberg Orders Tracker Knowledge Base