Система управления заявками для брокера: купить OMS у поставщика, доработать ту, что есть в вашей торговой платформе, или построить свою

Система управления заявками брокера (OMS) — это софт, который ведёт заявку клиента с момента её поступления до исполнения или отмены. Он проверяет заявку, отправляет её на площадку или другому брокеру, отслеживает её и записывает каждый шаг. Такую систему можно купить у поставщика, доработать обработку заявок, которая уже есть в вашей торговой платформе, или построить свою. Правильный выбор зависит от того, через сколько платформ и площадок проходят ваши заявки и является ли то, как вы обрабатываете заявки, частью того, что вы продаёте. Обязанности от выбора не меняются. За риск-проверки и записи отвечает ваша компания, кто бы ни написал софт.

Что система управления заявками делает для брокера?

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

• Она принимает заявку и присваивает ей идентификатор, который остаётся с ней до конца
• Она выполняет предторговые проверки: достаточно ли денег или маржи, укладываются ли объём и цена в лимиты, есть ли разрешение торговать инструментом
• Она отправляет заявку на биржу, поставщику ликвидности или вышестоящему брокеру
• Она отслеживает состояние заявки — например, рабочая (ещё открыта на рынке), частично исполнена, исполнена, отменена или отклонена — и все изменения, которые клиент вносит по ходу
• Она передаёт каждое исполнение обратно на счёт клиента и в ваш бэк-офис
• Она записывает каждый шаг с отметкой времени

Отправка часто идёт по FIX — общему формату сообщений, которым брокеры и площадки передают друг другу заявки и исполнения. FIX Trading Community, которая его поддерживает, описывает протокол FIX как «глобальный открытый стандарт, который позволяет финансовым организациям обмениваться торговой информацией». Её перечень торговых сообщений начинается с раздела «Заявки и исполнения». Спросите у каждой площадки и каждого брокера, к которым вы планируете подключиться, какую версию FIX и какие сообщения они ожидают.

Чем OMS отличается от EMS и от нашей торговой платформы?

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

У розничных брокеров часто уже есть третий вид — обработка заявок внутри их торговой платформы. Сервер платформы принимает заявку, проверяет счёт и либо оставляет риск у брокера, либо передаёт заявку дальше через коннектор, который называется гейтвеем. На своей странице для брокеров MetaQuotes пишет, что гейтвей MetaTrader 5 «позволяет брокерам мгновенно хеджировать свой риск». Для многих брокеров эта встроенная обработка и есть их OMS, даже если никто её так не называет.

Чего регуляторы ждут от учёта заявок?

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

В ЕС статья 25 MiFIR говорит, что инвестиционные компании «должны в течение пяти лет хранить в распоряжении компетентного органа соответствующие данные по всем заявкам и всем сделкам с финансовыми инструментами, которые они провели». Статья 28 MiFID II требует от компаний, которые исполняют заявки клиентов, «процедур и механизмов, обеспечивающих быстрое, справедливое и оперативное исполнение заявок клиентов по отношению к другим заявкам клиентов или торговым интересам инвестиционной компании».

Статья 27 MiFID II о наилучшем исполнении говорит, что компания должна по запросу уметь показать клиенту, «что его заявки были исполнены в соответствии с политикой исполнения инвестиционной компании». Чтобы это показать, компании нужна запись о том, когда поступила каждая заявка и куда она ушла.

В США правило SEC 17a-3 требует от брокеров-дилеров вести запись о каждой брокерской заявке, исполнена она или нет. Правило называет такую запись меморандумом. В ней должны быть указаны «условия заявки или инструкций», «время получения заявки, время её ввода, цена, по которой она исполнена» и, «насколько это осуществимо, время исполнения или отмены».

FINRA — саморегулируемая организация, которая надзирает за брокерами-дилерами США. Правило SEC 613 требует от FINRA и национальных фондовых бирж США совместно представить план консолидированного аудиторского следа, известного как CAT. На странице FINRA он описан как консолидированный аудиторский след, «который собирает и точно идентифицирует каждую заявку, отмену, изменение и исполнение сделки по всем акциям и опционам, допущенным к биржевым торгам, на всех рынках США». На той же странице сказано, что «каждый член национальной фондовой биржи или национальной ассоциации ценных бумаг обязан соблюдать все положения плана CAT NMS».

Правило SEC 15c3-5 требует от брокера-дилера с доступом к рынку «создать, задокументировать и поддерживать систему средств контроля рисков и надзорных процедур». Эти средства контроля «должны находиться под прямым и исключительным контролем брокера или дилера», с узким исключением для клиентов, которые сами являются брокерами-дилерами. Софт можно купить, но лимиты остаются под вашим контролем.

Все источники в этой статье открывались 2 ноября 2026 года. Статья рассматривает только правила ЕС и США. В других странах действуют свои.

Что остаётся неизменным, какой бы путь мы ни выбрали?

Эти задачи есть на любом пути. Меняется то, кто пишет и эксплуатирует софт:

