Как не потерять все деньги за пару минут или риск-менеджмент в алгоритмической торговле

  • Tutorial



Введение


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

"Алготрейдер спит — торговля идет!" — любят говорить некоторые трейдеры. Но в реальности не все так просто. Как вы думаете с чего начинается алгоритмическая торговля? С подключения к бирже или написания алгоритма? Для профессионально участника трейдинг начинается с разработки риск-менеджмента.

Считается, что алготрейдинг значительно эффективнее классического трейдинга. Потому, что у роботов не бывает эмоциональных решений, они готовы работать 24/7, точно знают, когда покупать и когда продавать, совершают сделки со скоростью не доступной обычному человеку. Однако, в силу своих суперспособностей, они создают повышенный класс рисков.
Например, известный случай вошедший в историю как «Месть машин» принес убытки в $460 млн, или сломавшийся робот принес потери в размере $4.3 млн или сбои на Московской бирже приводящие к остановкам и убыткам для трейдеров и т.д. Достаточного одного такого инцидента и торговым счетам может быть нанесен непоправимый ущерб. Это особенно актуально, если торговля маржинальная, когда цена ошибки возрастает в несколько раз.

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

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

1. Архитектурные решения


Прежде чем перейти к классификации рисков немого расскажу о типовых решениях в торговой части алгоритмического тнейдинга.

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

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

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


Рис.1. Схема архитектурного решения для торгового сервера.

2. Общая классификация рисков


  • 2.1. Инфраструктурные риски
  • 2.2. Проблемы с подключением к бирже/брокеру
  • 2.3. Проблемы в логике торговых стратегий

2.1. Инфраструктурные риски


Основная доля проблем в данном классе связана с торговыми серверами. Для алгоритмической торговли даже очень мощный ПК не подходит по множеству причин: ненадежное оборудование, нестабильное интернет-соединение, плохое электропитание и т.д.

Основные риски:

  • полная/частичная потеря работоспособности сервера;
  • аварийная перезагрузка операционной системы;
  • физический отказ сервера.

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

2.1.1. Варианты решения


  • Колокация на бирже. Идеальный и самый дорогой вариант. Как правило используется в высокодоходных HFT алгоритмах или в крупных компаниях, например, банках, где данная инфраструктура переиспользуется для других торговых решений.
  • Аренда виртуальных/выделенных серверов. Если вы не большой хедж-фонд или частный трейдер, то наверняка используете именно этот вариант. Простое легко настраиваемое и масштабируемое решение. Всегда можно найти провайдера, подходящего по параметрам цена/качество.
  • Своя серверная. В данном случае реализуется собственная серверная с надежным резервируемым подключением. Иногда это особенно актуально, если приходится работать с чувствительными к приватности данными или часть серверов используются для ресурсоемких задач оптимизации/машинного обучения, аренда которых выйдет в копеечку.

2.1.2. Правила подбора торговых серверов


  • Надежный/стабильный провайдер. ЦОД с вашими серверами должен отвечать классу надежности TIER III с uptime не менее 99,98% с резервируемыми каналами связи. Провайдер не должен останавливать или перезагружать ваши сервера в случае проведения своих технических работ.
  • Качество интернет соединения. Всегда тестируйте скорость, задержки и стабильность канала связи. Заявленные показатели не всегда соответствуют реальности.
  • Запас мощности минимум 40-50% (ЦП, оперативная память, SSD) по сравнению с обычным режимом торговли. Как правило, на сильных движениях на рынке кратно увеличиваются нагрузки в потоках данных и алгоритмы начинают активно совершать сделки. В этот ответственный момент не должно быть никаких тормозов на ваших серверах.

2.2. Проблемы с подключением


На биржах и у брокеров время от времени случаются технические сбои. Например, в работе трейдинговой платформы Сбербанка произошел сбой или «недоработали» на Московской бирже, биржа закрылась на обед, Мосбиржа приостановила торги из-за сбоя и т.д.

Основные риски:

  • разрывы соединения;
  • высокие задержки;
  • некорректные данные;
  • частичная потеря данных.


2.2.1. Разрывы соединения


