Розробка системи ребалансування криптопортфеля фонду під ключ

Чому ручне ребалансування криптопортфеля дає просадку

Ручне ребалансування криптопортфеля виглядає простою задачею: порахували цільові частки, виставили заявки, дочекалися виконання. Але між розрахунком і закриттям другої ноги угоди минає від хвилин до години, і за цей час ціни йдуть — фактичні частки вже не збігаються з моделлю. Чим більше активів і майданчиків у портфелі, тим сильніше підсумкове розходження.

Відхилення часток портфеля накопичується не за одну ітерацію. Лоти округлюються під мінімальний крок, частина лімітних заявок не виконується, щось залишається невикупленим — склад повільно від'їжджає від цільового.

Фонд у підсумку несе незапланований ризик: перевага у волатильному активі обертається просадкою фонду глибше розрахункової, і рішення щодо такого ризику ніхто не ухвалював.

Розсинхрон обліку додає другу проблему. Угоди йдуть на кількох майданчиках, між рахунками ходять перекази, нараховуються комісії — і якщо баланси звіряються вручну, розрахунок цільових часток іде від хибної бази.

Помилка оператора тут не аномалія, а очікуваний результат: копіювання рядків у таблиці, перерахунок на око, забута нога угоди.

Сервіси зберігання активів і аналітичні платформи, включно з Coin Metrics, віддають звірку окремим звітом саме тому: без неї частки рахуються від недостовірних залишків.

Розбираємо, як це закривається — регламентом розрахунку, автоматичним виставленням заявок і щоденною звіркою обліку.

Що дає фонду кероване ребалансування криптопортфеля

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

Автоматичне ребалансування переносить цю логіку в правила: цільові ваги й поріг відхилення задані заздалегідь, розрахунок запускається за розкладом і за подією, а людина підключається лише на підтвердження великих угод. Частка ручних операцій падає до поодиноких винятків, реакція на відхилення — хвилини замість годин.

Зниження просковзування — наслідок не «розумного алгоритму», а дисципліни виконання. Великий ордер ріжеться на частини, виставляється лімітними заявками за поточною глибиною книги ордерів, за потреби розтягується в часі.

Ціну для розрахунку відхилень беремо з незалежного джерела — Chainlink, щоб тригер не спрацьовував на тонкій біржовій свічці.

Контроль ризику портфеля будується як набір жорстких лімітів до відправлення заявки: максимальна частка одного активу, концентрація за секторами, денний обіг, допустима просадка.

У разі спрацювання правило не «показує попередження», а блокує операцію й піднімає алерт — нештатний сценарій переходить із класу «помітили пізніше» в клас «не пройшов».

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

Це дає вивантаження для аудиту, відтворюваність розрахунків і зрозумілу картину для звітності перед інвесторами — замість листування й ручних таблиць.

Варіанти виконання: ручний контур, напівавтомат, автономний

Режим роботи — це не «рівень зрілості» продукту, а вибір того, хто тримає відповідальність за угоду і наскільки швидко система зобов'язана реагувати на відхід ціни від цільової частки.

Розрахунковий модуль цільових ваг у всіх трьох контурах один — змінюється лише ділянка між сигналом і відправленням заявки на біржу.

Обмеження автоматики задаються не кодом, а ризик-політикою: ліміт на обсяг однієї заявки, максимальне відхилення від цільової ваги, пауза при аномальній волатильності та журнал за кожним рішенням.

Якщо правило не можна сформулювати однозначно, ділянку залишають за людиною, а автоматику звужують до розрахунку й підготовки заявок.

Перемикання між контурами робимо налаштуванням: історія ваг і журнал угод спільні, тому зміна режиму не вимагає переписувати логіку й не розриває аудит.

Етапи робіт: від аудиту портфельної логіки до передачі

Роботу починаємо не з коду, а з розбору того, як фонд керує складом портфеля зараз: цільові частки, допустимі відхилення, джерела цін, періодичність перевірки умов.

