Финансовый Информационный Обмен

Эта статья включает список общих ссылок , но в ней отсутствуют соответствующие встроенные цитаты . Пожалуйста, помогите улучшить эту статью, введя более точные цитаты. ( Март 2014 ) ( Узнайте, как и когда удалять это сообщение )

Протокол Financial Information eXchange ( FIX ) — это протокол электронной связи, инициированный в 1992 году для международного обмена информацией в реальном времени, связанной с операциями с ценными бумагами и рынками. С триллионами долларов, ежегодно торгуемыми только на NASDAQ , субъекты финансовых услуг используют прямой доступ к рынку (DMA) для увеличения скорости доступа к финансовым рынкам. Управление доставкой торговых приложений и поддержание низкой задержки все чаще требует понимания протокола FIX.

Спецификация протокола FIX была первоначально разработана в 1992 году Робертом «Бобом» Ламурё и Крисом Морстаттом для обеспечения электронной передачи данных о торговле акциями между Fidelity Investments и Salomon Brothers . FIX изначально касался информации между брокерами-дилерами и их институциональными клиентами. В то время эта информация передавалась устно по телефону. Fidelity поняла, что информация от их брокеров-дилеров может быть направлена ​​не тому трейдеру или просто утеряна, когда стороны кладут трубку. Она хотела заменить такие сообщения машиночитаемыми данными , которые затем можно было бы передавать трейдерам, анализировать, использовать и хранить. Например, брокеры-дилеры звонят с указанием интереса ( IOI ), чтобы купить или продать пакет акций. Инициатива FIX создала новые сообщения, такие как IOI .

По данным FIX Trading Community, FIX стал фактическим стандартом обмена сообщениями для предторговой и торговой коммуникации на мировых фондовых рынках и расширяется в постторговое пространство для поддержки сквозной обработки , а также продолжает расширяться на валютные рынки , рынки с фиксированным доходом и деривативы . ^[1]

FIX Trading Community — это некоммерческий отраслевой орган по стандартизации, миссия которого — решать деловые и нормативные вопросы, влияющие на торговлю несколькими активами на мировых финансовых рынках, посредством более широкого использования стандартов, включая язык обмена сообщениями FIX Protocol, обеспечивая операционную эффективность, повышенную прозрачность и снижение затрат и рисков для всех участников рынка. ^[2]

FIX широко используется как покупающей стороной (институтами), так и продающей стороной (брокерами/дилерами) финансовых рынков . Среди его пользователей — паевые инвестиционные фонды , инвестиционные банки , брокеры, фондовые биржи и ECN .

FIX стал стандартным электронным протоколом для предторговой коммуникации и исполнения сделок. Хотя он в основном используется для сделок с акциями в зоне фронт-офиса , также возможны сделки с деривативами облигаций и валютные сделки. Можно сказать, что в то время как SWIFT является стандартом для обмена сообщениями бэк-офиса , FIX является стандартом для обмена сообщениями фронт-офиса. Однако сегодня членство в FIX Protocol Ltd. расширяет FIX на распределение блоковых сделок и другие фазы торгового процесса на каждом рынке, практически для каждого класса активов.

Первоначально стандарт FIX был монолитным, включая семантику прикладного уровня, кодирование сообщений и уровень сеанса в одной технической спецификации. Он оставался монолитным вплоть до версии FIX 4.2. ^[3] После этого кодировки сообщений и спецификации уровня сеанса начали разделяться на отдельные документы, и в конечном итоге FIX превратился в семейство связанных технических стандартов. ^[4]

Кодирование сообщений, называемое уровнем представления в модели взаимодействия открытых систем (модель OSI), отвечает за формат передачи сообщений.

Исходное кодирование сообщений FIX известно как кодирование tagvalue. Каждое поле состоит из уникального числового тега и значения. Тег семантически идентифицирует поле. Поэтому сообщения являются самоописывающими. Кодирование tagvalue основано на символах с использованием кодов ASCII .

Сообщение состоит из заголовка, тела и трейлера. Поля сообщения разделяются символом начала заголовка (SOH) ( ASCII 0x01).

До версии 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).

