Обмен финансовой информацией - Financial Information eXchange

«FIXT» перенаправляется сюда. Информацию о медиакомпании и звукозаписывающей компании см. В FiXT .

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

История

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

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

Торговое сообщество FIX

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

Пользователи

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

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

Технические характеристики

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

Кодировки сообщений

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

Кодировка значения тега (классический FIX)

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

FIX tagvalue формат сообщения

Поля сообщения разделены символом 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 Content

Пример сообщения FIX: отчет о выполнении (символ вертикальной черты используется для представления символа 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 |

В приведенном выше сообщении 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 в конце тега = значение принадлежит тегу.

Трейлер: Контрольная сумма

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

FIXML

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

Простое двоичное кодирование (SBE)

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

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

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

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

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

/* Generated struct from schema */
struct Message {
  ...
  uint32_t qty;
  ...
  const char *symbol;
  ...
};

void consume_message(void *incoming_message) {
  const struct Message *msg = (const struct Message*) incoming_message;
  printf("Traded %u of %s\n", msg->qty, msg->symbol);
  ...
}

Другие кодировки FIX

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

Протоколы сеанса

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

FIX Транспорт (FIXT)

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

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

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

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

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

Уровень сеанса FIX Performance (FIXP)

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

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

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

Когда устанавливается двухточечный сеанс, одноранговые узлы согласовывают гарантии доставки из следующих вариантов:

  • Восстанавливаемый: доставка сообщения ровно один раз. При обнаружении пропусков пропущенные сообщения могут быть восстановлены путем повторной передачи.
  • Идемпотент: доставка не более одного раза. Если обнаруживаются пробелы, отправитель уведомляется, но восстановление находится под контролем приложения, если оно вообще выполняется.
  • Без последовательности: не дает никаких гарантий доставки. Этот выбор подходит, если гарантии не нужны или если восстановление обеспечивается на уровне приложения или через другой канал связи.
  • Нет: сообщения приложений не должны отправляться в одном направлении сеанса.

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

Схематическое изображение системы FIX

Ниже приведена диаграмма того, как выглядит обмен сообщениями FIX между покупателем / покупателем и продавцом / поставщиком.

Схема подключения системы обмена финансовой информацией Diagram.svg

Последние разработки в протоколе FIX

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

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

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

FIX Protocol Limited выпустила протокол FAST, который расшифровывается как FIX Adapted for Streaming. FAST - это бинарный протокол, который в основном используется для отправки рыночных данных Multicast через UDP-соединения.

Инструменты для тестирования

Многие компании предлагают продукты и услуги для тестирования FIX:

  • Sensiple PhiFIX
  • Lefinsys Testamatiq
  • B2Bits ФАКТЫ
  • CameronTec VeriFIX
  • Esprow ETP Studio для FIX
  • Инструменты тестирования Exactpro
  • FIX Flyer Зажигание
  • GDS Fizzer - Фреймворк FIX Fuzzing
  • Wipro FIX Examen
  • FixSpec Central

Смотрите также

Примечания

внешние ссылки