Правила фіксуємо в однозначному вигляді — зазвичай розходження між описом стратегії й тим, що реально рахує поточна таблиця, виявляється вже тут.

1. Аудит портфельної логіки. Збираємо цільові ваги, пороги спрацювання, правила округлення й черговість угод, окремо відзначаємо рішення, які зараз ухвалюються вручну.
2. Проєктування правил ребалансування. Описуємо умови запуску, порядок розрахунку обсягів і поведінку в граничних випадках: нестача ліквідності, різкий розрив ціни, недоступне джерело котирувань.
3. Узгодження на історії. Проганяємо правила на минулих даних фонду й звіряємо результат з очікуваннями керуючого — до початку впровадження.
4. Впровадження системи. Розрахункове ядро, інтеграції з біржами й кастодіальним контуром, журнал кожної заявки, розмежування прав оператора.
5. Перевірка на тестовому контурі. Прогін сценаріїв на малих обсягах, звірка розрахунків незалежним методом, перевірка відмов і повторного запуску.
6. Приймання. Демонстрація в робочих умовах, передача доступів, документація за правилами та інструкція щодо дій при збої.
7. Передача команді фонду. Навчання керуючого й чергового інженера, супровід перших циклів ребалансування.

Кожен етап закінчується артефактом: схемою правил, протоколом прогону, інструкцією для чергового. Якщо на узгодженні правило виявляється неоднозначним, повертаємося на крок назад — це дешевше, ніж ловити розходження вже на живих угодах.

Що залишається у фонду: конфігурація, доступи, регламенти

Після запуску система залишається у вашому контурі: керуючі ключі, конфігурація та інфраструктура — на вашому боці, ми не залишаємося єдиною точкою доступу до торгового контуру.

Передаємо не «працюючий сервіс», а комплект артефактів, за яким систему зможе супроводжувати будь-який інженер, а не лише автор.

Склад фіксуємо актом — щоб через рік не з'ясувалося, що частина налаштувань живе лише в листуванні.

• Конфігурація системи — цільові ваги активів, коридор допустимого відхилення, частота перевірки, ліміти на обсяг однієї заявки. Зберігається файлами у вашому репозиторії, з історією правок і відкатом до попередньої версії.
• Політики доступу — ролі, розподіл ключів підпису, пороги підтверджень, окремі права на зміну налаштувань і на виведення коштів. Наш доступ відкликається однією операцією, без зупинки системи.
• Регламент ребалансування — умови спрацювання тригера, правило розрахунку обсягу заявки, дії при просковзуванні вище порогу та при обриві зв'язку з біржею.
• Схеми й архітектурна документація — потоки даних, точки відмови, резервний контур, перелік зовнішніх залежностей.
• Моніторинг і оповіщення — набір метрик, пороги спрацювання, канали сповіщень, порядок ескалації черговим.
• Порядок відновлення — покрокові дії при інциденті: зупинка торгового контуру, відкат конфігурації, звірка позицій з біржею.
• Журнал операцій — причина кожного ребалансування, фактичні обсяги угод, залишкове відхилення від цільових ваг.
• Передача знань — розбір із вашою командою та доступ до тестового контуру для самостійних прогонів змін.

Кейс: як фонд прибрав ручні операції та знизив просковзування

Фонд із портфелем із десятка активів тримав цільові ваги в таблиці й приводив портфель до них вручну: аналітик раз на добу звіряв фактичні частки з цільовими, трейдер збирав заявки й виставляв їх блоками.

Між звірками вага встигала відійти від цілі на 8–12%, реакція займала 6–9 годин, а частина обсягу йшла за ціною гіршою за розрахункову — на волатильному ринку це з'їдало результат стратегії.

Ми зібрали кейс ребалансування як контур із трьох модулів: розрахунок відхилень за актуальними котируваннями (кілька джерел цін усереднюються, включно з Chainlink), планувальник виконання, який дробить велику заявку й веде її з лімітом за ціною, і контроль складу — він звіряє фактичний портфель з очікуваним і піднімає розходження. Ребалансування запускається за порогом відхилення, а не за розкладом.

