Разработка клиентской отчётности для торговой платформы — это создание слоя, который превращает события торгов, проводки ledger, цены и справочные данные в выписки, понятные клиенту и воспроизводимые для операционной команды. Надёжная выписка — не просто страница клиентского кабинета, сохранённая в PDF. Это зафиксированный снимок отчётности с определёнными счётом, периодом, моментом среза, методикой расчёта, исходными записями и версией документа.

Такой подход становится критичным, когда в продукте появляются новые инструменты, валюты, источники цен, схемы комиссий и процессы клиентской поддержки. Экран может пересчитать результат после позднего исполнения, коррекции FX-курса или исправления маркет-данных. Выписка, уже предоставленная клиенту, должна позволять ответить на другой вопрос: что именно было показано, на какой момент, по каким данным и правилам? В материалах SEC по подтверждениям сделок указываются такие сведения, как дата и время операции, инструмент, цена, количество, роль брокера и определённые раскрытия вознаграждения; также подчёркивается необходимость согласования данных подтверждения с клиентскими выписками и журналами брокера-дилера. ([sec.gov](https://www.sec.gov/about/divisions-offices/division-trading-markets/division-trading-markets-compliance-guides/guide-broker-dealer-registration?utm_source=openai))

Не используйте интерфейс как расчётный движок отчётности

Расчёт на фронтенде полезен для оперативного экрана. Но он не должен быть источником истины для выгружаемой выписки, клиентского спора или проверки операций. В разных представлениях часто отличаются фильтры, округление, время цены, источник FX-курса и учёт pending-операций. В итоге клиент, сотрудник поддержки и back-office смотрят на один счёт, но получают разные цифры.

Практичная архитектура выделяет отдельный конвейер отчётности:

  • Входные события: заявки и исполнения, проводки денежных средств, начисления комиссий, корпоративные действия, справочник инструментов, цены и FX-курсы.
  • Сверка: сопоставление внутренних записей с брокером, кастодианом, клирингом, банком или внешним провайдером; выявление расхождений до финализации отчёта.
  • Снимок отчёта: материализованный результат по счёту и периоду с точным cut-off, версиями данных и правилами расчёта.
  • Представление: клиентский портал, PDF, CSV, рабочее место поддержки и back-office читают один утверждённый снимок, а не пересчитывают результат каждый по-своему.

Это логичное развитие надёжного ledger и исполнения сделок. В рамках FinTech и trading-систем отчётность может быть отдельным сервисом, но каждая строка и итог должны сохранять связь с породившими их бизнес-событиями.

Сначала определите cut-off, затем проектируйте макет выписки

Фраза «выписка за сентябрь» не является полной спецификацией. Необходимо явно определить границы периода, timezone, правило рабочего календаря, timestamp среза, точку оценки и обработку поздно пришедших событий. Выписка на 23:59:59 UTC может заметно отличаться от выписки, закрываемой по времени Нью-Йорка. Для круглосуточного криптопродукта, FX-счёта и ценных бумаг с отдельным циклом расчётов понятие «конец дня» будет разным.

Какие метаданные нужны каждому отчёту

  • идентификатор счёта и юридического лица или tenant;
  • начало и конец периода, timezone и timestamp cut-off;
  • цена оценки позиции, её источник и время получения цены;
  • FX-курс, источник и момент конвертации;
  • методика себестоимости и P&L: FIFO, средняя цена или логика конкретного контракта;
  • версии правил комиссий, financing, borrow, налогов и custody;
  • версия генератора, время создания, статус и ссылка на заменённую версию отчёта.

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

Позиции и P&L: показывайте не только итог, но и способ его получения

Система отчётности по торговому P&L не должна ограничиваться одной строкой net profit/loss. В ней должны быть различимы составляющие:

  • Реализованный P&L: результат по закрытым лотам или контрактам с учётом заявленного метода сопоставления.
  • Нереализованный P&L: разница между определённой себестоимостью открытой позиции и её оценкой на момент cut-off.
  • Доходы и расходы: комиссии, финансирование, borrow fees, дивиденды, купоны, налоги и другие начисления должны быть видны отдельно, а не скрыты в общем результате.
  • Валютный эффект: при различии валюты счёта, инструмента и расчёта нужно отделять результат по инструменту от эффекта конвертации.

Например, акция в USD может вырасти в долларах, но результат владельца EUR-счёта изменится из-за EUR/USD. Защищаемая выписка не показывает только итог после конвертации: она фиксирует базовую валюту, правило пересчёта и использованный курс. Такой же подход нужен для частичных исполнений, дробных количеств, мультипликаторов деривативов и коротких позиций: расчётная логика должна быть проверяемой.

Движение денег и комиссии — самостоятельные события ledger

Одного поля «cash balance» недостаточно для объяснения счёта. В клиентской выписке нужны начальный остаток, пополнения, выводы, расчёты по сделкам, комиссии, налоги, проценты или financing, дивиденды и денежные последствия корпоративных действий. У каждой строки должны оставаться дата возникновения, value date, направление, валюта, статус и ссылка на исходное событие.

Особенно важно не смешивать исполненные, ожидающие и рассчитанные суммы. Сделка может быть исполнена в trade date, а денежное движение произойдёт в settlement date; поэтому available-to-trade cash, settled cash и closing cash в выписке могут быть разными показателями. Их названия и формулы должны быть явными. В разъяснениях ESMA по MiFID II для более частой ex-post отчётности о расходах и комиссиях подчёркивается согласованность методологии и, когда это возможно, использование фактически реализованных и известных ex-post расходов. ([esma.europa.eu](https://www.esma.europa.eu/publications-data/questions-answers/1816?utm_source=openai))

Корпоративные действия и исправления требуют истории, а не перезаписи

Split, reverse split, дивиденды, merger, spin-off, смена тикера и корректировка контракта могут изменить количество, себестоимость и исторический P&L. Система должна сохранять цепочку преобразования: исходный лот или инструмент, событие corporate action, коэффициент и итоговую позицию. Простая перезапись текущей позиции создаёт проблему для аудита и поддержки.

То же относится к позднему исполнению, cancel/correct, исправлению данных брокера или дефекту в правилах комиссий. Если уже выпущенный отчёт ошибочен, нельзя незаметно пересоздавать старый PDF с тем же идентификатором. Нужен управляемый процесс:

  1. зафиксировать причину и затронутые исходные события;
  2. выполнить расчёт и создать новую версию отчёта;
  3. сохранить исходный snapshot и пометить его как заменённый, если это применимо;
  4. предоставить клиенту исправленный документ с понятным описанием различий;
  5. показывать ту же исправленную версию в портале, поддержке и back-office.

Статус корректировки, номер версии и объяснение изменений — также задача продуктового дизайна. POLADO помогает сочетать этот workflow с UI/UX и продуктовым дизайном, чтобы клиенту не приходилось получать расшифровку только через поддержку.

Сделайте выгружаемые выписки проверяемыми и защищёнными

PDF и CSV — это клиентские документы, а не случайный результат кнопки Export. Добавляйте ID отчёта, timestamp выпуска, период, маскированную ссылку на счёт, базовую валюту, методологические примечания и статус корректировки. В audit log следует хранить создание, утверждение при необходимости, доставку и скачивание. Доступ должен ограничиваться tenant и конкретным счётом; ссылки на загрузку — иметь срок действия; а чувствительные данные не должны попадать в технические логи.

Тестируйте сценарии, которые приводят к самым сложным спорам: дублированное исполнение, события вне порядка, отмена после частичного fill, отсутствие цены, пересмотр FX-курса, отрицательный cash, переименование инструмента, split на границе периода и корректировка комиссии после закрытия месяца. Цель — не только корректный PDF-шаблон, а одинаковый ответ во всех операционных каналах.

Чек-лист перед запуском клиентской отчётности

  • Есть ли authoritative source of truth для каждой позиции, суммы cash и комиссии?
  • Идемпотентны и трассируемы ли события order, fill, cash, fee и corporate action?
  • Зафиксированы ли и версионируются ли правила cut-off, timezone, цены и FX?
  • Явно ли разделены realized/unrealized P&L и статусы settlement?
  • Используют ли портал, PDF, CSV, поддержка и back-office один snapshot отчёта?
  • Создаёт ли исправление новую версию, не удаляя историю выданного документа?
  • Может ли уполномоченный сотрудник проследить итог до исходных событий и правил?

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