Trading platform fee engine development — это не простое умножение объёма сделки на ставку. Надёжная платформа должна объяснять каждую комиссию, своп, rebate и ручную корректировку: какое правило сработало, какая версия была активна, какой FX-курс использован, как выполнено округление и почему результат был пересчитан. Без такой цепочки доказательств модуль комиссий быстро становится причиной споров по выпискам, ручных таблиц и труднообратимых расхождений по балансу.

Для брокера, prop-trading продукта или мультиактивной платформы fee engine стоит проектировать как самостоятельный компонент с правилами. Он интегрируется с исполнениями, позициями, счетами, кампаниями, связями introducing broker, параметрами инструментов и ledger, но не должен быть скрыт внутри одного из этих модулей. FinTech и trading-системы POLADO охватывают проектирование таких компонентов вместе с back-office процессами и интеграциями.

Разделяйте правило и результат расчёта

Фраза «7 USD за лот EURUSD» не является моделью для реализации. Машиночитаемый тариф должен быть структурированным. Для каждого правила нужны как минимум: rule ID, версия, статус жизненного цикла, интервал действия, приоритет, условия eligibility, формула, валюта начисления, политика округления и данные согласования.

Результат должен быть immutable calculation record, а не редактируемым полем сделки. Храните snapshot входных данных, выбранную версию правила, параметры формулы, промежуточные значения, сведения о FX-конвертации, итог, статус и correlation ID. Изменение коммерческого тарифа не должно молча менять исторические начисления. Новое расписание действует с указанного времени; исправление прошлого периода оформляется отдельным adjustment или управляемым recalculation.

Что версионировать в тарифе

  • Комиссии: за лот, контракт, единицу или notional; процент; фиксированная сумма; минимумы и лимиты.
  • Overnight financing: направление long/short, группа инструмента, rollover cut-off, day multiplier, календарь праздников и day-count convention.
  • Rebate: скидки клиенту, промо-кредиты, liquidity incentives или доля introducing broker.
  • Дополнительные сборы: биржевые, регуляторные, custody или platform fee как отдельные компоненты.
  • Округление: этап применения, точность и обработка остатка.

Модель по компонентам полезна и для post-trade интеграций. В материалах FIX commission и другие transaction fee представлены раздельно, а не как единая непрозрачная сумма. Внутренняя модель платформы должна сохранять это различие.

Eligibility и приоритет должны быть детерминированными

Одна сделка может соответствовать нескольким тарифам: tenant default, pricing для account group, VIP volume tier, исключение для инструмента и кампания. Нельзя выбирать «первое найденное правило». Нужна документированная и тестируемая политика выбора.

Последовательность может учитывать юридическое лицо и tenant; account и account group; инструмент и instrument group; сторону; venue; timestamp сделки; volume tier; кампанию; затем явный priority. Если после этого остаются два равноприоритетных правила, engine должен вернуть configuration exception, а не списать средства. Иначе порядок создания настроек администратором сможет незаметно менять финансовый результат.

Volume tiers должны фиксироваться в момент расчёта

Определите период измерения: календарный месяц, rolling 30 days, settlement month или собственный цикл брокера. Опишите, какие события входят в объём: отменённые fills, corrections, internal transfers, операции тестовых счетов. Для сделки сохраняйте tier basis и выбранный tier. Новый уровень, достигнутый позднее, не должен переписывать старые комиссии, если ретроактивное ценообразование прямо не предусмотрено договором.

Сделайте комиссию, конвертацию и своп объяснимыми

Надёжное broker commission calculation software хранит не только итог, но и путь к нему. Например, сделка объёмом 2,4 лота по ставке 3,50 USD за лот даёт 8,40 USD. Если валюта счёта EUR, система должна сохранить курс 0,9200, источник, timestamp, направление котировки и правило округления. Значение 7,728 EUR превращается в 7,73 EUR только по видимой политике, а не из-за неявной детали кода.

Не используйте неопределённый «последний курс». Правило должно задавать источник, bid/ask/mid, время valuation и fallback-поведение. Если допустимого курса нет, система не должна молча подставлять оценку. Создайте pending valuation или операционное исключение, которое можно закрыть с подтверждением.

Trading swap calculation engine рассчитывает начисление по snapshot открытой позиции, а не только по исходному fill. В момент rollover cut-off фиксируйте открытую quantity, сторону, параметры финансирования, multiplier инструмента и календарный контекст. Не зашивайте в код практики вроде midweek multiplier: настраивайте их на уровне инструмента или market calendar. При поздней correction позиции или пересечении cut-off применяйте заранее выбранную политику: reverse-and-replace, delta adjustment либо контролируемый recalculation.

IB rebate и ручные корректировки — отдельные финансовые события

Для introducing broker rebate system development недостаточно хранить referral relationship только в текущем профиле счёта. В момент обработки сделки фиксируйте IB, кампанию, rate plan, basis распределения, валюту выплаты, clawback conditions и settlement status. Это сохраняет историческую атрибуцию, когда связь счёта с IB позднее меняется.

Ручная корректировка не должна быть прямым редактированием баланса. Нужны adjustment type, сумма, валюта, reason code, связанный trade/position/calculation ID, подтверждающий документ и статус approval. В maker-checker процессе автор не должен утверждать собственную корректировку. Вместо перезаписи исходного начисления создавайте reversal event или delta event.

Ledger-события и сверка — операционное доказательство

Создавайте явные события: fee assessed, fee posted, fee reversed, rebate accrued, rebate paid и adjustment posted. Для каждого нужны idempotency key, business date, event timestamp, source trade ID, rule version и calculation ID. Ledger entries должны формироваться из этих событий, чтобы сумма в интерфейсе, клиентская выписка, экспорт и интеграция с GL опирались на одну цепочку записей.

Trading fee reconciliation должна работать на трёх уровнях:

  1. Execution-to-fee: для каждого eligible fill и rollover snapshot создан необходимый расчёт?
  2. Fee-to-ledger: каждое финальное начисление проведено ровно один раз в верный счёт и валюту?
  3. Internal-to-external: совпадают ли внутренние компоненты с данными venue, liquidity provider, clearing broker или банка?

Расхождения следует разбирать по компоненту, валюте, trade ID, value date и reason code, а не только по net total. Post-trade стандарты отдельно рассматривают cancel и correction flows; такая же декомпозиция в fee domain делает сверку и поддержку значительно управляемее.

Что проверить до релиза

  • Partial fills, cancel/replace и trade corrections.
  • Сделки по обе стороны границы effective time нового тарифа.
  • Minimum fee, cap, negative rebate и multi-component charges.
  • Валюты начисления и выплат, отличающиеся от валюты счёта.
  • Отсутствие курса: fallback и exception workflow.
  • Праздничный rollover, weekend multipliers и границы close/open cut-off.
  • Retry, который не создаёт duplicate posting.
  • Доказательство, что новая версия правила влияет только на целевую population.

POLADO может реализовать fee engine как продуктовый компонент, связанный с order-state обработкой, immutable ledger, reporting и back-office approvals, а не как изолированный калькулятор. Посмотрите FinTech-проекты FT10 и ESFX. Если вы планируете broker commission calculation software, swap-модуль или слой reconciliation, запросите FinTech-консультацию: определим event flow, тарифные правила, исключения и безопасный поэтапный план реализации.