Что такое FIX-протокол (FIX Protocol)?

FIX-протокол (FIX Protocol) используется участниками рынка для передачи ордеров и информации об их исполнении друг другу в электронном виде.

До появления FIX Protocol-а ордера передавались от инвестора к брокеру и от брокера на биржу по телефону, что приводило часто к ошибкам, разночтениям и неточностям. Ситуация напоминала испорченный телефон: например, работник брокера в разговоре с инвестором по телефону мог что-то не так понять или не расслышать или чисто по-человечески перепутать и предать неверный приказ своему сотруднику на биржу. Тот тоже мог что-то  не так понять или в спешке перепутать. В результате клиент получал не то, что хотел, а потом начиналась долгая история выяснения отношений между клиентом и брокером, на кого повесить убытки по неправильно исполненному ордеру.

Немного истории

С появлением достаточно мощных и дешёвых компьютеров и быстрых сетей связи работникам финансового рынка пришла в голову естественная идея передавать всю информацию в электронном виде. Все началось в 1993 году, когда работники инвестиционной компании Fidelity Investments и брокерской конторы Salomon Brothers изобрели примитивный текстовый протокол для передачи ордеров и отчетов об их исполнении.

С обеих сторон над протоколом работало по два человека — программист и бизнес-аналитик: со стороны Salomon Borthers — Chris Morstatt (техническая часть) и Jim Leman (бизнес-часть), со стороны Fidelity — Robert (Bob) Lamoureux (техническая часть) и Jacques Perold (бизнес-часть). Это имена достойны быть записаными золотыми буквами в историю электронной биржевой торговли. James Leman умер в возрасте 72 лет 6 сентября 2018 года.

Протокол использовался в начале только между Fidelity и Salomon Brothers. Биржи в те времена еще не все были электронными, поэтому на биржи ордера передавались по-прежнему — по телефону. По началу протокол тогда назывался SBX (Salomon Brothers Exchange), но потом Salomon и Fidelity, понимая важность сделанного ими изобретения, предложили Goldman Sachs и Putman присоединиться к разработке протокола. На первой же встрече кто-то заметил, что бренд «Salomon Brothers» в названии протокола не будет способствовать росту его популярности в финансовой среде, поэтому название протокола быстро поменяли на «Financial Information Protocol» или сокращенно «FIX».

Первый публично опубликованный релиз спецификации FIX, написанный Крисом и Робертом носил номер 2.7. В протоколе использовались только ASCII-символы, имелись сообщения уровня сессии и уровня приложения: поддерживалась рассылка IOI-сообщений и ответы на них, и лишь базовые операции с ордерам: выставление ордеров (New), модификация (Amend) и отмена (Cancel). Объем спецификации составлял 50 страниц. Имелось только 17 сообщений, 103 тега и поддерживалась только торговля акциями.

Идея была настолько плодотворной, что на этот протокол перешли за два года большинство брокерских контор в США. Еще бы: экономились гигантские средства, уменьшалось количество ошибок, а значит и сокращался риск убытков ими вызванных. В 1995 году аналитики обнаружили что 75% брокеров США используют FIX Protocol для торговли. С ростом рынка 90-ых (.com бум), а значит и количеством ордеров ни о какой передаче ордеров по телефону уже и речи идти не могло.

В настоящее время FIX Protocol это lingua franca финансовых технологий. В нескольких итерациях протокол расширяли, добавляя в него все больше функций, распространяя его не только на торговлю акциями, но и деривативами, облигациями и валютами. Для сравнения нынешняя спецификация FIX описывает 168 сообщений, 7868 тегов и покрывает все классы ценных бумаг.

В 1998 году разработка FIX-протокола и его спецификаций, а также разработка сопутствующих технологий, была передана в консорциум FIX Protocol Ltd. Позднее консорциум переименовали в FIX Trading Community. Членами организации сейчас являются более 270 ведущих финансовых организаций, 35% из них европейские, 29% — американские, 26% из Тихоокеанского региона включая Японию. FIX Trading Community проводит по всему миру конференции, а также выпускает ежеквартальный журнал FIX Global Trading.

[ См. также: Что такое FIX-engine ]

С чего начать

Знание FIX Protocol-а очень важно для всех, кто связан с разработкой торговых программ, с поддержкой client connectivity и market connectivity инфраструктурой. На собеседованиях о нём часто спрашивают, и знать элементарные основы этого протокола так же важно, как знать базовые алгоритмы и базовые структуры данных. Протокол довольно прост и его легко можно освоить, прочитав спецификацию, а начать знакомство можно хотя бы со статьи в Википедии.

Самые-самые основы для иллюстрации

