FIX ≠ DMA: три способа отправить заявку

В БКС есть направление прямого доступа к бирже: мы подключаем клиентов к шлюзам Московской биржи, помогаем с роботами и инфраструктурой. Часто разговор начинается с вопроса про FIX – и почти всегда за ним стоят разные вещи. Этот текст – ответ, который мы обычно даём клиентам, только подробнее: с маршрутами заявки, требованиями и примером сообщения.

FIX – протокол, а не способ подключения

FIX (Financial Information eXchange) – протокол обмена сообщениями о заявках и сделках. Он описывает, как выглядит сообщение: какие поля в заявке, как приходит подтверждение, как передаётся информация об исполнении. Торговые системы по всему миру используют его как общий стандарт, поэтому многие платформы и готовые роботы «говорят» на FIX из коробки.

Чего протокол не описывает – это маршрута. Одно и то же FIX-сообщение может уйти на сервер брокера, а может сразу в торговое ядро биржи. От маршрута зависит всё остальное: задержка, оформление, требования к вашему ПО и цена.

Поэтому вопрос «есть ли FIX» стоит переформулировать: куда вы хотите отправлять заявки по FIX? Вариантов три.

1. FIX к серверу брокера

Ваша платформа подключается по FIX к серверу QUIK брокера. Терминал при этом не нужен: робот работает с сервером программно, без запущенного QUIK и привязки к рабочему месту.

Маршрут заявки: робот → сервер QUIK брокера → торговая система брокера → биржа.

Это не DMA. Заявка проходит через ту же инфраструктуру, что и заявки из терминала, и потолок по скорости задаёт она. Зато и требований меньше: отдельная сеть не нужна, сертифицировать своё ПО на бирже тоже не нужно.

У БКС этот вариант реализован двумя модулями к QUIK:

•     FIX Connector – базовый вариант. До 10 счетов, одна FIX-сессия. Не поддерживает алгоритмические и OMS-заявки, РПС и РЕПО, кроме безадресного с центральным контрагентом.

•     FIX Adapter – для тех, кому этого мало: добавляет алгоритмические заявки и OMS-заявки QUIK.

Кому подходит: у вас уже есть система, которая работает по FIX, нужно торговать с нескольких счетов по единым правилам, а скорость вторична. Главное здесь – совместимость: не переписывать то, что уже работает.

2. FIX Gate: прямой вход на срочный рынок

FIX Gate – шлюз Московской биржи на срочном рынке (торговая система SPECTRA), работает по FIX версии 4.4. Ваше ПО подключается к нему напрямую, минуя торговую систему брокера.

Маршрут заявки: робот → шлюз биржи → торговое ядро.

Это уже DMA, и вместе с ним приходят три обязательных элемента:

•     Свой логин на шлюзе. Его производительность заказывается в единицах: одна единица – 30 заявок в секунду.

•     Сертифицированное ПО. Транзакционные шлюзы принимают только программы, прошедшие сертификацию на бирже. Проходит её владелец ПО: если это ваша разработка – вы, если готовое решение – обычно вендор.

•     Сеть до биржи. Здесь у FIX Gate выбор шире, чем у остальных транзакционных шлюзов. Кроме колокации и выделенных каналов, биржа допускает подключение через интернет с шифрованием или VPN. Среди транзакционных шлюзов это единственный такой вариант, у TWIME и MFIX его нет. Подойдёт ли он вашей стратегии, зависит от её требований к задержке.

Важная деталь: FIX Gate – шлюз транзакционный. Он принимает заявки и возвращает ответы по ним, но котировки и стакан не отдаёт. Рыночные данные подключаются отдельно – через FAST или более быструю SIMBA.

3. MFIX: прямой вход на фондовый и валютный рынки

MFIX – FIX-шлюз фондового и валютного рынков, которые работают на торговой системе ASTS. Проще всего описать его через сравнение с FIX Gate.

Что общего: FIX 4.4, прямое подключение к ядру биржи, свой логин, сертификация ПО, котировки и стакан подключаются отдельно.

Чем отличается:

•     Через интернет не подключиться – только колокация или выделенный канал.

•     Это не один сервис, а набор: торговый MFIX Trade, его версия с гарантией порядка заявок FIFO MFIX Trade, Trade Capture со сделками и Drop Copy с копией всех заявок и сделок.

•     Для доступа нужны статус квалифицированного инвестора и торгово-клиринговый счёт. На срочном рынке этого не требуется.

Котировки к MFIX обычно подключают через FAST.

Drop Copy: копия потока заявок на обоих рынках

Drop Copy есть на обоих рынках. Это отдельная FIX-сессия, через которую приходят отчёты о заявках и сделках – не только ваших собственных, а в пределах заданного круга: по фирме, брокеру или набору счетов. Торговать через неё нельзя, она только для чтения.

На срочном рынке Drop Copy – отдельный сервис со своим FIX-логином, и он транслирует заявки и сделки, прошедшие через любой шлюз: FIX Gate, Plaza II и TWIME. То есть даже робот на бинарном TWIME может получать контрольную копию своего потока по FIX. На фондовом и валютном рынках Drop Copy входит в семейство MFIX.

Используют его для контроля – например, чтобы риск-менеджмент видел весь поток заявок независимо от торговых сессий – и чтобы восстановить данные после обрыва. Скорость у него не главное: на фондовом рынке задержка в обычных условиях до 100 миллисекунд.

