Лимитные заявки
Лимитная заявка — распоряжение на совершение сделки на покупку/продажу заданного количества лотов финансового инструмента по той цене, которую выставивший заявку участник торгов считает приемлемой.
Общая информация
Лимитные заявки обладают рядом свойств, которые необходимо учитывать при ведении торгов с их помощью. В частности, следует помнить, что:
Лимитная заявка — это прямая заявка.
Прямые заявки передаются бирже без дополнительной обработки или ожидания дополнительных условий выставления со стороны торговой системы. Такие заявки видны всем участникам торгов и с момента выставления отражаются на состоянии биржевого стакана целевого финансового инструмента. Кроме того, средства (деньги/лоты), необходимые для выполнения прямой заявки, резервируются непосредственно в момент её выставления.
Лимитная заявка напрямую формирует биржевой стакан.
Биржевой стакан — это буквально список лимитных заявок, ожидающих исполнения по заданной цене. Когда выставляется лимитная заявка, она помещается в очередь на исполнение в ожидании встречного предложения с такой же ценой. Заявки на продажу будут завышать цену от текущей лучшей цены, заявки на покупку — наоборот. Наиболее близкие друг к другу по цене заявки определяют текущую рыночную цену лота, по которой будут совершаться сделки по рыночным заявкам.
Лимитная заявка может остаться неисполненной.
Если рыночная заявка исполняется незамедлительно по текущей лучшей цене лота, лимитная заявка ожидает исполнения по той цене, которая была указана при выставлении. Если за всё время существования заявки не было встречных предложений, совпадающих по цене с выставленной заявкой, такая заявка останется неисполненной и впоследствии будет отменена.
Участник торгов выставляет лимитную заявку на покупку (бид) 1000 лотов инструмента по цене 300 рублей. Текущая лучшая цена лота 301 рубль. Если рынок проявит тенденцию на рост и лучшая цена лота будет увеличиваться, заявка с непривлекательной для других участников торгов ценой останется неисполненной и возможность заключения выгодной сделки будет упущена. Во избежание таких ситуаций рекомендуется пользоваться стоп-заявками и объединять их с лимитными заявками в группы.
Биржа может ограничивать цену лимитной заявки.
В целях контроля агрессивности выставляемых заявок биржа может вводить ограничения по минимальной и максимальной цене лота. Такое ограничение рассчитывается от лучшей цены лота на момент выставления заявки и предназначено для защиты инвесторов от возможных ошибок при заключении сделок. Условия ограничения определяются самой биржей и могут различаться для разных рынков.
Для рынка акций на Московской Бирже действует ограничение на предельную цену в 5% от текущей лучшей цены инструмента. Если текущая лучшая цена инструмента равна 300 рублям, заявки с ценами 315.01 и 284.99 будут автоматически отклонены биржей как избыточно агрессивные.
Выставляемая лимитная заявка должна быть обеспечена в соответствии с уровнем риска клиента и подходом к ведению торгов:
При немаржинальной торговле обеспечение заявки составляет полную стоимость заявки;
Для маржинальной торговли обеспечение зависит от уровня риска клиента.
Убедиться в достаточности средств можно с помощью запроса на оценку заявки. Ознакомиться с условиями обеспечения заявки в зависимости от уровня риска можно здесь.
Лимитные заявки стоит рассматривать как возможность заключения сделки по желаемой цене (в рамках определённых границ), но без гарантий заключения сделки.
Если этот подход не соответствует используемой торговой стратегии, рекомендуем воспользоваться рыночными заявками для повышения вероятности заключения сделки.
Условия выполнения
Основным условием выполнения заявки является параметр timeInForce
, регулирующий обработку остатка заявки после исчерпания всех встречных предложений рынка. Возможные значения:
Условие | Описание |
---|---|
oneday | Заявка действительна в течение торгового дня. Если встречная заявка с подходящей ценой содержит недостаточный для полного выполнения заявки объём, неиспользованный остаток останется позицией в стакане до полного выполнения заявки, её отмены или завершения торгового дня, в рамках которого была выставлена заявка. |
goodtillcancelled | Аналогично |
immediateorcancel | Заявка выполняется на доступный на момент выставления объём, остаток снимается с торгов. |
fillorkill | Заявка может быть выполнена только полностью. Если доступный объём не позволяет выполнить заявку, она не будет выставлена вовсе. |
Примеры запросов
Общие требования
Заявку через API можно выставить на исполнение, изменить и снять с исполнения, если она не была выполнена ранее. При этом, независимо от выбранного действия и протокола взаимодействия, все запросы должны:
- Быть авторизованными
- Быть идентифицируемыми
- Содержать сообщение со всеми необходимыми характеристиками заявки
От протокола взаимодействия же зависит, как эти условия соблюсти.
- HTTP API
- WebSocket API
Авторизация
Авторизация нужна для подтверждения у отправителя наличия прав на использование запрошенного ресурса. Для авторизации запросов используется JWT токен, выполняющий роль Access токена. Полное описание доступных способов авторизации представлено в разделе Авторизация.
В HTTP API для передачи токена используется параметр заголовка Authorization
. Заголовок должен передаваться с каждым выполняемым запросом.
Передаётся этот токен как Bearer-токен, в связи с чем заголовок должен содержать префикс Bearer
перед передаваемым значением. Выглядит корректно заполненный заголовок Authorization
так:
Authorization: Bearer eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImN0eSI6IkpXVCJ9.eyJzdWIiOiJMb2dpblNhbXBsZSIsImVudCI6ImNsaWVudCIsImVpbiI6IjAxMjM0IiwiY2xpZW50aWQiOiIwMTIzNDU2IiwiYXpwIjoiMDEyMzQ1Njc4OWFiY2RlZjAxMjMiLCJhZ3JlZW1lbnRzIjoiQWdyZWVtZW50U2FtcGxlMSBBZ3JlZW1lbnRTYW1wbGUyIEFncmVlbWVudFNhbXBsZTMiLCJwb3J0Zm9saW9zIjoiUG9ydGZvbGlvU2FtcGxlMSBQb3J0Zm9saW9TYW1wbGUyIFBvcnRmb2xpb1NhbXBsZTMiLCJzY29wZSI6Ik9yZGVyc1JlYWQgT3JkZXJzQ3JlYXRlIFRyYWRlcyBQZXJzb25hbCBTdGF0cyIsImV4cCI6Mjg3MTc2MzE5OSwiaWF0IjowLCJpc3MiOiJBbG9yLklkZW50aXR5IiwiYXVkIjoiQ2xpZW50IFdBUlAgV2FycEFUQ29ubmVjdG9yIHN1YnNjcmlwdGlvbnNBcGkgQ29tbWFuZEFwaSBJbnN0cnVtZW50QXBpIFRyYWRpbmdWaWV3UGxhdGZvcm0ifQ.QOQVMIAoZ6SnF5urnIzJ0EvtQd9P5Sx355069kXoID207wHOTW0wkKNMcrIKXmENEQQ_0yDjqH_kjeqWLBJuqA
Идентификация
Идентификация запроса нужна для разделения десятка однотипных запросов на уникальные. Идентификатор задаётся со стороны пользователя и передаётся в виде значения параметра заголовка X-ALOR-REQID
, в связи с чем рекомендуем предусмотреть механизм его генерации в используемом ПО.
В качестве идентификатора запроса можно использовать любую символьную комбинацию, включая специальные символы !@№;%:?*()-_=+/|"'
. На идентификатор действуют два ограничения:
Значение идентификатора должно быть уникальным для торговой системы. Если значение ранее уже использовалось для другого запроса, вместо повторного выполнения будет возвращена копия ответа на первый запрос с этим идентификатором
Спец.символы, нарушающие целостность JSON объекта, должны быть экранированы
Таким образом, в качестве идентификатора запроса система готова принять как Dxxxxx-Order-Market-No-812643-@-MOEX
, так и d3c886f1-ea1e-4634-aff4-119c902ad926
при условии, что эти значения не передавались ни одним из пользователей API ранее.
Корректно заполненный заголовок X-ALOR-REQID
не требует дополнительных префиксов и выглядит следующим образом:
X-ALOR-REQID: d3c886f1-ea1e-4634-aff4-119c902ad926
Соединение
Все запросы на управление заявками через WebSocket API, независимо от типа заявки и запрашиваемой операции, выполняются через интерфейс /cws
. Перед отправкой запроса установите WebSocket-соединение с этим интерфейсом.
Полный URL интерфейса:
Авторизация
Авторизация нужна для подтверждения у отправителя наличия прав на использование запрошенного ресурса. Для авторизации запросов используется JWT токен, выполняющий роль Access токена. Полное описание доступных способов авторизации представлено в разделе Авторизация.
В WebSocket API для передачи токена используется отдельный запрос к интерфейсу /cws с кодом операции authorize
. Запрос достаточно выполнять раз в 15-20 минут для авторизации всех последующих запросов в рамках того же WebSocket-соединения.
Установите соединение с нужным контуром системы и отправьте сообщение с кодом операции authorize
и действительным Access токеном в качестве значения параметра token
:
{
"opcode": "authorize",
"guid": "c328fcf1-e495-408a-a0ed-e20f95d6b813",
"token": "eyJhbGciOiJ..."
}
Если запрос сформирован корректно, в ответ вернётся сообщение с кодом 200, подтверждающее авторизацию соединения:
{
"requestGuid": "c328fcf1-e495-408a-a0ed-e20f95d6b813",
"httpCode": 200,
"message": "The connection has been initialized."
}
Параметр guid
отвечает за идентификацию сообщения и описан ниже.
Идентификация
Идентификация запроса нужна для разделения десятка однотипных запросов на уникальные. Идентификатор задаётся со стороны пользователя и передаётся в виде значения параметра guid
в теле сообщения, в связи с чем рекомендуем предусмотреть механизм его генерации в используемом ПО.
В качестве идентификатора запроса можно использовать любую символьную комбинацию, включая специальные символы !@№;%:?*()-_=+/|"'
. На идентификатор действуют два ограничения:
Значение идентификатора должно быть уникальным для торговой системы. Если значение ранее уже использовалось для другого запроса, вместо повторного выполнения будет возвращена копия ответа на первый запрос с этим идентификатором
Спец.символы, нарушающие целостность JSON объекта, должны быть экранированы
Таким образом, в качестве идентификатора запроса система готова принять как Dxxxxx-Order-Market-No-812643-@-MOEX
, так и d3c886f1-ea1e-4634-aff4-119c902ad926
при условии, что эти значения не передавались ни одним из пользователей API ранее.
Корректно заполненный параметр guid
не требует дополнительных префиксов и выглядит следующим образом:
{
"guid": "d3c886f1-ea1e-4634-aff4-119c902ad926"
}