Перейти к основному содержимому

Стоп-заявки

Стоп-заявки — распоряжение брокеру на выставление рыночной или лимитной заявки на бирже только при достижении определённых условий.

Общая информация​

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

Стоп-заявка — это условная заявка.

Стоп-заявки стоит рассматривать как промежуточный этап выставления прямых заявок.

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

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

Заявки, следующие за условными, подчиняются всем требованиям к прямым заявкам.

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

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

Вложенность условных заявок ограничена.

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

Группы заявок

Это ограничение можно частично обойти, объединив несколько заявок в группу.

Ограничение по цене работает в обе стороны.

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

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

  • Стоп-лосс (Stop loss) — цена в заявке менее выгодная, чем текущая рыночная. Такая заявка позволяет участнику торгов совершить сделку с теми потерями, с которыми он готов согласиться. Например, выставить рыночную заявку на продажу инструмента при падении рынка по той цене, по которой потери будут минимальными.

Особенности реализации

В API других торговых систем для создания тейк-профит и стоп-лосс заявок могут использоваться запросы к разным ресурсам. В АЛОР Брокер API оба типа заявок создаются одной и той же командой, тип заявки при этом определяется направлением сделки и условием срабатывания.

Условные заявки могут «вынести».

При выставлении цены срабатывания участники торгов опираются на текущую динамику торгов, в связи с чем отклонение цены срабатывания от текущей рыночной цены зачастую довольно мало. Этим могут воспользоваться крупные игроки, способные спровоцировать ложный «пробой» ценового уровня, при котором рыночная цена совершает кратковременный, но всё же существенный скачок. Это приведёт к срабатыванию всех стоп-заявок, попавших в ценовой диапазон скачка. Ложный «пробой» имеет кратковременный характер и цена достаточно быстро возвращается в прежнее положение, но последствия от такого скачка могут быть достаточно серьёзными в зависимости от выбранного для выставления типа биржевой заявки. Если лимитные заявки при должной сноровке и своевременном обнаружении скачка можно успеть отменить до исполнения, рыночные заявки будут незамедлительно выполнены по невыгодной цене, зачастую превышая те потери, на которые трейдер был готов.

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

Группы заявок

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

Обеспечение заявки

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

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

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

Условия выполнения​

Срок действия

Благодаря тому, что условные заявки существуют только на серверах Брокера, их срок действия не ограничен биржей и может составлять несколько часов, дней, недель, месяцев или лет. В торговой системе АЛОР Брокер для указания срока действия используется параметр stopEndUnixTime, передаваемый в теле запроса. В качестве значения указывается дата завершения заявки в формате Unix-времени, тип данных int64.

Пример значения
{
  "stopEndUnixTime": 1735689599 // 31.12.2024 23:59:59 UTC
}

Цена срабатывания

Чтобы условная заявка сработала, цена на инструмент должна достигнуть определённого значения. В торговой системе АЛОР Брокер для указания значения цены используется параметр triggerPrice, передаваемый в теле запроса. В качестве значения указывается желаемая цена за лот в валюте расчётов, тип данных decimal. Если значение дробное, в качестве делителя указывается точка («.»).

Так, если условная заявка должна сработать при достижении цены лота значения 350 рублей 86 копеек, значение параметра должно быть следующим:

Пример значения
{
  "triggerPrice": 350.86
}

Условие срабатывания

Чтобы определить тип заявки (тейк-профит или стоп-лосс), помимо цены срабатывания также должно быть задано условие срабатывания относительно этой цены. В торговой системе АЛОР Брокер для этого используется параметр condition, передаваемый в теле запроса. В качестве значения указывается один из четырёх строковых вариантов, поддерживаемых системой:

  • More — Больше указанной цены
  • MoreOrEqual — Больше или равно указанной цены
  • LessOrEqual — Меньше или равно указанной цены
  • Less — Меньше указанной цены

Так, если условная заявка должна сработать, когда цена опустится до значения 350 рублей 86 копеек или ниже, значение параметра должно быть следующим:

Пример значения
{
  "triggerPrice": 350.86,
  "condition": "LessOrEqual"
}

Примеры запросов​

Общие требования​

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

  • Быть авторизованными
  • Быть идентифицируемыми
  • Содержать сообщение со всеми необходимыми характеристиками заявки

От протокола взаимодействия же зависит, как эти условия соблюсти.

Авторизация

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

В HTTP API для передачи токена используется параметр заголовка Authorization. Заголовок должен передаваться с каждым выполняемым запросом.