Информацию о разрыве соединения можно получить несколькими способами:

  • API события в коннекторе — Connected, Disconnected.
  • Используя алгоритмы проверки соединения типа Heartbeat, которые, как правило, присутствуют в API.
  • Косвенным путем. По отсутствию данных в потоках данных.

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

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

2.2.2. Проблемы с данными


Для начала рассмотрим основные типы биржевых данных. В зависимости от типа коннектора и биржи эти данные не много разнятся, но в основном плюс-минус одинаковые.

Входящие изменения:

  • Биржевые стаканы/ордербук
  • Сделки
  • Заявки
  • Позиции
  • Баланс

Исходящие данные:

  • Заявки на регистрацию

Входящие и исходящие данные могут идти как из одного, так и из различных подключений. Бывает, что один из потоков может отвалиться «по-тихому», а остальные при этом будут работать в штатном режиме. Даже если данные идут из одного источника, все равно нужно следить за каждым потоком в отдельности.

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

WatchDogs отслеживают:

  • частоту обновления данных в потоке;
  • задержки по таймстемпу в данных и текущему времени;
  • по факту наличия данных определяет наличие связи с биржей.

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

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

2.2.3. Варианты решения


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

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

Порядок восстановления работы:

  • восстановить подключение;
  • загрузить потерянные данные;
  • оповестить алгоритмы о восстановлении связи;
  • передать в алгоритмы потерянные данные;
  • переключить потоки в real time;
  • торговая логика алгоритмов должна нормализовать свои позиции и перевыставить заявки.

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

2.3. Проблемы в логике торговых стратегий


Самые опасные, коварные и непредсказуемые проблемы таятся в запрограммированной логике торговых стратегий. Какими бы продуманными ни были торговые алгоритмы, но все сценарии предвидеть невозможно. Различные факторы и их сочетание могут породить неожиданное поведение. Причем некоторые ошибки могут таиться годами и «всплыть» в самый неожиданный момент.

2.3.1. Классификация проблем


  1. Ошибки в заявках:
    • Отрицательные цена/объем;
    • Обратное направление;
    • Не верный тип и т.д.
  2. Ошибки в API:
    • Не все поля заполнены в транзакции;
    • Используется устаревшая версия API;
    • Ошибки конвертации и т.д.
  3. Нарушение спецификации инструментов:
    • Не верная точность цены и объема в заявке;
    • Не правильное значение лотов;
    • Нарушение минимального и максимального объема в заявке;
    • Цена вне «ценового коридора»;
    • Торги не доступными или не существующими инструментами.
  4. Нарушение регламента торгов:
    • До начала и после завершения торговой сессии;
    • Во время клиринга;
    • В праздничные или выходные дни.
  5. Девиантное поведение заявок:
    • Высокая частота выставления заявок;
    • Большое количество активных заявок.
  6. Нарушение лимитов торговой стратегии:
    • По балансу денежных средств;
    • По позиции по инструментам;
    • Превышение максимального объема в одной заявке;
    • Превышение максимального суммарного объема в активных заявках по инструментам.
  7. Нарушение лимитов торгового счета:
    • По общей позиции по инструментам;
    • По общему балансу денежных средств;
    • Большое количество заявок, не приводящих к сделкам.
  8. Отсутствие обработки исключений в программном коде торговых стратегий

При этом одни ошибки могут породить другие. Например, остановка алгоритма из-за грубой ошибки приведет к нарушению позиции и как следствие нарушению лимитов.

2.3.2. Варианты решения


Решение данных проблем сводится к контролю заявок и лимитов торговых стратегий (см. раздел 3). При этом любое исключение в программном коде должно привести к немедленной остановке проблемного алгоритма и снятию всех его активных заявок.

3. Контроль заявок и лимитов торговых стратегий


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

Проверки можно разделить на два типа:
3.1. Базовая проверка заявок
3.2. Анализ и контроль лимитов

3.1. Базовая проверка заявок


Все исходящие заявки должны проверяться на:

  • грубые ошибки;
  • корректность и достаточность данных для API;
  • соответствие спецификации торгуемых инструментов;
  • соблюдение регламента торгов и т.д.

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