Содержимое тела сообщения определяется типом сообщения (35 MsgType) в заголовке.

Трейлер содержит последнее поле сообщения, 10 ( Checksum), всегда выраженное трехзначным числом (например, 10=002).

Пример сообщения FIX, отчет о выполнении ( 35=8), с символом вертикальной черты ( |), представляющим символ SOH:

8=FIX.4.2 | 9=178 | 35=8 | 49=PHLX | 56=PERS | 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 EQUITY TESTING | 59=0 | 47=C | 32=0 | 31=0 | 151=15 | 14=0 | 6=0 | 10=128 |

Сообщения FIX формируются из нескольких полей; каждое поле имеет пару тег-значение, которая отделена от следующего поля разделителем SOH (0x01). Тег представляет собой целое число, которое указывает значение поля. Значение представляет собой массив байтов, которые содержат определенное значение для конкретного тега (например, тег 48 — это SecurityID, строка, которая идентифицирует безопасность; тег 22 — это IDSource, целое число, которое указывает используемый класс идентификатора). Значения могут быть представлены в виде обычного текста или закодированы как чисто двоичные (в этом случае значению предшествует поле длины). Протокол FIX определяет значения для большинства тегов, но оставляет диапазон тегов зарезервированным для частного использования между согласившимися сторонами.

Протокол FIX также определяет наборы полей, которые составляют конкретное сообщение; в пределах набора полей некоторые будут обязательными, а другие — необязательными. Порядок полей в сообщении, как правило, неважен, однако повторяющимся группам предшествует счетчик, а зашифрованным полям — их длина. Сообщение разбивается на три отдельных раздела: заголовок, тело и хвост. Поля должны оставаться в правильном разделе, и внутри каждого раздела положение может быть важным, поскольку поля могут выступать в качестве разделителей, которые не позволяют одному сообщению переходить в другое. Последнее поле в любом сообщении FIX — это тег 10 ( контрольная сумма ).

Существует две основные группы сообщений — административные и прикладные. Административные сообщения обрабатывают основы сеанса FIX. Они позволяют запускать и завершать сеанс, а также восстанавливать пропущенные сообщения. Сообщения прикладных сообщений обрабатывают отправку и получение информации, связанной с торговлей, например, запрос заказа или информацию о текущем состоянии и последующем выполнении этого заказа.

Длина тела — это количество символов, начиная с тега 35 (включительно) и до тега 10 (исключая), включая конечные разделители SOH.
Пример ниже (отображается с разделителями SOH как '|') имеет длину тела 65:

8=ИСПРАВЛЕНИЕ.4.2|9=65|35=A|49=СЕРВЕР|56=КЛИЕНТ|34=177|52=20090107-18:15:16|98=0|108=30|10=062| ^ 5 + 10 + 10 + 7 + 21 + 5 + 7 ^ = 65

Контрольная сумма сообщения FIX всегда является последним полем в сообщении с тегом 10и значением из 3 символов. ^[5] Она вычисляется путем суммирования значения ASCII всех символов в сообщении (за исключением самого поля контрольной суммы), а затем по модулю 256. ^[6] Например, в сообщении выше суммирование всех значений ASCII (включая символы SOH со значением ASCII 1) дает 4158. Выполнение операции по модулю дает значение 62. Поскольку контрольная сумма состоит из трех символов, это дает 10=062.

FIXML ^[7] — это схема XML для сообщений FIX. Семантически она эквивалентна сообщениям, закодированным в тег-значении, но использует технологию парсера XML. FIXML обычно используется для бэк-офиса и клиринговых приложений, а не для торговли.

Simple Binary Encoding ^[8] определяет формат проводов, использующий примитивные типы данных, которые являются собственными для вычислительных систем. Кодирование и декодирование сообщений, таким образом, имеет гораздо меньшую задержку, чем протоколы на основе символов, поскольку не требуется трансляция для помещения данных в формат, который могут использовать компьютеры. Помимо преимуществ в задержке, производительность более детерминирована, поскольку сообщения SBE ограничены шаблонами, а элементы данных фиксированной длины являются предпочтительными. Другим следствием является то, что поля, как правило, находятся в фиксированном положении, поэтому фильтрам сообщений и маршрутизаторам не нужно взламывать все сообщение для доступа к ключевым полям.

