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

Для брокера или FinTech-продукта этот слой должен давать однозначные ответы: какие счета принадлежат клиенту, какая версия торговой группы действует, может ли счёт выставить новый ордер сейчас, почему изменилось кредитное плечо, кто и на каком основании приостановил торговлю, а также подтвердил ли внешний сервер применение ограничения.

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

За что отвечает account management

KYC onboarding отвечает за идентификацию, проверку документов и решение по комплаенсу. Торговый сервер обычно является источником фактов об исполнении, ордерах и позициях. Сервис риск-контроля оценивает экспозицию и ограничения. Финансовый ledger должен быть источником истины по денежным движениям и балансу.

Сервис управления счетами координирует эти системы, но не должен становиться неконтролируемой копией каждой из них. Его зона ответственности: внутренний идентификатор счёта, связь клиент—счёт, lifecycle status, торговая группа, права на инструменты, привязка менеджера, история конфигурации и audit trail. При этом он хранит устойчивые связи с CRM-профилем, KYC-кейсом, счётом на торговом сервере, кошельком или ledger-счётом.

Такое разделение исключает опасную подмену источников данных. Back office может показывать баланс или позиции, но должен указывать их источник и актуальность, а не незаметно менять данные ledger или восстанавливать позиции из неполных событий.

POLADO проектирует такие слои в рамках услуги FinTech и trading-системы. Примеры FinTech-направления можно посмотреть в проектах FT10 и ESFX.

Опишите жизненный цикл счёта как конечный автомат

Набор флагов вроде is_active, is_verified и is_blocked быстро создаёт противоречивые комбинации. Надёжнее использовать формальную state machine: у счёта одно текущее состояние, у каждого перехода есть причина, а разрешены только заранее определённые переходы.

Практичный набор статусов

  • requested — заявка на счёт создана, provisioning ещё не начат;
  • pending_review — ожидается решение KYC, комплаенса или операционной команды;
  • provisioning — создаётся и настраивается счёт на внешнем торговом сервере;
  • ready — технически счёт создан, но условия активации ещё не выполнены;
  • active — разрешены операции в рамках группы и риск-политики;
  • trading_restricted — доступ к кабинету или отчётам может сохраняться, но новые сделки запрещены или ограничены;
  • suspended — действует временная блокировка по риску, комплаенсу или операционной причине;
  • closing — новая активность остановлена до закрытия позиций, сверки средств и зависимостей;
  • closed — счёт остаётся исторической записью и не принимает обычные изменения.

Значение имеет не только название статуса, но и правило перехода. Переход active → suspended может быть экстренным действием риск-службы. Возврат suspended → active может требовать заключения, второго согласования и подтверждения от торгового сервера. Повторно активировать закрытый счёт обычно не следует: безопаснее открыть новый и сохранить старый как неизменяемую историю.

Торговая группа — это версионируемый пакет правил

В интерфейсе trading group часто выглядит как короткий ярлык — например, «Retail USD» или «Pro FX». На практике это пакет политик: валюта счёта, доступные инструменты, границы плеча, лимиты объёма, торговые сессии, комиссии и swap, stop-out, права на market data и правила маршрутизации исполнения.

Не стоит заставлять каждый счёт читать изменяемую текущую конфигурацию группы без истории. Одно изменение общей группы может незаметно изменить условия тысяч клиентов. Вместо этого создавайте неизменяемые версии группы и фиксируйте, какая именно версия назначена счёту и с какого момента она действует.

Минимальные сущности конфигурации

  • group template — бизнес-идентификатор торговой группы;
  • group version — неизменяемый снимок правил и период действия;
  • account assignment — связь счёта с конкретной версией;
  • instrument entitlement — права по символу, классу активов, площадке или сессии;
  • account exception — узкое согласованное исключение из общей политики;
  • approval record — инициатор, согласующий, причина, доказательства и срок действия исключения.

Исключения должны быть минимальными и, когда это возможно, ограниченными по времени. Накопление постоянных индивидуальных override-ов превращает конфигурацию в непрозрачную и плохо тестируемую систему.