Передаётся этот токен как Bearer-токен, в связи с чем заголовок должен содержать префикс Bearer перед передаваемым значением. Выглядит корректно заполненный заголовок Authorization так:

Authorization: Bearer eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImN0eSI6IkpXVCJ9.eyJzdWIiOiJMb2dpblNhbXBsZSIsImVudCI6ImNsaWVudCIsImVpbiI6IjAxMjM0IiwiY2xpZW50aWQiOiIwMTIzNDU2IiwiYXpwIjoiMDEyMzQ1Njc4OWFiY2RlZjAxMjMiLCJhZ3JlZW1lbnRzIjoiQWdyZWVtZW50U2FtcGxlMSBBZ3JlZW1lbnRTYW1wbGUyIEFncmVlbWVudFNhbXBsZTMiLCJwb3J0Zm9saW9zIjoiUG9ydGZvbGlvU2FtcGxlMSBQb3J0Zm9saW9TYW1wbGUyIFBvcnRmb2xpb1NhbXBsZTMiLCJzY29wZSI6Ik9yZGVyc1JlYWQgT3JkZXJzQ3JlYXRlIFRyYWRlcyBQZXJzb25hbCBTdGF0cyIsImV4cCI6Mjg3MTc2MzE5OSwiaWF0IjowLCJpc3MiOiJBbG9yLklkZW50aXR5IiwiYXVkIjoiQ2xpZW50IFdBUlAgV2FycEFUQ29ubmVjdG9yIHN1YnNjcmlwdGlvbnNBcGkgQ29tbWFuZEFwaSBJbnN0cnVtZW50QXBpIFRyYWRpbmdWaWV3UGxhdGZvcm0ifQ.QOQVMIAoZ6SnF5urnIzJ0EvtQd9P5Sx355069kXoID207wHOTW0wkKNMcrIKXmENEQQ_0yDjqH_kjeqWLBJuqA

Идентификация

Идентификация запроса нужна для разделения десятка однотипных запросов на уникальные. Идентификатор задаётся со стороны пользователя и передаётся в виде значения параметра заголовка X-REQID, в связи с чем рекомендуем предусмотреть механизм его генерации в используемом ПО.

В качестве идентификатора запроса можно использовать любую символьную комбинацию, включая специальные символы !@№;%:?*()-_=+/|"'. На идентификатор действуют два ограничения:

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

  • Спец.символы, нарушающие целостность JSON объекта, должны быть экранированы

Таким образом, в качестве идентификатора запроса система готова принять как Dxxxxx-Order-Market-No-812643-@-MOEX, так и d3c886f1-ea1e-4634-aff4-119c902ad926 при условии, что эти значения не передавались ни одним из пользователей API ранее.

Корректно заполненный заголовок X-REQID не требует дополнительных префиксов и выглядит следующим образом:

X-REQID: d3c886f1-ea1e-4634-aff4-119c902ad926

Управление заявками​

Взаимозаменяемость запросов

Способы создания заявок взаимозаменяемы. Например, заявку, выставленную через HTTP API, можно изменить или снять через WebSocket API, и наоборот.

Выставление заявки

Интерактивный запрос

Интерактивное описание запроса доступно на странице Создание рыночной стоп-заявки

Для создания стоп-заявки с последующим выставлением на биржу рыночной заявки через HTTP API используется POST-запрос к конечной точке /commandapi/warptrans/TRADE/v2/client/orders/actions/stop.

Полный URL конечной точки выглядит так:

https://api.alor.ru/commandapi/warptrans/TRADE/v2/client/orders/actions/stop
https://apidev.alor.ru/commandapi/warptrans/TRADE/v2/client/orders/actions/stop

В теле сообщения необходимо указать характеристики как стоп-заявки, так и рыночной заявки:

Пример тела запроса
{
// Параметры стоп-заявки:
  "condition": "MoreOrEqual",
  "triggerPrice": 350.86,
  "stopEndUnixTime": 1735678799,
  "activate": true,
// Параметры рыночной заявки
  "side": "sell",
  "quantity": 100,
  "instrument": {
    "symbol": "SBER",
    "exchange": "MOEX",
    "instrumentGroup": "TQBR"
  },
  "user": {
    "portfolio": "D39004"
  }
}
Ожидаемый результат

Создана стоп-заявка, в результате срабатывания которой должна быть выставлена на биржу рыночная заявка на продажу 100 лотов инструмента SBER на Московской Бирже (MOEX) в режиме T+2 (TQBR) по той цене, которая является лучшей ценой лота в момент исполнения.

