Протокол Обмен финансовой информацией (FIX ) является электронным протоколом протокол связи, инициированный в 1992 году для международного обмена информацией в режиме реального времени, касающейся операций с ценными бумагами и рынков. Поскольку триллионы долларов ежегодно торгуются только на NASDAQ, компании, предоставляющие финансовые услуги, используют прямой доступ к рынкам (DMA), чтобы ускорить выход на финансовые рынки. Управление доставкой торговых приложений и поддержание низкого уровня задержки все чаще требует понимания протокола FIX.
Протокол FIX Первоначально спецификация была разработана в 1992 году Робертом «Бобом» Ламуре и Крисом Морстаттом для обеспечения электронной передачи данных о торговле акциями между Fidelity Investments и Salomon Brothers. Первоначально FIX обращался к информации между брокерами-дилерами и их институциональными клиентами. В то время эта информация передавалась устно по телефону. Компания Fidelity поняла, что информация от их брокеров-дилеров может быть перенаправлена не тому трейдеру или просто потеряна, когда стороны повесили телефоны. Он хотел, чтобы такие коммуникации были заменены машиночитаемыми данными, которые затем могли быть переданы трейдерам, проанализированы, обработаны и сохранены. Например, брокеры-дилеры звонят с указанием заинтересованности (IOI ), чтобы купить или продать пакет акций. Инициатива FIX создала новые сообщения, такие как IOI.
. Согласно сообществу трейдеров FIX, FIX стал де-факто стандартом обмена сообщениями для предпродажной и торговой коммуникации на мировых фондовых рынках, и становится все больше и больше. -Торговое пространство для поддержки сквозной обработки, а также продолжение расширения на рынки иностранной валюты, фиксированной прибыли и деривативов.
Торговое сообщество FIX - это некоммерческий отраслевой орган по стандартизации, миссия которого заключается в решении деловых и нормативных вопросов, влияющих на несколько активов. торговля на мировых финансовых рынках за счет более широкого использования стандартов, в том числе языка обмена сообщениями FIX Protocol, что обеспечивает операционную эффективность, повышенную прозрачность и снижает затраты и риски для всех участников рынка.
FIX широко используется как стороной покупки (учреждения), так и стороной продажи (брокеры / дилеры) финансовых рынков. Среди его пользователей паевые инвестиционные фонды, инвестиционные банки, брокеры, фондовые биржи и ECN. См. FIX Trading Community Organization для получения обширного списка основных пользователей FIX.
FIX стал стандартным электронным протоколом для предторговых коммуникаций и исполнения сделок. Хотя он в основном используется для операций с акциями в области фронт-офиса, также возможны операции с облигациями, деривативами и FX. Можно сказать, что в то время как SWIFT является стандартом для обмена сообщениями бэк-офиса, FIX является стандартом для обмена сообщениями фронт-офиса. Однако сегодня членство в FIX Protocol Ltd. расширяет FIX до блочной торговли распределения и других этапов торгового процесса на каждом рынке практически для каждого класса активов.
Первоначально стандарт FIX был монолитным, включая семантику прикладного уровня, кодирование сообщений и сеансовый уровень в единой технической спецификации. Он оставался монолитным до версии FIX 4.2. После этого кодировки сообщений и спецификации сеансового уровня стали разделяться на отдельные документы, и в конечном итоге FIX превратился в семейство связанных технических стандартов.
Кодирование сообщений, называемое уровнем представления в модели взаимодействия открытых систем (модель OSI), отвечает за проводной формат сообщений.
Исходная кодировка сообщения FIX известна как кодировка значения тега. Каждое поле состоит из уникального числового тега и значения. Тег семантически идентифицирует поле. Таким образом, сообщения описывают сами себя. Кодирование значения тега основано на символах с использованием кодов ASCII.
Поля сообщения разделены символом ASCII 01
До FIX.4.4 заголовок содержал три поля: 8 (BeginString
), 9 (BodyLength
) и 35 (MsgType
) теги.
Начиная с FIXT.1.1 / FIX.5.0, заголовок содержит пять обязательных полей и одно дополнительное поле: 8 (BeginString
), 9 (BodyLength
), 35 ( MsgType
), 49 (SenderCompID
), 56 (TargetCompID
) и 1128 (ApplVerID
- если присутствует, должен быть на 6-й позиции).
Содержание в теле сообщения определяется (тег 35, MsgType
) типом сообщения, определенным в заголовке.
Последнее поле сообщения - тег 10, FIX Message Checksum. Он всегда выражается трехзначным числом (например, 10 = 002
).
Заголовок + Тело + Трейлер: содержимое FIX
Пример сообщения FIX: Отчет о выполнении (символ вертикальной черты используется для представления символа SOH )
8 = FIX.4.2 | 9 = 176 | 35 = 8 | 49 = PHLX | 56 = ЧЕЛОВЕК | 52 = 20071123-05: 30: 00.000 | 11 = ATOMNOCCC9990900 | 20 = 3 | 150 = E | 39 = E | 55 = MSFT | 167 = CS | 54 = 1 | 38 = 15 | 40 = 2 | 44 = 15 | 58 = ТЕСТИРОВАНИЕ АКЦИЙ PHLX | 59 = 0 | 47 = C | 32 = 0 | 31 = 0 | 151 = 15 | 14 = 0 | 6 = 0 | 10 = 128 |
В приведенном выше сообщении FIXMessage длина 9 является правильной, а контрольная сумма 10 была проверена с использованием источника, доступного в QuickFIX, реализации FIX с открытым исходным кодом.
FIX-сообщения формируются из ряда полей; каждое поле представляет собой пару значений тега, которая отделена от следующего поля разделителем SOH (0x01). Тег представляет собой целое число, указывающее значение поля. Значение представляет собой массив байтов, которые содержат конкретное значение для конкретного тега (например, тег 48 - это securityID, строка, которая идентифицирует безопасность; тег 22 - это IDSource, целое число, указывающее используемый класс идентификатора). Значения могут быть в виде простого текста или закодированы как чисто двоичные (в этом случае значению предшествует поле длины). Протокол FIX определяет значения большинства тегов, но оставляет диапазон тегов, зарезервированных для частного использования между сторонами, согласившимися.
Протокол FIX также определяет наборы полей, которые составляют конкретное сообщение; в наборе полей одни будут обязательными, а другие - необязательными. Порядок полей в сообщении обычно не важен, однако повторяющимся группам предшествует счетчик, а зашифрованным полям - их длина. Сообщение разбито на три отдельных раздела: голова, тело и хвост. Поля должны оставаться в пределах правильного раздела, и внутри каждого раздела положение может быть важным, поскольку поля могут действовать как разделители, которые не позволяют одному сообщению переходить в следующее. Последнее поле в любом сообщении FIX - это тег 10 (контрольная сумма ).
Есть две основные группы сообщений - администраторские и прикладные. Сообщения администратора обрабатывают основы сеанса FIX. Они позволяют запускать и завершать сеанс, а также восстанавливать пропущенные сообщения. Сообщения приложения связаны с отправкой и получением связанной с торговлей информации, такой как запрос ордера или информации о текущем состоянии и последующего исполнения этого ордера.
Длина тела - это количество символов, начиная с тега 35 (включительно) до тега 10 (исключено). Разделители SOH учитываются по длине тела.. Например: (SOH был заменен на '|').
8 = FIX.4.2 | 9 = 65 | 35 = A | 49 = SERVER | 56 = CLIENT | 34 = 177 | 52 = 20090107-18: 15: 16 | 98 = 0 | 108 = 30 | 10 = 062 | 0 + 0 + 5 + 10 + 10 + 7 + 21 + 5 + 7 + 0 = 65
Имеет длину тела 65.. Разделитель SOH в конце Tag = Value принадлежит Тег.
Контрольная сумма сообщения FIX всегда является последним полем сообщения. Он состоит из трех символов и имеет тег 10. Он задается путем суммирования значений ASCII всех символов в сообщении, кроме символов самого поля контрольной суммы, и выполнения по модулю 256 по полученному суммированию. Например, в сообщении выше суммирование всех значений ASCII (включая символ SOH, который имеет значение 1 в таблице ASCII) приводит к 4158. Выполнение операции по модулю дает значение 62. Поскольку контрольная сумма состоит из три символа, используется 062.
FIXML - это схема XML для сообщений FIX. Он семантически эквивалентен сообщениям, закодированным с помощью тегов, но использует технологию синтаксического анализа XML. FIXML обычно используется для бэк-офиса и клиринговых приложений, а не для торговли.
Простое двоичное кодирование определяет формат передачи данных с использованием примитивных типов данных, которые присущи вычислительным системам. Таким образом, кодирование и декодирование сообщений имеют гораздо меньшую задержку, чем символьные протоколы, поскольку перевод данных в формат, который могут использовать компьютеры, не требуется. Помимо преимуществ задержки, производительность более детерминирована, поскольку сообщения SBE ограничиваются шаблонами, а элементы данных фиксированной длины предпочтительны. Другим следствием является то, что поля обычно находятся в фиксированной позиции, поэтому фильтрам сообщений и маршрутизаторам не нужно взламывать все сообщение для доступа к ключевым полям.
SBE был разработан FIX High Performance Working Group для поддержки высокопроизводительной торговли. Кодирование значения тега больше не считалось пригодным для использования, поскольку оно основано на символах, а не в двоичном формате, а его поля и сообщения переменной длины приводят к недетерминированной производительности.
В отличие от значения тега и FIXML, сообщение SBE не является самоописывающим. По сети отправляются только данные с минимальным заголовком для идентификации шаблона, управляющего сообщением. Обмен метаданными, описывающими структуру сообщения, между одноранговыми узлами осуществляется вне канала.
FIX Trading Community публикует схему XML для схем сообщений SBE. Схема сообщения может содержать любое количество шаблонов сообщений. Шаблон описывает поля, составляющие сообщение. Кроме того, схема предоставляет список простых и составных типов данных, которые можно повторно использовать в любом количестве полей.
Торговое сообщество FIX также разработало стандартные сопоставления между FIX и другими протоколами сообщений, включая:
Уровень сеанса отвечает за обмен сообщениями, включая механизмы восстановления контрольных точек.
Исходный протокол сеанса FIX не имел собственного имени, так как он был частью монолитной спецификации, охватывающей семантику прикладного уровня и кодирование сообщений. Однако, начиная с версии FIX 5.0, уровень сеанса был выделен как независимая спецификация с введением FIXT. FIXT был в значительной степени таким же, как исходный безымянный уровень сеанса в версии 4.x, но предлагал одно существенное нововведение - он предоставлял механизм смешивания версий уровня приложения FIX с общей версией сеанса. Текущая версия FIXT - 1.1.
Теоретически FIXT не зависит от транспорта. Однако обычно он используется поверх протокола управления передачей (TCP).
FIXT - это протокол точка-точка. Это гарантирует доставку сообщений в обоих направлениях. Сообщения, отправляемые в каждом направлении, имеют порядковый номер сообщения в заголовке сообщения. При сбое связи одноранговый узел может запросить повторную передачу пропущенных сообщений. Доставка сообщений поддерживается даже в случае отключения и последующего восстановления сеанса.
Чтобы реализовать установление сеанса и гарантированную доставку, FIXT и классический FIX 4.x определяют следующие типы сообщений сеанса:
Разработан FIXP от FIX High Performance Working Group для удовлетворения потребностей высокопроизводительной торговли. Основная потребность заключается в кодировании и декодировании сообщений с малой задержкой, а также в контроле над гарантиями доставки сообщений.
Чтобы обеспечить низкую задержку, двоичное кодирование сообщений поддерживается как для сеансового уровня, так и для сообщений приложений. Фактический формат проводов абстрагируется в спецификации FIXP, поэтому пользователи могут выбрать кодировку FIX по своему выбору, если одноранговые узлы согласны с протоколом для использования. Ранняя разработка использовала простое двоичное кодирование.
FIXP охватывает как двухточечные, так и многоадресные варианты использования с общими примитивами.
Когда устанавливается двухточечный сеанс, одноранговые узлы согласовывают гарантии доставки из следующих вариантов:
Гарантии доставки может быть асимметричным. Например, трейдер может вводить ордера через идемпотентный поток, в то время как исполнения возвращаются через восстанавливаемый поток. На быстро движущихся рынках задержка, связанная с ретрансляцией, часто нежелательна, что приводит к упущенным возможностям или плохим сделкам.
Ниже представлена диаграмма того, как выглядит обмен сообщениями FIX между покупателем / покупателем и продавцом / поставщиком.
последняя версия протокола FIX реализует «транспортную независимость», разрешая перенос нескольких версий сообщений приложений через одну версию транспортного независимого сеанса FIX (FIXT.1.1 и выше).
Транспортная независимость также открывает путь для транспортных протоколов, таких как очереди сообщений и веб-службы, которые будут использоваться вместо традиционного FIX over TCP.
FIX теперь поддерживает алгоритмическую торговлю с использованием языка определения алгоритмической торговли FIX FIXatdl.
FIX Protocol Limited выпустила протокол FAST, что означает FIX Adapted для потоковой передачи. FAST - это бинарный протокол, который в основном используется для отправки Multicast рыночных данных через UDP-соединения.
Многие компании предлагают продукты и услуги для тестирования FIX: