Разработка системы прав на рыночные данные для trading-платформы — это создание слоя решений, который до передачи котировки определяет, имеет ли конкретный пользователь, счёт, организация, приложение или автоматизированный процесс право получить определённый data feed. Pricing engine получает, нормализует и подготавливает цены к распространению. Entitlement-слой отвечает на другой вопрос: кому разрешено видеть, получать через API, выгружать или использовать эти цены в автоматическом процессе.
Такое разделение особенно важно для брокеров, поставщиков финансовых данных и операторов торговых продуктов с несколькими каналами. Один клиент может видеть delayed-котировки в личном кабинете, real-time данные в терминале и не иметь доступа к ним через API. Другой может смотреть цену на экране, но не иметь права выгружать историю, передавать данные далее или использовать их в non-display алгоритме. Если правила реализованы отдельно в web, mobile, terminal и API, доступ быстро становится несогласованным, а отзыв прав и отчётность становятся ненадёжными.
Что должна решать система entitlement
Надёжная система должна одновременно оценивать кто делает запрос, какой продукт, feed или инструмент запрашивается и где и для какой цели данные будут использованы. Одного признака «premium-клиент» недостаточно. Решение может зависеть от биржи или вендора, конкретного feed, класса активов, списка инструментов, типа клиента, организации, состояния торгового счёта, канала, устройства, сессии, цели использования и срока действия права.
Запрос bid/ask по EUR/USD, например, должен возвращать не расплывчатый boolean, а конкретный результат:
- разрешить real-time display;
- разрешить только delayed display, например с задержкой 15 минут;
- разрешить лишь last price или end-of-day данные;
- запретить доставку и показать путь к подписке или поддержке;
- разрешить отображение, но запретить экспорт, использование ботом или redistribution.
Это не формальность интерфейса. В опубликованной политике Nasdaq по compliance среди предметов проверки указаны контроль entitlement/disentitlement, добавление и удаление пользователей, одновременный доступ, отчётность и способ доставки данных — real-time, delayed, end-of-day и другие варианты. На сайте NYSE также выделены отдельные категории политик для entitlement control и delayed market data.
Архитектура: единый контур принятия решений
Каноническая модель прав
Факты о правах обычно приходят из нескольких источников: billing и подписки, клиентские договоры, статус professional/non-professional, KYC, группы торговых счетов, договоры организации и ручные исключения операционной команды. Не стоит позволять каждому приложению становиться собственным источником истины. Нужны каноническая доменная модель и сервис, который собирает эти основания и выдаёт единое решение.
Запись grant должна как минимум содержать тип и ID субъекта, scope счёта или организации, data product/feed, scope инструментов, разрешённый тип использования, scope канала, даты начала и окончания, статус, ссылку на источник, согласовавшего сотрудника и версию политики. Именно эта запись позволяет ответить на вопрос: «Почему пользователь получил эти данные в 10:04?» — без ручного сопоставления нескольких несвязанных систем.
POLADO проектирует такие интеграционные границы в рамках услуги FinTech и trading-системы, связывая доступ к данным с контролируемыми состояниями клиентов и счетов, а не с локальными флагами у каждого feed-потребителя.
Отделите policy evaluation от доставки котировок
Gateway доставки не должен содержать растущий набор жёстко прописанных названий тарифов и исключений по биржам. Он должен запрашивать у policy decision point решение allow, deny или allow-with-constraints. Полезный ответ включает режим доставки, размер задержки, обязательную маркировку, разрешённые типы использования, scope инструментов, срок действия, версию политики и понятный reason code.
Политики необходимо версионировать. Для них нужны приоритеты, явный принцип deny-overrides, даты действия, история согласований и автоматические тесты. Тогда новую подписку или feed можно вводить через контролируемую конфигурацию, а не через срочный релиз с риском ошибки.
Оценивайте пользователя, счёт и сессию вместе
Пользователь может быть активен, в то время как его торговый счёт закрыт, заморожен, переведён в read-only, находится на KYC review или имеет ограничение по оплате. Кроме того, в терминале клиент может сменить счёт в рамках одной сессии. Поэтому entitlement нельзя определять только по user ID после логина: нужны identity, organisation, выбранный account и session context.
Последовательность контроля должна быть явной: аутентификация субъекта, определение разрешённого контекста счёта, оценка прав, создание подписки и реакция на последующие изменения статуса. Если счёт отозван, открытый WebSocket-stream не должен продолжать работу лишь потому, что токен входа ещё не истёк.
Права на уровне инструмента и способа использования
Разрешение вида «real-time equities» может быть удобным верхним уровнем, но production-система должна поддерживать scope по бирже, feed, классу активов, сегменту рынка, списку символов и отдельному инструменту. Instrument master не владеет правилами доступа, однако предоставляет стабильные идентификаторы и атрибуты, без которых правило невозможно корректно оценить.
Тип использования также должен быть самостоятельным измерением. Просмотр графика человеком не означает автоматического права использовать ту же цену в алгоритме, формировать производный набор данных, вызывать export endpoint или публиковать обновления по webhook. В материалах SEC о рыночных данных рассматриваются различные сценарии, включая display и non-display, а также разные категории подписчиков и модели оплаты. Их нельзя сводить к одному признаку «авторизован». ([sec.gov](https://www.sec.gov/files/rules/final/2020/34-90610.pdf?utm_source=openai))
Проверяйте права во всех каналах
Скрыть виджет во frontend — не значит обеспечить entitlement control. Web-кабинет, iOS/Android-приложение, desktop terminal, REST API, WebSocket gateway, сервис выгрузок и фоновые отчёты должны получать одно и то же policy-решение. Иначе пользователь, которому отказано в личном кабинете, сможет получить real-time данные через забытый API endpoint.
- Web и mobile: проверка до подписки; при изменении прав — удаление потока и корректное состояние delayed, unavailable или subscription.
- Торговый терминал: актуализация snapshot при входе и смене счёта; приём server-side события отзыва во время сессии.
- API: OAuth scope сам по себе недостаточен. Проверяйте endpoint, инструменты, продукт, цель использования и rate limit.
- Экспорт и отчёты: CSV, PDF, исторические бары и scheduled reports требуют отдельного решения; право увидеть данные на экране не равно праву на массовое извлечение.
Пользовательский интерфейс должен честно объяснять ограничения, включая заметную маркировку delayed данных. Услуга UI/UX и продуктовый дизайн помогает встроить такие состояния, смену счёта и upgrade-flow без лишнего трения в торговом сценарии.
Кеширование без утечки доступа и быстрый отзыв
Проверять удалённую базу на каждый tick обычно слишком медленно и ненадёжно. Кеширование допустимо, но его границы нужно определить сознательно. В cache key должны входить субъект, выбранный счёт, канал, data product, релевантный instrument scope и версия политики. Ключ вида «у пользователя есть real-time» способен случайно перенести право между счетами, каналами или feeds.
Используйте сразу два механизма: короткий TTL и event-driven invalidation. Отмена подписки, неуспешный платёж, freeze счёта, изменение KYC, отключение пользователя или ручной disentitlement создают событие. Его потребители очищают кеш и активно закрывают либо понижают уже открытые подписки. Недостаточно отказать только в следующем запросе: активный stream может продолжать передавать данные слишком долго.
Зафиксируйте SLO на отзыв прав по каждому каналу: когда изменение влияет на новые запросы, текущие streams, кешированные экраны и фоновые выгрузки. Затем проверяйте этот сценарий под нагрузкой и при частичной недоступности зависимых сервисов.
Аудит и операционная поддержка
Необязательно хранить полный payload каждой котировки ради аудита. Обычно достаточно decision event: request ID, correlation ID, субъект и счёт, продукт, scope инструментов, канал, usage, решение, reason code, entitlement ID, версия политики, timestamp и событие-источник изменения. Операционная команда должна быстро отвечать на вопросы: у кого сейчас есть право, на каком основании оно выдано, когда истекает, что менялось недавно и почему запрос отклонён.
В dashboard должны быть видны всплески deny, число активных recipients по feed, задержка распространения отзыва, orphaned subscriptions, cache hit rate, latency оценки политики и ошибки интеграций. Это превращает договорно и коммерчески чувствительный контроль в управляемую операционную функцию. POLADO может настроить alerting, runbook, release gates и доказательства для инцидентов в рамках Техническая поддержка и консалтинг.
Checklist перед запуском
- Соберите все feeds, договоры, классы получателей, требования к отчётности и ограничения использования.
- Определите словарь разрешений: real-time, delayed, snapshot, display, non-display, API, export и redistribution.
- Явно смоделируйте scope пользователя, организации, счёта, сессии и инструмента.
- Назначьте канонический источник событий подписки, KYC, состояния счёта и ручных override.
- Опишите отзыв прав для новых запросов и для уже открытых streams.
- Обяжите все каналы и фоновые процессы обращаться к одному decision service.
- Спроектируйте recipient reporting, историю изменений и decision evidence до production rollout.
Итог: pricing engine может нормализовать и распространять цены, но не должен быть окончательным владельцем решения о праве на их использование. Entitlement-слой делает правила доступа едиными, объяснимыми и исполнимыми во всех каналах. POLADO может оценить ваши feeds, тарифы, состояния счетов и API, а затем спроектировать policy model, интеграции, аудит и поддержку, опираясь на опыт финансовой аналитики, например ESFX. Обратитесь за технической консультацией до того, как новый feed или клиентский tier умножит долг по контролю доступа.