Метрики до і після

• Час реакції на відхилення: 6–9 годин → 3–7 хвилин.
• Частка ручних угод: близько 95% → 12% — вручну залишаються лише великі обсяги поза лімітами, їх підтверджує гаманець із кількома підписами.
• Втрати на виконанні: 0,8–1,1% → 0,2–0,3% від обсягу угоди завдяки дробленню й ліміту ціни.
• Виконання без переробок: 88% → 99%.

Стабільність виконання тримається на повторному запуску без дублів: незавершене ребалансування продовжується з місця зупинки, а недоступність одного джерела цін не валить контур — розрахунок іде за рештою, розходження потрапляє в журнал.

Ручні операції пішли зі щоденного циклу, і результат стратегії перестав залежати від того, хто сьогодні на зміні.

Чим порогова схема відрізняється від календарної і що вибрати?

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

Порогова дивиться на склад портфеля й спрацьовує, коли відхилення частки від цільової виходить за коридор допуску — у першому випадку момент перебудови відомий заздалегідь, у другому його визначає ринок.

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

Без гістерезису портфель, що стоїть на межі, видає каскад дрібних угод, і кожна з'їдає результат на комісії та просковзуванні.

Вибір схеми зводять до трьох параметрів: розкид поведінки активів, вартість однієї угоди та допустиме розходження з еталонною структурою. Наш підхід — гібрид: календарний обхід як базовий ритм і пороги як запобіжник, із логуванням кожного спрацювання.

Так частота перебудов залишається керованою, а у звітності видно, чому угода відбулася саме в цей момент.

Технічні сумніви: доступи, збої, ліміти, аудит операцій

Права розділяємо за ролями, а не за людьми: трейдер ініціює ребалансування, ризик-менеджер затверджує відхилення від цільових ваг, казначей підписує виведення коштів.

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

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

Збої перевіряємо навмисно — обрив каналу до біржі, відмова вузла, перезапуск процесу: операції ідемпотентні за ідентифікатором наміру, тому повтор не створює другої угоди, а підхоплює розпочату.

Аудит операцій — незмінюваний журнал: хто ініціював, які ваги були до і після, який ліміт спрацював, який підпис підтвердив. Записи зчеплені хешами, заднім числом їх не підмінити, а вивантаження віддається в машинозчитуваному вигляді.

Кому з команди замовника давати доступ до журналу?

Достатньо ролі «спостерігач»: вона відкриває історію та вивантаження, але не дає змінювати ліміти чи ініціювати операції. Ключі підпису й доступ до журналу розведені — той, хто дивиться, не може діяти.

Обговоримо задачу: що потрібно від фонду для старту

Щоб повернутися з оцінкою та планом робіт, а не із загальними міркуваннями, потрібні вихідні дані фонду. Частину з них зафіксуємо як проєктні припущення, але від повноти картини напряму залежать і строк, і точність оцінки.

• Інвестиційна політика: цільові ваги за активами, допустимі відхилення й умови запуску ребалансування — за порогом, за календарем або комбіновано.
• Інфраструктура виконання: біржі та кастодіани, типи підключень, мультипідписні гаманці, білий список адрес виведення.
• Розподіл ролей і ключів: хто формує заявку, хто підтверджує, скільки підписів потрібно для переказу коштів і де зберігаються ключі.
• Джерела цін і обліку: звідки беруться котирування, як рахується вартість чистих активів, у якому вигляді потрібен звіт про угоду.
• Контроль і ліміти: журнал дій, розмежування прав, обмеження на обсяг і частоту угод, регламент зупинки при відхиленні від очікуваної поведінки.
• Середовище розміщення й навантаження: ваш контур чи виділений, вимоги до резервного копіювання й часу відновлення, кількість активів і рахунків, частота перерахунку ваг.

Після розбору повернемося з архітектурою, оцінкою строків і планом робіт за етапами — з явним розподілом зон відповідальності фонду та нашої команди.