Айсберг-заявки: видимый объём, резерв и исполнение

Сравните данные владельца с публичным ценовым уровнем и последовательно запускайте встречные покупки. Очередь A/B — учебное представление известного сценария: обычный публичный стакан не раскрывает скрытый резерв и владельца каждой заявки. После изменения параметров примените их, чтобы построить новый пример. Последовательность покупок фиксирована, поэтому большая пользовательская заявка может исполниться лишь частично.

Айсберг-заявки, или reserve orders, позволяют указать видимую часть большего объёма. В интерфейсе параметр может называться Display Size, peak quantity или visible quantity. Это настройка, а не обязательно объём, который сейчас стоит в стакане:

Если отмены не было: общий объём = исполнено + осталось, а осталось = видимый объём + скрытый резерв. Пополнение переносит количество из резерва в видимую часть; оно не увеличивает исходную заявку. Максимальная видимая часть может оставаться прежней, хотя после частичного исполнения на экране будет меньше.

В исходном примере продаются 25 единиц по лимитной цене 100: видны максимум 10, ещё 15 находятся в резерве. За первой частью стоит отдельная заявка B на продажу 5 единиц по той же цене. Количества и цены условные; других ценовых уровней, заявок и отмен в сценарии нет.

Встречная покупка 4 единиц уменьшает видимую часть айсберга с 10 до 6. Скрытый резерв остаётся равным 15, исполнено 4. Публичный уровень теперь показывает 11: 6 у айсберга и 5 у B. Покупка ещё 6 исчерпывает первую часть. Модель показывает следующие 10, оставляя 5 в резерве. Это пополнение, а не прибавление новых 10 единиц к общему объёму.

Новая часть встаёт за B, поэтому следующая покупка 5 единиц исполняет B, не меняя исполненный объём айсберга. Позже, когда у айсберга останется всего 5 единиц, последняя видимая часть составит 5, хотя её максимум задан равным 10. Полный журнал событий доступен в компоненте.

Такой порядок соответствует опубликованным правилам Kraken: пополненная часть переходит в конец очереди своей цены. Это выбранная модель, а не правило для любой биржи. Сценарий одной встречной покупки также показывает, что достаточно большая заявка может поглотить несколько пополненных частей. Документация CME по сообщениям об исполнении описывает несколько пополнений в одном событии сопоставления заявок. Пополнение не обязательно означает нового покупателя или отдельный отчёт об исполнении.

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

CME Market by Order различает нативную и синтетическую реализации. У нативного айсберга CME при пополнении сохраняется OrderID, но PriorityID может измениться. Постоянный идентификатор поэтому не доказывает сохранение прежнего места в очереди. Ориентируйтесь на правила сопоставления конкретного инструмента, а не на предположение о единой для всех очереди FIFO.

Некоторые параметры можно совмещать, если площадка это разрешает, но они не взаимозаменяемы. Стоп-условие относится к активации, а iceberg — к видимому объёму. Разницу между условием срабатывания и лимитной ценой объясняет гид Buy Stop vs Buy Limit.

Агрегированный стакан показывает видимый объём на ценовом уровне. Он может объединять несколько заявок, как в демонстрации объединены айсберг и B. Данные по отдельным заявкам могут быть подробнее, но набор полей и идентификаторов зависит от потока данных. Компонент раскрывает обе стороны для обучения; он не восстанавливает приватные количества по рыночным данным.

Повторные исполнения с последующим пополнением могут указывать на скрытую ликвидность. Сами по себе они не раскрывают точный первоначальный объём, оставшийся резерв или владельца. На ту же цену могут приходить новые независимые заявки. Предполагаемый айсберг — гипотеза, убедительность которой зависит от данных, а не достоверная карта чужих намерений.

Отображение части ограничивает размер, который одновременно виден другим. Это может быть полезно, если трейдер хочет исполнять большую заявку, не раскрывая весь её остаток. Однако исполнения не становятся невидимыми: меньший видимый объём не гарантирует слабого влияния на рынок или постоянного наличия встречных участников.

• Лимитная цена ограничивает допустимую цену исполнения; неисполненный остаток всё равно может ждать или вовсе не исполниться.
• Пополнение может менять приоритет в очереди. Меньшая видимая часть не обязательно ускоряет исполнение всей заявки.
• Другие участники могут реагировать на видимые исполнения и изменения стакана, даже если весь резерв скрыт.

Разделяйте ценовое ограничение и качество исполнения относительно другого ориентира. Гид по проскальзыванию объясняет расхождение между ориентиром и ценой сделки; настройка iceberg сама по себе не устраняет необходимость такого сравнения.

• Поддерживают ли этот инструмент, биржа и маршрут айсберг-заявки; нативная это реализация или синтетическая.
• Минимальное количество, шаг объёма, допустимую видимую часть и срок действия в актуальной спецификации.
• Правила пополнения, приоритета, изменения и отмены, включая работу с дочерними заявками синтетического айсберга.
• Фактические исполнения и остаток родительской заявки в отчёте, а также применимый тариф комиссий.

Справка Kraken показывает, что требования к видимой части зависят от площадки; конкретные лимиты нельзя переносить на все биржи. В демонстрации используются целые единицы и фиксированный максимум видимой части, чтобы механику было легко проверить. Она не проверяет доступность заявки на бирже и не отправляет реальные ордера.

Всегда ли айсберг оплачивается по тарифу мейкера?

Нет. Iceberg описывает видимый объём, а не роль в предоставлении ликвидности для каждого исполнения. Возможность немедленной сделки, допустимые сочетания параметров и комиссия зависят от реализации и исполнения. Проверьте правила maker/taker площадки. Гид по торговым расходам также объясняет, почему спред и комиссию следует оценивать вместе.

Можно ли выставить такую заявку из MT4 или MT5?

Наличие стакана само по себе не подтверждает поддержку iceberg. Брокер должен предоставить подходящий маршрут или внешнюю реализацию для этого инструмента. Проверьте документацию и тестовую среду: требования синтетического инструмента к соединению и отмене могут отличаться от нативной биржевой заявки.

Стоит ли всегда выбирать наименьшую видимую часть?

Универсально лучшего размера нет. Меньшая часть раскрывает меньше объёма за раз, но может потребовать больше пополнений с предусмотренным площадкой изменением очереди. Выбор также ограничен минимальным количеством и его шагом. Демонстрация объясняет механику, а не оптимизирует стратегию исполнения реальной заявки.