SBE был разработан рабочей группой FIX High Performance Working Group для поддержки высокопроизводительной торговли. Кодирование Tagvalue было признано больше неподходящим, поскольку оно основано на символах, а не на двоичных данных, а его поля и сообщения переменной длины приводят к недетерминированной производительности.

В отличие от tagvalue и FIXML, сообщение SBE не является самоописывающим. По сети передаются только данные с минимальным заголовком для идентификации шаблона, который управляет сообщением. Метаданные, описывающие макет сообщения, передаются внеполосно между одноранговыми узлами.

FIX Trading Community публикует схему XML для схем сообщений SBE. Схема сообщения может содержать любое количество шаблонов сообщений. Шаблон описывает поля, составляющие сообщение. Кроме того, схема предоставляет список простых и составных типов данных, которые могут повторно использоваться любым количеством полей.

С практической точки зрения, предполагая реализацию C/C++ и корректируя порядок байтов: большинство несоставных типов в сообщении напрямую отображаются на тот же тип в языке. Например, 32-битное целое отображается на uint32_t, фиксированные строки отображаются на const char *, плавающие точки отображаются на floatи т. д. Можно сгенерировать C/C++ structиз определения схемы. Затем, имея указатель на буфер сообщения, доступ к несоставным полям сообщения сводится к приведению его типа к указателю на структуру и непосредственному доступу к членам структуры.

/* Сгенерированная структура из схемы */ struct Message { ... uint32_t qty ; ... const char * symbol ; ... };          void acquire_message ( void * coming_message ) { const struct Message * msg = ( const struct Message * ) coming_message ; printf ( "Продано %u из %s \n " , msg -> qty , msg -> symbol ); ... }                

Сообщество FIX Trading также разработало стандартные соответствия между FIX и другими протоколами сообщений, включая:

• Буферы протокола Google
• АСН.1
• JSON

Сеансовый уровень отвечает за обмен сообщениями, включая механизмы восстановления контрольных точек.

Исходный протокол сеанса FIX не имел собственного имени, поскольку был частью монолитной спецификации, охватывающей семантику прикладного уровня и кодирование сообщений. Однако, начиная с версии FIX 5.0, сеансовый уровень был выделен в независимую спецификацию с введением FIXT. ^[9] FIXT был в значительной степени таким же, как исходный неназванный сеансовый уровень в версии 4.x, но он предлагал одно существенное новшество — он предоставлял механизм для смешивания версий прикладного уровня FIX поверх общей версии сеанса. Текущая версия FIXT — 1.1.

Теоретически FIXT не зависит от транспорта. Однако обычно он используется поверх протокола управления передачей (TCP).

FIXT — это протокол «точка-точка». Он гарантирует доставку сообщений в обоих направлениях. Сообщения, отправляемые в каждом направлении, содержат порядковый номер сообщения в заголовке сообщения. В случае сбоя связи одноранговый узел может запросить повторную передачу пропущенных сообщений. Доставка сообщений поддерживается даже в случае отключения и последующего восстановления сеанса.

Для реализации установления сеанса и гарантированной доставки FIXT и классический FIX 4.x определяют следующие типы сообщений сеанса:

• Сердцебиение
• Запрос на тест
• Повторная отправка запроса
• Отклонять
• ПоследовательностьСброс
• Выйти
• Вход в систему
• XMLnonFIX

FIXP ^[10] был разработан рабочей группой FIX High Performance Working Group ^[11] для удовлетворения потребностей высокопроизводительной торговли. Основная потребность заключается в кодировании и декодировании сообщений с низкой задержкой и контроле гарантий доставки сообщений.

Для обеспечения низкой задержки поддерживаются двоичные кодировки сообщений как для сеансового уровня, так и для сообщений приложений. Фактический формат проводов абстрагирован в спецификации FIXP, поэтому пользователи могут выбирать кодировку FIX по своему выбору, если одноранговые узлы согласятся на используемый протокол. Ранняя разработка использовала простое двоичное кодирование.

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