3.2. Контроль лимитов


Для контроля лимитов проверяется:
3.2.1. Изменение баланса и позиции до выставления заявки
3.2.2. Изменение текущего баланса и позиции
3.2.3. Цена и объем заявки
3.2.4. Поведение заявок

3.2.1. Анализ изменения баланса и позиции до выставления заявки


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

3.2.2. Анализ изменения текущего баланса и позиции


Формируются лимиты на изменение торгуемого объема и позиции по инструментам за периоды времени: 15 сек, 30 сек, 1 мин, 5 мин, 15 мин, 1 час, 1 день. Постоянный контроль изменений за периоды времени позволит увидеть девиацию в поведении и остановить торги, до того момента, когда отклонение станет критичным.

Бывает, что проблемы с алгоритмом проявляются не сразу. Он может начать «сливать» не спеша и не нарушая лимитов на коротком промежутке времени. Можно проснуться утром и обнаружить значительную просадку из-за одного не много «поломанного» алгоритма. Оно нам надо? Оно нам не надо.

3.2.3. Анализ цены и объема заявки


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

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

Если изменения превышают заданные лимиты, то заявки отклоняются до отправки на биржу.

3.2.4. Анализ поведения заявок


Здесь проверяется:

  • количество заявок, не приводящих к сделкам;
  • количество активных заявок;
  • частота выставления заявок за периоды 1 сек, 3 сек, 5 сек, 15 сек, 30 сек, 1 мин.

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

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

Данные проверки осуществляются на нескольких уровнях:

1. На уровне коннектора. Защита коннектора «притормаживает» заявки, когда частота выставления подходит к максимальной. Это необходимо, чтобы не потерять доступ к бирже. Данные меры крайние, поэтому важно заранее правильно рассчитывать нагрузку на коннектор.

2. На уровне торговой стратегии. Если алгоритм превышает свой лимит по частоте выставления заявок, то он принудительно останавливается с ошибкой. При этом снимаются все ранее выставленные активные заявки.

4. Интеграция риск-менеджмента в архитектурное решение


Интеграцию риск-менеджмента можно условно разделить на две основные части (см. Рис.2):

  • PRE-TRADE включает в себя базовый контроль заявок, контроль цены и объема заявки, контроль изменения баланса и позиции до выставления заявки, так же здесь анализируется поведение заявок.
  • POST-TRADE включает в себя проверки на разрывы соединения и корректность маркет данных, осуществляется постоянный контроль изменений баланса и текущих позиций, здесь так же анализируется поведение заявок.



Рис. 2. Схема интеграции риск-менеджмента в архитектурное решение для торгового сервера.

5. Логирование и репортинг


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

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

Заключение


Обычно риск-менеджмент к торговым алгоритмам начинают «прикручивать» в последнюю очередь, когда уже случилось пару инцидентов и пришло понимание, что без него не обойтись.

Так же как техника безопасности написана кровью, так и риск-менеджмент в алготрейдинге написан маржинколами и слитыми счетами.

Однако, если грамотно построить торговую систему и настроить риск-менеджмент, то можно спать спокойно и быть уверенным, что "Алготрейдер спит — торговля идет!"

