Симвология

Хочу немного рассказать про один наш подпроект, который выпил много крови и дал много опыта. Внутри мы называем его симвология — часть проекта Option Workshop, в которой решается задача предоставления пользователю списка доступных инструментов


Задача

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


Для российского рынка задача решается легко. Любая система (QUIK, Plaza 2 и т.п.), с которой вы проинтегрируете свой прикладной софт, в том или ином виде выдаст список инструментов. Кроме того, так как инструментов относительно мало, те же системы будут транслировать весь поток данных, то есть такого механизма, как подписка на получение данных, практически не встречается, вы просто всегда получаете всё.


Можно сказать, что для РФР проблемы нет и писать не о чем. Для рынков США всё иначе.


Во-первых, количество контрактов (под контрактом мы понимаем всё, что торгуется, вплоть до отдельного опциона) больше даже не в разы, а на порядки. Так, на фортс обращаются около 6000 контрактов, а на опционных рынках США (фьючерсном и эквити) счёт опционов идёт на миллионы. Собрать и структурировать информацию обо всех инструментах – первая подзадача.


Во-вторых, количество систем, “точек интеграции”, с которыми можно связывать свой прикладной софт, также гораздо больше. Масса проприетарных систем от разных брокеров, и несколько независимых вендоров. Ввиду большого количества инструментов, все системы подразумевают, что прежде чем получать данные по инструменту с сервера, нужно оформить подписку. Упрощённо говоря, нужно отправить сообщение, которое содержит символ – строковый код инструмента, и тип данных, которые вы хотите получать. Количество подписок, как правило, ограничено несколькими сотнями.


Мы интегрируем Option Workshop с несколькими системами (и расширяем этот набор) и проблемой для нас является то, что каждая из них имеет свой формат символов. Для примера, возьмём mini фьючерсы на S&P 500, конкретно сентябрь 2016-го года. В таблице ниже приводятся символы этого контракта в разных системах.


 
СистемаСимвол
CQG“F.US.EPU6”
IB“ESU6”
IQ Feed“@ESU16”

Специально привожу символы в кавычках, чтобы подчеркнуть, что речь идёт о строке. Видно, что символы отличаются не только форматом, но даже кодом актива (ES, EP). То есть, вторая подзадача заключается в том, чтобы обеспечить для каждого узла дерева символы, понятные всем системам, с которыми интегрируется программа.


Как задача решается в других системах

Во-первых, давайте разделим системы на самостоятельные и “приводы”. Примеры самостоятельных – QUIK, CQG, IB, TOS, TT. Примеры приводов – Option Workshop и множество других проектов. Самостоятельные системы имеют свои бэкенды (серверную часть), через которую клиентские места получают котировки. Приводы цепляются к клиентским терминалам или серверным API самостоятельных систем и паразитируют на них.


Если у первых стоит задача создать систему инструментов только под себя, то вторые вынуждены подстраиваться под несколько символьных номенклатур. Скажем, если вы проинтегрировали свой софт с CQG и IB, то для запроса на получение истории дневных свечей по одному и тому же инструменту вам придётся указать в запросе разные символы.


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


В приводах часто пользователю предлагается самостоятельно прописать символ инструмента в той системе, с которой он интегрирует программу. Хотя есть примеры, где по крайней мере для самых торгуемых инструментов симвология автоматизирована.


Что сделали мы

Дерево

Рисунки ниже поясняют, как выглядит дерево инструментов в Option Workshop.


Различные уровни дерева инструментов        Различные уровни дерева инструментов


Различные уровни дерева инструментов


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


Как выглядит дерево понятно. Теперь, откуда оно берётся.


Процесс, собирающий дерево, запускается раз в сутки и работает больше часа. За это время он пережёвывает сотни мегабайт текстовых данных и раскладывает их в удобную структуру, которой можно пользоваться. Например, обращаться к ней через Web API.


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


Коротко об источниках данных.


CME Group

Структуру четырёх бирж группы CME проще всего построить по файлу, в котором описываются параметры системы маржирования. Это xml, размером 300-400 мегабайт, доступен для скачивания на сайте биржи. Его структура описана плохо, но, проявив настойчивость, можно разобраться и достать нужные данные.


Риск-параметры распространяются и в текстовом формате. Он компактнее, но не читается глазами и, насколько нам удалось разобраться, информация в xml варианте полнее. То есть на перспективу лучше работать с xml.


Ну и конечно же сайт группы также является источником информации. На наш взгляд cmegroup.com – один из лучших сайтов в индустрии, с очень полной и хорошо структурированной информацией.


