Разработка IB-системы для trading-платформы не сводится к реферальной ссылке, промокоду и виджету баланса. Брокеру или оператору trading-продукта нужна система, которая объясняет, кто привёл клиента, какое коммерческое соглашение действует, какое торговое или финансовое событие сформировало комиссию, когда она стала доступна к выплате и как выплата была сверена.
Ключевой принцип: маркетинговая атрибуция, расчёт комиссии и движение денег не должны жить в одной редактируемой записи. Атрибуцию могут исправить, торговые данные могут быть скорректированы, rebate может быть начислен позже, а выплату — оспорить. Поэтому исходные факты необходимо сохранять, а изменения фиксировать отдельными, прослеживаемыми событиями, а не переписывать историю.
POLADO проектирует такую операционную инфраструктуру в рамках услуги FinTech и trading-системы, связывая партнёрский слой с торговой платформой, CRM, KYC, wallet и back-office. Пример работы с FinTech и аналитическими продуктами — проект ESFX.
Какие вопросы должна закрывать IB-система
Термины Introducing Broker, affiliate, агент и региональный партнёр могут иметь разный коммерческий и регуляторный смысл в зависимости от юрисдикции и модели работы. Например, на рынке фьючерсов США Introducing Broker является отдельной категорией посредника. Модель продукта может создавать требования к регистрации, раскрытию информации, AML, хранению записей или правилам ведения деятельности. Комиссионный модуль помогает выстроить операции, но не заменяет юридическую и compliance-оценку.
На уровне продукта и операций система должна однозначно отвечать на вопросы:
- Какому партнёру принадлежит связь с конкретным клиентом или trading account?
- Какое правило атрибуции и какое доказательство установили эту связь?
- Основана ли комиссия на депозитах, лотах, nominal volume, net trading fee, spread revenue, swap или гибридной формуле?
- Когда доход является предварительным, одобренным, доступным к выплате, выплаченным, отменённым или спорным?
- Что происходит после отмены сделки, корректировки комиссии, возврата клиенту, chargeback или проверки на fraud?
- Можно ли сверить каждую выплату партнёру с конкретными начислениями и исходными событиями?
На эти вопросы нельзя надёжно ответить одним dashboard. Ответы должны быть заложены в модель данных, версии правил, журнал событий и процесс reconciliation.
Не сводите атрибуцию к полю с промокодом
Промокод — лишь один из сигналов атрибуции. Полноценная архитектура introducing broker platform development должна принимать реферальные ссылки, коды при регистрации, связь с приглашённым пользователем, лиды из CRM, импорт через API и контролируемое ручное назначение из back-office.
Что хранить в записи атрибуции
- Объект: клиент, юридическое лицо или идентификатор торгового счёта;
- Партнёр: IB, master IB, affiliate или агент;
- Источник: ссылка, код, импорт CRM или подтверждённое ручное назначение;
- Период действия: дата и время начала и окончания;
- Правило и доказательство: применённая политика, кампания и ссылка на основание;
- Статус: pending, active, locked, superseded или disputed.
Представим, что клиент зарегистрировался по ссылке Партнёра A, но до завершения KYC команда продаж вручную закрепила его за Партнёром B. Безопасная система не оставляет просто последнее изменение. Она применяет утверждённую политику атрибуции, фиксирует момент вступления решения в силу и сохраняет причину изменения прежней связи. Один и тот же revenue event не должен платить двум партнёрам, если нет явного правила split commission.
Настраиваемые, но версионируемые планы комиссий
Trading partner commission software должно давать коммерческой команде управляемую гибкость, но не позволять незаметно изменить уже рассчитанный доход. Для этого разделите сущности commission plan и commission plan version.
План может включать уровень партнёра, группу инструментов, тип счёта, регион, сегмент клиента, условия eligibility, hold period, валюту выплаты и параметры формулы. При изменении условий действующая версия закрывается, а новая создаётся с датой начала действия. Каждое событие дохода обязано хранить именно ту версию плана, по которой оно было рассчитано.
Модели, которые может поддерживать движок
- Фиксированная сумма за лот или определённую единицу объёма;
- Процент от чётко определённой базы eligible revenue;
- Разные ставки по инструменту, типу счёта, региону или уровню клиента;
- Прозрачное распределение между master IB и sub-IB в multi-level affiliate commission engine;
- Пороги, лимиты и прогрессивные месячные уровни;
- Гибридные правила, объединяющие квалифицированное пополнение и trading activity.
Термин «доход» должен быть определён внутри плана, а не в предположении Excel-файла. Gross commission, net trading fee, spread mark-up, swap income и доход после client rebates — разные базы. В формуле нужно также определить округление, дату конвертации валюты, отрицательные корректировки и поведение при отмене исходного события после закрытия payout period.
Используйте неизменяемые события дохода, а не редактируемый баланс
Надёжная модель получает исходные события: исполнения сделок, проводки комиссий, settled deposits, начисления rebate, корректировки и reversals. Комиссионный сервис определяет атрибуцию и действующую версию плана, после чего создаёт earning event.
Как минимум earning event должен хранить ID исходного события, ID клиента и счёта, ID партнёра, версию плана, входные данные расчёта, рассчитанную сумму, валюту, статус и временные метки. Idempotency key защищает от повторного начисления, если сообщение об исполнении или callback провайдера было доставлено повторно.
Если сделка отменена или комиссия исправлена, не удаляйте первоначальное начисление. Создайте связанное событие reversal или adjustment. Так изменение баланса становится понятным партнёру, а финансовая команда получает проверяемый след для trading platform rebate calculation и сверки выплат.
Исходные факты должны сохраняться; текущая сумма к выплате должна выводиться из первоначального начисления и утверждённых событий корректировки.
Разделите расчёт, согласование и выплату
Рассчитанная комиссия не равна комиссии, доступной к выплате. Практичный жизненный цикл выглядит так: calculated → pending hold/review → approved → payable → paid. Для disputed, rejected, reversed и expired позиций нужны отдельные состояния.
Правила согласования могут направлять рискованные комбинации в операционную очередь: первая выплата новому партнёру, необычно крупная сумма, аномальный торговый объём, несколько счетов с общими платёжными реквизитами, доход после chargeback или ручное изменение атрибуции. Утверждающий сотрудник должен записывать причину решения, свой идентификатор и timestamp; простого изменения статуса недостаточно.
При формировании payout batch система выбирает approved earnings, исключает позиции на hold и disputed, считает net payable по партнёру и создаёт payout reference. Затем результаты банка, wallet или payment provider необходимо сопоставить с batch. Статус “paid” должен означать сверенное завершение фактической выплаты, а не только создание файла экспорта.
Что показывать в партнёрском кабинете
IB portal development for brokers требует прозрачности без раскрытия лишних клиентских данных, внутренних маржин или показателей других партнёров. Кабинет должен показывать данные, разрешённые договором, и объяснять происхождение каждого баланса.
- Referral funnel: leads, registrations, KYC state и активные торговые счета;
- Eligible trading activity или volume, если это предусмотрено договором;
- Pending, approved, payable и paid earnings;
- Детализацию по дате, группе счетов, инструменту и плану;
- Причины adjustments и reversals;
- Историю выплат, references и документы для скачивания;
- Профиль партнёра, платёжные реквизиты и необходимые compliance-документы.
Для каждого итогового показателя нужен путь детализации: summary → earning event → source event → applied plan version. Тогда support, finance и compliance работают с одними фактами, а не пытаются свести разные таблицы.
Чек-лист реализации
- Определите авторитетные торговые события: executions, fees, corrections, изменения статуса счёта и reversals.
- Нормализуйте идентичность клиента, KYC eligibility и mapping счетов между CRM, KYC и trading-системой.
- Зафиксируйте приоритет атрибуции, правила переназначения, lock periods и split commission policy.
- Версионируйте commission plans и не перезаписывайте правила исторических начислений.
- Храните audit trail для source events, earnings, approvals, adjustments и payouts.
- Тестируйте duplicate events, задержанные callbacks, частичные сбои, retry и повторную доставку сообщений.
- Ежедневно сверяйте totals исходных систем с earned, approved, payable и paid totals.
- Применяйте role-based access, maker-checker controls и защиту payout-данных и выгрузок.
IB-система — не маркетинговое дополнение. Она затрагивает финансовые операции, идентичность клиента, торговые данные и платёжные контроли. Проектирование рядом с fee engine, ledger, KYC-статусами и back-office workflow даёт более надёжную партнёрскую программу и существенно упрощает разбор спорных случаев.
Как POLADO помогает определить scope
POLADO может помочь описать модель атрибуции, версии commission plans, интеграции с источниками событий, партнёрский кабинет, очереди согласования и payout reconciliation для действующего или нового trading-продукта. Обычно правильный первый этап — техническое и операционное discovery: определить системы-источники, исключения, контроли и зоны ответственности до начала разработки. Для review архитектуры, мониторинга и управляемых релизов после запуска доступна услуга Техническая поддержка и консалтинг.
Если вам нужна не очередная реферальная страница, а проверяемый слой партнёрских операций, свяжитесь с POLADO, чтобы обсудить вашу trading-платформу, доступные API, процесс выплат и регуляторные ограничения. Цель — создать объяснимую комиссионную систему, которую команда операций может сверить, а партнёры — понимать и использовать с доверием.