Чому ручне ребалансування криптопортфеля дає просадку
Ручне ребалансування криптопортфеля виглядає простою задачею: порахували цільові частки, виставили заявки, дочекалися виконання. Але між розрахунком і закриттям другої ноги угоди минає від хвилин до години, і за цей час ціни йдуть — фактичні частки вже не збігаються з моделлю. Чим більше активів і майданчиків у портфелі, тим сильніше підсумкове розходження.
Відхилення часток портфеля накопичується не за одну ітерацію. Лоти округлюються під мінімальний крок, частина лімітних заявок не виконується, щось залишається невикупленим — склад повільно від'їжджає від цільового.
Фонд у підсумку несе незапланований ризик: перевага у волатильному активі обертається просадкою фонду глибше розрахункової, і рішення щодо такого ризику ніхто не ухвалював.
Розсинхрон обліку додає другу проблему. Угоди йдуть на кількох майданчиках, між рахунками ходять перекази, нараховуються комісії — і якщо баланси звіряються вручну, розрахунок цільових часток іде від хибної бази.
Помилка оператора тут не аномалія, а очікуваний результат: копіювання рядків у таблиці, перерахунок на око, забута нога угоди.
Сервіси зберігання активів і аналітичні платформи, включно з Coin Metrics, віддають звірку окремим звітом саме тому: без неї частки рахуються від недостовірних залишків.
Розбираємо, як це закривається — регламентом розрахунку, автоматичним виставленням заявок і щоденною звіркою обліку.
Що дає фонду кероване ребалансування криптопортфеля
Ручне ребалансування впирається в людський фактор: трейдер бачить відхилення ваги із запізненням, збирає ордер «на око» і фіксує угоду в таблиці вже постфактум.
Автоматичне ребалансування переносить цю логіку в правила: цільові ваги й поріг відхилення задані заздалегідь, розрахунок запускається за розкладом і за подією, а людина підключається лише на підтвердження великих угод. Частка ручних операцій падає до поодиноких винятків, реакція на відхилення — хвилини замість годин.
Зниження просковзування — наслідок не «розумного алгоритму», а дисципліни виконання. Великий ордер ріжеться на частини, виставляється лімітними заявками за поточною глибиною книги ордерів, за потреби розтягується в часі.
Ціну для розрахунку відхилень беремо з незалежного джерела — Chainlink, щоб тригер не спрацьовував на тонкій біржовій свічці.
Контроль ризику портфеля будується як набір жорстких лімітів до відправлення заявки: максимальна частка одного активу, концентрація за секторами, денний обіг, допустима просадка.
У разі спрацювання правило не «показує попередження», а блокує операцію й піднімає алерт — нештатний сценарій переходить із класу «помітили пізніше» в клас «не пройшов».
Журнал операцій ведеться лише на дозапис: кожна зміна ваги, відхилення, спрацювання ліміту та відправлений ордер із міткою часу, ідентифікатором і причиною.
Це дає вивантаження для аудиту, відтворюваність розрахунків і зрозумілу картину для звітності перед інвесторами — замість листування й ручних таблиць.
Варіанти виконання: ручний контур, напівавтомат, автономний
Режим роботи — це не «рівень зрілості» продукту, а вибір того, хто тримає відповідальність за угоду і наскільки швидко система зобов'язана реагувати на відхід ціни від цільової частки.
Розрахунковий модуль цільових ваг у всіх трьох контурах один — змінюється лише ділянка між сигналом і відправленням заявки на біржу.
| Варіант | Коли підходить | Чим обмежений |
|---|---|---|
| Ручний режим | Широкий поріг відхилення, рідкісні угоди, стабільний склад портфеля | Реакція залежить від людини: між сигналом і виконанням минають години, момент входу втрачається |
| Напівавтоматичне ребалансування | Потрібен контроль на вході: система рахує цільові частки й готує заявки, рішення підтверджує людина | Ручне підтвердження залишається вузьким місцем при різкому русі ринку |
| Автономний контур | Відхилення від цільових ваг потрібно гасити цілодобово, правила формалізовані заздалегідь | Потребує лімітів, запобіжників і повного журналу: помилка в правилі тиражується на кожну угоду |
Обмеження автоматики задаються не кодом, а ризик-політикою: ліміт на обсяг однієї заявки, максимальне відхилення від цільової ваги, пауза при аномальній волатильності та журнал за кожним рішенням.
Якщо правило не можна сформулювати однозначно, ділянку залишають за людиною, а автоматику звужують до розрахунку й підготовки заявок.
Перемикання між контурами робимо налаштуванням: історія ваг і журнал угод спільні, тому зміна режиму не вимагає переписувати логіку й не розриває аудит.
Етапи робіт: від аудиту портфельної логіки до передачі
Роботу починаємо не з коду, а з розбору того, як фонд керує складом портфеля зараз: цільові частки, допустимі відхилення, джерела цін, періодичність перевірки умов.
Правила фіксуємо в однозначному вигляді — зазвичай розходження між описом стратегії й тим, що реально рахує поточна таблиця, виявляється вже тут.
- Аудит портфельної логіки. Збираємо цільові ваги, пороги спрацювання, правила округлення й черговість угод, окремо відзначаємо рішення, які зараз ухвалюються вручну.
- Проєктування правил ребалансування. Описуємо умови запуску, порядок розрахунку обсягів і поведінку в граничних випадках: нестача ліквідності, різкий розрив ціни, недоступне джерело котирувань.
- Узгодження на історії. Проганяємо правила на минулих даних фонду й звіряємо результат з очікуваннями керуючого — до початку впровадження.
- Впровадження системи. Розрахункове ядро, інтеграції з біржами й кастодіальним контуром, журнал кожної заявки, розмежування прав оператора.
- Перевірка на тестовому контурі. Прогін сценаріїв на малих обсягах, звірка розрахунків незалежним методом, перевірка відмов і повторного запуску.
- Приймання. Демонстрація в робочих умовах, передача доступів, документація за правилами та інструкція щодо дій при збої.
- Передача команді фонду. Навчання керуючого й чергового інженера, супровід перших циклів ребалансування.
Кожен етап закінчується артефактом: схемою правил, протоколом прогону, інструкцією для чергового. Якщо на узгодженні правило виявляється неоднозначним, повертаємося на крок назад — це дешевше, ніж ловити розходження вже на живих угодах.
Що залишається у фонду: конфігурація, доступи, регламенти
Після запуску система залишається у вашому контурі: керуючі ключі, конфігурація та інфраструктура — на вашому боці, ми не залишаємося єдиною точкою доступу до торгового контуру.
Передаємо не «працюючий сервіс», а комплект артефактів, за яким систему зможе супроводжувати будь-який інженер, а не лише автор.
Склад фіксуємо актом — щоб через рік не з'ясувалося, що частина налаштувань живе лише в листуванні.
- Конфігурація системи — цільові ваги активів, коридор допустимого відхилення, частота перевірки, ліміти на обсяг однієї заявки. Зберігається файлами у вашому репозиторії, з історією правок і відкатом до попередньої версії.
- Політики доступу — ролі, розподіл ключів підпису, пороги підтверджень, окремі права на зміну налаштувань і на виведення коштів. Наш доступ відкликається однією операцією, без зупинки системи.
- Регламент ребалансування — умови спрацювання тригера, правило розрахунку обсягу заявки, дії при просковзуванні вище порогу та при обриві зв'язку з біржею.
- Схеми й архітектурна документація — потоки даних, точки відмови, резервний контур, перелік зовнішніх залежностей.
- Моніторинг і оповіщення — набір метрик, пороги спрацювання, канали сповіщень, порядок ескалації черговим.
- Порядок відновлення — покрокові дії при інциденті: зупинка торгового контуру, відкат конфігурації, звірка позицій з біржею.
- Журнал операцій — причина кожного ребалансування, фактичні обсяги угод, залишкове відхилення від цільових ваг.
- Передача знань — розбір із вашою командою та доступ до тестового контуру для самостійних прогонів змін.
Кейс: як фонд прибрав ручні операції та знизив просковзування
Фонд із портфелем із десятка активів тримав цільові ваги в таблиці й приводив портфель до них вручну: аналітик раз на добу звіряв фактичні частки з цільовими, трейдер збирав заявки й виставляв їх блоками.
Між звірками вага встигала відійти від цілі на 8–12%, реакція займала 6–9 годин, а частина обсягу йшла за ціною гіршою за розрахункову — на волатильному ринку це з'їдало результат стратегії.
Ми зібрали кейс ребалансування як контур із трьох модулів: розрахунок відхилень за актуальними котируваннями (кілька джерел цін усереднюються, включно з Chainlink), планувальник виконання, який дробить велику заявку й веде її з лімітом за ціною, і контроль складу — він звіряє фактичний портфель з очікуваним і піднімає розходження. Ребалансування запускається за порогом відхилення, а не за розкладом.
Метрики до і після
- Час реакції на відхилення: 6–9 годин → 3–7 хвилин.
- Частка ручних угод: близько 95% → 12% — вручну залишаються лише великі обсяги поза лімітами, їх підтверджує гаманець із кількома підписами.
- Втрати на виконанні: 0,8–1,1% → 0,2–0,3% від обсягу угоди завдяки дробленню й ліміту ціни.
- Виконання без переробок: 88% → 99%.
Стабільність виконання тримається на повторному запуску без дублів: незавершене ребалансування продовжується з місця зупинки, а недоступність одного джерела цін не валить контур — розрахунок іде за рештою, розходження потрапляє в журнал.
Ручні операції пішли зі щоденного циклу, і результат стратегії перестав залежати від того, хто сьогодні на зміні.
Чим порогова схема відрізняється від календарної і що вибрати?
Різниця — у тригері. Календарне ребалансування запускає угоди за розкладом: раз на день, тиждень або місяць, незалежно від того, як відійшли частки.
Порогова дивиться на склад портфеля й спрацьовує, коли відхилення частки від цільової виходить за коридор допуску — у першому випадку момент перебудови відомий заздалегідь, у другому його визначає ринок.
Поріг — не одне число, а коридор плюс гістерезис: вхід у перебудову при виході за верхню межу й повернення до звичайного контролю лише після звуження до нижньої.
Без гістерезису портфель, що стоїть на межі, видає каскад дрібних угод, і кожна з'їдає результат на комісії та просковзуванні.
| Схема | Коли підходить | Обмеження |
|---|---|---|
| Календарна | Активи близькі за волатильністю, потрібне рівне операційне навантаження й прозора звітність | Різкий розворот між датами фіксується із запізненням, частки встигають від'їхати від еталона |
| Порогова | Дохідності активів розходяться, жорстко обмежене відхилення від еталонної структури | У спокійному боковику мовчить тижнями, у шторм дає серію перебудов поспіль |
| Гібридна | Широкий портфель із різними класами активів, критична керованість витрат | Потребує налаштування порогів за кожним активом і контролю ліквідності в момент спрацювання |
Вибір схеми зводять до трьох параметрів: розкид поведінки активів, вартість однієї угоди та допустиме розходження з еталонною структурою. Наш підхід — гібрид: календарний обхід як базовий ритм і пороги як запобіжник, із логуванням кожного спрацювання.
Так частота перебудов залишається керованою, а у звітності видно, чому угода відбулася саме в цей момент.
Технічні сумніви: доступи, збої, ліміти, аудит операцій
Права розділяємо за ролями, а не за людьми: трейдер ініціює ребалансування, ризик-менеджер затверджує відхилення від цільових ваг, казначей підписує виведення коштів.
Ключі підпису живуть в окремому контурі: сервіс розрахунку формує лише непідписану операцію, тому один скомпрометований доступ не дає вивести активи — максимум заявку, яку відхилить другий підпис.
Обсяг угоди обмежений на кількох рівнях: частка від портфеля, ліміт на одну операцію й накопичений добовий. При перевищенні система не дорізає ордер, а зупиняє серію й фіксує стан портфеля у відомій точці.
Збої перевіряємо навмисно — обрив каналу до біржі, відмова вузла, перезапуск процесу: операції ідемпотентні за ідентифікатором наміру, тому повтор не створює другої угоди, а підхоплює розпочату.
Аудит операцій — незмінюваний журнал: хто ініціював, які ваги були до і після, який ліміт спрацював, який підпис підтвердив. Записи зчеплені хешами, заднім числом їх не підмінити, а вивантаження віддається в машинозчитуваному вигляді.
Що буде, якщо угода «зависне» між станами?
Сервіс зберігає намір і його статус до підтвердження в мережі. Після перезапуску він звіряє фактичні позиції з журналом і або завершує операцію, або відкочує її — портфель не залишається в напівзастосованому вигляді.
Кому з команди замовника давати доступ до журналу?
Достатньо ролі «спостерігач»: вона відкриває історію та вивантаження, але не дає змінювати ліміти чи ініціювати операції. Ключі підпису й доступ до журналу розведені — той, хто дивиться, не може діяти.
Обговоримо задачу: що потрібно від фонду для старту
Щоб повернутися з оцінкою та планом робіт, а не із загальними міркуваннями, потрібні вихідні дані фонду. Частину з них зафіксуємо як проєктні припущення, але від повноти картини напряму залежать і строк, і точність оцінки.
- Інвестиційна політика: цільові ваги за активами, допустимі відхилення й умови запуску ребалансування — за порогом, за календарем або комбіновано.
- Інфраструктура виконання: біржі та кастодіани, типи підключень, мультипідписні гаманці, білий список адрес виведення.
- Розподіл ролей і ключів: хто формує заявку, хто підтверджує, скільки підписів потрібно для переказу коштів і де зберігаються ключі.
- Джерела цін і обліку: звідки беруться котирування, як рахується вартість чистих активів, у якому вигляді потрібен звіт про угоду.
- Контроль і ліміти: журнал дій, розмежування прав, обмеження на обсяг і частоту угод, регламент зупинки при відхиленні від очікуваної поведінки.
- Середовище розміщення й навантаження: ваш контур чи виділений, вимоги до резервного копіювання й часу відновлення, кількість активів і рахунків, частота перерахунку ваг.
Після розбору повернемося з архітектурою, оцінкою строків і планом робіт за етапами — з явним розподілом зон відповідальності фонду та нашої команди.