• Предторговые риск-проверки каждой новой заявки и каждого изменения рабочей заявки с лимитами, которые устанавливают ваши собственные риск-менеджеры
• Аудиторский след: каждая заявка, изменение, отмена, исполнение и отклонение с отметкой времени, которые хранятся столько, сколько требуют применимые к вам правила
• FIX-подключения к каждой площадке и вышестоящему брокеру, каждое из которых настроено и протестировано вместе с компанией на другой стороне
• Сверка: ежедневное сопоставление ваших заявок, исполнений и позиций с данными ваших площадок, брокеров и клиринговой компании, где каждое расхождение объяснено

Часть этой работы может взять на себя поставщик или платформа, но за всю её по-прежнему отвечает ваша компания.

Когда брокеру стоит купить OMS у поставщика?

Покупайте, когда ваш поток заявок похож на поток других клиентов поставщика. Типичные признаки:

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

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

Когда стоит доработать обработку заявок в нашей торговой платформе?

Дорабатывайте, когда большинство ваших клиентов торгуют на одной платформе, обработка заявок в ней работает и не хватает лишь узкого фрагмента. Это может быть риск-правило, которое нельзя задать в её настройках, маршрут к новому поставщику ликвидности или связь с вашим бэк-офисом. Для этого разработчики платформ предлагают программные интерфейсы — API. MetaQuotes пишет, что её «Gateway API используется для интеграции MetaTrader 5 с другими торговыми системами и создания собственных потоков данных». Spotware описывает Manager's API своей платформы cTrader как интерфейс, который даёт брокерам «полный контроль над серверными сущностями cTrader».

Прежде чем дорабатывать, выясните:

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

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

Когда собственная OMS оправдана?

Собственная разработка окупается в таких случаях:

• Заявки приходят через несколько платформ или каналов, и вам нужен единый учёт всех заявок и единый набор риск-лимитов для всех них
• Обработка заявок — часть того, что вы продаёте: например, ваши собственные правила маршрутизации или типы заявок, которые не поддерживают проверенные вами продукты
• Плата за пользователя, заявку или подключение превысила стоимость команды, которая эксплуатировала бы вашу собственную систему
• Вам нужна полная история заявок в вашей собственной базе данных, в структуре, которую контролируете вы
• Вы планируете добавлять или менять платформы и площадки и не хотите каждый раз перестраивать учёт

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

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

Что проверить до подписания договора с поставщиком OMS?

• Можем ли мы в любой момент выгрузить полную историю заявок и аудиторский след в задокументированном формате и сколько это будет стоить, когда мы уйдём?
• Кто устанавливает и меняет риск-лимиты: наши сотрудники в наших собственных интерфейсах или служба поддержки поставщика по запросу?
• Какие площадки и брокеры уже подключены и используются другими клиентами сегодня, а какие только в планах?
• Как меняется плата, когда число пользователей, заявок или подключений к площадкам удваивается?
• Что происходит с рабочими заявками, если OMS или одно из подключений падает, и могут ли наши сотрудники отменить все рабочие заявки одного счёта или всей компании?
• Как считаются цена и сроки доработок под наши правила и кому принадлежит код, написанный для нас?
• За какой срок нас предупредят, если поставщик снимет продукт с продажи или изменит его цену?

Что значит владеть кодом и данными?

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

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

Что спросить у компании, которая будет это строить?

• Какие состояния заявок будет отслеживать система и как она обрабатывает частичные исполнения и изменения рабочей заявки?
• Как после перезапуска посреди торгового дня система восстанавливает рабочие заявки и позиции и сверяет их с данными площадок до возобновления торговли?
• Какие площадки и каких брокеров вы подключите первыми, по какой версии FIX и кто организует тестирование с каждым из них?
• Где выполняются риск-проверки, сколько времени они занимают и как это измеряли?
• Что записывается в аудиторский след по каждой заявке, с какими отметками времени, и может ли система выдать записи, которые запрашивает наш регулятор?
• Как устроена ежедневная сверка и кому сообщают, когда она находит расхождение?
• Можете показать это в действии в системе, которая работает сегодня?

Где здесь место amBrain?

amBrain ведёт этот блог. Эту часть своей работы компания описывает одной строкой: «amBrain строит инфраструктуру алгоритмической торговли: исполнение заявок, рыночные данные и предторговый риск-контроль». Ещё одна строка на сайте amBrain гласит: «Разработка торговых терминалов, систем управления заявками и биржевая интеграция по протоколу FIX».

amBrain делает софт с 2019 года. О том, как компания работает с клиентами, она говорит: «Три формата: полная разработка, выделенная команда или инженеры внутри вашей команды». О владении у неё такая строка: «Клиент сохраняет полное владение продуктом и кодом, кроме наших переиспользуемых компонентов». До подписания попросите поимённый список этих компонентов.

Эта статья — не кейс, и работа для клиентов в ней не описывается. В ней не утверждается, что amBrain строил, покупал или дорабатывал OMS для какого-либо клиента. FIX Trading Community, MetaQuotes, Spotware и FINRA цитируются по их опубликованным страницам, и статья не утверждает, что между amBrain и кем-либо из них есть какие-либо отношения. Цен и сроков amBrain статья не приводит.

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