Всем удачных торгов!
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 23

    0

    Подскажите, а вы как алготрейдер каким софтом пользуетесь?

      +1

      Надо было вот этим дать парням из Стэнфорда дать почитать. А то они деньги привлекают, привлекают. А потом сливают, сливают… И хорошо бы свои, так нет — чужие!
      https://smart-lab.ru/blog/607989.php

        0
        Нужно быть очень аккуратным доверяя свои деньги неизвестным людям. К сожалению, в данной сфере очень много мошенников…
          0
          Парней убил инфраструктурный риск. Если на bitmex'e останавливать торговлю при проблемах с биржей — можно там вообще не торговать.
          +2
          empenoso, для алготрейдинга пришлось написать свою торговую платформу. Существующие решения меня не устраивают по множеству причин. Раньше была идея сделать разработку публичной, но позже я от нее отказался. Проект ориентирован на профессиональных участников, требует навыков программирования.
          К сожалению, у нас почему-то считается, что алготрейдинг — это скрипты на LUA для QUIK или какой-нибудь редактор с кубиками для стратегий типа MA. А когда люди начинают глубже погружаться в вопросы алгоритмов бектестирования, времени оптимизации, подключения к биржам, программного кода торговых стратегий, технической поддержки и так далее, то у большинства на этом, как правило, алготрейдинг и заканчивается)
            +1

            Ну да, уровень школьных кружков по робототехнике.

            +1
            Можете немножко рассказать про биржевые/брокерские API? Я по вечерам пытаюсь написать что-то подобное, один из открытых вопросов — интеграция. Есть какие-то стандартные или хотя бы массово популярные протоколы, или у всех всё своё? До брокеров пока с этим вопросом не добрался, да и вряд ли у них есть на попробовать бесплатно, а платить я пока не готов — процесс движется медленно, это будет куча денег на ветер. Как вы решали этот вопрос?
              0
              Все зависит от того к какой бирже и через какого брокера вы планируете подключаться, какой тип протокола будете использовать и на какой секции торговать. Вопрос очень обширный и разнообразный.
              Если говорить про Московскую биржу и бюджетный вариант, то начните с терминала Quik и его API. Данный терминал присутствует у большинства российских брокеров. Демо-доступ можно получить через поставщика ARQA Technologies.
              Да, практически к любому подключению можно получить демо-доступ. Ни одна биржа не заинтересована, чтобы на ее боевом API проводили стресс-тестирование)
                0
                Интегрироваться через квик это изврат) Я рассматриваю вариант не HFT, думаю, для начала (для дева и тестирования, как минимум) подойдёт деплой в AWS/Azure. Тащить туда QUIK это лишние проблемы.

                Раньше была идея сделать разработку публичной, но позже я от нее отказался
                Если не секрет — почему? Чтобы не плодить конкурентов или другие причины?
                  +1
                  Коммерческие ПО для алготрейдинга условно делится на два типа:
                  1) Профессиональный софт для крупных фондов и управляющих компаний.
                  2) Массовый продукт рассчитанный на околорыночников и жаждущих легких денег.
                  В первом случае софт стоит очень дорого, так как в него входит профессиональная поддержка, дорогая инфраструктура, команда разработчиков и т.д.
                  Во втором случае софт не дорогой и рассчитан на большой поток новых клиентов. Он специально упрощается, чтобы уменьшить порог вхождения. В нем легко на тестах строятся кривые доходности уходящие в небо, но системную алгоритмическую торговлю на нем построить очень сложно.
                  Была идея, что есть некая прослойка между первым и вторым классом, на которую и был ориентирован мой продукт. Но она оказалась на столько мала, что как публичный коммерческий продукт ее развивать оказалось нецелесообразно.
                  +1
                  Спаибо за статью очень познавательно.
                  Может подскажите пару вопросов:
                  1. Возможен ли Direct Access к NYSE для обычных смертных :) и сколько это стоит, нужна ли брокерская лицензия что бы на прямую совершать сделки на NYSE
                  2. Если не секрет можете немного описать свою торговую платформу:
                  — Есть ли там UI и для чего он используется (контроль робота, построение графиков, отображение сделок)
                  — какой тех. стек (что использовали для UI если он есть, и что на чем сам Trading Engine написан)

                  Я программист и начинающий трейдер, хочу начинать копать в сторону алготрейдинга, но пока исследую саму предметную область.
                    0
                    1. Для начала рекомендую воспользоваться услугами американского брокера, тот же IB. DMA для начинающего трейдера с высокой долей вероятности будет избыточен.
                    2. Это очень объемный вопрос) UI есть, написан на C#/WPF. Скорости работы более чем достаточно, но и не HFT. Все разбито на модули — визуализация, тестирование, оптимизация, работа с данными, исполнение и т.д. На разработку всего фреймворка у меня ушло около 4 лет.
                      0
                      Спасибо за ответ, жду продолжения статьи :)
                      Для инветсирования я использую TD Ameritrade брокера, у них очень мощный клиент для торговли thinkorswim с кучей инструментов для анализа, аля Photoshop в трейдинге. Пока исследую разных брокеров с точки зрения API что бы начать писать коннектор.
                      Было бы здорово если бы вы написали, какие источники информации использовали (тренинги, видео, книги) для изучения трейдинга и построения роботов.
                  0
                  Я пока более-менее близко видел два протокола сравнительно крупных брокеров (в США), у обоих проприетарные API, у одного еще и обязательный gateway на Java, который нужно перелогинивать раз в неделю.
                    0
                    Я так понимаю речь идет об Interactive Brokers. Да, это один из самых доступных брокеров на Америку. Коннекторы к IB Gateway и TWS не сложные. Правда с данными у них беда, нет тиков, только снепшоты.
                      0
                      Да, они. Но честно говоря, мне вот совсем не мечтается раз в неделю вручную заходить по расписанию и перетыкать логин в каком-то гейте, да еще на джаве, и ЕМНИП этому гейту еще UI нужен — как его на VPS-ке запустить адекватно? У того же TD Ameritrade тоже есть требования по релогину, но их можно обойти, если правильно использовать refresh tokens. В общем пока что IB не торт (хотя может быть я что-то не уловил).
                        0
                        Без гейта можно обойтись, если использовать FIX (правда становится он доступен после 1500 комиссий в месяц)
                        На VPS'ке вполне можно поднять что нибудь типа Xvnc, а проблема еженедельного рестарта решается при помощи IBController (правда двухфакторку придется отключить, поэтому лучше выделять отдельную учетку)
                    0

                    Можете попробовать того же Тинькова — там совсем всё просто с API. API свой собственный, но открытый. У них там целый раздел с документацией и кодом на гитхабе есть. И много денег это дело совсем не требует.

                      0
                      Пока не могу их рекомендовать. Для них этот бизнес новый, все очень сырое. Судя по API они ориентировались на криптобиржи с REST. Не самый надежный выбор.
                      Для алгоритмической торговли на MOEX лучше рассмотрите подключение через шлюз PLAZAII, будет одним из самых оптимальных решений.
                        0

                        Для серьёзной торговли — понятное дело, что не подходит: во время открытия или закрытия биржи безбожно тормозит и глючит. Но именно поиграться и забросить, либо перейти на что-то более серьёзное — сойдёт, т.к. порог вхождения крайне низкий:


                        • протокол очень простой;
                        • протокол универсальный для всех бирж;
                        • минимальные финансовые затраты;
                        • удобство подключения (а Т-банком тут очень многие пользуются).
                          0

                          25 мая с.г. МОЕХ выкатывает новую версию SPECTRA, и вот с ней-то покувыркаться придется. Ну, с partitioned matching. Совершенно уродское архитектурное решение, которое спихивает внутренние проблемы сведения заявок на разных серверах на пользователей PLAZA2.


                          Да, это верно что движок сведения заявок должен масштабироваться и заявки должны сводиться параллельно и одновременно на разных серверах. Так это делается, например, на NASDAQовском движке сведения. Но где сводятся заявки, клиента волновать не должно, он просто получает данные/отправляет заявки на биржу, а не по потоку репликации с суффиксом _MATCH{ID}. Вангую, что спустя полгода-год МОЕХ от этой идеи откажется.


                          DMA, который Вы предлагаете изучить и использовать, нужен только если анонимус будет делать HFT, а HFT — это еще и вложение в инфраструктуру. А это где-то под 1 млн рублей расходов, как минимум. Лучше 1.5~2 млн рублей.

                          0
                          HTTP/WS апи для фондового рынка и возможность писать ботов под любой язык/платформу, а не только под c#/windows — это впечатляющий прогресс, по сравнению с конкурентами. Но реализовано всё через одно место. Видно, что ни разработчики, ни их менеджер, в предметной области не разбираются от слова совсем. Вместо хорошо спроектированного апи у них какой-то случайный набор методов. Печально, что не нашлось нормального консультанта, который бы объяснил, что именно требуется алготрейдеру.
                        0

                        Кажется автор в теме, наверно даже знает толк в отключении ненужных ядер процессора.

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

                        Самое читаемое