FIXatdl - FIXatdl

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

Задний план

До середины девяностых годов практически вся торговля ценными бумагами осуществлялась по телефону, но с появлением FIX торговля постепенно перешла на электронные средства. Протокол FIX используется для связи между системами управления заказами на стороне продавца и покупателя (OMS) для обмена приказами и информацией об исполнении без вмешательства человека с использованием стандартизованных сообщений и рабочих процессов, определенных протоколом. Первоначально фирмы, работающие на стороне продавца, предоставляли доступ к своим «торговым столам» только через FIX, что означало, что как только ордер поступал к брокеру на стороне продавца, он обрабатывался трейдером-человеком, по крайней мере, в начале его жизненного цикла. Впоследствии фирмы-продавцы начали предлагать прямой доступ через FIX к биржам / рынкам, членами которых они были; это известно как прямой доступ к рынку (DMA). В то время у многих фирм на стороне продавца были свои собственные запатентованные системы для автоматической торговли на рынке с использованием алгоритмических торговых стратегий, и со временем они начали понимать, что предоставление доступа к этим торговым стратегиям покупателям было способом привлечь бизнес и увеличить доход.

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

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

История

Для решения этих проблем FIX Protocol Limited создала Рабочую группу по алгоритмической торговле в третьем квартале 2004 года. Первоначальной задачей группы было решить первую из этих проблем, что было сделано путем определения новой группы полей, StrategyParametersGrp, состоящей из Теги FIX с 957 по 960 - эти теги были официально представлены с выпуском FIX 5.0 в 4 квартале 2006 года. Благодаря разрешению фирмам-продавцам включать свои собственные поля в повторяющуюся структуру пар "имя-значение" от поставщиков OMS не требовалось определять конкретные структуры сообщений FIX для каждого пункта назначения для продажи.

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

Идея использования XML-структуры для описания представления пользовательских интерфейсов алгоритмов и их сопутствующих параметров была впервые предложена в рамках рабочей группы Дэниелом Клейденом, а затем JP Morgan Chase в сообщении на форуме 2005 года. Члены рабочей группы разработали эту идею в 2006 году, а в январе 2007 года пригласили представителей отрасли на семинар для рассмотрения их идей. В конечном итоге была разработана спецификация, и ее бета-тестирование началось в июле 2007 года. Эта спецификация стала FIXatdl 1.0, которая была одобрена Глобальным техническим комитетом FPL (GTC) 28 марта 2008 года.

Несмотря на некоторый первоначальный энтузиазм, в целом версия 1.0 не получила должного отклика на рынке. Некоторые поставщики увидели возможность предоставлять услуги в соответствии со стандартом, такие как ULLINK (теперь часть Itiviti) с публикацией своих алгоритмов и управлением ими, а также инструмент UL AMS, но в то время как основные поставщики OMS были раздражены накладными расходами на внедрение новых брокерских алгоритмов, у них было выросли, чтобы получать прибыль, которую они могли получать как от своих клиентов, так и от брокеров, стремящихся внедрить свои алгоритмы на стол покупателя.

Хотя версия 1.0 была большим шагом вперед, у нее были некоторые существенные ограничения. В частности, определение передаваемых данных и их представление в пользовательском интерфейсе были тесно связаны друг с другом, что ограничивало гибкость брокеров на стороне продавца при определении своих алгоритмов. Спецификация 1.0 также предоставляла недостаточный контроль с точки зрения макетов пользовательского интерфейса. Рабочая группа намеревалась устранить эти ограничения в том, что должно было стать версией 1.1 спецификации. Первым важным изменением было разделение определения содержания данных из представления, определение того, что называется отдельным «Контрактом данных», состоящим из параметров алгоритма, их типов данных и вспомогательной информации, такой как минимальные и максимальные значения. Отдельный раздел XML-документа затем касается структуры пользовательского интерфейса, того, какие элементы управления использовать для каждого параметра и где их разместить на экране. Предоставляется схема XSD , чтобы файлы FIXatdl были действительными и правильно сформированными.

FIXatdl версии 1.1 был предварительно одобрен GTC 9 февраля 2010 г., когда он вошел в период общественного обсуждения, а затем окончательно утвержден 3 марта 2010 г. Спецификация была официально представлена ​​рынку на конференции FPL по Европе, Ближнему Востоку и Африке. 23 марта 2010 г.

Некоторая ранняя работа была предпринята над версией стандарта 1.2, но отсутствие интереса отрасли к дальнейшим изменениям привело к тому, что стандарт остался в версии 1.1.

Структура документа

Документ FIXatdl может содержать одно или несколько определений стратегии. В определении стратегии есть четыре основных раздела:

  • Раздел метаданных, определяющий, к каким географическим регионам, рынкам (биржам) и классам активов применима стратегия.
  • Раздел параметров, в котором перечислены все параметры, используемые стратегией, их типы данных, ограничения (например, минимальные и максимальные значения) и то, как они должны быть представлены в итоговом сообщении FIX.
  • Раздел StrategyLayout, который определяет элементы управления пользовательского интерфейса, которые будут использоваться для этой стратегии, как они должны быть размещены на экране и как они сопоставляются с параметрами, описанными в предыдущем разделе документа.
  • Раздел StrategyEdit, в котором описаны применяемые правила проверки - обычно это проверки между полями.

Документы FIXatdl должны соответствовать набору схемы XSD, предоставленной FPL. Эти схемы разделены на следующие четыре категории:

  • Ядро (определяет содержимое данных, типы данных, ограничения и т. Д.)
  • Макет (определяет элементы управления, которые можно использовать, и их расположение)
  • Проверка (не требует пояснений)
  • Поток (позволяет включать / отключать элементы управления, скрывать / отображать и обновлять, в зависимости от состояния или содержимого других элементов управления)

Возможности пользовательского интерфейса

Панели стратегии

Версия 1.1 поддерживает 14 различных элементов управления пользовательским интерфейсом, которые можно сгруппировать следующим образом:

  • Этикетки
  • Поля ввода текста (часто называемые текстовыми полями)
  • Флажки и переключатели, как по отдельности, так и в виде списков
  • Списки, как с одиночным, так и с множественным выбором
  • Выпадающие списки, как редактируемые, так и не редактируемые
  • Элементы управления часами, для ввода даты / времени
  • Ползунки для выбора одного из небольшого количества настроек
  • Числовые счетчики, как одинарные, так и двойные для целых чисел и чисел с плавающей запятой соответственно

Элементы управления размещаются с использованием иерархии панелей (называемых StrategyPanels), каждая из которых может иметь горизонтальную или вертикальную ориентацию. На рисунке справа показано, как элементы XML относятся к отдельным панелям в данном макете.

Принятие

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

Существуют также реализации Java и .NET с открытым исходным кодом , atdl4j и Atdl4net соответственно, которые обе совместимы с версией 1.1.

Другие стандарты пользовательского интерфейса

Часто задают вопрос, почему FIXatdl не использует готовый стандарт пользовательского интерфейса, такой как Mozilla XUL , Microsoft Windows Presentation Foundation или Apache Flex ? Это правильный вопрос, но похоже, что авторы спецификации хотели сохранить полную независимость от платформы, и принятие любой одной платформы может повредить этому предложению. Несмотря на недостаточную степень сложности некоторых из этих платформ, текущая спецификация обеспечивает приемлемую степень контроля с точки зрения компоновки пользовательского интерфейса без чрезмерных ограничений. Еще неизвестно, как этот выбор дизайна окажется успешным, и действительно кажется вероятным, что дальнейшее уточнение этой части спецификации будет необходимо по мере роста принятия.

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

использованная литература

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