Стоп-заявка сработает, если рыночная цена лота будет равна или превысит значение 350 рублей 86 копеек, или отменится, если условие не будет выполнено до 31 декабря 2024 года 23:59:59 UTC.

В случае успешного выполнения запроса API вернёт сообщение с кодом ответа 200, содержащее в себе биржевой номер заявки:

Пример тела ответа
{
  "message": "success",
  "orderNumber": "189...559"
}

Если обработка запроса завершилась ошибкой, API вернёт информацию о причинах этой ошибки.

Параметры запроса

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

Изменение заявки

Интерактивный запрос

Интерактивное описание запроса доступно на странице Изменение рыночной стоп-заявки

Для изменения ранее выставленной рыночной стоп-заявки через HTTP API используется PUT-запрос к той же конечной точке с добавлением Path-параметра {stopOrderId}, заменяемого при выполнении запроса номером заявки.

Изменение заявки

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

Полный URL конечной точки выглядит так:

https://api.alor.ru/commandapi/warptrans/TRADE/v2/client/orders/actions/stop/189...559
https://apidev.alor.ru/commandapi/warptrans/TRADE/v2/client/orders/actions/stop/189...559

Где 189...559 — фактическое значение параметра {stopOrderId}.

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

Пример тела запроса
{
// Параметры стоп-заявки:
  "condition": "MoreOrEqual",
  "triggerPrice": 330.15,
  "stopEndUnixTime": 1719781199,
  "activate": true,
// Параметры рыночной заявки
  "side": "sell",
  "quantity": 50,
  "instrument": {
    "symbol": "SBER",
    "exchange": "MOEX",
    "instrumentGroup": "TQBR"
  },
  "user": {
    "portfolio": "D39004"
  }
}
Ожидаемый результат

Заявка с номером 189...559 отменена. Создана новая стоп-заявка, в результате срабатывания которой должна быть выставлена на биржу рыночная заявка на продажу 50 лотов инструмента SBER на Московской Бирже (MOEX) в режиме T+2 (TQBR) по той цене, которая является лучшей ценой лота в момент исполнения.

Изменённая стоп-заявка сработает, если рыночная цена лота будет равна или превысит значение 330 рублей 15 копеек, или отменится, если условие не будет выполнено до 30 июня 2024 года 23:59:59 UTC.

В случае успешного выполнения запроса прежняя заявка будет отменена и API вернёт сообщение с кодом ответа 200, содержащее в себе биржевой номер новой заявки:

Пример тела ответа
{
  "message": "success",
  "orderNumber": "189...560"
}

Если обработка запроса завершилась ошибкой, API вернёт информацию о причинах этой ошибки.

Параметры запроса

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

Снятие заявки

Интерактивный запрос

Интерактивное описание запроса доступно на странице Снятие заявки

Отмена заявки

Отменить можно только ожидающую исполнения заявку. Отмена исполненной заявки невозможна.

Для снятия ранее выставленной стоп-заявки через HTTP API используется DELETE-запрос к конечной точке /commandapi/warptrans/TRADE/v2/client/orders/{orderId}, где {orderId} — Path-параметр, в котором передаётся номер заявки.

Помимо номера заявки необходимо также указать следующие атрибуты заявки:

Query-параметры

    portfolio stringrequired

    Идентификатор клиентского портфеля

    Example: D39004
    exchange stringrequired

    Possible values: [MOEX]

    Биржа

    stop booleanrequired

    Является стоп-заявкой?

    Example: true
Внимание к параметрам

Для снятия стоп-заявок используется тот же запрос, что и для снятия биржевых заявок. Отличие заключается в значении параметра stop: для биржевых заявок значение должно быть false, для стоп-заявок — true.

Полный URL запроса для снятия заявки выглядит так:

https://api.alor.ru/commandapi/warptrans/TRADE/v2/client/orders/189...560?portfolio=D39004&exchange=MOEX&stop=true
https://apidev.alor.ru/commandapi/warptrans/TRADE/v2/client/orders/189...560?portfolio=D39004&exchange=MOEX&stop=true
Ожидаемый результат

Заявка с номером 189...560 отменена.

В случае успешного выполнения запроса прежняя заявка будет отменена и API вернёт сообщение с кодом ответа 200:

success

Если обработка запроса завершилась ошибкой, API вернёт информацию о причинах этой ошибки.

Параметры запроса

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

Группы заявок

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

Что дальше?​

Для быстрого погружения в процессы использования API можете воспользоваться руководствами по быстрому старту для тестового и боевого контуров системы.