Разработка instrument master для торговой платформы — это создание управляемого источника истины для каждого торгуемого инструмента: идентификаторов, символов, спецификаций контракта, торговых правил, статуса жизненного цикла и версий с датами действия. Это не просто форма «добавить тикер» в админ-панели. Корректно спроектированный instrument master синхронизирует котирование, исполнение, маржу, комиссии, риск, отчётность и клиентские каналы.
Без такого контура один и тот же продукт быстро получает несколько противоречивых описаний. В мобильном приложении может отображаться одна точность цены, шлюз заявок может принимать другой шаг объёма, а сервис маржи — использовать устаревший размер контракта. Это уже не косметическая ошибка данных: возможны отклонённые заявки, неверный P&L, некорректные выписки и ручные исправления. В рамках FinTech и trading-систем POLADO мы рассматриваем конфигурацию инструментов как базовый домен платформы, а не набор разрозненных настроек.
Какие данные должны быть в instrument master?
Символ, который видит клиент, например EURUSD, XAUUSD или AAPL, — только короткая метка. Платформа должна однозначно понимать экономическую сущность инструмента, источники цен и исполнения, допустимые действия и версию правил, действовавшую в конкретный момент времени.
Постоянный внутренний ID и маппинг внешних кодов
Для каждого инструмента нужен неизменяемый внутренний ID. Отдельно храните отображаемый символ, код площадки, символ провайдера ликвидности, символ поставщика market data, FIX SecurityID, ISIN, CFI, MIC и иные внешние идентификаторы. Стандарт ISO 10962 определяет структуру CFI для международной классификации финансовых инструментов. Он полезен для классификации, но не заменяет внутренний стабильный ключ платформы.
Модель должна поддерживать связь many-to-many: у одного внутреннего продукта допустимо несколько внешних представлений. Например, внутренний CFD на технологический индекс США может иметь один символ в ценовом фиде, другой — на стороне исполнения, а третий идентификатор — в отчётности. Для каждого mapping храните источник, значение, тип, приоритет, статус проверки, период действия и аудит изменений. Тогда смена вендора или переименование символа становится контролируемой операцией, а не поиском и заменой по production-базе.
Общая схема и типизированные расширения по классам активов
Создайте общий слой для названия, класса актива, статуса, площадки, валюты котировки, валюты расчёта и часового пояса. Поверх него применяйте типизированные расширения. Набор произвольных JSON-настроек кажется гибким, но усложняет валидацию, отчётность и интеграционные контракты.
- FX и spot metals: базовая и котируемая валюты, pip precision, правила расчётов, rollover и группа финансирования.
- CFD: базовый актив, размер контракта, обработка корпоративных событий и финансирование.
- Фьючерсы: expiry, последний день торговли, поставочный или расчётный тип, multiplier, контрактный месяц и связь с continuous contract.
- Опционы: underlying, call/put, strike, expiry, стиль исполнения и multiplier.
- Акции и ETF: идентификаторы ценной бумаги, основная площадка листинга, правила лота и применимость корпоративных действий.
Обязательные поля и проверки должны зависеть от класса актива. Нельзя активировать фьючерс без логики expiry или опцион без strike и типа права.
Спецификация контракта должна управлять расчётами
Contract specification management становится рискованным, когда одинаковые экономические параметры копируются между сервисами. Tick size, точность цены, точность количества, минимальный и максимальный объём заявки, шаг объёма, размер контракта, multiplier, валюта котировки и валюта расчёта связаны между собой. Если pricing, order validation и margin используют разные значения, под одним символом фактически существуют разные инструменты.
Например, если минимальный шаг цены равен 0,01, multiplier равен 100, а позиция составляет два контракта, изменение на один tick должно одинаково отражаться в P&L во всех расчётах. В документации FIX для биржевых деривативов отдельно описана связь между minimum price increment и contract value factor. Следовательно, условия контракта должны быть версионируемыми входными данными расчётов, а не только текстом в карточке продукта.
Повторно используемые наборы правил
Не копируйте все правила в каждую карточку инструмента. Создавайте отдельные профили: расписание regular trading для акций, календарь праздников для металлов, execution policy для retail FX, набор маржинальных уровней. Затем привязывайте к инструменту конкретную версию профиля. Это упрощает управление торговыми сессиями, доступными типами заявок, режимом close-only, leverage, ограничениями short selling и доступностью по регионам.
Важно разделять зоны ответственности: сервис сессий отвечает на вопрос, открыт ли рынок сейчас; instrument master определяет, какое расписание и календарь относятся к данной версии инструмента. Risk и margin сервисы должны получать утверждённые параметры из master data, а не поддерживать собственные вручную скопированные списки.
Явная модель жизненного цикла инструмента
Флаг enabled/disabled не описывает реальный жизненный цикл. Практическая модель отделяет бизнес-статусы и разрешённые действия:
- Draft: конфигурация создаётся и ещё не видна production-потребителям.
- Pending approval: maker отправил новую версию на независимую проверку.
- Scheduled: версия утверждена, но ожидает даты и времени вступления в силу.
- Active: инструмент доступен для разрешённых операций котирования, торговли и отображения клиенту.
- Close-only / reduce-only: новое увеличение экспозиции запрещено, существующие позиции можно закрывать или сокращать.
- Suspended: торговля, котирование либо оба процесса временно остановлены.
- Expired, delisted или archived: новые операции невозможны, но история сохраняется для отчётности и аудита.
Expiry фьючерса, rollover CFD, изменение symbol mapping и пересмотр маржинального параметра могут использовать единый механизм версий, но должны иметь разные политики влияния и утверждения. Не перезаписывайте активную запись. Создавайте новую версию, чтобы сделку, маржинальное решение или клиентскую выписку можно было восстановить по условиям, действовавшим в момент события.
Maker-checker, даты действия и аудит
Для критичных изменений необходимы разделение обязанностей, проверяемый diff, плановое включение и безопасный rollback. Maker предлагает новую версию. Checker видит изменения по полям, зависимости и предупреждения о влиянии до утверждения. Решение формирует неизменяемое audit-событие: старые и новые значения, пользователей, время, reason code и результат проверки.
Храните effective timestamp в UTC, а в операционном интерфейсе показывайте локальное время с явным указанием зоны. Блокируйте пересекающиеся интервалы действия одной характеристики одного инструмента. Для срочных исправлений используйте отдельный break-glass процесс с ограниченным доступом, обязательным обоснованием, последующей проверкой и регистрацией инцидента — а не общий admin override.
Конфигурация инструмента должна управляться как production-изменение: проверка, версия, плановое применение, наблюдение и возможность отката.
Распространение изменений и сверка downstream-систем
Прямое чтение общей базы данных не подходит всем потребителям. У pricing, execution, risk, reporting и клиентских приложений разные требования к задержке, доступности и кэшированию. Более надёжный подход — публиковать утверждённые события с номером версии, например InstrumentVersionActivated и InstrumentTradingStatusChanged, а потребителям позволять строить собственные проекции.
Факт отправки события не доказывает согласованность платформы. Каждый обязательный consumer должен подтвердить применённую версию. Операционная команда должна видеть: pricing применил версию 184, margin — версию 184, client API — версию 184; ошибка любого consumer должна быть заметной. Идемпотентные обработчики, номера версий, checksum, retry и dead-letter процесс защищают от двойного применения и тихой потери сообщения.
Проверка перед публикацией
- Заполнены ли обязательные атрибуты для класса актива и торговой модели?
- Совместимы ли tick size, точность, лимиты объёма и размер контракта?
- Разрешается ли каждый production mapping в соответствующем источнике market data или исполнения?
- Поддержаны ли зависимости конвертации для валют котировки, расчёта, комиссий и маржи?
- Проверены ли новые leverage или margin параметры вместе с limit и liquidation логикой?
- Не пересекается ли момент вступления в силу с сессией, rollover, cut-off или batch-процессом?
- Прошли ли обязательные downstream-системы preview или проверку интеграционного контракта?
Back-office UX для безопасной работы
Длинная админ-форма не является контролем. Начинайте с обзора инструмента: активная версия, ближайшее запланированное изменение, lifecycle status, внешние mapping и состояние применения в downstream-системах. Далее ведите пользователя по разделам для конкретного класса актива, валидациям, preview mapping и очереди утверждений.
Нужны два режима сравнения: построчный diff активной и предлагаемой версии, а также сверка версии master data с версиями, применёнными каждым consumer. Это особенно важно в насыщенных финансово-аналитических продуктах наподобие ESFX, где удобство сканирования и безопасные действия оператора не менее важны, чем сама модель данных.
Критерии приёмки для владельца платформы
Не принимайте функцию только потому, что администратор способен создать символ. Платформа должна позволять создать draft, привязать исходные идентификаторы, проверить спецификацию контракта по классу актива, провести независимое утверждение, запланировать активацию, опубликовать версионное изменение и показать статус применения по каждому consumer. Исторические сделки и отчёты должны восстанавливаться по версии инструмента, действовавшей на дату события.
Если вы создаёте или масштабируете брокерскую, CFD или multi-asset платформу, определите instrument master до того, как pricing, order и margin модули закрепят собственные настройки продуктов в коде. Свяжитесь с POLADO для консультации: мы поможем провести аудит текущей конфигурации, спроектировать target schema, maker-checker workflow, контракты событий и поэтапный план реализации.