Разработка ценового движка торговой платформы — это построение слоя, который превращает исходящие от поставщиков обновления в контролируемые исполнимые цены bid и ask. Это не функция графика. В production-системе необходимо корректно определить инструмент, привести сообщения разных вендоров к единой модели, выбрать допустимые исходные цены, применить утверждённые правила спреда или наценки, не допустить использования устаревшей цены и передать корректную котировку нужной аудитории.

Риск быстро растёт, когда брокерский или FinTech-продукт добавляет инструменты, поставщиков ликвидности, группы счетов либо white-label арендаторов. Ошибка в сопоставлении символов, событие вне последовательности, «зависший» фид или неверно назначенное правило наценки могут привести к инцидентам и сложным разбирательствам. Надёжный контроль ценообразования повышает операционную устойчивость, но не гарантирует торговый результат, качество исполнения при любых рыночных условиях или доходность.

За что должен отвечать ценовой движок

Надёжная архитектура разделяет сырые рыночные данные и опубликованную клиентскую котировку. Событие от поставщика сохраняется неизменным, а затем к нему последовательно применяются нормализация, выбор источника, защитные проверки и коммерческие правила. Благодаря этому команда может ответить и на вопрос «что прислал поставщик?», и на вопрос «какую цену получила конкретная группа клиентов?».

  • Приём фидов: получение FIX-, WebSocket-, streaming- или polling-событий с сохранением источника и порядка обновлений.
  • Нормализация: преобразование vendor-сообщения в единую внутреннюю модель инструмента и котировки.
  • Ценообразование: формирование валидного bid/ask из разрешённых источников по явной политике выбора.
  • Коммерческие правила: наценки, спреды, ограничения и округление для групп клиентов.
  • Дистрибуция: отправка snapshot и incremental updates авторизованным каналам и арендаторам.
  • Управление: версии правил, согласования, временные override и доказательная audit trail.

POLADO может спроектировать этот слой в рамках FinTech и trading-систем, а не распределять ценовую логику между API, клиентскими приложениями и таблицами back-office.

Сначала нормализуйте фиды, затем рассчитывайте цену

Символ поставщика не должен быть единственным источником истины. Один фид может использовать EURUSD, другой — EUR/USD, третий — внутренний код вендора. Даже одинаковое название не всегда означает один и тот же контракт: могут отличаться точность цены, размер контракта, валюта котировки, торговое расписание, тип инструмента или дата экспирации. Особенно это важно для металлов, индексов, CFD, криптоактивов и срочных инструментов.

Создайте внутренний реестр инструментов

Для каждого инструмента храните версионируемую внутреннюю запись: постоянный ID, отображаемый символ, класс актива, mapping поставщиков, tick size, точность цены, единицу объёма, параметры контракта, календарь сессий и политику ценообразования. Сопоставления должны быть проверяемой конфигурацией, а не набором исключений в коде.

Каждое входящее событие должно сохранять как минимум ID поставщика, ID инструмента у поставщика, source timestamp, время получения платформой, sequence либо update ID, ссылку на raw payload и результат валидации. Инкрементальные рыночные сообщения могут добавлять, изменять и удалять записи стакана. Если consumer просто перезаписывает «последнюю цену», он может сохранить удалённый уровень, применить изменение к неправильному состоянию или принять позднее событие после более нового.

Как строить валидные bid и ask

Движок может выбирать лучший допустимый bid и ask из нескольких источников, предпочитать primary provider или использовать composite с учётом оценки здоровья источника. Конкретная политика зависит от продукта, но она должна быть явной, детерминированной и покрытой тестами. До публикации необходимо проверить как минимум следующее:

  • bid и ask положительны, а bid не превышает ask;
  • итоговый спред находится в допустимых границах для инструмента;
  • движение цены не является выбросом относительно недавнего валидного состояния или сопоставимых источников;
  • событие не откатывает принятую последовательность или source time без утверждённого условия reset;
  • если для продукта важен размер, доступная ликвидность соответствует минимальному порогу.

Движок наценок брокера: настройки с аудитом и контролем изменений

Broker markup engine преобразует выбранную исходную или composite-котировку в цену для клиента. В простой модели к ask добавляется наценка, а из bid она вычитается. На практике правила часто зависят от инструмента, класса актива, группы счетов, региона, white-label арендатора, сессии и иногда от диапазона объёма.

