Разработка post-trade allocation для торговой платформы — это создание контролируемого слоя, который начинает работать после исполнения блок-заявки. Он определяет допущенные счета, распределяет исполненный объем по утвержденным правилам, рассчитывает среднюю цену и связанные суммы, проводит проверки, передает инструкции во внешние системы и сохраняет доказуемую историю всех действий и исправлений.

Этот слой не заменяет OMS. OMS отвечает за прием, маршрутизацию, жизненный цикл заявки и получение исполнений. Allocation также не является reconciliation: reconciliation сопоставляет записи разных систем и выявляет расхождения после обработки. Post-trade allocation превращает агрегированные исполнения в инструкции по отдельным счетам до подтверждения, расчетов и последующей сверки. Back-office может использовать результат, но логика распределения не должна быть скрыта внутри обычной административной панели.

Что должна делать система распределения после исполнения

Надежная разработка системы распределения блок-сделок начинается с неизменяемой записи каждого fill, поступившего из OMS, от брокера, торговой площадки или execution gateway. Для каждого исполнения нужны устойчивый идентификатор, время источника, объем, цена, сторона, инструмент, валюта и данные брокера. Затем система объединяет релевантные исполнения в блок и использует версионированный снимок участников.

  1. Прием и нормализация исполнений. Исходные данные сохраняются, идентификаторы приводятся к единому виду, повторная доставка не создает вторую операцию.
  2. Фиксация набора участников. Сохраняются счета, целевые объемы, параметры мандата и условия допуска на конкретный момент времени.
  3. Расчет предлагаемого распределения. Применяется правило pro rata, целевое распределение или иной утвержденный алгоритм с ограничениями.
  4. Проверка перед отправкой. Контролируются ограничения счета, объемы, settlement-инструкции, лоты, комиссии и необходимые согласования.
  5. Передача и контроль подтверждений. Инструкции отправляются по API, файлу или FIX, а acknowledgements и rejects сохраняются в карточке операции.
  6. Корректировки как новые события. Исходная инструкция остается доступной, а изменение оформляется отдельной версией, amendment или cancel/replace.

Средняя цена и частичные исполнения

Блок может быть исполнен несколькими сделками по разным ценам. В платформе со средней ценой распределения взвешенная средняя обычно рассчитывается как сумма произведений цены каждого fill на его количество, деленная на общий исполненный объем. Например, 400 единиц по 10.00 и 600 единиц по 10.20 дают среднюю цену 10.12 для 1 000 единиц.

Но формулы недостаточно. Система должна явно показывать, какие исполнения включены в ценовую группу, какая точность цены применяется, как распределяются комиссия, налоги и прочие сборы, а также меняют ли правила конкретного счета итоговую net amount. В post-trade процессах по FIX отдельно существуют агрегированные исполнения, allocation-инструкции, строки распределения, расходы и settlement-данные. В рабочем продукте эти сущности должны оставаться прозрачными.

Лоты, округление и остаток

При частичном исполнении распределяется только фактически исполненный объем. Pro rata часто подходит как базовый принцип, но не является универсальным правилом. На итог могут влиять ограничения мандата, доступность денежных средств, directed brokerage, пригодность инструмента, целевые веса и минимальные размеры лота.

Округление нельзя оставлять как незафиксированное ручное действие. Система должна показать исходный расчет, правило лота или округления, остаточный объем и детерминированную причину, по которой остаток был назначен конкретному счету или отправлен на ручную проверку. Это позволяет ответить на важный вопрос: почему один счет получил 34 единицы, а два других — по 33?

Проверки, которые не дают ошибке уйти дальше

Качественное post-trade processing software отделяет расчет от выпуска инструкции. Распределение может быть рассчитано, но не должно отправляться до успешного прохождения контрольных правил. Базовый набор проверок включает:

  • равенство суммы строк распределения фактически исполненному объему блока;
  • совпадение инструмента, стороны, даты сделки, валюты и ценовой группы;
  • активный статус счета, допуск по мандату и торговые ограничения;
  • проверку лотов, точности количества, цены и валютного округления;
  • наличие действительных settlement-инструкций;
  • защиту от повторной обработки fill и повторной отправки через idempotency;
  • согласование maker-checker для исключений, override и отклонений от политики.

Экран исключений должен помогать принять действие, а не просто показывать красный статус. Оператору нужны нарушенное правило, исходные значения, версия правила, затронутые счета и допустимые дальнейшие шаги. Иначе команда снова будет искать причины в письмах и электронных таблицах.

Исправления должны дополнять историю, а не перезаписывать ее

Зрелая разработка workflow распределения рассматривает исправление как самостоятельное бизнес-событие. Нельзя незаметно изменить строку уже утвержденного allocation после смены settlement-инструкции или обнаружения недопустимого счета. Нужно сохранить исходный вариант и создать связанную версию корректировки с кодом причины, инициатором, согласующим, временем, измененными полями и ответом внешней стороны.

Например, если счет необходимо исключить после выпуска инструкции, процесс может потребовать создания correction request, согласования, пересчета оставшихся объемов в рамках разрешенной политики и отправки cancel/replace либо amendment контрагенту. В интерфейсе должна быть видна вся цепочка: блок, исполнения, первоначальное распределение, исправление, acknowledgement и финальный операционный статус.

Архитектура институционального слоя allocation

Распределение следует моделировать как самостоятельный домен между execution и settlement, а не как функцию загрузки Excel. Базовые сущности: execution fill, block, allocation instruction, allocation line, eligibility snapshot, validation result, approval, outbound message, acknowledgement и correction event. У каждой сущности должны быть внутренний ID, внешние ссылки, номер версии, временные метки и неизменяемая история событий.

Интеграции лучше строить через очереди с безопасным повтором и idempotency. Повтор транспортной попытки не должен создавать второе распределение у брокера или кастодиана. В интерфейсе важно отдельно отображать бизнес-статус и статус доставки: «утверждено» не означает «подтверждено контрагентом», а «подтверждено» не всегда означает «рассчитано».

Вопросы перед запуском разработки

  • Можно ли настраивать правила распределения, допуски и маршрутизацию исключений без изменения кода?
  • Как представлены множественные fill, брокеры, ценовые группы, частичные исполнения и остаточные лоты?
  • Можно ли восстановить условия допуска счета именно на момент расчета?
  • Какие действия требуют второго согласующего, а какие выпускаются автоматически?
  • Включает ли audit trail статусы отправленных сообщений и acknowledgements контрагента?
  • Где проходят границы ответственности между OMS, allocation, reconciliation, расчетом комиссий и back-office?
  • Что происходит при reject, задержке, дублировании или нарушении последовательности сообщения?

Разработка post-trade allocation с POLADO

POLADO создает FinTech и trading-системы для финансовых процессов с правилами и контролем: нормализацию execution-данных, очереди операционных исключений, защищенные API, FIX-интеграции и audit-ready event history. Если команде нужны удобные рабочие экраны для сложных таблиц, корректировок и согласований, подключается услуга UI/UX и продуктовый дизайн. Пример FinTech- и аналитического направления представлен в проекте ESFX.

Если распределение блок-сделок все еще зависит от Excel, ручного экспорта и правок без объяснимой истории, запланируйте консультацию с POLADO. Мы поможем выделить границы между execution, allocation, подтверждениями и reconciliation, а затем сформировать план разработки под ваши инструменты, контрагентов и требования контроля.