|
|
Поверхностно об алготрейдинге 3
|
Отправлено elite on 06/08/15 8:27
Получение T&S-данных из Level2. Аллокация ордеров. PriceTakers vs PriceGivers. Организация перехода биржи на новый движок. Поглощение бирж. Матчинг. Dark-pool. Централизация vs Децентрализация. Real-Time Tester. Типы синхронизаторов.
Грубый алгоритм получения T&S-данных из Level2
Представим, что у нас есть некая последовательность значений Level2 — большие вектора, где каждому ценовому уровню соответствует свой объем (банды). Пронумеруем элементы этой последовательности от нуля (текущий), в сторону прошлого.
ECN (биржи)
Сраниваем между собой Level2[0] и Level2[1]. Если Bid[0] >= Ask[1], то в T&S попадают все банды из Level2[1]_Ask, которые не выше Bid[0]. Аналогично для ситуации Ask[0] <= Bid[1]. В остальных случаях в моделируемый T&S ничего не попадает.
Данный алгоритм легко проверить на лин. связи с официально предоставляемыми биржами T&S-данными. Затем навести некоторые улучшениче через неравномерные по бандам распределения и т.д… Вообщем, тема копается всегда с грубой модели выше.
STP (желательно много ЛП)
Vector_Ask[0] = Level2[0]_Ask — Level2[1]_Ask. У этого вектора суммируются от лучшего (по цене) банда все отрицательные значения, пока не встретится первый неотрицательный банд. Это сумма заносится в T&S[0]. С Bid — аналогично.
ECN/STP
Здесь посложнее, т.к. надо объединить два почти противоречащих друг-другу метода для ECN и STP. Расписывать не буду.
Зачем T&S?
Применимость в ММ-алгоритмах уже описывал. Также, например, можно оценивать ценовые уровни скопления серьезных объемов и анализировать их влияние на отдаленные (секунды, минуты, часы) ценовые цели.
На FOREX для того, чтобы оценивать взаимосвязи между всеми символами, иногда резонно использовать Level2 не символов, а валютных пар (самим строить синтетический Level2).
Аллокация ордеров
Так называется правило (алгоритм) распределения заполнения (при исполнении) лимитных заявок, расположенных на одном и том же банде.
Например, на лучшем банде располагается сразу несколько заявок, суммарный объем которых больше, чем пришедший объем маркет-ордера от PriceTaker. Понятно, что PriceTaker получит полный объем исполнения по цене на лучшем банде. Встает вопрос, а как этот объем распределить между заявками, что находились на банде?
И тут у каждой системы возникает свое видение, как это делать правильно.
Pro-Rata
Это классическое правило аллокации, когда на момент исполнения все заявки имеют коэффициент исполнения, соответствующий той части объема, которую вносят заявки в общий объем банда.
Это значит, что не имеет значения, разбиваете ли вы свой лимитник на куски, в какой последовательности эти куски отправляете. Исполнение всегда будет одинаковым.
FIFO
Здесь главенствует время постановки лимитника. Лимитники заливаются по приоритету: пока раньше выставленные лимитники не будут залиты полностью, другие лимитники заливаться не будут.
При таком правиле аллокации PriceGivers пытаются выставить свои лимитники раньше остальных, чтобы увеличить вероятность их исполнения. Как следствие, это вызывает сужение спреда и уменьшение объемов на бандах, т.к. если кто-то выставил свою заявку на новый банд (уменьшил спред), то другому участнику нет желания присоединяться к этому банду, т.к. все равно он будет аутсайдером перед более пронырливым.
При выставлении заявки на новый банд, ее отправляют либо полным объемом, либо разбивают на куски по убывающей, выставляя их в этой же последовательности в очереди. Это позволяет, если необходимо, убрать часть объема своей заявки (по принципу стека), при этом не потеряв приоритет исполнения.
Volume (Weigth) FIFO
Термин сочинил на ходу. Приоритет идет не по времени выставления, а по объему заявки (или иному кастомному признаку — Weight).
Такая аллокация побуждает PriceGivers наполнять наилучшие банды максимальной ликвидностью. Для PriceTakers это одно из наилучших правил.
Weight Pro-Rata
Также термин сочинил. Это модификация Pro-Rata, где заявкам даются уже не одинаковые веса распределения, а в зависимости от признака Weight.
Например, может использоваться любое распределение (мат. термин) по времени выставления заявок: чем раньше выставил, тем выше вес. В частности, распространено использование мат. линейного распределения по времени (Time Pro-Rata).
Аналогично делается и по Volume и даже по более сложным признакам (например, Weigth = TimeLive * Volume).
При таком подходе применяются уже различные математически обоснованные методы оптимального выставления заявок — максимизация вероятности наибольшего по суммарному объему исполнения заявок от участника рынка. Т.е. находятся алгоритмы, как разбивать на куски заявку и в какой последовательности их отправлять на банд.
Что используют и зачем
Каждая площадка придумывает свои правила аллокации, либо использует уже кем-то наработанные. В зависимости от целей, что она преследует. Понятно, что основная цель — увеличение прибыли, т.е. увеличение оборота. И тут встает нетривиальный вопрос выбора алгоритма аллокации. Чтобы и PriceGivers мотивировать и активность PriceTakers не уменьшить. Тут все зависит от базы имеющейся клиентуры площадки и перспектив развития.
Чаще всего не заморачиваются и выбирают простые варианты: Pro-Rata и FIFO.
Единственный алгоритм, где не возникает коллизий с минимально допустимым объемом (лотом) — FIFO-варианты.
PriceTakers vs PriceGivers
Когда в T&S-данных есть классификация по направлениям, можно говорить об общих показателях торговли PriceTakers, либо же PriceGivers.
Будем считать далее, что упомянутое направление касается PriceTakers. Это условность на самом деле, т.к. PriceGivers-направления — просто с обратным знаком.
Вспомним, что каждый элемент T&S-последовательности представляет из себя данные по совершенной кем-то из PriceTakers сделке: цена, объем и ее направление.
Это значит, что мы вполне в состоянии построить динамику изменения суммарного Equity всех PriceTakers по каждому символу в отдельности и, соответственно, по любой совокупности символов. Более того, на FOREX, рассматривая все кроссы и мажоры одновременно, можно построить динамику изменения общего валютного профиля PriceTakers: сколько какой валюты «на руках» у PriceTakers.
Level3--
Есть такое понятие, как Level3 — это полная информация о текущем состоянии каждого из участников рынка. Грубо говоря, это хорошо охраняемый инсайд. Однако, как было сказано выше, мы можем к нему приблизиться, вычислив Equity_PriceTakers.
Напомню, фактическое предназначение PriceTakers — мясо для PriceGivers, среди которых есть очень сильные участники рынка. Т.е. само алгоритмическое ценообразование служит обогащению PriceGivers за счет слива PriceTakers.
Так что PriceGivers будут делать все, чтобы Equity_PriceTakers уменьшался. Поэтому исользование такого легко вычисляемого алгоритмического инсайда видится разумным с точки зрения природы современного электронного фин. рынка.
Организация перехода биржи на новый движок
Каждая биржа работает на каком-то торговом движке. Допустим, владелец биржи осознал серьезное угрожающее (или тормозящее) бизнесу несовершенство текущего движка. Перед ним встает задача написать новый совершенный движок биржи.
Может так оказаться, что новый движок несовместим (такое бывает) со старым. Как перевести биржу на новый движок?
Проблема в том, что на старом движке находится вся текущая ликвидка. И если старый просто выключить и дать новый. То на новом ликвидки практически не будет (убийство биржи) — не могут все мгновенно перестроиться.
Поэтому делают ECN/STP-схему работы нового движка. Когда старый движок подключается по STP к новому в качестве единственного LP. А новый дает еще свою внутреннюю ECN.
Это позволяет торговать сразу через два движка.
После того, как начинает завоевывать популярность более совершенный движок (потому что через него торговать выгоднее — торговые издержки меньше, возможностей больше), на него начинает перетекать ликвидность со старого (попадает во внутреннюю ECN нового движка).
В итоге со старого движка ликвидка практически вся переходит на новый. После чего старый закрывается полностью. И остается только новый уже без внешнего LP. Т.е. получается обновленная биржа (ECN) — абсолютно вся на новом совершенном движке.
Важно понимать, что биржевой движок (или движок любой другой торговой площадки) ничего не имеет общего с торговыми API. Т.е. никто, кроме самой биржи, не в состоянии как-либо влиять на работу этого внутреннего движка напрямую. Это можно делать только косвенно.
Для этого владелец движка пишет бриджи между своим внутренним движком и внешним торговым API. Чаще всего ограничиваются только одним таким реальным торговым API — FIX API (ПОЧТИ обязаловка — стандарт). Но бывают случаи, когда реальных торговых API несколько.
Торговые платформы со своими торговыми API — это не реальные торговые API площадки, а их обертка: иногда более высокоуровневая, иногда менее функциональная, но более простая в работе. Например, почти у всех торговых платформ имеющиеся торговые API на самом деле являются обертками. Поэтому торговля через них увеличивает торговые издержки за счет latency обертки.
Поглощение бирж
Торговых площадок очень много. На некоторых из них могут торговаться не только коинтегрированные ФИ, но и вообще одни и те же ФИ. Т.е. один и тот же ФИ торгуется на разных площадках.
Для того, чтобы поглотить эти площадки (перелить всю их ликвидку на свою площадку), нужно создать ECN/STP-агрегатор, где все площадки-жертвы выступают в качестве LP. Такой способ создает новую торговую площадку с более выгодными ценами — демпинг цен.
Благодаря также грамотному маркетингу продвижения новой площадки, на нее из-за демпинга переходят сначала алго-тейкеры, затем алго-гиверы, затем снова тейкеры и т.д. Переливая ликвидку, как снежный ком. С определенного момент процесс становится необратимым. И площадки-жертвы полностью поглощаются.
На примерах выше вы можете видеть основную историческую значимость ECN/STP-схем. Они служат целям централизации рынка, более эффективного ценообразования, увеличения ликвидности и улучшения цен.
Матчинг
Матчингом называется описанное ранее сведение двух разнонаправленных торговых заявок в рамках ECN. Заметьте, что STP-исполнение заявок не является матчингом.
Классификатор матчинга
В любой ECN (бирже) есть возможножность статистической классификации проведенного матчинга на группы участников рынка, внутри которых происходит наибольший оборот матчинга. Например, если два участника рынка, благодаря матчингу, переливают друг-другу деньги через взаимный матчинг, то подобный классификатор выделит их в отдельную группу.
Самоидентификация
Любой ECN стратегически выгодно, чтобы у нее было как можно больше брокеров (независимых баз данных клиентов). Это нужно для уменьшения вероятности создания себе гипотетического конкурента.
Конкурент рождается чаще всего через самоидентификацию брокеров, которая происходит следующим образом. Относительно крупные брокеры проводят классификацию матчинга своих баз данных клиентов. Если удается выявить крупнооборотистые группы таких клиентов внутри своих баз данных, то возникает очевидная мысль: зачем эти клиенты должны платить ECN за матчинг между собой, когда он происходит все равно между клиентами брокера? Конечно же, это прагматический вопрос.
Dark-pool
Ответом на него служит создание своего ECN/STP-движка, где ECN служит для матчинга внутриброкерских клиентов, а STP — для исполнения на внешней ECN (во избежании путаницы дальше по тексту будем называть внешнюю ECN биржей (чаще всего так оно и есть)). Данное решение дает несколько плюсов (и минусов), как для брокера, так и для его клиентов.
Брокер уже имеет свою торговую площадку, которая по отношению к бирже имеет свое название — dark-pool. Соответственно, комиссия от матчинга своих клиентов идет теперь к владельцу этой площадки, а не к владельцу биржи.
Клиенты брокера получают иногда более качественное исполнение (чем на бирже), если оно происходит внутри ECN, т.к. latency (технические/вычислительные временные задержки) биржи для клиентов брокера всегда выше, чем latency клиентской базы данных клиентов брокера.
Но есть и неоднозначные для клиентов моменты. Если проводится STP-транзакция, то гарантированного исполнения клиентов уже не выходит. Т.е. FillRate (качество исполнения) < 100%. Как уже подробно разбиралось ранее, это следствие того, что заявки клиентов при STP-схеме больше не видны в Level2 биржи. Т.е. биржевые клиенты не могут на них реагировать. Грубо говоря, клиенты dark-pools становятся лишь только PriceTakers (не PriceGivers) для биржи.
Однако, они оставляют свое право PriceGivers внутри dark-pool, и это ни есть мало. Т.к. не забываем, что перед созданием (и ее причиной) dark-pool происходила адекватная вышеописанная самоидентификация. Также надо сказать, что dark-pool позволяет дать его клиентам анонимность перед биржей, т.к. все STP-транзакции идут теперь только от одного имени — имени dark-pool. Более того, dark-pool из-за своей обособленности по отношению к бирже создает дополнительную защиту от особо-агрессивных биржевых PriceGivers (ММ-алгоритмы и другие HFT-представители алготрейдинга), что не без оснований привлекает многих участников рынка переходить через торговлю с бирж в dark-pools.
Развитие dark-pools
Согласно описанной ранее схеме поглощения бирж, крупный dark-pool в состоянии поглотить биржу и фактически начать выполнять уже ее роль. При этом регуляторское бремя биржи не касается dark-pools, т.к. они практически являются чисто-электронными (виртуальными) образованиями. Разумеется, регуляторская лапа в будущем не обойдет и их, как это всегда происходило, когда что-то новое набирало серьезный вес.
Централизация vs Децентрализация
Как видите, создание dark-pools — это естественный эволюционный процесс, происходящий внутри рынка — его децентрализация. Ненулевая вероятность децентрализации заставляет централизованные биржи улучшать свои торговые условия. Т.е. децентрализация для бирж является неким механизмом, повышающим эффектиновсть данного вида рынка. Однако, существуют и отрицательные стороны излишней децентрализации, которые былы показаны на примере FOREX. Там та же ECN/STP-схема, как это не парадоксально, служит уже для централизации рынка и соответствующего улучшения торговых условий.
Т.е. через ECN/STP-образования можно, как децентрализовывать рынок путем создания dark-pools, так и централизовывать — создание высокоуровневой агрегации из тех же dark-pools, в частности.
Наилучшие торговые условия находятся где-то на золотой середине между парадигмами децентрализованного и централизованного рынков.
Real-Time Tester
Любой алготрейдер сталкивается с задачей перевода тестерного робота в боевое состояние, готовое для работы на реальном рынке.
На самом деле существует только один способ грамотного перевода. К счастью, он практически универсален.
Боевой робот делится на две части: тестер и синхронизатор.
Тестер выдает торговое окружение тестерного робота на текущий момент истории (до настоящего).
Синхронизатор эти данные согласует с текущим реальным торговым окружением, пытаясь подогнать их с виртуальным (полученным в тестере).
Например, виртуальное окружение показывает, что сейчас на таком-то уровне стоит лимитник. Задача синхронизатора сделать так, чтобы на этом ценовом уровне уже на реальном рынке стоял подобный лимитник.
Типы синхронизаторов
Универсального синхронизатора быть не может. Но существуют только два принципиально разных подхода к синхронизации.
- Классический — через маркеты (а-ля лимитники по цене хуже текущей). Это самая простая схема, когда через маркеты копируется торговое окружение. Плюсы этого метода заключаются в полном повторении и простой наглядности. Минусы — отрицательные проскальзывания. Т.е. для ТС с низким мат. ожиданием это плохой вариант.
- Через лимитные приказы. Когда, например, копируемый BUY считается, как BuyLimit на цене открытия копируемой позиции. Также учитываются все копируемые лимитные приказы. Плюсом такого метода является нивелирование отрицательных проскальзываний. Минусом — реджекты лимитных приказов могут искажать результаты.
Классический вариант в том или ином виде реализован во всех сигнальных сервисах, столь популяризируемых сейчас. Такая схема выгодна сервисам, т.к. синхронизатор максимально простой, и их слабо заботят торговые издержки клиентов.
Вторая схема, на сколько мне известно, нигде не применяется. Возможно, кто-то из очень занудных алготрейдеров у себя реализовал…
Манипуляционное использование сигнальных сервисов
Выше говорил, какие издержки несут так модные сейчас сигнальные сервисы, использущие примитивную классическую схему синхронизации: через маркет-ордера.
Стоит упомянуть еще один минус такой синхронизации — манипуляционная составляющая. Описанная ниже техника может кому-то напомнить layering. Но все же это другое. Наперед скажу, что нижеизложенное имеет смысл только для ECN (биржи) и ECN/STP-площадок.
Представьте, что вы поставщик сигналов (лучше бесплатных) и у вас есть подписчики (их больше будет тогда), торгуемый сайз которых выше вашего. Тогда время от времени у вас есть возможность включать простой перелив денег со счетов ваших подписчиков на ваш мастер-счет:
Выставляете БОЛЬШИЕ BuyLimit и SellLimit вовнутрь спреда и делаете «спусковой крючек» — небольшой SELL (продаете себе же — BuyLimit). Это вызывает лавину SELL-приказов со стороны ваших подписчиков. Начинает заливаться ваш BuyLimit, т.е. расти BUY-поза. Что вызывает снова лавину, но уже BUY-приказов со стороны ваших подписчиков. Т.е. начинает заполняться ваш SellLimit.
В итоге, вызвав подобные рекурсивные лавины (основа которых еще лежит в latency сигнальных сервисов), вы получаете перелив денег с ваших подписчиков на ваш мастер-счет. Это улучшает показатели вашего мастер-счета, привлекая еще больше подписчиков.
Конечно, не обязательно лимитники выставлять на мастер-счете. Это можно сделать на вашем личном другом счете. Тогда получите перелив на него. Но мастер-счет будет иметьт небольшую просадку, что может оттолкнуть подписчиков.
Могут быть и другие варианты таких махинаций, но их ядро-идея будет неизменной, как написал выше.
ММ-алгоритмы практически невозможно прибыльно синхронизировать через классическую схему. Поэтому целесообразно обращаться к упомянутой ранее альтернативной схеме синхронизации.
Любые торговые действия на ECN (биржи) — всегда перелив денег с одних торговых счетов на другие. Поэтому демонизировать саму технику перелива просто глупо. Нужно просто понимать, что к чему.
Не надо забывать, что задача почти любого ММ-алгоритма — создать взаимовыгодные условия для перелива денег с чужих счетов на свои. Взаимовыгодность заключается в том, что сливающие делают это с меньшей скоростью, чем могли бы, если бы ММ-алгоритма не было. Бывают и исключения — нет взаимовыгодности.
Рыночные закономерности (не HFT)
Рынок характеризуется наличием различного рода закономерностей в каждый момент времени. Если обозначить N(t), как функцию количества закономерностей в зависимости от времени и построить ее график. То сразу бросятся в глаза провалы — резкое уменьшение количества рыночных закономерностей.
Эти провалы почти всегда соответствуют важным событиям, > 90% из которых являются плановыми — экономические новости по расписанию.
При поиске рыночных закономерностей разумно выбрасывать из анализа подобные периоды провалов N(t), как плановые, так и форс-мажорные. Выбрасывают еще и периоды явных отсутствий искомых закономерностей — специальный автоматизированный фильтр.
Такие действия позволяют значительно увеличить вероятность нахождения закономерности.
Поэтому во время торговли найденной рыночной закономерности прекращается какая-либо торговая деятельность перед выходом запланированной новости и некоторое время после.
P.S.
Спасибо sergeev-у, с чьей подачи получилось начать и системно продолжить написание данного ликбеза.
hrenfx
|
|
< Поверхностно об алготрейдинге 2
| Итоги 10-ти лет антиинфляционного портфеля >
| |
|
Поверхностно об алготрейдинге 3