Используйте fixed-decimal арифметику или эквивалентное аккуратно спроектированное представление цены. Двоичная floating-point арифметика может дать заметные расхождения при округлении. Необходимо также зафиксировать порядок расчёта: например, выбрать допустимую базовую цену, применить защитные границы, применить наценку и только затем округлить до точности инструмента. Другой порядок способен изменить опубликованную цену.

Правилам нужен governance, а не только форма администратора

  • Сохраняйте владельца правила, согласующего, время вступления в силу, область действия и версию.
  • Проверяйте существенные изменения в shadow mode, сравнивая их с действующей публикацией до активации.
  • Обеспечьте быстрый возврат к ранее одобренной версии.
  • Для ручных override фиксируйте причину, оператора и время истечения.
  • Задавайте максимальную наценку и минимальный спред, чтобы ошибка ввода не породила неправдоподобную цену.

Защита от устаревших котировок и fallback-фиды

Защита от stale quote на торговой платформе не должна опираться только на timestamp поставщика. Часы поставщика, задержка сети, очередь consumer и поведение при reconnect могут исказить оценку свежести. Храните source time, receive time и время последней успешной публикации. Затем задавайте пороги свежести для каждого инструмента и состояния рынка: для основной FX-пары во время активной сессии и для инструмента вне регулярной сессии они не должны быть одинаковыми.

При нарушении порога требуется заранее определённое поведение: сделать котировку недействительной, оставить её только как indicative для отображения, остановить публикацию исполнимых цен или заблокировать приём заявок по инструменту. Молча сохранять старую исполнимую цену как fallback — небезопасно.

Fallback должен быть объяснимым

Переключение на резервный источник не следует запускать только потому, что от него пришло последнее сообщение. Оценивайте возраст цены, частоту обновлений, crossed или аномальный спред, долю отклонённых событий, разрывы sequence, latency источника и coverage по инструментам. Логируйте причину переключения, активированный источник и причину возврата на primary provider.

Не смешивайте failover ценового фида и failover маршрутизации исполнения. Они могут использовать общие сигналы о здоровье поставщика, но pricing определяет видимую клиенту цену, а liquidity bridge или order-routing решает, куда направить принятую заявку.

Сессии, дистрибуция и наблюдаемость

Ценовой движок должен учитывать, открыт ли рынок, находится ли он в pre-open, rollover, раннем закрытии, maintenance или праздничной паузе. Последняя цена вне сессии не должна выглядеть как живая исполнимая котировка. Согласуйте pricing state machine с управлением торговыми сессиями, чтобы границы сессии одинаково влияли и на публикацию, и на приём заявок.

Для дистрибуции полезно хранить отдельные уровни raw, normalized, composite и client-group prices. Тогда система может отправлять entitlement-aware поток без повторного расчёта базовой цены для каждого подписчика. Заранее проектируйте reconnect snapshot, incremental updates, rate limiting, backpressure и resynchronisation: быстрый расчёт не решает проблему, если подписчик не способен восстановить согласованное состояние.

На операционной панели должны быть видны quote age, latency от источника до публикации, update rate, число отклонённых событий, активный источник, fallback state, спред, subscriber lag и результат наценки по инструменту и группе. Алерты должны обнаруживать деградацию фида до того, как в поддержку придёт скриншот клиента. Метрики дополняют, но не заменяют сохранённые события котировок и audit logs.

Свяжите цену с заявкой и исполнением

Передавайте в жизненный цикл заявки quote ID, версию pricing rule и ссылку на источник или composite в момент её принятия. При последующем разборе команда должна восстановить raw-событие, нормализованное состояние, выбранный источник, расчёт наценки, опубликованную котировку, время заявки и результат исполнения без догадок по разрозненным логам. Такой подход также делает ценовые данные полезнее для операционной аналитики, как в FinTech и analytics проекте ESFX.

Что определить до начала разработки

  1. Какие инструменты, поставщики, группы клиентов и каналы доставки входят в первый релиз?
  2. Кто отвечает за symbol mapping, precision, торговые календари и stale thresholds?
  3. Какова composite-политика: лучший допустимый bid/ask, primary-first или выбор по health score?
  4. По каким измерениям применяются наценки и кто утверждает их изменение?
  5. Что именно происходит при stale, crossed, outlier или unavailable quote?
  6. Как quote ID и версия правила сохраняются до исполнения и расследования?

POLADO может провести оценку текущих фидов, определить модель ценовых контролей, реализовать pipeline и операционные инструменты, а также проверить сценарии отказов до релиза. Начните с консультации по FinTech и trading-системам, чтобы обсудить инструменты, источники цен и правила для клиентских групп.