Розробка системи звітності крипто-фонду: де рвуться дані
Фонд рідко веде облік з однієї точки. Дані надходять із кастодіальних звітів, вивантажень бірж, рухів за гаманцями, банківських рахунків і позабіржових угод, які не залишають сліду в мережі.
У кожного джерела свій формат файлу, своя періодичність і своє написання тікера — це перша точка, де облік операцій фонду розсипається на незв’язані частини.
Далі ламається зв’язність. Угода потрапляє до журналу одним записом, а рух за гаманцем — іншим, і зв’язку між ними немає: переказ між власними адресами виглядає як дві операції та роздуває оборот.
Комісії, нараховані й не зараховані відсотки, завислі транзакції осідають у звірянні залишків за джерелами як розбіжність, яку щоразу пояснюють вручну.
Звіряння залишків за джерелами — найтрудомісткіший етап. Мітки часу в джерел не збігаються: біржа фіксує виконання в момент угоди, кастодіан — у момент розрахунку, і залишок на кінець дня в них законно різний. Щоб звести це, аналітик будує таблицю відповідностей активів і вручну розмічає кожну розбіжність.
Закриття періоду у фонді перетворюється на ручне перенесення даних у таблиці. Формули в книзі тягнуться одна за одною, правка ламає попередні аркуші, а слід від угоди до проводки відновлюється з пам’яті. Звітність крипто-фонду за IFRS вимагає цього сліду — аудитор запитує його першим ділом.
Розбираємо, як це закривається: єдина модель обліку, де угода, рух за гаманцем і проводка пов’язані ключами, а звіряння йде за регламентом, а не вручну.
Що змінюється після впровадження: вимірювані ефекти
Впровадження вимірюється не кількістю звітів, а часом, який команда витрачає на ручні звіряння. Нижче — п’ять величин, за якими видно, що облік працює: їх ми фіксуємо на старті, щоб порівняти стан до й після.
Звітний період закривається за години, а не за дні
Раніше вивантаження збирали вручну з біржових кабінетів, гаманців і таблиць. Система бере дані з вузлів і торгових інтерфейсів за розкладом, приводить їх до єдиного довідника активів і агрегує на кінець періоду — закриття місяця скорочується з кількох днів до кількох годин.
Звіряння операцій відбувається автоматично
Кожна транзакція зіставляється із записом внутрішнього обліку за унікальним ідентифікатором, а не за сумою та датою. Частка автоматично звірених операцій сягає 95% і вище, залишок розбирається як виняток.
Зникає клас розбіжностей ручного введення
Перенесення цифр між таблицями дає перестановки, дублі та загублені рядки. Єдине джерело даних прибирає саму операцію, тому розбіжність «у гаманці не те, що в обліку» не виникає.
Повнота за активами підтверджується
Система тримає реєстр адрес, рахунків і біржових підключень, включно із забутими. Якщо за активом немає даних, звіт просто не збирається: пропуск видно під час підготовки, а не під час перевірки.
Рух коштів простежується до джерела
Будь-яка цифра розкривається до транзакції з датою, контрагентом і призначенням — підхід, близький до вимог МСФЗ до обліку цифрових активів. Перевіряльник отримує не зведення, а ланцюжок підтверджень від гаманця до рядка звіту.
Варіанти побудови системи: власний контур, гібрид, сервіс
Вибір між трьома режимами визначає не зручність інтерфейсу, а те, хто відповідає за повноту даних і як глибоко потрібно входити в методику обліку.
Власний контур дає максимум контролю, зовнішній — мінімум експлуатації, гібрид закриває фонди з кількома стратегіями та ручними коригуваннями.
Загальне правило для всіх варіантів одне: інтеграції працюють лише на читання — ні приватні ключі, ні права на переміщення коштів у контур звітності не передаються, інакше аудит втрачає незалежність.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Власний контур обліку | Потрібна довільна методика розрахунку, свої звіряння й повна історія операцій; є команда, що експлуатує вузли та сховище | Довше впровадження: розгортання, бекапи й моніторинг залишаються на боці фонду, повнота даних також |
| Гібридна схема обліку | Потрібен швидкий старт і гнучка звітність: сирі дані беремо із зовнішніх джерел, правила обліку й звіряння тримаємо в себе | Залежність від джерел: затримки, зміна форматів, пропуски в історії; незалежне звіряння обов’язкове |
| Зовнішній контур звітності | Підходить для стандартного набору звітів і мінімального строку запуску без власної інженерної команди | Набір звітів обмежений шаблонами сервісу, власну методику не внести; ключі доступу й дані на боці підрядника |
На практиці рішення зводиться до трьох питань: яка глибина історії потрібна для розрахунку дохідності, хто відповідатиме за розбіжності під час звіряння і наскільки критична затримка даних. Відповіді на них і визначають архітектуру — далі збираємо схему обліку під неї.
Етапи робіт: від розбору джерел до передачі контуру
Звітність фонду ламається не на формулах, а на вході: один майданчик віддає історію неповно, другий змінює формат вивантаження, перекази між власними рахунками подвоюють оборот.
Тому контур збирають фіксованим порядком — кожен етап спирається на попередній, а результат перевіряється на даних, а не на словах.
- Інвентаризація джерел даних. Перелік біржових і кастодіальних виписок, банківських рахунків, адрес у мережі, внутрішніх таблиць. За кожним джерелом — формат, глибина історії, часовий пояс і доступ лише на читання.
- Схема потоків даних. На одній схемі видно, що звідки надходить, де нормалізується, де лежить сирий шар і де збираються вітрини звітів. Узгоджуємо до коду: правка тут дешевша за правку в розрахунку.
- Правила зіставлення операцій. Як сходяться перекази між рахунками та всередині мережі, як враховуються комісії, нарахування й ребалансування. Окремо закриваємо подвійний облік за переказами між власними рахунками.
- Налаштування розрахунку й форм звітності. Залишки на дату, рух коштів, реалізований і нереалізований результат, розкриття для аудитора. Кожна форма прив’язана до правил обліку, а не до ручних правок.
- Приймальні перевірки. Прогін на закритих періодах і звіряння зі звітами, яким фонд довіряє. Окремо — неповні вивантаження, завислі операції, розбіжності за часом і перезбирання історії.
- Регламент закриття періоду. Хто і що запускає, у якому порядку, де точки контролю і що робити при розбіжності. Це інструкція для команди фонду, а не «покликати розробника».
- Передача контуру замовнику. Доступи з розмежуванням ролей, документація за потоками й розрахунками, навчання та супровід на перших закриттях. Далі контур працює без нас.
Що передаємо на руки: реєстри, звітність, регламенти
Систему не можна вважати зданою, поки її роботу не можуть вести без нас. Тому разом із кодом замовнику йде комплект артефактів: реєстри, схеми, доступи, правила закриття періоду та інструкції для співробітників.
- Єдиний реєстр операцій — рухи за гаманцями та біржовими рахунками в одній структурі з незмінними ідентифікаторами. Реєстр сходиться з виписками, а розбіжність видно на рівні конкретної операції.
- Матриця доступу — ролі прив’язані до дій: перегляд, підготовка проводки, підтвердження, вивантаження. Права видаються ролі, а не людині, тому заміна співробітника не відкриває зайвого.
- Регламент закриття періоду — порядок звіряння, фіксації курсу й блокування періоду. Після закриття дані не правляться заднім числом: виправлення йдуть окремою операцією з причиною та автором.
- Схеми потоків даних — від джерела (біржа, вузол мережі, гаманець зберігання) до рядка звіту: де дані очищаються, збагачуються курсом і проходять перевірки.
- Передача документації — опис моделі даних, довідників і правил класифікації операцій; новий інженер вводиться за документами, а не за переказами.
- Інструкції для співробітників — пам’ятки на кожну роль: як оформити коригування, спірну операцію, новий тип активу.
- Регламент змін — як додати звіт або джерело, не ламаючи звіряння минулих періодів.
Комплект робить систему перевірюваною: аудит іде за документами, а не за пам’яттю тих, хто її збирав.
Кейс: звели дані з чотирьох джерел в один реєстр
Фонд збирає дані з чотирьох джерел: кастодіан Fireblocks, дві біржі та банківський рахунок. Щотижня вивантаження зводили вручну — різні формати, часові пояси й правила округлення, курс доводилося відновлювати за історією угод. Закриття місяця розтягувалося на десять робочих днів, а розбіжності спливали вже в готовому звіті.
Почали з моделі даних: кожна операція отримує наскрізний ключ «джерело + зовнішній ідентифікатор», час приводиться до єдиного поясу, до угоди прив’язується курс на момент виконання.
Далі зіставлення йде за правилами — сума, напрямок, адреса гаманця, — і в ручний розбір потрапляє лише залишок.
Що змінили
- Єдиний реєстр операцій замість чотирьох вивантажень, з історією змін за кожним записом.
- Звіряння між джерелами на вході: незбіг залишку блокує завантаження і йде відповідальному.
- Контрольні суми за кожним джерелом на кінець дня — розбіжність видно в момент появи, а не через місяць.
Що отримали
| Показник | До | Після |
|---|---|---|
| Закриття періоду | 10 робочих днів | 2 дні |
| Операцій, звірених автоматично | близько 40% | 96% |
| Розбіжностей, знайдених до звітності | одиниці | 30–40 за місяць |
Ручної роботи стало менше не за рахунок послаблення контролю, а тому що спірні операції відокремлюються від потоку. Звіт збирається з реєстру, тому цифри в ньому збігаються з даними кастодіана й бірж без повторного звіряння.
Що робити, якщо облік уже розкидано по чужих таблицях?
Першим ділом — інвентаризація таблиць. Виписуємо всі джерела: вивантаження з бірж і кастодіанів, адреси гаманців, ручні реєстри угод, файли, які хтось веде «для себе» в обхід загального процесу.
За кожним потрібно чотири відповіді: хто власник, за який період є дані, у якому форматі вони лежать і що в них унікального. Останній пункт зазвичай відсікає більшу частину роботи.
Міграція наявного обліку будується на правилі «першоджерело важливіше за ручний запис». Якщо операція відновлюється з вивантаження біржі або даних мережі, ручну копію не переносимо — вона не додає інформації, але гарантовано розійдеться з оригіналом під час першого ж звіряння.
У новий контур потрапляє лише те, що не відновлюється: домовленості поза біржею, операції між власними рахунками, нарахування, які ніде не фіксувалися автоматично.
Історичні періоди переносимо не суцільно, а за контрольними точками — датами закриття звітності. На кожній точці звіряємо залишки за позиціями та підсумковий баланс.
Розбіжності фіксуємо окремим списком із причиною, а не підганяємо цифри під очікуваний результат: підігнана історія потім спливе під час першої перевірки.
Збереження старих даних вирішується знімком. Вихідні файли не видаляємо і не перезаписуємо — вони фіксуються як незмінний архів лише для читання, з контрольною сумою та зрозумілою структурою папок.
Новий облік стартує з дати відсічення, і все, що до неї, відтворюється з архіву: звіт за будь-який минулий період збирається, навіть якщо в новому контурі цих операцій немає.
План переходу включає паралельний період: старий і новий контури рахуються одночасно, розбіжності розбираються до моменту перемикання.
Лише коли обидві сторони сходяться на контрольних точках, старий порядок закривається — інакше переноситься не облік, а ті самі помилки в новій обгортці.
Технічні сумніви: доступи, звіряння, відновлення
Збираємо питання, які найчастіше піднімають на технічному розборі: звідки беруться дані фонду, хто і що бачить усередині системи, що робити при розбіжності залишків і як вона переживає збій. Нижче — прямі відповіді, без загальних слів.
Звідки система бере дані фонду?
З кількох незалежних джерел: вузли мереж, вивантаження кастодіальних сервісів, записи торгових майданчиків. Кожен підключений окремим модулем зі своїм журналом і розкладом опитування.
Якщо джерела дають різні залишки, система не усереднює їх, а фіксує розбіжність і зберігає обидва значення до ручного розбору.
Як розмежовані права доступу?
Ролі описуються під структуру фонду: аналітик, бухгалтер, аудитор, адміністратор. Права перевіряються на боці сервісу, а не в інтерфейсі — прямий запит до даних їх не обійде. Аудитор бачить зрізи закритих періодів лише на читання, а ручні правки позначаються автором і часом.
Звіт не зійшовся з біржею — що далі?
Розбіжність залишків — робочий сценарій, а не аварія. Система розбирає її за причинами: неврахована комісія, затримка вивантаження, нарахування поза зрізом, курсова різниця на момент фіксації.
Кожна розбіжність стає в чергу із зазначенням джерела й часу, відповідальний бачить записи, що її породили.
Що відбувається після збою?
Журнал змін ведеться лише на дозапис — переписати історію операції не можна. Щоденні знімки стану плюс відтворення журналу дають повне відновлення за хвилини, а звіти минулих періодів перезбираються детерміновано: однакові вхідні дані дають однаковий результат.
Обговоримо задачу: покажемо схему і повернемося з оцінкою
Щоб повернутися з оцінкою, а не із загальними словами, на розмові розбираємо три речі: звідки надходять дані, як вважається результат і хто підтверджує коректність цифр на боці замовника.
Достатньо переліку джерел — біржові вивантаження, кастодіальні рахунки, гаманці, банківські надходження — і опису звітних форм, які фонд здає інвесторам та аудитору. Деталі інтеграцій уточнюємо самі: доступи до тестового контуру потрібні вже на прототипі, а не на запуску.
Після розмови ви отримуєте:
- Схему потоків даних: від джерела до рядка звіту, з точками звіряння та зберіганням сирих вивантажень для аудиту.
- План етапів впровадження: підключення джерел, нормалізація угод, розрахунок вартості активів і дохідності, звітні форми, звіряння на історичних періодах.
- Оцінку строків за кожним етапом — з позначками, де строк залежить від швидкості відповіді контрагентів.
- Склад команди: хто веде інтеграції, хто розрахункову логіку, хто приймання та підтримку після запуску.
- Реєстр ризиків за даними — розбіжності курсів, пропущені періоди, ручні коригування — і спосіб закриття кожного.
- Чернетку моделі доступу: що бачать інвестори, керуючий і аудитор, як розділяються права.
- Протокол розмови із зафіксованими припущеннями, щоб оцінка не розпливлася до наступної ітерації.
Старт робіт з обліку — з одного джерела та однієї звітної форми: на них перевіряємо сходження з поточними цифрами фонду, далі розширюємо контур. Опишіть задачу в загальних рисах — повернемося зі схемою, планом етапів та оцінкою строків.