При установлении сеанса «точка-точка» участники согласовывают гарантии доставки из следующих вариантов:

• Восстанавливаемый: доставка сообщений exact-one. Если обнаружены пробелы, то пропущенные сообщения могут быть восстановлены путем повторной передачи.
• Идемпотент: доставка at-most-once. Если обнаружены пробелы, отправитель уведомляется, но восстановление находится под контролем приложения, если оно вообще выполняется.
• Unsequenced: не дает никаких гарантий доставки. Этот выбор подходит, если гарантии не нужны или восстановление осуществляется на уровне приложения или через другой канал связи.
• Примечание: сообщения приложений не должны отправляться в одном направлении сеанса.

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

Ниже представлена ​​схема того, как ИСПРАВИТЬ обмен сообщениями между Покупателем/Клиентом и Продавцом/Поставщиком. ^[12]

Последняя версия протокола FIX реализует «транспортную независимость», позволяя передавать несколько версий сообщений приложений через одну версию транспортно-независимого сеанса FIX (FIXT.1.1 и выше).

Транспортная независимость также открывает путь к использованию транспортных протоколов, таких как очереди сообщений и веб-сервисы, вместо традиционного FIX через TCP.

FIX теперь поддерживает алгоритмическую торговлю с помощью языка определения алгоритмической торговли FIX FIXatdl .

В 2005 году FIX Trading Community выпустило протокол FAST , который расшифровывается как FIX Adapted for Streaming. FAST — это бинарный протокол, который в основном используется для отправки многоадресных рыночных данных через UDP-соединения.

Кроме того, в 2020 году сообщество FIX Trading Community выпустило новую двоичную кодировку FIX, основанную на простом двоичном кодировании (SBE), призванную дополнить существующую кодировку FAST. ^[13]

• FIXatdl
• SWIFT:Типы сообщений
• Список протоколов электронной торговли

• FIX Protocol Ltd. - этот официальный сайт сообщества FIX Trading содержит стандарты FIX
• FIXimate FIX Словарь FIX Устаревшие версии FIX Последние версии
• FIXwiki — Wiki, посвященный FIX. Инструмент для справочника спецификаций, как FIXimate, но поскольку это вики, он также позволяет оставлять пользовательские заметки и отзывы.
• B2BITS FIX Antenna .NET Core — реализация движка .NET FIX с открытым исходным кодом.
• Esprow FIX Tools — онлайн-браузер словарей FIX для всех версий FIX, включая анализатор сообщений FIX
• Полный словарь протокола FIX на Onixs - быстрый и простой в использовании современный словарь протокола FIX (версии 4.0, 4.1, 4.2, 4.3, 4.4, 5.0, 5.0.SP1, 5.0.SP2, FIXT1.1).
• FixSpec FIX 4.0 Архивировано 07.11.2015 на Wayback Machine FIX 4.1 Архивировано 07.11.2015 на Wayback Machine FIX 4.2 Архивировано 07.11.2015 на Wayback Machine FIX 4.3 Архивировано 07.11.2015 на Wayback Machine FIX 4.4 Архивировано 07.11.2015 на Wayback Machine FIX 5.0 Архивировано 07.11.2015 на Wayback Machine FIX 5.0 SP1 Архивировано 01.07.2019 на Wayback Machine FIX 5.0 SP2 Архивировано 04.03.2016 на Wayback Machine FIXT Архивировано 01.07.2019 на Wayback Machine
• FIXSIM - анализатор сообщений FIX, примеры сообщений, поддержка тестирования.
• Онлайн-ресурс, включающий заметки по использованию Rapid Addition - Онлайн-ресурс FIX, включающий подробные заметки по использованию (версии 4.0, 4.2, 5.0 SP2).
• FIXGlobal — бесплатный глобальный торговый журнал и официальный журнал протокола FIX.
• Что такое протокол FIX? - Нетехнический обзор протокола FIX.
• Простой декодер FIX, написанный на скрипте оболочки с использованием sed, который быстро работает в Unix/Linux, нуждается в обновлении до последней версии FIX.
• Fix Parser — онлайн-анализатор сообщений FIX