Рыночные заявки
Рыночная заявка или заявка «по рынку» — распоряжение на совершение сделки на покупку/продажу указанного количества лотов финансового инструмента по текущей рыночной цене. Рыночной ценой при этом считается лучшая цена встречной заявки в биржевом стакане.
Общая информация
Рыночные заявки обладают рядом свойств, которые необходимо учитывать при ведении торгов с их помощью. В частности, следует помнить, что:
Рыночная заявка — это прямая заявка.
Прямые заявки передаются бирже без дополнительной обработки или ожидания дополнительных условий выставления со стороны торговой системы. Такие заявки видны всем участникам торгов и с момента выставления отражаются на состоянии биржевого стакана целевого финансового инструмента. Кроме того, средства (деньги/лоты), необходимые для выполнения прямой заявки, резервируются непосредственно в момент её выставления.
Рыночная заявка влияет на биржевой стакан, но не наполняет его.
В отличии от лимитных заявок, рыночная заявка не ставится в очередь на исполнение в биржевой стакан. Вместо этого такая заявка извлекает лучшее встречное предложение из стакана и поглощает его на тот объём, кото рый запрошен или доступен. Исключение составляют случаи, когда запрошенный объём превышает весь доступный объём встречных предложений.
Рыночная заявка имеет наибольшую вероятность исполнения.
Сделка по рыночной заявке совершается по текущей рыночной цене, что означает отсутствие необходимости ждать подходящего встречного предложения, как это бывает с лимитными заявками. Единственное условие, при котором рыночная заявка не будет выполнена в полном объёме — отсутствие на рынке достаточного объёма встречных предложений.
Участник торгов выставляет рыночную заявку на покупку (бид) 1000 лотов инструмента. Если общий объём встречных предложений (асков) в биржевом стакане больше этого значения — заявка будет выполнена. Если меньше — заявка будет выполнена частично или отменена в зависимости от выбранного значения timeInForce
.
Средняя цена лота может отличаться от лучшей цены лота на момент выставления заявки.
Рыночные заявки подвержены влиянию эффекта «проскальзывания» (slippage): если встречное предложение с лучшей ценой лота не позволяет полностью удовлетворить выставленную заявку, после его исчерпания будет задействовано следующее встречное предложение. Соответственно, цена следующего предложения станет новой лучшей ценой лота и сделка на остаток пройдёт по этой цене.
Участник торгов выставляет рыночную заявку на покупку (бид) 1000 лотов инструмента. Встречное предложение с лучшей ценой 300 рублей за лот содержит только 200 лотов. Следующее за ним предложение с ценой 301 рубль содержит 600 лотов. Третье предложение в стакане также содержит 600 лотов, но уже по цене 302 рубля. При выполнении заявки первые два предложения будут исчерпаны полностью, а третье — на объём остатка после первых двух. Сделки будут заключаться по цене встречных предложений, из-за чего средняя цена лота в такой заявке будет равна 301 рублю вместо 300 рублей цены, бывшей лучшей на момент выставления заявки.
Выставляемая рыночная заявка должна быть обеспечена в соответствии с уровнем риска клиента и подходом к ведению торгов:
При немаржинальной торговле обеспечение заявки составляет полную стоимость заявки с надбавкой в 5% на случай изменения цены;
Для маржинальной торговли обеспечение зависит от уровня риска клиента с надбавкой в 1% от этой суммы на случай изменения цены.
Убедиться в достаточности средств можно с помощью запроса на оценку заявки. Ознакомиться с условиями обеспечения заявки в зависимости от уровня риска можно здесь.
Рыночные заявки стоит рассматривать как практически гарантированный способ заключить сделку по выбранному инструменту любой ценой и быстро.
Если этот подход не соответствует используемой торговой стратегии, рекомендуем воспользоваться лимитными заявками для заключения сделок по желаемой цене.
Условия выполнения
Основным условием выполнения заявки является параметр 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"
}