В БКС есть направление прямого доступа к бирже: мы подключаем клиентов к шлюзам Московской биржи, помогаем с роботами и инфраструктурой. Часто разговор начинается с вопроса про FIX (Financial Information eXchange) – и почти всегда за ним стоят разные вещи. Этот текст – ответ, который мы обычно даём клиентам, только подробнее: с маршрутами заявки, требованиями и примером сообщения.
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 |
|
Фондовый или валютный |
MFIX |
Нужна минимальная задержка? |
Да |
Не FIX, а TWIME или FIFO TWIME |
Можно ли перевести 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.
maxood
Для меня, как разработчика, DMA (Direct Memory Access) - передача данных между устройством, например сетевой картой, и оперативной памятью без копирования силами процессора. Здесь важно разделять два DMA: Direct Market Access - доступ к бирже, не обязательно без брокера. И организацию доступа к рынку, эффективность обмена данными внутри компьютера. Они могут работать вместе, но итоговые задержки зависят от всей системы, а более быстрая доставка заявки ещё не гарантирует её исполнения раньше остальных.
BCS_DMA Автор
Спасибо за ваш комментарий, в целом, справедливо.
Про название: в статье DMA - это Direct Market Access, путь заявки до биржи. Direct Memory Access - уровень ниже, внутри сервера, и его клиент настраивает уже сам, если борется за микросекунды.
Про брокера: да, для клиента DMA без брокера не бывает. Логин на шлюзе биржи регистрирует брокер, заявки идут под его кодом участника торгов и в рамках лимитов по счету, только проверяет их уже биржа. «Напрямую» в статье значит другое: заявка не проходит через торговую систему брокера, а сразу попадает на шлюз биржи. Поэтому и формулировка - «минуя торговую систему брокера», а не брокера.
Про задержки согласны полностью. Быстрая доставка дает только более раннее место в очереди на своей цене, а исполнится ли заявка - решает рынок. И считать задержку надо по всей цепочке: маркет-дата, обработка в программе, сеть, шлюз. Поэтому в статье первым вопросом при выборе маршрута стоит, важна ли задержка вообще: если выигрыш в микросекундах не превращается в деньги, FIX к серверу брокера проще и дешевле.