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

Почему расчёт NAV криптофонда ломается на масштабе

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

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

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

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

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

Что даёт автоматизированный расчёт NAV

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

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

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

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

Подходы к расчёту: от ручных таблиц до распределённого реестра

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

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

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

Как мы выстраиваем процесс внедрения

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

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

Такая последовательность даёт главное: цифру NAV можно объяснить и повторить. Если аудитор или инвестор спросит, откуда взялось значение, ответ лежит в журнале и схеме, а не в переписке.

Что заказчик получает на руки

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

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

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

Опишите вашу методику расчёта и источники данных — вернёмся с оценкой и планом по каждому из артефактов.

Кейс: как мы сократили время расчёта NAV втрое

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

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

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

Что изменилось в метриках

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

Чем отличается NAV криптофонда от традиционного расчёта?

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

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

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

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

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

Частые технические сомнения

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

Какая задержка между сделкой и обновлением NAV?

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

Как система встраивается в наш учёт и отчётность?

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

Что будет, если источник цен отвалится или отдаст мусор?

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

Можно ли пересчитать NAV задним числом?

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

Обсудим вашу задачу расчёта NAV

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

Что закрываем в рамках задачи:

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

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