Ризик-репортинг криптофонду: де ламається на ручних звірках
Контур ризик-репортингу криптофонду збирається з різнорідних джерел: залишки за гаманцями та біржовими рахунками, угоди, ціни, дані щодо стейкінгу та позик.
Кожне джерело віддає дані у своєму форматі та зі своїм лагом — вивантаження через біржові інтерфейси, файли від кастодіана, правки в таблицях. Уже тут з’являється вузьке місце звітного контуру: зведення даних роблять люди, а не система.
Ручна звірка даних тримається на одному-двох аналітиках. Вони зіставляють позиції, добирають пропущені операції, перераховують частки за фондом і метрики ризику вручну.
Поки рахунків та інструментів небагато, це працює; зі зростанням портфеля один пропущений переказ або неправильний курс дає розбіжності у звітності, які далі розходяться по всьому ланцюжку — від позицій до підсумкових показників.
Найнебезпечніше те, що розбіжність спливає пізно: на перевірці в інвестора, в аудиті або під час розрахунку винагороди. Тоді дані перезбирають заново, а довіра до цифр падає.
Галузеві джерела на кшталт Chainalysis дають розмітку адрес, але не закривають звірку з внутрішнім обліком фонду.
Звідси три завдання: єдиний шар нормалізації даних, автоматичні перевірки збіжності та відтворюваний розрахунок метрик ризику. Розбираємо, як це закривається і що саме прибирає ручну звірку.
Що дає ризик-репортинг: вимірювані ефекти для фонду
Єдине джерело даних прибирає головну причину розбіжностей у звітності криптофонду: позиції, угоди, котирування та довідники лежать в одному контурі, а не збираються вручну з вивантажень бірж, кастодіана та внутрішніх таблиць.
Звіт будується на тій самій вітрині, що й внутрішньоденний контроль лімітів, тому цифра в оперативному зведенні та в місячній формі збігається без ручних звірок.
Час підготовки звіту перестає залежати від ручного збирання: ризик-репортинг іде за розкладом, а перерахунок після уточнення даних займає хвилини замість зміни. Аналітик витрачає час на розбір відхилень, а не на зведення таблиць.
Простежуваність розрахунків означає, що кожна цифра розкривається до первинної угоди, курсу та версії методики. Значення перераховується із збереженого набору вхідних даних, тому ризик-комітет і аудитор перевіряють не готовий результат, а весь ланцюжок.
Контроль якості даних вбудовано в завантаження: перевірки на пропуски, дублі, аномальні котирування та розбіжність залишків за рахунками відсікають сміття до розрахунку.
Подія, що не пройшла перевірку, не потрапляє до звіту мовчки — вона позначається й вирушає на розбір до джерела.
Стійкість до збоїв джерел тримається на останньому достовірному стані: контур продовжує рахувати за ним і позначає дані як неповні.
Відмова вивантаження з біржі або затримка даних кастодіана не зупиняє випуск — звіт виходить з явною позначкою про покриття, і рішення ухвалюється на зрозумілих припущеннях.
Як збирати дані для звітності: порівняння підходів
Межа між ручною працею та розрахунком — головне рішення у звітності, а не вибір інструмента. Поки джерел три-чотири й звіт потрібен раз на квартал, вивантаження в таблиці коштує дешевше за будь-яке впровадження.
Коли з’являються десятки гаманців, біржових рахунків і кастодіальних звітів, ручна звірка перестає сходитися й не відтворюється від періоду до періоду.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручна звірка та вивантаження в таблиці | Разовий аудит, поодинокі джерела, прості стратегії | Не масштабується, немає відтворюваності, помилку у формулі видно через місяці |
| Галузевий сервіс обліку | Типові активи та стратегії, потрібен швидкий старт | Закрита логіка розрахунку, вузький набір джерел, свої метрики ризику не додати |
| Власний розрахунковий шар | Десятки джерел, свої метрики ризику, доказовість кожної цифри | Потрібні розробка, контроль якості даних і супровід |
| Автоматичний розрахунок плюс ручна звірка на вибірці | Перехідний період, поки довіру до автоматики не підтверджено | Подвійна робота на стику, потрібен регламент розбору розбіжностей |
Вибір робимо за картою джерел і переліком метрик, а не за «сучасністю» підходу: спочатку описуємо, звідки і з якою частотою надходять дані, потім — що саме рахуємо.
Власний розрахунковий шар виправданий, коли звіт має збиратися за однією формулою й повторюватися до цифри; ручна звірка залишається не альтернативою, а контрольною точкою на вибірці.
Як ми впроваджуємо контур звітності: етапи роботи
Звітний контур не ставиться поверх поточних процесів: спочатку потрібно зрозуміти, звідки беруться дані та що з ними відбувається по дорозі.
Тому впровадження звітного контуру починається з аудиту джерел даних — біржових вивантажень, ончейн-адрес, кастодіальних звітів, внутрішніх реєстрів угод: одні й ті самі поля в них майже завжди описані по-різному. Далі робота йде за етапами.
- Аудит джерел даних. Інвентаризація: хто віддає дані, з якою періодичністю, які поля і в якому вигляді. Окремо фіксуємо те, що досі збирається вручну.
- Схема потоків. Шлях запису від джерела до вітрини звіту: де вона нормалізується, де зберігається історія, як обробляються пропуски та правки заднім числом.
- Налаштування розрахунків. Визначення метрик — концентрація за контрагентами, ліквідність, плече, волатильність портфеля, — правила округлення та перерахунку курсів. Кожна цифра у звіті отримує однозначну формулу.
- Перевірка на історичних періодах. Прогін на минулих даних і звірка з поточною звітністю або ручними розрахунками: розбіжності розбираємо до причини, а не згладжуємо.
- Регламент і контроль якості. Звірки, оповіщення про розбіжності, повторні запуски та журнал змін — результат має відтворюватися.
- Приймання системи та передача команді. Перевіряємо сценарії відмови: недоступне джерело, виправлена заднім числом угода, розрив зв’язку. Потім документація, права доступу та навчання — рутинні правки команда закриває без нас.
Що передаємо разом із системою: конфігурації та регламенти
Система ризик-репортингу живе не лише кодом — її доля вирішується тим, наскільки зрозумілі правила експлуатації. Тому реліз передаємо одним пакетом: від схеми потоків даних до регламенту, за яким черговий аналітик випускає наступний звіт.
- Схема потоків даних — шлях від джерел котирувань та ончейн-подій через нормалізацію до вітрин звітності: де дані очищаються і в якій точці найчастіше рветься завантаження.
- Правила розрахунку показників — формули ризик-метрик, вікна усереднення, обробка пропусків і вихідних: розрахунок відтворюваний, а розбіжність із минулим звітом пояснювана.
- Регламент випуску звіту — послідовність від зрізу даних до публікації: контрольні звірки, строки, відповідальні ролі та дії при збої на кожному кроці.
- Матриця доступу — які ролі бачать позиції, ліміти та дані контрагентів; права аналітика, ризик-менеджера і зовнішнього аудитора плюс журнал дій.
- Документація зі звітності — опис кожного показника: джерело, логіка агрегації, обмеження. Новий фахівець входить у контур без пояснень розробника.
- Процедури звірки розбіжностей — як система позначає неповні або суперечливі дані і що робить черговий, перш ніж цифра піде до звіту.
Пакет оновлюється разом із кодом: зміна розрахунку не проходить без правки регламенту та документації. Ваша команда веде систему самостійно, а ми залишаємося на зв’язку щодо спірних випадків.
Кейс: як фонд скоротив підготовку звіту з тижня до годин
Фонд із кількома стратегіями готував щомісячний ризик-звіт для інвесторів і ризик-комітету: біржові позиції, кастодіальні рахунки, позабіржові угоди, рухи за гаманцями та перевірка контрагентів через Chainalysis.
Кожне джерело має свій формат вивантаження, свою затримку оновлення і свій спосіб рахувати вартість входу в позицію.
Що було
Звіт збирали 6–7 робочих днів: аналітики зводили вивантаження в електронних таблицях, розбіжності за залишками та собівартістю шукали вручну.
Збіжність між джерелом і фінальною версією трималася на 92–94%, до випуску доходило понад сотню ручних правок, а частину розбіжностей знаходив уже аудитор — документ доводилося перевипускати.
Що стало
Ми зібрали єдиний шар даних: нічні знімки позицій і угод приводяться до однієї моделі активу та однієї формули розрахунку вартості, а кожна цифра у звіті зберігає посилання на вихідний запис.
Правила звірки описані як правила, а не як пам’ять аналітика: розбіжність за залишком вище порогу блокує випуск і вирушає в чергу на розбір, тому помилка не доживає до фінальної версії, а розбіжності видно до публікації, а не після.
Підготовка звіту займає 2–4 години, ручних правок — одиниці замість сотні, і стосуються вони лише нових типів інструментів, для яких ще не задано правило.
Збіжність даних — 99,9% за залишками та розрахунковою вартістю, при цьому зріз на будь-яку минулу дату відтворюється заново, що знімає питання «звідки взялася ця цифра».
Що робити, якщо облік уже розгорнуто в кількох системах?
Розмова про облік у криптофонді майже завжди впирається в одне: єдиної системи немає. Позиції надходять від кастодіана, угоди та комісії — з торгових вивантажень, проводки та нарахування — з внутрішнього реєстру, рухи за рахунками — з казначейського контуру.
Формати в усіх свої: десь вивантаження з фіксованою шириною поля, десь вкладена відповідь посторінкового запиту, десь таблиця з розділювачем, який змінюється від звіту до звіту.
Перше, що варто зафіксувати: зводити облік в одну систему не потрібно. Працює шар зведення поверх наявних джерел — кожна із систем залишається джерелом істини за своїм контуром, а звітність і ризик-метрики будуються на нормалізованому поданні.
Такий шар, наприклад, знімає основний біль Fireblocks і подібних кастодіальних контурів: у них своя гранулярність позицій, і вона не зобов’язана збігатися з внутрішньою.
Далі — три інженерні правила. Інструмент зіставляється за єдиним довідником ідентифікаторів, інакше той самий актив надходить трьома різними тикерами.
Кожен запис прив’язується до зрізу часу, а не до моменту завантаження, інакше залишки на кінець дня роз’їжджаються на кілька годин.
Завантаження робиться повторюваним: сирі вивантаження зберігаються як є, розрахунок переграється з них, а розбіжність залишків вище заданого порогу стає окремим розривом із відповідальним, а не тихою коригуванням.
Процеси при цьому не зупиняються: зведення йде паралельно, старий порядок закриття періоду зберігається, поки новий шар не підтвердить результат на кількох циклах. Перехід робиться контур за контуром — спочатку торгові дані, потім кастодіальний шар, далі казначейство.
Ручне перекладання між системами зникає не одразу, а в міру того, як кожне джерело починає сходитися автоматично.
Часті питання щодо влаштування звітного контуру
Питання щодо звітності зазвичай з’являються не на запуску, а на другому-третьому циклі закриття — коли цифри за минулі періоди перестають сходитися з поточними. Нижче зібрали технічні сумніви, які найчастіше спливають до старту контуру.
Чому цифри за той самий період можуть розходитися при повторному розрахунку?
Розрахунок спирається лише на незмінний зріз вхідних даних, зафіксований на момент закриття періоду. Якщо джерело пізніше надіслало уточнення, воно не переписує минулий звіт, а йде окремим рядком коригування із зазначенням джерела та величини. У результаті розбіжність завжди пояснювана, а не виглядає помилкою розрахунку.
Що відбувається, якщо джерело недоступне або віддає дані із затримкою?
Збір іде через чергу з повторними спробами та зростаючим інтервалом, до відновлення використовується останній перевірений зріз. Період, зібраний не повністю, позначається як частковий — пропуски не заповнюються нулями, інакше звіт виглядає правдоподібно, але неправильний. Окрема метрика показує, скільки періодів закрито повністю і які джерела системно відстають.
Як переконатися в коректності розрахунків після зміни методики?
Методика зберігається з версіями, і при зміні історичні періоди перераховуються паралельно з поточними, у тіньовому режимі. Результати звіряються построково: розбіжності вище заданого порогу не публікуються, поки не розібрано причину. На виході залишається протокол звірки — його додають до самого звіту.
Як розмежовується доступ до даних?
Доступ розводиться за рівнями: зведені показники, деталізація за позиціями, вивантаження назовні. Частина команди бачить лише агрегати без контрагентів, вивантаження та правка методики логуються, права видаються за мінімально необхідним принципом і переглядаються при зміні ролей.
Ці чотири сюжети закривають більшу частину сумнівів на етапі вибору підрядника; решта — частковості, які розбираються вже на конкретних даних фонду.Обговоримо завдання: з чого почати звітний контур
Пропонуємо обговорити завдання предметно — з аудиту поточного звітного контуру. Дивимося, які джерела даних уже є (біржові вивантаження, рухи за гаманцями, брокерські рахунки), як у них сходяться баланси і де виникають розбіжності.
Це показує обсяг робіт швидше за будь-яку розмову «загалом»: одразу видно, що переносимо як є, а що доведеться вибудовувати заново.
Почати з аудиту вигідно й за строками. Він займає обмежений час і перевіряє, чи реальні вимоги до контуру — наприклад, щоденний розрахунок вартості портфеля при розрізнених джерелах. Після аудиту оцінка строків перестає бути діапазоном «від і до» і стає планом з етапами.
За підсумками ви отримуєте:
- карту джерел даних і способів їх регулярного отримання;
- перелік ризикових метрик і правил розрахунку — те, що потрапить до звіту;
- план впровадження за етапами із залежностями між ними;
- оцінку строків кожного етапу та склад команди під нього;
- схему звітного контуру: розрахунки, контроль цілісності, розмежування доступу;
- перелік розвилок, де потрібне ваше рішення — періодичність звіту, глибина історії, ролі отримувачів.
Опишіть завдання: які активи та стратегії покриваємо, хто і в якому вигляді отримує звіти, які перевірки обов’язкові. Повернемося з оцінкою строків і планом впровадження, де перший крок — аудит ваших даних.