The ICE

Самая сложная биржа. Для построения дерева её инструментов приходится собирать по сайту очень много разрозненной информации, структура которой часто меняется и нужно быть начеку.


Опционы на акции

С ними проще всего. Как известно, в США несколько бирж, на которых торгуются одни и те же опционы на акции (которые в свою очередь в большинстве своём торгуются каждая только на одной площадке). При этом клиринг происходит в одном месте – The Options Clearing Corporation. Клиринговая организация формирует структуру этого рынка, биржи забирают набор инструментов и каждый день на всех биржах торгуются одни и те же опционы. Для того, чтобы биржи могли получить актуальный набор опционов, OCC предоставляет хороший открытый web API, которым мы и воспользовались. Информации загружать приходится много, но она хорошо структурирована и структура стабильна во времени.


Фортс

Информации, доступной через шлюз этого рынка достаточно, чтобы построить структуру инструментов.


Символы

Дерево построено, для каждого контракта у нас есть полная информация – актив, дата экспирации, тип и страйк опциона, месяц контракта (не всегда совпадает с датой экспирации) и признак недельных опционов. Но сама по себе она не может быть использована для подписки на данные и выставления заявок в разных системах. Нам нужно сформировать символы.


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


Ниже показан кусок файла с правилами для Interactive Brokers. Это JSON. На первом уровне перечислены биржи. Для каждой биржи сначала задаётся набор правил по-умолчанию (“default” в примере), которые будут использоваться для формирования символа контракта в случае, когда для актива (коммодити, акции, индекса) не описан специфический набор правил. Далее после default правил следует большой список специфических правил (“assets” в примере).


Набор правил состоит из 4-х частей:


  1. am – правило формирования символа для актива,
  2. aom – правило формирования символа для опциона на актив,
  3. fm – правило формирования символа для фьючерса,
  4. fom – правило формирования символа для опциона на фьючерс.

Каждое правило – это форматная строка. Например, такая:


"{asset}{exp:f}{exp:y}"

Каждый элемент строки, заключённый в фигурные скобки, говорит конвертеру, что нужно добавить в символ в этом месте: {asset} – подставляется код актива, {exp:f} – подставляется фьючерсный код месяца экспирации, {exp:o} – опционный код месяца экспирации.


"CME" : {
	"default" : {
		"am" : "{asset}",
		"aom" : "{asset}{exp:o}{exp:y}{strike}",
		"fm" : "{asset}{exp:f}{exp:y}",
		"fom" : "{family}{exp:f}{exp:y} {type}{strike:format=0000}"},
	"assets" : {
		"AD" : {
			"a" : "{asset}",
			"fm" : "6A{exp:f}{exp:y}",
			"fom" : "{family}{exp:f}{exp:y} {type}{strike:mul=1000, weekmul=1000, format=0000}",
			"optf" : {
				"AD" : {
					"code" : "6A",
					"weekly" : {
						"W1" : "6A1",
						"W2" : "6A2",
						"W3" : "6A3",
						"W4" : "6A4",
						"W5" : "6A5",
						"W6" : "6A6"}},
				"XA" : {
					"code" : "NA-XA",
					"weekly" : {
						"W1" : "1XA",
						"W2" : "2XA",
						"W3" : "3XA",
						"W4" : "4XA",
						"W5" : "5XA",
						"W6" : "6XA"}}}},


Резюме

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


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


Сейчас программе не хватает удобства в части быстрого поиска инструмента/серии. Так или иначе, пользователь должен воспользоваться мышкой, чтобы оказаться в дереве инструментов и уже оттуда совершать действия. Это долго, много лишних кликов. Будем от них избавляться. Для этого потребуется доработка символогии, усложнение механизмов поиска по ней.


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


В ближайших планах добавить Eurex.







10 комментариев

avatar
раскрыть комментарий
avatar
Спасибо, Дмитрий! The ICE, говорят, ещё и цены на данные задрал до небес для всех, включая non prof.
avatar
Действительно с 01.01.2016:

ICE US (NYBOT) — $117/мес.,
ICE Europe — $117/мес. и это только для клиентов non prof, обслуживающихся в FCM. Для prof еще +$96/мес.

avatar
Московская биржа — самая гуманная биржа в мире.
avatar
раскрыть комментарий
avatar
Читаете какие-нибудь западные аналоги h2t? Может есть мысли, где нам можно было бы ow попиарить. 
avatar
раскрыть комментарий
avatar
Конечно.

avatar
раскрыть комментарий
avatar
раскрыть комментарий

Добавить комментарий