Разработка dealing desk для торговой платформы создаёт контролируемый операционный слой, в котором дилеры и команды исполнения разбирают исключения, принимают разрешённые решения по маршрутизации и сохраняют доказательства каждого действия. Это не просто список заявок и не панель ручного override. Качественный dealing desk фиксирует, почему заявка попала в очередь, какой рыночный контекст видел оператор, какое действие было ему разрешено, кто согласовал исключение и что произошло после отправки команды.
Такой слой нужен брокеру или FinTech-команде, когда работа уже не помещается в терминалы, чаты и таблицы, но полная замена всей торговой инфраструктуры нецелесообразна. POLADO может спроектировать его в рамках услуги FinTech и trading-системы, подключив к уже существующим компонентам платформы.
Что должен контролировать dealing desk
Задача dealing desk — не автоматизировать все решения и не давать дилеру неограниченную власть. Его задача — сделать вмешательство человека явным, ограниченным правилами и проверяемым. Для каждой заявки в рассмотрении рабочее место должно показывать единый операционный контекст:
- заявку, счёт, инструмент, направление, объём, номинал и временные метки;
- котировку на момент решения, её источник, возраст, состояние спреда и статус торговой сессии;
- открытые заявки, позиции, использованные лимиты и релевантную экспозицию счёта или группы;
- доступные варианты маршрутизации, состояние venue или liquidity provider и предыдущие попытки;
- ограничения, созданные риск-правилами, entitlement-политиками или правилами сессии;
- оператора, допустимое действие, код причины, комментарий и требуемое согласование.
Это не второстепенная деталь интерфейса. Именно такой контекст позволяет позже ответить на вопросы операций, поддержки, контроля и аудита: что было известно в момент решения и почему оно было принято.
Чем dealing desk отличается от OMS, pricing engine, risk system и liquidity bridge
У компонентов торговой платформы должны быть чёткие зоны ответственности. OMS хранит канонический жизненный цикл заявки: создание, изменение, отмену, исполнения и статусы. Pricing engine нормализует market data и формирует цены либо потоки котировок. Risk system рассчитывает pre-trade проверки, лимиты, margin и защитные действия. Liquidity bridge передаёт инструкции внешним контрагентам или venue и нормализует ответы об исполнении.
Dealing desk использует снимки и события этих систем, чтобы человек мог принять решение в рамках политики. Например, заявка может попасть в review из-за устаревшей котировки, деградации provider, приближения к лимиту экспозиции или неуспешной попытки маршрутизации. Но dealing desk не должен тайно дублировать расчёт margin, формирование цены или жизненный цикл заявки. Иначе одни и те же правила начинают применяться по-разному в разных частях платформы.
Такое разделение удобно и для поэтапной модернизации: можно добавить контролируемое рабочее место дилера поверх действующих order и execution сервисов. Подход к FinTech-продуктам также можно оценить по проектам FT10 и ESFX.
Очереди дилера и контроль исполнения
Очереди должны быть основаны на правилах
Единая папка «manual review» быстро становится непрозрачной. Очереди следует разделять по причине и модели обработки: stale price, крупный номинал, отклонение provider, частичное исполнение, исключение торговой сессии, корректировка сделки или предупреждение по экспозиции. Для каждой очереди нужны правило входа, приоритет, целевое время реакции, владелец, путь эскалации и условие закрытия.
Нельзя допускать, чтобы два дилера одновременно считали, что обрабатывают одну заявку. Для этого применяется ограниченное по времени claim/lease-владение, журнал передачи владельца и безопасный возврат заявки в очередь после истечения claim. Вмешательство supervisor должно быть отдельным видимым и аудируемым override, а не незаметной сменой управления.
Права должны зависеть от действия и контекста
Роль «dealer» сама по себе слишком груба. Один сотрудник может отправлять допустимые заявки на маршрутизацию, другой — отклонять их по утверждённым причинам, а предложение quote override или исключения выше установленного номинала может быть доступно только supervisor. Права могут ограничиваться группой счетов, классом инструмента, сессией, desk, регионом или диапазоном номинала.
Интерфейс не должен создавать впечатление, что риск-контроль можно просто обойти. Если заявка заблокирована системой риска, dealing desk обязан показать соответствующее правило и предложить только допустимые дальнейшие действия: отклонение, ожидание новой котировки, эскалацию на согласование или документированный запрос исключения.
Контроль котировок и защита от stale price
Дилерское решение небезопасно, если происхождение котировки неясно. Для каждого решения нужно хранить snapshot котировки: источник, timestamp источника, время получения, bid/ask, состояние ликвидности и версию конфигурации. На этой основе система может оценить возраст цены, задержку market data, расширение спреда, статус сессии и состояние provider до того, как предложит путь исполнения.
Защита от stale price — это не только автоматический reject. Продуктовая политика должна заранее определить, будет ли запрошена новая котировка, переведена ли заявка в review, возможен ли альтернативный routing или заявка должна быть отменена. Статусы для клиента, API и downstream-систем должны формироваться из одного управляемого процесса, иначе разные каналы начнут сообщать противоречивую историю.
Коды причин, эскалация и maker-checker
Одних произвольных комментариев недостаточно для надёжного контроля. Используйте структурированные reason code для причин вроде provider rejection, expiry котировки, отмены по запросу клиента, запрета сессии или одобренного исключения. Свободный комментарий полезен как дополнение, но структурированные поля необходимы для отчётности, проверки контролей и анализа повторяющихся проблем.
Для действий с высоким влиянием нужен maker-checker. Например, дилер предлагает исключение в маршрутизации, а другой уполномоченный сотрудник одобряет или отклоняет его. Согласование должно быть привязано к конкретной версии заявки и контексту решения. Если заявка изменилась, котировка истекла или существенно изменилась экспозиция, ожидающее согласование должно стать недействительным.
Неизменяемый аудиторский след dealing desk
Audit trail dealing desk — это не лог вида «пользователь изменил статус». Он должен быть append-only историей событий, отвечающей на вопросы: что было известно, какое действие запрашивалось, какие правила были оценены и как возник конечный результат. В журнале нужны:
- состояние заявки до и после изменения, а также событие-первопричина;
- идентификатор пользователя, роль, контекст аутентификации и, где уместно, данные рабочей сессии;
- код причины, комментарий, вложения и цепочка согласования;
- snapshot котировки, результат риска, экспозиция и версия правил/конфигурации;
- correlation ID, запросы маршрутизации, execution reports, ответы provider и временная последовательность;
- исправления и отмены как новые события, а не как тихое редактирование прошлого.
В FIX-модели полезно различать причину отправки execution report и итоговый статус заявки. Внутренняя модель событий также должна сохранять и причину действия, и получившееся состояние, а не сводить всё к одному полю status.
Интеграционная архитектура: кто владеет командой
Надёжный dealing desk сочетает синхронные проверки и асинхронную обработку событий. Когда оператор предлагает действие, backend должен проверить актуальное каноническое состояние заявки, права, применимые правила и нужные snapshot-данные. Затем он создаёт запрос согласования либо формирует контролируемую команду для routing-слоя. Execution reports и прочие downstream-события обновляют операционное представление асинхронно.
Браузер не должен напрямую отправлять инструкцию на venue. Действие пользователя — это намерение, которое сервер проверяет по актуальной версии заявки. Используйте idempotency keys, correlation ID между сервисами, определённые правила timeout/retry и явную обработку поздних или дублирующихся execution events. Это снижает риск двойной отправки при повторном клике, перезаписи нового статуса запоздалым fill и решения на устаревшем экране.
Чек-лист перед стартом разработки
- Какие категории заявок проходят straight-through processing, а какие направляются дилеру?
- Кто владеет каждой очередью, каков target response time и путь эскалации?
- Какие действия разрешены по роли, инструменту, группе счетов, сессии и номиналу?
- Какая система владеет freshness котировки, eligibility, риск-решением и каноническим order state?
- Какие доказательства необходимо сохранять snapshot-ом в момент решения?
- Как моделируются partial fill, provider rejection, поздние отчёты, корректировки и повторная маршрутизация?
- Какие действия требуют maker-checker и когда одобрение теряет силу?
- Включают ли UAT-сценарии outage provider, stale quote, дублирующие команды, параллельные claim и задержку событий?
Как POLADO помогает построить контролируемый dealing desk
Сильный проект начинается не с макета dashboard, а с модели решений, границ событий, матрицы прав и сценариев исключений. POLADO может создать рабочее место дилера вокруг существующих OMS, pricing, risk и liquidity bridge компонентов без обязательной полной замены платформы. Цель — не расширить произвольные полномочия оператора, а сделать решения по исполнению понятнее, безопаснее и проверяемее.
Если ваши процессы исполнения пока распределены между терминалами, таблицами и чатами, обратитесь к команде FinTech и trading-системы POLADO за технической консультацией. Вместе мы сможем описать текущий поток решений, границы интеграций и первоочередные контроли.