В данной статье я расскажу об основных функциях системы управления ордерами (OMS) в брокерской конторе, о том, что должна уметь OMS в брокерском бизнесе торговли акциями. Эта статья будет интересна финансовым программистам и архитекторам, а также всем тем, кто интересуется внутренним устройством сложным финансовых программных систем.
OMS является критической системой для брокерского бизнеса, о чем я уже упомянул в отдельной статье. Перечислю ниже некоторый функционал, который можно встретить, как правило, в любой OMS в любом банке, будь то стандартная OMS от стороннего вендора, либо OMS, написанная программистами самого банка.
Соединение с клиентскими системами
В настоящее время клиенты в основном передают ордера брокеру электронно. У брокера для сопряжения с клиентами как правило есть отдельная система. Эта система находится в руках «продажников», которые взаимодействуют с клиентами и мониторят поступающие ордера, которые дальше перенаправляются для торгов в другие системы банка, включая OMS. Следовательно OMS должна иметь сопряжение с этой системой. Как правило, сообщения между системами передаются с помощью FIX-протокола, а транспортом служит либо простое соединение по сокетам TCP/IP, либо какая-то система messaging (IBM Queues, Tibco EMS, TibcoRV или что-то другое).
Ввод ордеров вручную и импорт ордеров из Excel, CSV
Иногда ордера от клиентов или от других торговых отделов могут поступать и не в электронном виде. Поэтому OMS должна поддерживать ввод ордеров вручную: либо простой ввод по одной акции за раз (если речь идет о единичном ордере — single stock order), либо списком (если речь идет о корзине ордеров — basket order). Причем список может быть получен трейдером в виде Excel-файла, CSV-файла или просто текстовый файл. И все эти форматы OMS должна понимать и поддерживать. Вы не поверите, но даже есть такое требование как поддержка возможности трейдеру ввести ордер очень быстро и одной рукой (так как вторая рука у него может быть занята трубкой телефона).
Отчеты клиентам по исполнению ордеров
После получения ордера (или корзины ордеров) от клиентов, трейдер исполняет ордера, и отчет об исполнении ордеров OMS должна своевременно отправлять клиентам. Отправка отчетов может происходить в реальном времени (если например большой орде исполняется по частям), либо с задержкой. В последнем случае, например, отчеты об исполнении задерживаются в OMS и потом, когда весь ордер полностью исполнен, отправляются скопом, либо сводятся в один с усредненной ценой по всем исполнениям. Описание этой процедуры требует отдельной статьи, которую я напишу позже.
Получение ордеров от других банковских систем
В OMS ордера могут приходить не только от клиентов, но и из других внутренних систем банка — из других отделов торговли, если те отделы пользуются какой-то другой OMS. OMS должна уметь «разговаривать» с другими системами, т.е. принимать от них ордера и отправлять отчеты об их исполнении.
Поддержка разных стилей торговли
OMS в своем функционале повторяет организационную структуру торгового зала по той простой причине, что OMS — инструмент, который призван облегчать работу трейдеров. Так же, как делится торговый зал на отделы, так и OMS должна поддерживать все функции этих отделов: функции программной торговли (program trading), функции торговли отдельными акциями (single stock trading), функции и agency trading и principal trading.
В идеале, конечно, каждый банк стремится к конвергенции — к тому, чтобы все отделы торговли использовали одну OMS. Это удобно и с точки зрения поддержки, и единообразия, и обучения, и разработки. Но, как мы знаем, идеалы достижимы не всегда. В силу специфических причин частенько бывает так, что разные отделы пользуются разными OMS. Например, отдел программной торговли может пользоваться одной OMS, а отдел торговли отдельными акциями — другой просто потому, что так им удобнее. Или весь торговый зал находится в процессе поэтапного внедрения новой системы и постепенного вывода из строя старой. На внедрение может уйти от полугода до нескольких лет, а то и вообще планы внедрения могут приостановиться или поменяться. Но при этом торговый зал должен работать каждый торговый день.
Роутинг ордеров
После того, как ордер от клиента поступил в OMS, трейдер должен его куда-то отправить на исполнение. В терминологии пункт назначения ордера называется destination, а сама процедура отправки ордера — routing. Как именно распорядится конкретным ордером, решает сам трейдер, следуя определенным правилам и ситуации. Основными пунктами назначения ордеров, где они исполняются, могут быть:
- рынок (market destination, другой брокер)
- на внутреннюю электронную кроссинговую площадку (external crossing destination)
- в другой отдел (desk destination)
- в алгоритмический движок (algo destination)
Все эти пункты назначения должны быть представлены в OMS и поддерживаться со всеми их специфическими параметрами.
Кроссинг внутри OMS
Помимо кроссинга ордеров друг с другом в сторонней системе (внутренней системе банка или внешней системе) кроссинг ордеров может осуществляться и в самой OMS.
Скажем, один клиент прислал ордер на продажу 200 акций ABC, а другой прислал ордер на покупку 100 акций той же компании. Законы позволяют брокеру свести эти два ордера вместе, не отправляя их на рынок. Этот механизм называется agency crossing, потому что с обоих сторон брокер выступает в качестве агента. Второй вариант: клиентский ордер скажем на продажу 2000 акций XYZ трейдер может переправить в другой отдел, и там его исполнит, т.е. купит эти акции, сам банк. В этом случае произойдет кроссинг между agency ордером и principal ордером. Есть еще множество вариантов исполнения клиентского ордера внутри OMS, но я перечислил выше основные. И эти два основных типа исполнения ордеров OMS тоже должна поддерживать.
Взаимодействие с другими банковскими системами
OMS являясь системой, получает данные от других систем, и сама в то же самое время является источником данных для других систем. Вместе со всеми этими системами OMS формирует так называемую «систему систем» — клубок связанных друг с другом приложений, каждое из которых обменивается данными с другими системами. Все сделки и действия трейдеров должны отражаться в других системах: в системах мониторинга, аудита, отчетности и контроля рисков (middle office), а также результаты по торгам должны отражаться в системах back office для расчета баланса платежей с клиентами, с депозитариями и с клиринговыми домами.
Через OMS клиенты могут также совершать короткие продажи (short sell orders), в этом случае OMS должна быть тесно связана с системой отдела заимствования акций — Loans desk.
Разделение прав между пользователями
Так как с OMS работает множество пользователей, относящихся организационно к разным отделам торгового зала, OMS должна поддерживать функции разделения пользователей. В ней должна быть предусмотрена возможность определять, кто какие ордера видит, что какому пользователю можно делать, а что нет. Например, к OMS на PROD могут иметь доступ как трейдеры, так и работники поддержки и программисты, но только трейдеры должны иметь право создавать ордера и отправлять их на рынок, а все остальные — только видеть все эти операции в режиме read-only. Трейдеры одного отдела не должны видеть ордера трейдеров другого отдела. Менеджер торгового зала или аудитор должен видеть ордера всех трейдеров и так далее. Конкретные правила видимости и разрешений определяются бизнесом.
Идентификация пользователя в OMS должна быть унифицирована с идентификацией пользователя во всех системах банка и управляться из одного центра. Скажем, если в отдел на работу поступил новый трейдер, запись о нем создается в этой единой системе управления пользователями (LDAP, Windows NT Domain), и о нем через какое-то время (после обновления) узнают все остальные системы, куда он может залогиниться под своим единым именем пользователя.
Прочий функционал
Position management — OMS должна отслеживать текущие позиции по каждой акции. Если трейдер пытается продать больше, чем есть в наличии у банка, система должна предупредить трейдера о этом.
Inventory management — OMS должна показывать текущее наличие акций по каждой акции их стоимость в пересчете на текущие рыночные данные.
Market data — OMS должна показывать в реальном времени текущие рыночные данные по всем акциям, с которыми работает трейдер
Reference data — OMS должна показывать все характеристики (название компании, симвология, страна юрисдикции, сектор экономики и проч.) всех акций, с которыми работает каждый трейдер.
OMS должна поддерживать аналитические функции: рисовать графики, позволять сравнивать портфели акций с каким-то выбранным индексом, помогать трейдеру определять баланс ордеров (что нужно прикупить или что нужно продать) в сравнении с определенным параметром, позволять сливать несколько корзин в одну, разделять одну корзину на несколько по разным параметрам.
Изменение конфигурации системы в реальном времени на лету без перезагрузки
Мелкая перенастройка OMS под различные текущие операции торгового дня должна осуществляться на лету без рестарта всей системы. Поэтому при создании OMS стараются некоторый фукнционал выносит в конфигурационные, настроечные модули, с помощью которых можно временно что-то быстро включать или выключать в OMS по требованию трейдера: например, изменить «на лету» параметры валидации ордера, изменить параметры логгирования, чтобы уменьшить нагрузку на систему, перезагрузить какие-то рыночные данные, которые изменились прямо по середине торгового дня.
В идеале поддержка разных видов торговли
В идеале одна и та же OMS должна была бы поддерживать и торговлю акциями и торговлю деривативами. Но это конечно в идеале. Торговля акциями и деривативами сильно отличаются друг от друга. Смешивание двух функционалов в одной OMS приносит больше головной боли и проблем с поддержкой, чем нужно. Да и организационно деривативы и акции торгуются разными отделами банка, так что вполне обычно что эти два отдела пользуются разными OMS, которые поддерживаются и разрабатываются разными командами.
OMS это в первую очередь поддержка High-touch торговли, т.е. торговли где трейдеры, пользующиеся OMS, реально «работают» с ордерами. Но в идеале OMS должна позволять работать и с low-touch orders, т.е. с ордерами, которые идут через брокера по каналам DMA и DSA. Такие low-touch ордера специально назначенные трейдеры лишь мониторят и вмешиваются, если обнаруживают какие-то проблемы.
Общий код для всех регионов торговли
Опять-таки в идеале отделы торговли акциями банка во всех регионах хотели бы пользоваться одной и той же OMS. Разумеется с учетом региональных особенностей организации торгов. Если система работает, скажем, в APAC регионе, то она должна работать и в EMEA с минимальными перенастройками конфигурации. Общий код для разных регионов — это постоянная головная боль программистов OMS, ведь изменения в коде для одного региона могут неожиданно повлиять на поведение OMS в другом регионе. Причем это изменение может вылезти в самый неожиданный момент, ведь в каждом регионе это изменение попадет на PROD в разное время.
Итоги
Как видите, функционал OMS нетривиален. Пишутся такие системы годами, коллективом квалифицированных программистов и бизнес-аналитиков, тесно взаимодействующих с трейдерами торгового зала и их менеджерами, а также программистами всех других систем, с которыми интегрируется OMS. Поддержка такой системы тоже требует усилий отдельной команды поддержки, которая чаще всего сидит там же — в торговом зале — на расстоянии вытянутой руки от трейдеров.
Algo & DMA: технологии биржевой торговли 