Система управления заказами (OMS) — это программное обеспечение, которое отслеживает торговые заказы с момента, когда кто-то решает торговать, до момента, когда результат достигает счетов. Она фиксирует, что было запрошено, проверяет, разрешен ли заказ, отправляет его на исполнение и отслеживает все, что происходит с ним после этого.
Каждый заказ вызывает три вопроса, и OMS — это место, где находятся ответы: Что мы намеревались продать? Что на самом деле было продано? Что еще требует действий?
То, что предполагалось, и то, что фактически было продано, часто различаются. Представьте запрос на покупку 1 000 акций. Первые 400 акций покупаются, а затем покупатель просит отменить остальные. Пока этот запрос в пути, покупаются еще 150 акций. Заказ в конечном итоге помечается как “Отменен”, но 550 акций было куплено. Хорошая OMS показывает полную историю, стоящую за этим однословным статусом, и этот гид объясняет, как.
Короче говоря:
- OMS является центральной записью торговых заказов: что было запрошено, для кого и что с ним произошло.
- Он проверяет каждый заказ перед отправкой, затем отслеживает подтверждения, выполненные сделки, изменения и отмены.
- Он сам не выполняет сделки. Это делают брокеры и биржи, а OMS поддерживает порядок записей.
- Его временная история является одной из основных записей, которые фирмы и регуляторы используют для восстановления любого заказа позже.
Что такое система управления заказами?
На финансовых рынках OMS управляет заказами на акции, облигации, валюты, деривативы и другие инструменты. Это название также используется для программного обеспечения, которое онлайн-магазины используют для обработки поставок, но торговый OMS – это другой инструмент с другой задачей.
Думайте об этом как о журнале и контрольном пункте для заказов. Каждая сделка проходит через подобные этапы, независимо от того, начинается ли она с менеджера фонда, размещающего крупный заказ для пенсионного фонда, или с того, кто нажимает “Купить” в торговом приложении. В профессиональных компаниях OMS — это система, которая организует эти этапы. В потребительском торговом приложении те же функции обычно выполняются внутри платформы брокера, вне поля зрения.
Ключевые особенности торговой OMS
- Фиксация заказа: записывает аккаунт, инструмент, направление покупки или продажи, количество, тип заказа, цену и срок действия заказа.
- Проверки перед торговлей: подтверждает, что заказ разрешен, что аккаунт может его позволить и что он соответствует торговым лимитам.
- Маршрутизация: отправляет одобренные заказы брокеру, системе исполнения или торговой площадке.
- Отслеживание заказов: ведет живую запись подтверждений, выполнений, изменений и отмен.
- Управление позицией: обновляет активы и наличные по мере поступления сделок, чтобы следующий заказ проверялся на основе актуальных данных.
- Распределение: делит большой исполненный заказ между счетами, на которые он был размещен, когда это необходимо.
- Аудиторский след: хранит временную историю каждого события, так что любой может позже точно воссоздать, что произошло.
- Передача после торговли: передает результаты в бухгалтерские и операционные системы.
Некоторые продукты OMS являются отдельными приложениями. Другие встроены в более крупную торговую платформу.
Ключевые термины на простом английском
| Термин | Что это значит |
|---|---|
| Ордер | Инструкция купить или продать определенное количество инструмента |
| Место торговли | Место, где ордера сопоставляются, например, фондовая биржа |
| Исполнение | Сделка, которая выполняет все или часть ордера |
| Частичное исполнение | Торговля только частью количества до сих пор |
| Рабочее количество | Часть ордера, которая все еще ждет исполнения |
| Рыночный ордер | Ордер на торговлю как можно скорее по лучшей доступной цене |
| Лимитный ордер | Ордер, который может быть исполнен только по указанной цене или лучше |
| Срок действия | Как долго ордер остается активным, например, на один день или до отмены |
| Подтверждение | Подтверждение от принимающей стороны о том, что она приняла ордер |
| Изменение | Запрос на изменение ордера, например, его цены или количества |
| Отмена | Запрос на остановку количества, которое еще не было исполнено |
| Ожидающая отмена | Отмена была запрошена, но еще не подтверждена; ордер все еще может торговать |
| Отклонено | Ордер был отклонен, либо внутренними проверками фирмы, либо принимающей стороной |
| Истекло | Ордер достиг конца своего срока действия без полного исполнения |
| Распределение | Разделение исполненного ордера между несколькими счетами |
| Клиринг и расчет | Шаги после сделки, которые подтверждают, кто кому что должен, и затем обменивают ценные бумаги и наличные |
Как работает система управления заказами, шаг за шагом
Where the OMS sits
Orders go out through the OMS; confirmations and fills come back to it; results go on to the back office. Shown from a fund manager’s point of view. In a trading app, the broker runs the OMS.
- Order sourceInvestor, fund manager, algorithm or app
- OMSRecords, checks and tracks the order
- ExecutionBroker, EMS or smart order router
- Trading venueExchange or other venue matches orders
- ↑ Confirmations and fills flow back to the OMS
- Post-tradeThe OMS passes results to the back office, which works with clearing and settlement
1. Заказ введен
Заказ может поступать от человека, системы управления портфелем, торгового алгоритма или другой программы, подключенной через API (интерфейс программирования приложений). OMS сначала должно точно знать, что запрашивается.
«Купить 1,000 XYZ по $25» само по себе недостаточно. OMS также необходимо знать, для какого аккаунта предназначен заказ, какой именно инструмент имеется в виду (один и тот же тикер может существовать на нескольких рынках), валюту и как долго заказ остается действительным. Заказ на день истекает в конце торгового дня; заказ типа «действителен до отмены» продолжает действовать, пока не будет исполнен или отменен, хотя многие брокеры устанавливают максимальный срок.
Система OMS присваивает заказу идентификатор. Каждый последующий заполнение, изменение и отмена связаны с этим идентификатором. Без этой связи команда операций могла бы получить действительную сделку и не знать, к какой инструкции она относится.
2. Заказ проверен
Перед отправкой чего-либо OMS проводит предварительные проверки торговли, либо самостоятельно, либо через подключенные службы управления рисками и соблюдения норм. Типичные проверки охватывают:
- может ли аккаунт торговать этим инструментом,
- достаточно ли у него наличных или маржи (денег, заимствованных у брокера),
- соответствует ли размер и цена установленным пределам,
- является ли инструмент в ограниченном списке, например, потому что компания располагает конфиденциальной информацией о компании.
Количество открытых заказов также учитывается. Учетная запись может иметь достаточно денег для одного заказа, но не для двух аналогичных заказов, размещенных в один и тот же момент. Хорошие проверки учитывают заказы, которые все еще ждут, а не только сделки, которые уже произошли.
Проверки на соответствие также могут проводиться после сделки, чтобы подтвердить, что результат остался в рамках правил. Когда проверка не проходит до сделки, отказ должен объяснять причины. “Инструмент не разрешен для этого счета” можно исправить за считанные минуты. “Заказ не выполнен” заставляет кого-то копаться в журналах.
3. Заказ отправлен и подтверждён
Одобренные заказы направляются в их пункт назначения: брокеру, системе управления исполнением, интеллектуальному маршрутизатору заказов или прямому соединению с торговой площадкой.
Отправка заказа и его принятие — это два отдельных события. OMS записывает свою собственную подачу, а затем ждет, пока другая сторона подтвердит или отклонит ее. Если большой заказ разбивается на меньшие “дочерние” заказы, OMS сохраняет их связь с оригинальным “родительским”, чтобы иметь возможность проверять, чтобы дочерние заказы никогда не превышали сумму родительского.
Заказы передаются между системами в виде сообщений, часто через торговый API или стандартный протокол FIX. OMS считывает эти сообщения и обновляет статус и количество каждого заказа.
4. Заполнение, изменения и отмены отслеживаются
Заполнение увеличивает количество купленных или проданных единиц и может оставить часть заказа все еще действующим. Изменение запрашивает изменение заказа. Отмена запрашивает остановку всего, что еще не было продано.
Ни изменение, ни отмена не вступают в силу в момент их отправки. Пока другая сторона не подтвердит это, оригинальный ордер может продолжать торговлю. Спецификация состояния ордеров FIX, которой следуют многие торговые системы, имеет отдельный статус “ожидает отмены” именно по этой причине. Она также позволяет отмененному ордеру содержать исполненные сделки. Один только статус не говорит вам, сколько было сделано; количества говорят об этом.
5. Результаты поступают в постторговые системы
После завершения торговли OMS передает данные о сделках, деталях аккаунтов и идентификаторов в бэк-офисные системы. Затем операционная команда проверяет эти записи на соответствие с подтверждениями от брокеров, площадок и клиринговых компаний.
Для управляющего фондом, который купил акции для нескольких портфелей одновременно, это также момент, когда выполненное количество распределяется по каждому портфелю согласно заранее согласованным правилам.
Исполнение сделки не является тем же самым, что и ее расчет. На рынках ценных бумаг расчет — это фактический обмен ценными бумагами и наличными, который осуществляется инфраструктурой клиринга и расчета. OMS предоставляет данные об аккаунте и распределении, используемые в этом процессе; он не удерживает активы и не завершает расчет самостоятельно. Например, акции США рассчитываются через один рабочий день после сделки (T+1).
Пример: частично заполненный заказ, который отменяется
Вот порядок из введения в деталях. Это гипотетический пример: купить 1,000 акций XYZ с лимитом в $25, действительным в течение дня. Счет начинается без акций XYZ, все проверки проходят, и комиссии не учитываются.
- Брокер принимает заказ. 400 акций торгуются по $24.98, и 600 все еще в работе.
- Покупатель запрашивает отмену оставшейся части. Отмена сейчас находится в ожидании.
- Перед подтверждением 150 дополнительных акций торгуются по цене $24.99.
- Брокер подтверждает отмену оставшихся 450 акций.
Follow the cancellation
An illustrative buy order for 1,000 shares. A cancellation stops the remaining quantity; it does not reverse existing fills.
Order status: Canceled
- Shares filled
- 550
- Still working
- 0
- Canceled
- 450
The remaining 450 shares are canceled. The 550 shares already bought remain in the account. No quantity is still working.
Read the complete sequence
- First fill: 400 shares trade at $24.98. Another 600 are still working.
- Cancel requested: a cancellation is pending. The 600 remaining shares can still execute.
- Another fill: 150 more shares trade at $24.99 before cancellation is confirmed. Filled quantity is now 550; 450 remain working.
- Cancel confirmed: those 450 shares are canceled. The final result is 550 bought, 450 canceled and none working.
Конечный результат:
- Куплено: 550 акций
- Отменено без торговли: 450 акций
- Все еще работает: 0 акций
- Общая стоимость: (400 × $24.98) + (150 × $24.99) = $13,740.50
- Средняя цена: $13,740.50 ÷ 550 ≈ $24.9827
Аннулированные акции не влияют на среднюю цену, поскольку они никогда не торговались. Отмена также не отменяет 550 акций, уже купленных.
Если покупатель все еще хочет 1,000 акций в общем, оставшаяся разница составляет 450. Кто-то, кто смотрел только на первое исполнение и отправил новый заказ на 600, в конечном итоге получит 1,150 акций, если этот заказ будет полностью исполнен.
Если бы покупатель никогда не попросил отменить, неиспользованные акции просто истекли бы к закрытию, потому что это был дневной ордер.
Настоящие системы могут обозначать эти шаги по-разному или пропускать некоторые промежуточные сообщения, но количества всегда должны суммироваться: заполненные + еще работающие + отмененные (или истекшие) должны равняться текущему количеству заказа, включая любые изменения.
OMS против EMS и других торговых систем
Несколько систем могут обрабатывать один и тот же заказ, и один продукт может сочетать несколько ролей.
| Система | Основная задача | На какой вопрос отвечает |
|---|---|---|
| PMS (система управления портфелем) | Отслеживает портфели и решает, что купить или продать, например, при ребалансировке | Что мы должны торговать? |
| OMS | Записывает заказы, проводит проверки, отслеживает статус и передает результаты в операции | Что было заказано, на какой счет и каково текущее состояние? |
| EMS (система управления исполнением) | Предоставляет трейдерам инструменты для работы с заказами на рынке, часто с использованием актуальных данных и алгоритмов | Как мы должны исполнить этот заказ прямо сейчас? |
| OEMS | Объединяет функции OMS и EMS в одной системе | Оба вышеупомянутых в одном месте |
| Умный маршрутизатор заказов | Выбирает, куда отправить заказ, основываясь на правилах маршрутизации | Какой площадке следует получить этот заказ? |
| Система сопоставления | Сопоставляет заказы на покупку и продажу внутри торговой площадки | Какие заказы могут торговать друг с другом? |
| Бэк-офис | Обрабатывает бухгалтерский учет, записи и сверку | Согласованы ли все записи? |
Простой способ запомнить разницу: PMS решает что торговать, OMS отслеживает что было заказано и для кого, а EMS управляет как это выполняется. Умный маршрутизатор заказов решает куда его отправить, а механизм сопоставления связывает покупателей с продавцами внутри площадки.
Кто использует систему управления заказами?
Управляющие активами, пенсионные фонды и хедж-фонды (сторона “покупки”) используют OMS для преобразования инвестиционных решений в контролируемые заказы. Они часто торгуют от имени многих портфелей одновременно, поэтому правила распределения и инвестиционные ограничения являются центральными.
Банки и брокеры (сторона “продаж”) получают заказы от клиентов и отправляют их на рынки. Их OMS должен обрабатывать большие объемы заказов, лимиты на уровне клиентов и четкое разделение между заказами клиентов и собственными сделками компании.
Проприетарные торговые фирмы торгуют своими деньгами и используют управление заказами наряду со своими стратегиями и контролем рисков.
Розничные инвесторы обычно не видят OMS по имени. Однако, когда вы размещаете заказ в торговом приложении, системы брокера выполняют те же шаги: они фиксируют ваш заказ, проверяют ваш баланс, отправляют заказ на рынок и обновляют ваш счет по мере поступления исполнений. Когда приложение показывает заказ как “частично исполненный” или “ожидает отмены”, вы видите те же состояния заказа, которые отслеживает OMS.
Краткая история: от телефонных звонков до электронных заказов
Перед тем как торговля стала электронной, многие заказы были переданы по телефону или написаны на бумажных талонах, а сотрудники вручную отслеживали исполнение. С распространением электронной торговли в 1990-х годах компаниям нужен был общий язык для отправки заказов между системами. Протокол FIX возник в результате проекта 1992 года между Fidelity Investments и Salomon Brothers для электронного обмена информацией о заказах на акции, и впоследствии стал отраслевым стандартом. FIX — это общий язык; OMS — одна из основных систем, которая его использует.
Почему компании используют систему управления заказами
Меньше ручных ошибок
Ошибка в количестве или цене может обойтись очень дорого. В декабре 2005 года трейдер компании Mizuho Securities в Токио ввел заказ на продажу 610,000 акций по 1 йене вместо 1 акции по 610,000 йен, что более чем в 40 раз превышало количество акций, выпущенных компанией J-Com. На экране появилось предупреждение, но трейдер его проигнорировал. Попытки Mizuho отменить заказ были заблокированы из-за сбоя в системе Токийской фондовой биржи. Убыток в конечном итоге составил около 40 миллиардов йен. Суд впоследствии обязал биржу выплатить часть суммы, но признал Mizuho частично ответственной из-за недостатков в собственном управлении заказами.
Урок для любого OMS: предупреждение, которое можно закрыть, недостаточно. Ограничения по размеру и цене, которые фактически блокируют заказ, предотвращают подобные ошибки до того, как они попадут на рынок.
Единственный источник истины
Трейдеры, риск-менеджеры, операционные сотрудники и клиенты все нуждаются в одном и том же ответе на вопрос “что случилось с этим заказом?” Когда каждое исполнение, изменение и отмена обновляют одну центральную запись, никому не нужно собирать историю из электронных писем, таблиц и отдельных экранов.
Последовательные элементы управления
Ограничения и запреты применяются к каждому заказу одинаково, независимо от того, исходит ли он от человека, алгоритма или API. Правила настраиваются один раз вместо того, чтобы запоминаться каждым трейдером.
Полный аудит следов
Торговые компании должны иметь возможность показать, часто спустя годы, что произошло с каждым заказом: кто его ввел, когда он был изменен, куда он был отправлен и что было продано.
Регуляторы полагаются на эти записи. В Соединенных Штатах Консолидированная аудиторская трасса SEC предназначена для отслеживания заказов по котируемым акциям и опционам на протяжении всего их жизненного цикла, от создания до маршрутизации, изменения, отмены и исполнения. Правила в других регионах, такие как MiFID II в Европейском Союзе, устанавливают свои собственные требования к ведению записей. Те же записи используются в обзорах наилучшего исполнения, которые проверяют, были ли заказы клиентов исполнены на наилучших доступных условиях.
Система управления операциями (OMS) сама по себе не делает компанию соответствующей нормам, но она производит большую часть данных, от которых зависят команды по соблюдению правил. Вот почему хорошая OMS сохраняет полную историю вместо того, чтобы перезаписывать старое состояние заказа.
Что может пойти не так в управлении заказами
Соединение обрывается после отправки заказа
ОМС отправляет заказ, но соединение прерывается до получения подтверждения. Заказ мог либо дойти до места назначения, либо нет. Простая повторная отправка может удвоить позицию. Безопасный процесс восстановления сначала проверяет статус заказа с другой стороны, и тем временем показывает сотрудникам, что результат не определён.
Повторяющееся сообщение становится повторной сделкой
Когда соединения восстанавливаются, системы иногда повторно отправляют ранее отправленные сообщения. OMS должен распознать, что повторная сделка является той же самой сделкой, которую он уже зарегистрировал, а не новой. Если площадка позже исправляет или отменяет (“бастует”) сделку, это изменение сохраняется как новая запись, так что оригинал остается видимым.
Система теряет след того, что уже заполнено
Наиболее известным примером сбоя в обработке заказов является Knight Capital. 1 августа 2012 года дефект в автоматизированном маршрутизаторе заказов компании оставил ее неспособной распознать, когда заказы были выполнены. Она продолжала отправлять новые заказы. В первые 45 минут торговли было отправлено более 4 миллионов заказов при попытке выполнить всего 212 заказов клиентов, было заключено более 397 миллионов сделок и потеряно более 460 миллионов долларов. Позже SEC обнаружила, что у компании не было адекватных контролей для ограничения отправляемых заказов и накапливаемых позиций.
Неисправным компонентом оказался маршрутизатор, а не OMS, но урок применим к любой системе обработки заказов. Всегда знайте, сколько уже было сделано сделок, и устанавливайте жесткие ограничения, которые останавливают систему, когда цифры перестают иметь смысл.
Торговля правильная, но аккаунт неверный
Торговля по правильной цене все еще может привести к убыткам, если она зачислена на неправильный счет. Вот почему изменения в распределениях и счетах обычно требуют разрешений, зафиксированной причины и проверки, а записи заказов должны регулярно сверяться с данными бэк-офиса.
Признаки хорошо построенной OMS
Независимо от того, оцениваете ли вы систему, используете одну на работе или просто хотите знать, как выглядит “хорошее”, вот ситуации, которые отличают надежную OMS от хрупкой:
| Ситуация | Что делает хорошо построенная OMS |
|---|---|
| Заказ превышает лимит счета | Блокирует его или отправляет на утверждение и фиксирует причину |
| Заказ частично выполнен, затем отменен | Сохраняет видимые выполненные и рабочие количества до подтверждения отмены |
| Соединение разрывается после отправки заказа | Проверяет реальный статус заказа перед повторной отправкой чего-либо |
| Сообщение о выполнении приходит дважды | Распознает дубликат и не учитывает сделку дважды |
| Распределение изменяется после сделки | Требует разрешения и ведет историю изменений |
| Кто-то спрашивает, что произошло со старым заказом | Восстанавливает оригинальную инструкцию, каждое изменение и каждое выполнение |
Система, созданная для одного типа бизнеса, такого как управляющий фондом акций, может также потребовать значительных доработок для работы с другими инструментами, такими как валюты или производные финансовые инструменты.
