Разработка системы отчетности крипто-фонда под ключ

Разработка системы отчётности крипто-фонда: где рвутся данные

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

Дальше ломается связность. Сделка попадает в журнал одной записью, а движение по кошельку — другой, и связи между ними нет: перевод между своими адресами выглядит как две операции и раздувает оборот. Комиссии, начисленные и не зачисленные проценты, зависшие транзакции оседают в сверке остатков по источникам как расхождение, которое каждый раз объясняют вручную.

Сверка остатков по источникам — самый трудоёмкий этап. Метки времени у источников не совпадают: биржа фиксирует исполнение в момент сделки, кастодиан — в момент расчёта, и остаток на конец дня у них законно разный. Чтобы свести это, аналитик строит таблицу соответствий активов и вручную размечает каждое расхождение.

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

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

Что меняется после внедрения: измеримые эффекты

Внедрение измеряется не числом отчётов, а временем, которое команда тратит на ручные сверки. Ниже пять величин, по которым видно, что учёт работает: их мы фиксируем на старте, чтобы сравнить состояние до и после.

Отчётный период закрывается за часы, а не за дни

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

Сверка операций идёт автоматически

Каждая транзакция сопоставляется с записью внутреннего учёта по уникальному идентификатору, а не по сумме и дате. Доля автоматически сверенных операций выходит к 95% и выше, остаток разбирается как исключение.

Уходит класс расхождений ручного ввода

Перенос цифр между таблицами даёт перестановки, дубли и потерянные строки. Единый источник данных убирает саму операцию, поэтому расхождение «в кошельке не то, что в учёте» не возникает.

Полнота по активам подтверждается

Система держит реестр адресов, счетов и биржевых подключений, включая забытые. Если по активу нет данных, отчёт просто не собирается: пропуск виден при подготовке, а не на проверке.

Движение средств прослеживается до источника

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

Варианты построения системы: свой контур, гибрид, сервис

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

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

Этапы работ: от разбора источников до передачи контура

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

1. Инвентаризация источников данных. Перечень биржевых и кастодиальных выписок, банковских счетов, адресов в сети, внутренних таблиц. По каждому источнику — формат, глубина истории, часовой пояс и доступ только на чтение.
2. Схема потоков данных. На одной схеме видно, что откуда приходит, где нормализуется, где лежит сырой слой и где собираются витрины отчётов. Согласуем до кода: правка здесь дешевле правки в расчёте.
3. Правила сопоставления операций. Как сходятся переводы между счетами и внутри сети, как учитываются комиссии, начисления и ребалансировки. Отдельно закрываем двойной учёт по переводам между своими счетами.
4. Настройка расчёта и форм отчётности. Остатки на дату, движение средств, реализованный и нереализованный результат, раскрытия для аудитора. Каждая форма привязана к правилам учёта, а не к ручным правкам.
5. Приёмочные проверки. Прогон на закрытых периодах и сверка с отчётами, которым фонд доверяет. Отдельно — неполные выгрузки, зависшие операции, расхождения по времени и пересборка истории.
6. Регламент закрытия периода. Кто и что запускает, в каком порядке, где точки контроля и что делать при расхождении. Это инструкция для команды фонда, а не «позвать разработчика».
7. Передача контура заказчику. Доступы с разграничением ролей, документация по потокам и расчётам, обучение и сопровождение на первых закрытиях. Дальше контур работает без нас.

Что передаём на руки: реестры, отчётность, регламенты

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

• Единый реестр операций — движения по кошелькам и биржевым счетам в одной структуре с неизменяемыми идентификаторами. Реестр сходится с выписками, а расхождение видно на уровне конкретной операции.
• Матрица доступа — роли привязаны к действиям: просмотр, подготовка проводки, подтверждение, выгрузка. Права выдаются роли, а не человеку, поэтому замена сотрудника не открывает лишнего.
• Регламент закрытия периода — порядок сверки, фиксации курса и блокировки периода. После закрытия данные не правятся задним числом: исправления идут отдельной операцией с причиной и автором.
• Схемы потоков данных — от источника (биржа, узел сети, кошелёк хранения) до строки отчёта: где данные очищаются, обогащаются курсом и проходят проверки.
• Передача документации — описание модели данных, справочников и правил классификации операций; новый инженер вводится по документам, а не по пересказам.
• Инструкции для сотрудников — памятки на каждую роль: как оформить корректировку, спорную операцию, новый тип актива.
• Регламент изменений — как добавить отчёт или источник, не ломая сверку прошлых периодов.

Комплект делает систему проверяемой: аудит идёт по документам, а не по памяти тех, кто её собирал.

Кейс: свели данные из четырёх источников в один реестр

Фонд собирает данные из четырёх источников: кастодиан Fireblocks, две биржи и банковский счёт. Каждую неделю выгрузки сводились вручную — разные форматы, часовые пояса и правила округления, курс приходилось восстанавливать по истории сделок. Закрытие месяца растягивалось на десять рабочих дней, а расхождения всплывали уже в готовом отчёте.

Начали с модели данных: каждая операция получает сквозной ключ «источник + внешний идентификатор», время приводится к единому поясу, к сделке привязывается курс на момент исполнения. Дальше сопоставление идёт по правилам — сумма, направление, адрес кошелька, — и в ручной разбор попадает только остаток.

Что изменили

• Единый реестр операций вместо четырёх выгрузок, с историей изменений по каждой записи.
• Сверка между источниками на входе: несовпадение остатка блокирует загрузку и уходит ответственному.
• Контрольные суммы по каждому источнику на конец дня — расхождение видно в момент появления, а не через месяц.

Что получили

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

Что делать, если учёт уже разбросан по чужим таблицам?

Первым делом — инвентаризация таблиц. Выписываем все источники: выгрузки с бирж и кастодианов, адреса кошельков, ручные реестры сделок, файлы, которые кто-то ведёт «для себя» в обход общего процесса. По каждому нужно четыре ответа: кто владелец, за какой период есть данные, в каком формате они лежат и что в них уникального. Последний пункт обычно отсекает большую часть работы.

Миграция существующего учёта строится на правиле «первоисточник важнее ручной записи». Если операция восстанавливается из выгрузки биржи или данных сети, ручную копию не переносим — она не добавляет информации, но гарантированно разойдётся с оригиналом при первой же сверке. В новый контур попадает только то, что не восстанавливается: договорённости вне биржи, операции между своими счетами, начисления, которые нигде не фиксировались автоматически.

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

Сохранение старых данных решается снимком. Исходные файлы не удаляем и не перезаписываем — они фиксируются как неизменяемый архив только для чтения, с контрольной суммой и понятной структурой папок. Новый учёт стартует с даты отсечения, и всё, что до неё, воспроизводимо из архива: отчёт за любой прошлый период собирается, даже если в новом контуре этих операций нет.

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

Технические сомнения: доступы, сверки, восстановление

Собираем вопросы, которые чаще всего поднимают на техническом разборе: откуда берутся данные фонда, кто и что видит внутри системы, что делать при расхождении остатков и как она переживает сбой. Ниже — прямые ответы, без общих слов.

Как разграничены права доступа?

Роли описываются под структуру фонда: аналитик, бухгалтер, аудитор, администратор. Права проверяются на стороне сервиса, а не в интерфейсе — прямой запрос к данным их не обойдёт. Аудитор видит срезы закрытых периодов только на чтение, а ручные правки помечаются автором и временем.

Отчёт не сошёлся с биржей — что дальше?

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

Что происходит после сбоя?

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

Обсудим задачу: покажем схему и вернёмся с оценкой

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

После разговора вы получаете:

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

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