Сообщения FIX-протокола состоят из символов ASCII-текста. Они представляют собой наборы тегов (tags) и их значений (values) (например, 35=D), разделенных специальным символбным кодом SOH — Start of Header (0x01). В Википедии прекрасно описано, как выглядит типичное сообщение FIX-протокола.

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

Представим, что «А» это клиент, а «B» это брокер.

Клиент «А» хочет открыть новый ордер у брокера. Для этого он посылает брокеру FIX-сообщение 35=D, которое называют NOS (New Order Single). Помимо тега 35=D в сообщении присутствуют многие другие, но для данной простой иллюстрации они сейчас несущественны.

На стороне клиента «А» ордер, пока он обрабатывается брокером, находится в состоянии (Pending New). Если брокер, скажем, задержится с ответом на час, весь этот час на стороне клиента ордер будет находиться в неподтвержденном состоянии. Наконец, брокер «B» подтверждает ордер у себя и отправляет FIX-ответ Acknowledgement клиенту — сообщение 35=8 (Execution report), тег 150=0 говорит, что это конкретное сообщение является подтверждением, а тег 39=0 сообщает, что на стороне брокера «B» ордер находится в состоянии New (Открыт и ждет исполнения) .

Клиент «A» после получения подтверждения приводит у себя запись об ордере в то же состояние — New («Открыт и ждет исполнения») . Ордер открыт и клиент «А» теперь ждет от брокера следующих сообщений о том, что ордер исполнен полностью (Fill) или частично (Partial Fill).

Представим, что клиент «А» передумал и решил отменить ордер. Он отменяет ордер в своей системе и теперь должен сообщить брокеру, чтобы он сделал то же самое. Для этого генерируется сообщение 35=F (Cancel).

Пока клиент «А» не получил подтверждения об отмене, ордер на его стороне находится в состоянии Pending Cancel. Брокер «B» получает это сообщение, обрабатывает его, отменяет ордер и отправляет клиенту «А» подтверждение об отмене: 35=8 (Execution Report), 150=4 (это сообщение является подтверждением об отмене), 39=4 (статус ордера на стороне брокера — «Отменен»).

Клиент «А» получает подтверждение и переводит ордер на своей стороне из состояния Pending Cancel в состояние Canceled.

Как вы, наверное, обратили внимание, в этом диалоге брокер все время посылал сообщения типа 35=8 (Execution Report). Это потому, что инициатором диалога являлся клиент, а брокер являлся отвечающей стороной.

Общие мысли

Если говорить сухим языком программирования, перед нами — пример работы классического конечного автомата. Каждое сообщение переводит ордер в строго определенный статус, из которого он может перейти только к определенным другим статусам.

Иллюстрация взята с сайта: https://resources.itrsgroup.com/docs/geneos/4.6.0/FixAnalyser2Netprobe/index.html

Все переходы из различных состояний в другие должны в конечном счете закончитася финальным состоянием (terminal state). Ордер-заявка должен быть либо:

• заполнен (Filled)
• заполнен частично (Partial Fill), а остальное отменено (Canceled)
• отменен клиентом (Canceled)
• отменен брокером насильно (Unsolicited Cancel)
• отвергнут (Rejected)
• заменен на другой (Replaced)

В теории после отправки 35=D вы должны получить либо Reject, либо Ack. Ордер не может быть вечно в состоянии Pending New. Последнее означает, что либо ваше сообщение потерялось где-то в каналах связи между вами и брокером, либо ответ брокера потерялся на пути от брокера к вам.

Правила разрешения коллизий

Протокол FIX помимо сообщений прикладного уровня (application level) определяет еще кучу правил о том, как должна устанавливаться и поддерживаться связь между клиентом и адресатом — это сообщения сессионного уровня (session level). Как должны клиент и адресат восстанавливать связь после ее обрыва. Например, клиентская программа рухнула и после рестарта заново установила связь, а на стороне брокера уже скопились сообщения-ответы для клиента и клиентская программа сначала должна сообщить, какие из этих сообщений она успела до падения обработать, а какие просит переслать (Resend request) еще раз.

Спецификация протокола также определяет правила разрешения коллизий сообщений. Например, клиент решил отправить поправку к объему заявки (Amend quantity), а брокер уже получил по ордеру клиента Fill с биржи, но еще не отправил клиенту. Или клиент отправляет отмену заявки брокеру (Cancel request), а уже брокер получил частичное исполнение (Partial Fill) этой заявки с биржи. Все это описано в приложениях к спецификации и клиентские библиотеки, реализующие протокол FIX, должны строго этой спецификации следовать, чтобы не привести к путанице и взаимонепониманию, кто кому сколько миллиардов долларов должен в результате неправильной интерпретации того или иного пункта спецификации.

[ См. также: Еще немного о FIX-протоколе — статья-продолжение ]