А при чём тут «самые быстрые» шлюзы

Иногда FIX вспоминают и в разговоре о самых быстрых шлюзах биржи – TWIME и FIFO TWIME. Формально они относятся к тому же семейству стандартов: TWIME построен на FIX Simple Binary Encoding (бинарное кодирование сообщений) и сессионном протоколе FIXP. Но это другой протокол со своей спецификацией. FIX Gate и MFIX обмениваются текстовыми сообщениями FIX 4.4, TWIME – бинарными, и сессия устроена иначе. Робот, написанный под FIX Gate, на TWIME без доработки не заработает.

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

Как понять, какой FIX нужен вам

Три вопроса почти всегда дают ответ.

Можно ли перевести FIX-робота с брокера на биржу, не меняя код

Частично. FIX – общий стандарт, но каждый шлюз публикует свою спецификацию поверх него: какие сообщения и поля обязательны, как указывать инструмент и счёт, какие дополнительные поля используются. В спецификации FIX Gate отличия от стандартного протокола прямо отмечены, и в ней есть собственные поля, которых нет у FIX-подключения к серверу QUIK.

Поэтому при переходе:

•     остаётся FIX-движок робота – установка сессии, контроль нумерации сообщений, heartbeat – и вся торговая логика;

•     переписывается слой, который собирает и разбирает сообщения: его нужно привести к спецификации FIX Gate;

•     добавляется сертификация программы на бирже – без неё транзакционный логин не выдадут.

Как это выглядит на практике. Так устроена заявка New Order Single (тип сообщения D) для FIX Gate – поля взяты из спецификации биржи, значения условные, разделитель полей SOH для читаемости заменён на |:

8=FIX.4.4|9=…|35=D|49=<ваш логин>|56=<TargetCompID из спецификации>|34=215|

52=20261001-07:15:03.120|

11=ord-000215|1=A01|55=SiZ6|54=1|38=5|40=2|44=81250|59=0|

60=20261001-07:15:03.120000000|10=…|

Большая часть здесь – стандартный FIX 4.4: 11 – идентификатор заявки, 54 – направление, 38 – количество, 44 – цена. Но есть и детали, которые задаёт именно биржа:

•     40=2 – шлюз принимает только лимитные заявки;

•     1 (Account) – трёхсимвольный код клиента, формат задан биржей;

•     55 (Symbol) – короткий код инструмента в формате биржи, например SiZ6;

•     59 (TimeInForce) – значение 0 означает котировочную заявку, которая остаётся в стакане после частичного исполнения, а для пассивных заявок есть нестандартное значение z (Book-or-cancel);

•     собственные поля с номерами от 20000: 20008 Flags, 20021 MatchRef, 20035 NccRequest, 20036 DisplayVarianceQty для айсбергов.

Всё это и есть та часть, которая отличается от шлюза к шлюзу. Поэтому работу с конкретным шлюзом удобно держать в отдельном модуле: торговая логика формирует заявку в своих терминах, а модуль переводит её в поля нужного шлюза. Упрощённо:

from dataclasses import dataclass

SOH = "\x01"

@dataclass

class Order:

    order_id: str

    instrument: str   # код инструмента в терминах робота

    side: str         # "buy" / "sell"

    qty: int

    price: float

 

def fix_message(fields: list[tuple[int, str]], header: list[tuple[int, str]]) -> str:

    """Собирает FIX 4.4: считает BodyLength (9) и CheckSum (10)."""

    body = "".join(f"{tag}={val}{SOH}" for tag, val in header + fields)

    head = f"8=FIX.4.4{SOH}9={len(body.encode())}{SOH}"

    checksum = sum((head + body).encode()) % 256

    return f"{head}{body}10={checksum:03d}{SOH}"

 

class FixGateAdapter:

    """Всё, что специфично для FIX Gate, живёт здесь."""

    def init(self, sender: str, target: str, client_code: str):

        self.sender, self.target, self.client_code = sender, target, client_code

        self.seq = 0

 

    def new_order(self, o: Order, sending_time: str, transact_time: str) -> str:

        self.seq += 1

        header = [(35, "D"), (49, self.sender), (56, self.target),

                  (34, str(self.seq)), (52, sending_time)]

        fields = [(11, o.order_id), (1, self.client_code), (55, o.instrument),

                  (54, "1" if o.side == "buy" else "2"), (38, str(o.qty)),

                  (40, "2"),        # FIX Gate: только лимитные заявки

                  (44, f"{o.price:g}"), (59, "0"), (60, transact_time)]

        return fix_message(fields, header)

При переходе на другой шлюз меняется только класс адаптера и настройки сессии, а торговая логика, которая создаёт Order, остаётся прежней. Готовый FIX-движок в реальном роботе всё равно нужен: этот пример показывает разделение ответственности, а не заменяет библиотеку.

Объём доработки зависит от того, как написан робот. Если работа с конкретным шлюзом вынесена в отдельный модуль, переход сводится к новому модулю и сертификации. Если поля брокерского FIX разбросаны по всему коду, работы больше.

Что дальше

Если вы пока выбираете между API брокера, QUIK и прямым доступом, начните с разбора что такое DMA и когда он действительно нужен.

В следующей инженерной статье разберём три механизма, которые защищают от потери контроля над заявками и которые часто путают: Cancel-on-Disconnect, Drop Copy и Kill Switch.

Если хотите обсудить подключение своей системы, пишите на dma@bcs.ru.