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

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

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

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

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

Идея была настолько плодотворной, что на этот протокол перешли за два года большинство брокерских контор в США. Еще бы: экономились гигантские средства, уменьшалось количество ошибок, а значит и сокращался риск убытков ими вызванных. С ростом рынка 90-ых, а значит и количеством ордеров ни о какой передаче ордеров по телефону уже и речи идти не могло.

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

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

С чего начать

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

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

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

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

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

001

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

002

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

003

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

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

004

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

005

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

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

Общие мысли

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

image13_geneos_-_fix-analyser2_plug-in

Иллюстрация взята с сайта: 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-протоколе — статья-продолжение ]

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s