Войти
Язык определения алгоритмической торговли FIX, более известный как FIXatdl - это стандарт обмена метаинформацией, необходимой для обеспечения алгоритмической торговой деятельности на финансовых рынках. Он работает в тандеме с протоколом Financial Information eXchange (FIX), который является lingua franca электронной торговли на рынке ценных бумаг.
До середины девяностых годов практически все операции с ценными бумагами осуществлялись по телефону, но с появлением 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 были действительными и правильно сформированными.
Версия 1.1 FIXatdl была предварительно одобрена GTC 9 февраля 2010 г., когда она вошла в период общественного обсуждения, а затем окончательно одобрена 3 марта 2010 г. Спецификация была официально представлена на рынке в FPL. Конференция Европа, Ближний Восток и Африка, 23 марта 2010 г.
Некоторая ранняя работа была предпринята над версией 1.2 стандарта, но отсутствие интереса отрасли к внесению дальнейших изменений привело к тому, что стандарт остался на версии 1.1.
Документ FIXatdl может содержать одно или несколько определений стратегии. В определении стратегии есть четыре основных раздела, а именно:
Документы FIXatdl должны проверяться на соответствие набору схемы XSD, предоставленной FPL. Эти схемы разделены на следующие четыре категории:
Панели стратегии Версия 1.1 поддерживает 14 различных элементов управления пользовательского интерфейса, которые можно сгруппировать следующим образом:
Элементы управления размещаются с использованием иерархия панелей (называемых StrategyPanels), каждая из которых может иметь горизонтальную или вертикальную ориентацию. На рисунке справа показано, как элементы XML относятся к отдельным панелям в данном макете.
В отличие от предыдущей версии, версия 1.1 была широко принята и принята в индустрии ценных бумаг. Даже в конце 2009 года уже были фирмы, использующие стандарт 1.1, несмотря на его предварительный статус. Примеры фирм, поддерживающих стандарт FIXatdl, включают:
, также есть Java и .NET <16 с открытым исходным кодом.>, atdl4j и Atdl4net соответственно, которые обе совместимы с версией 1.1.
Часто задают вопрос, почему FIXatdl не использует готовый стандарт пользовательского интерфейса, такой как Mozilla XUL, Microsoft Windows Presentation Foundation или Apache Flex ? Это правильный вопрос, но похоже, что авторы спецификации хотели сохранить полную независимость от платформы, и принятие любой одной платформы может повредить этому предложению. Несмотря на недостаточную сложность некоторых из этих платформ, текущая спецификация обеспечивает приемлемую степень контроля с точки зрения макета пользовательского интерфейса, не будучи чрезмерно ограничивающей. Еще неизвестно, как этот выбор дизайна окажется успешным, и действительно кажется вероятным, что дальнейшее уточнение этой части спецификации будет необходимо по мере роста принятия.