Изменение плеча, валюты и инструментов требует контроля с учётом исполнения

Кредитное плечо — не обычное поле профиля. При открытых позициях или отложенных ордерах его изменение может повлиять на требуемую маржу, риск-профиль и downstream-контроли. До принятия команды система должна получить risk preview на основе текущих позиций, equity, используемой маржи и лимитов. Итогом может быть немедленное применение, применение после закрытия позиций, отправка на согласование или отказ.

Изменение базовой валюты ещё чувствительнее: от неё зависят исторические отчёты, ledger posting, комиссии, сверка и ограничения торгового сервера. Во многих продуктах это не update существующей записи, а контролируемое закрытие старого и создание нового счёта.

Права на инструменты должны проверяться в месте приёма ордера, а не только скрываться в интерфейсе клиента. API gateway или order-entry сервис обязан перед отправкой ордера повторно проверить статус счёта, tenant, версию группы, entitlement по инструменту и применимые риск-правила. Серверная проверка доступа, подход default-deny и контроль разрешённых переходов соответствуют устоявшимся рекомендациям OWASP для авторизации и чувствительных операций.

Сначала определите границы интеграций

Надёжная реализация явно назначает источник истины для каждого факта и контракт событий для распространения изменений:

  • Identity и KYC: личность, результаты проверок, юрисдикция и compliance-атрибуты;
  • CRM: менеджер отношений, источник лида и контекст коммуникации;
  • Account management: lifecycle, группы, права, команды смены статусов и аудит;
  • Trading server: серверный счёт, credentials, execution-настройки, факты об ордерах и позициях;
  • Risk controls: exposure, проверки лимитов, решения об ограничениях и аварийные действия;
  • Financial ledger: неизменяемые денежные движения, связи с кошельками и бухгалтерская сверка.

Используйте явные идентификаторы и correlation ID на всех границах. Команда provisioning должна связывать KYC-решение, внутренний ID счёта, версию группы, внешний request ID и ID созданного серверного счёта. Тогда сбой можно расследовать без ручного поиска в нескольких панелях.

Как исключить дублирующее provisioning и небезопасные изменения

Timeout, retry и повторный клик — нормальные условия распределённой системы. Поэтому provisioning нужен idempotency key, созданный до первого вызова внешнего сервиса. Повторная попытка должна вернуть исходный результат или продолжить ту же операцию, но не открыть второй активный счёт. Храните запись provisioning с хешем запроса, ключом идемпотентности, внешней ссылкой, текущим шагом и статусом reconciliation.

Привилегированные изменения оформляйте как команды, а не как прямое редактирование базы. Команда «изменить плечо с 1:100 на 1:500» должна содержать старое и новое значение, инициатора, reason code, согласование, correlation ID, результат risk preview, время вступления в силу, подтверждение внешней системы и результат rollback при необходимости. Для существенных операций применяйте least privilege, повторную аутентификацию при необходимости, maker-checker и серверную проверку политик.

Аудит должен быть частью продукта

Запись аудита должна отвечать на вопросы: кто, что, с каким счётом, через какой канал, по какому праву и согласованию сделал; какими были старое и новое значения; успешно ли внешняя система применила изменение. Неизменяемую историю событий лучше хранить отдельно от редактируемой операционной проекции. Централизованное управление логами и сроки хранения должны позволять быстро найти привилегированные действия при инциденте или сверке.

Checklist перед релизом

  • Автоматически тестируются разрешённые и запрещённые переходы состояний?
  • Повтор provisioning никогда не создаёт дублирующий внешний счёт?
  • Версия группы видна в истории счёта?
  • Suspension и ограничения инструментов блокируют все пути ввода ордера, включая API?
  • Изменение плеча учитывает позиции и риск-контроли?
  • В аудите есть actor, основание, approval, before/after и результат применения?
  • Ежедневная сверка выявляет расхождения статусов и конфигураций между системами?

Перестройка жизненного цикла счетов не требует одномоментной замены всей платформы. POLADO может оценить границы trading server, CRM, back office и ledger, спроектировать state model и versioned policies, а затем подготовить безопасный план миграции и реализации.