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

Котировка не является автоматически «публичным» объектом приложения. Один и тот же инструмент может быть доступен одному клиенту в real-time, другому — с задержкой, третьему — только как end-of-day данные, а четвёртому — не показываться вовсе. Права на отображение, API-выдачу, экспорт файла, расчёт алерта и машинное использование данных могут различаться. Конкретные правила определяют договоры биржи, поставщика и клиента; entitlement-слой нужен, чтобы технически и последовательно исполнять настроенные условия.

Описывайте право как контекстное решение, а не как название тарифа

Роли trader, analyst и admin полезны для продуктовых сценариев, но слишком грубы для лицензируемых рыночных данных. Проверка должна учитывать:

  • Субъект: пользователь, service account или конкретный сотрудник организации;
  • Tenant и аккаунт: у одного человека могут быть разные подписки в разных компаниях;
  • Продукт данных: quote, trade, top of book, depth, reference data, история или производная аналитика;
  • Рыночный охват: площадка, MIC, класс активов, набор инструментов либо отдельный инструмент;
  • Актуальность: real-time, delayed или end-of-day;
  • Действие: показ, чтение через API, экспорт, вычисление алерта, webhook, вход модели или проверка перед исполнением;
  • Условия: версия соглашения, профессиональный статус, территория, лимит устройств/сессий и срок действия.

Разделяйте роли в приложении и entitlements на данные. Тогда администратор поддержки сможет остановить подписку организации на конкретный depth feed, не меняя остальные возможности пользователя. И наоборот: пользователь может видеть delayed-котировки, но не иметь права экспортировать их, строить по ним алерты или передавать в автоматический workflow.

Разделите справочник инструментов и каталог лицензируемых data products

Справочник инструментов отвечает за symbol mapping, ISIN, валюту, класс активов, площадку и статус торгов. Этого недостаточно для контроля лицензий. Нужен отдельный каталог data products, например «акции площадки A, real-time top-of-book для display» и «акции площадки A, delayed display». Каждый продукт связывается с определённым universe инструментов и разрешёнными действиями.

В предметной модели должны быть как минимум:

  • Entitlement grant: субъект, продукт, разрешённые действия, период действия, статус и источник выдачи;
  • Agreement acceptance: версия договора, время принятия и доказательство, привязанное к пользователю или организации;
  • Usage policy: лимиты экспорта, ограничения параллельных сессий, география и условия display/non-display;
  • Decision record: входные параметры, результат, причина и версия policy, использованная при проверке.

Такое разделение делает систему устойчивее к изменению символов у поставщика, расширению списка инструментов и появлению новых коммерческих пакетов. В guidance ESMA delayed data в соответствующем контексте описываются как данные, предоставляемые через 15 минут после публикации. Не превращайте это в универсальную константу: задержка должна быть настройкой конкретного data product, а её статус должен быть ясно показан в интерфейсе.

Один центр принятия решений, контроль на каждом канале

Скрытая кнопка графика во frontend не является контролем доступа. Web-кабинет, мобильное приложение, REST/GraphQL API, websocket gateway, задача экспорта и worker алертов должны получать одинаковый ответ.

Практическая архитектура использует центральный Policy Decision Point (PDP), который отвечает на вопрос: «Может ли субъект S выполнить действие A с продуктом P для инструмента I сейчас?» API gateway, сервис данных, streaming gateway, export worker и notification worker работают как Policy Enforcement Points (PEP). Для чувствительных действий они обращаются к PDP напрямую либо проверяют короткоживущий подписанный entitlement token, выпущенный той же логикой.

Не ограничивайте token общим claim вида premium=true. Включите tenant, коды продуктов, действия, версию policy и короткий срок жизни. Проверяйте доступ при открытии stream, а затем подписывайтесь на события изменения entitlement. При отзыве доступа необходимо закрыть затронутые websocket-подписки, отменить ожидающие exports и заставить alert/automation worker повторно проверить право перед следующим использованием данных.

Проводите границы кэша по уровням прав

Типичный путь утечки — серверный кэш с ключом только по symbol и interval. Если в нём оказался real-time результат, delayed-подписчик может получить неверный уровень данных, даже если UI показывает отметку «delayed». Ключ кэша должен различать как минимум data product или freshness tier, рыночный охват, а при необходимости tenant и разрешённую цель.

Более безопасный паттерн: хранить raw feed только в доверенной backend-зоне, применять entitlement-фильтр до формирования клиентского ответа и отдельно кэшировать уже отфильтрованное представление. В streaming не публикуйте один общий topic наподобие quotes:AAPL. Subscription service должен подключать клиента к внутреннему каналу, выбранному на основе разрешённого tier; клиент не выбирает напрямую vendor feed или широкий broadcast-topic.

Та же логика действует для алертов. Проверки при создании алерта недостаточно. Когда условие срабатывает, worker обязан подтвердить, что лицензия и право на доставку ещё действуют и что отозванный пользователь или tenant не получит уведомление на основе данных, которыми больше не вправе пользоваться.

Экспорт, non-display и право «действовать» — разные разрешения

Разрешение показать котировку не означает разрешение создать CSV, отправить отчёт по email или отдать ответ API для дальнейшего распространения. Моделируйте export отдельным action с ограничениями на формат, число строк, диапазон дат, получателя и срок доступа. Генерируйте файл на сервере, фиксируйте запрос, выдавайте короткоживущую ссылку и блокируйте ещё не скачанные файлы при отзыве связанного права.

Non-display использование также требует отдельного action. Система может читать данные для контроля риска, генерации сигнала, smart routing, model input или автоматизации — и это отличается от просмотра человеком на графике. Отделите право действовать от права видеть цену: подписчик может иметь право на display, но не на запуск data-driven alert, webhook или order workflow. Материалы биржевых политик продолжают различать display и non-display use, поэтому нельзя считать, что одна категория подписки автоматически покрывает оба сценария.

Сделайте аудит воспроизводимым

Audit log нужен не только для безопасности. Он помогает поддержке, сверке биллинга, операционной отчётности и разбору решений системы. Для каждого решения сохраняйте субъект, tenant, продукт, scope площадки/инструмента, action, результат, reason code, версию policy, correlation ID и timestamp. Не записывайте в журнал котировки или повторно используемые credentials без отдельной защищённой необходимости.

Команда эксплуатации должна уметь ответить: «Какой tier был доступен этому пользователю в конкретную дату?», «Почему экспорт отклонён?», «За какое время отзыв прав дошёл до активных сессий?» и «Какой service account потреблял non-display data?» Это естественная часть архитектуры FinTech и trading-систем. Для аналитических продуктов уровня ESFX особенно важны происхождение данных, пользовательский контекст и согласованное поведение интерфейса.

Чек-лист перед релизом permission system

  • Для каждого data product явно определены действия display, API, export, alert и non-display.
  • Real-time и delayed payloads визуально различаются и не пересекаются в кэше.
  • Web, mobile, API, websocket и background services используют одну модель решения.
  • Изменение подписки, договора, статуса пользователя или организации создаёт событие revocation.
  • Активные streams, exports и alerts повторно проверяются после отзыва прав.
  • Audit events сохраняют причину решения и действовавшую на тот момент версию policy.
  • Юридическая и операционная команды сопоставили конкретные условия поставщика или площадки с настраиваемыми продуктами и policy.

Проектируйте entitlement layer как границу распространения данных, а не как поздний feature flag. POLADO может помочь спроектировать новый market-data продукт, провести аудит существующей модели прав или внедрить единый контроль в клиентских приложениях и backend-сервисах. Свяжитесь с нами, чтобы обсудить ваши feeds, типы подписчиков и операционные требования.