Обучение
Как оценить FIX API, прежде чем закладываться на интеграцию
Что проверить в FIX-сессии помимо версии: покрытие сообщений, поведение при переподключении, маппинг символов, drop-copy и вопросы, которые показывают, годится ли песочница хоть на что-то.
«Мы поддерживаем FIX 4.4 и 5.0» не говорит ни о чём. Это как сказать, что у машины есть колёса. То, что определяет, будет ли работать интеграция, — вещи гораздо менее гламурные: какие сообщения покрыты, что происходит, когда сессия падает, и ведёт ли себя песочница как продакшен.
Вот список, который ваша техническая команда должна проверить, прежде чем закладывать недели работы.
Чего версия вам не говорит
FIX — это протокол, а не реализация. Две площадки, заявляющие поддержку 4.4, могут различаться в:
- Какие типы сообщений они реализуют и какие игнорируют
- Какие теги обязательны в каждом сообщении
- Как они обрабатывают пользовательские поля
- Какие коды отказа они возвращают и что те означают
- Как они управляют нумерацией последовательности после обрыва связи
Ни одно из этих различий не видно в «FIX 4.4». Все они проявляются при сертификации — а это уже когда вы вложили время.
Документация по сообщениям должна быть доступна до подписания чего-либо. Если её дают только после договора, вы покупаете вслепую.
Покрытие сообщений: что спрашивать
Как минимум вам нужна ясность по четырём потокам:
Котирование. Стриминг цен или request/response? Подписка по инструменту или по списку? Какую глубину они отправляют и с какой частотой?
Ввод заявок. Какие типы поддерживаются — рыночная, лимитная, стоп, IOC, FOK? Заявки на изменение и отмену? Каково поведение, когда отклоняется изменение уже частично исполненной заявки?
Отчёты об исполнении. Отправляют ли они частичные исполнения? С какой гранулярностью? Как определяется связь между исходной заявкой и её исполнениями?
Drop-copy. Существует ли отдельная сессия, которая реплицирует вашу активность для сверки и compliance? Для фондов и фирм с обязательствами по отчётности это не опция.
Запросите вот это: полную спецификацию сообщений и тегов, включая коды отказа, до сертификации.
Поведение при переподключении — там, где всё ломается
Это та часть, что отличает интеграцию, которая выживает, от той, что будит вас под утро.
Конкретные вопросы:
Что происходит с заявками в полёте, когда падает сессия? Отменяются ли они автоматически, остаются ли живыми или зависит от настройки? Все три ответа допустимы; не знать, какой из них ваш, — нет.
Как обрабатывается sequence reset? Когда вы переподключаетесь, они ожидают, что вы продолжите нумерацию с того места, где остановились, что вы её сбросите, или согласовывают? Плохо обработанное расхождение последовательности может заблокировать всю сессию.
Есть ли восстановление потерянных сообщений? Если вы были отключены 30 секунд, можете ли вы запросить сообщения за этот интервал или они потеряны?
Каков таймаут heartbeat и что происходит при его превышении?
Если какой-то из этих ответов — «это мы посмотрим на сертификации», примите это как информацию: значит, это не задокументировано.
Маппинг символов: нудно и критично
Каждая площадка называет свои инструменты по-своему. Золото может быть XAUUSD, GOLD или XAU/USD — с различиями в размере контракта, количестве разрядов и часах сессии.
Маппинг всего вашего каталога должен быть согласован до сертификации, а не во время. Это самая частая причина задержек, и её полностью можно избежать.
Места, где обычно кусает:
- Инструменты с одинаковым названием и разным размером контракта
- Различия в количестве знаков после запятой, которые ломают расчёты пипсов
- Часы сессии, не совпадающие с теми, что ожидает ваша платформа
- Инструменты, которые есть в вашем каталоге и отсутствуют в их
Запросите вот это: согласованный маппинг всего вашего каталога, а не репрезентативной выборки.
Песочница: единственный стоящий тест
Песочница, которая не ведёт себя как продакшен, переносит обнаружение багов на вашу первую живую сессию. Это разница между тестовой средой и декорацией.
Паритет продакшена означает конкретно:
- Те же типы сообщений и те же коды отказа
- Реалистичное поведение при отказах, а не всеобщее принятие
- Репрезентативную задержку, а не мгновенную
- Те же часы сессии и те же правила инструментов
И критически важно: учётные данные до коммерческих обязательств. Площадка, которая просит вас подписать, чтобы дать доступ к песочнице, переворачивает правильный порядок.
Что вам стоит там протестировать:
- Полный цикл заявки: отправка, частичное исполнение, полное исполнение, отмена
- Принудительный обрыв связи в середине живой заявки
- Sequence reset
- Отказы: намеренно спровоцировать их и проверить, что коды соответствуют задокументированным
- Весь ваш каталог инструментов
- Поведение во время смоделированного окна высокой волатильности
Сколько должна занимать сертификация
При полном онбординге и согласованном маппинге — дни, а не недели.
Сроки почти никогда не растягивает технология — их растягивает ожидание. Поэтому с самого начала стоит иметь со своей стороны названного технического контакта с полномочиями принимать решения, а не цепочку согласований.
Если площадка называет вам срок сертификации в несколько недель, не объясняя, чем он обоснован, спросите, какая часть процесса медленная. Ответ многое скажет о том, какими будут операционные отношения потом.
Когда FIX — не ответ
Стоит это сказать, потому что есть склонность считать, что FIX всегда превосходит остальное:
Если вы ведёте брокеридж на MetaTrader с розничными или профессиональными клиентами на этой платформе, мост MT5 — правильный путь. FIX добавил бы сложности без выгоды.
Если ваш стек HTTP-first и современный — что типично для недавних проп-фирм и крипто-смежных площадок — REST плюс низколатентный WebSocket с документацией OpenAPI может подойти лучше, чем FIX, и интегрируется заметно быстрее.
FIX — это путь, когда ваш OMS или EMS нативно на нём говорит, когда вам нужен drop-copy для compliance или когда объём и задержка оправдывают вложения в интеграцию.
Многие фирмы начинают с моста и добавляют FIX по мере масштабирования. Это разумная последовательность, а не поражение.
Часто задаваемые вопросы
FIX 5.0 лучше, чем 4.4? Не для большинства случаев. 4.4 остаётся стандартом де-факто в институциональном FX и лучше поддержан по всей цепочке. 5.0 вводит структурные улучшения, но если ваш контрагент и ваш OMS без проблем говорят на 4.4, нет причин усложнять.
Нужен ли мне drop-copy? Если у вас есть обязательства по отчётности, администратор фонда, который должен сверять, или аудиторы, которые будут требовать прослеживаемость, — да. Если вы небольшой брокер без таких обязательств — это роскошь. Всё равно спросите, доступен ли он: то, что он существует, кое-что говорит о зрелости площадки.
Могу ли я использовать собственный FIX-движок? Обычно да, и это норма. Проверить нужно, что ваш движок и их реализация совпадают в важных деталях — прежде всего в обработке последовательности и пользовательских полях.
Что делать, если у песочницы нет паритета продакшена? Прямо потребовать его. Если ответ — что его нет, это важные данные о том, каким будет вывод в продакшен, и вам стоит заложить в бюджет время на стабилизацию, которое вы не предусмотрели.
Технические детали нашей реализации — в FIX API: сессии, покрытие сообщений, песочница с паритетом и поведение при переподключении, задокументированное до сертификации. Клиенты подключаются и исполняют сделки через нас; учётные данные к песочнице выдаются до каких-либо коммерческих обязательств.
Об общей рамке: как брокер выбирает ликвидность.
