Розробка алгоритму статистичного арбітражу для криптовалют
Ви знайшли дві монети, які, здається, ходять разом — BTC і ETH. Але коли одна йде вгору, а інша запізнюється, ви хочете на цьому заробити. Статистичний арбітраж (stat arb) саме про це: тимчасові відхилення від історично стійких співвідношень. На відміну від чистого арбітражу (безризикового прибутку), stat arb несе ризик — співвідношення може тимчасово розширитися перед тим, як повернеться. Саме ця ризикованість і створює можливість для прибутку. Наш досвід 5+ років і більше 50 реалізованих проєктів дозволяють перетворити цю ідею на працюючий алгоритм.
Чому коінтеграція важливіша за кореляцію?
Кореляція показує, як змінюються ціни разом, але не гарантує повернення до середнього. Коінтеграція — статистичний зв'язок, при якому лінійна комбінація двох рядів стаціонарна. Простіше кажучи: активи можуть розходитися, але в довгостроковій перспективі повертаються один до одного. Саме ця властивість потрібна для stat arb.
Тест Engle-Granger для перевірки коінтеграції:
from statsmodels.tsa.stattools import coint def find_cointegrated_pairs(prices_dict, p_threshold=0.05): symbols = list(prices_dict.keys()) pairs = [] for i, sym1 in enumerate(symbols): for sym2 in symbols[i+1:]: score, p_value, _ = coint( prices_dict[sym1], prices_dict[sym2] ) if p_value < p_threshold: pairs.append((sym1, sym2, p_value)) return sorted(pairs, key=lambda x: x[2]) Хороші кандидати в крипті: BTC/ETH, BTC-SPOT/BTC-PERP, аналогічні Layer-1 токени, ETH/LDO (staking derivative).
Модель: Spread і Z-score
Для коінтегрованої пари (X, Y) знаходимо hedge ratio β через OLS:
from sklearn.linear_model import LinearRegression def calculate_hedge_ratio(price_x, price_y, window=60): # Rolling OLS для динамічного hedge ratio hedge_ratios = [] for i in range(window, len(price_x)): x = price_x[i-window:i].values.reshape(-1, 1) y = price_y[i-window:i].values model = LinearRegression().fit(x, y) hedge_ratios.append(model.coef_[0]) return hedge_ratios Spread = Y - β × X Z-score нормалізує спред:
Z-score = (Spread - mean(Spread)) / std(Spread) Торгові сигнали:
- Z-score > +2: спред аномально широкий → продаємо Y, купуємо X (лонг спред)
- Z-score < -2: спред аномально вузький → купуємо Y, продаємо X (шорт спред)
- |Z-score| < 0.5: закриваємо позицію (повернення до середнього)
Як вибрати між статичним і динамічним хедж-раціо?
Статичне β через OLS просте, але застаріває. Kalman Filter адаптує hedge ratio в реальному часі, даючи в 2-3 рази менше хибних сигналів. На основі наших тестів, Kalman filter кращий за OLS у 2-3 рази за точністю сигналів. Порівняння методів:
| Параметр | Rolling OLS | Kalman Filter |
|---|---|---|
| Адаптивність | низька | висока |
| Чутливість до викидів | висока | низька |
| Кількість сигналів | середня | висока |
Приклад реалізації Kalman Filter:
from pykalman import KalmanFilter kf = KalmanFilter( transition_matrices=[1], observation_matrices=price_x.values.reshape(-1, 1, 1), initial_state_mean=0, initial_state_covariance=1, observation_covariance=1, transition_covariance=0.05 ) state_means, state_covs = kf.filter(price_y.values) hedge_ratio_dynamic = state_means.flatten() Детальніше про фільтр Калмана
Фільтр Калмана — рекурсивний алгоритм, який оцінює стан системи за зашумленими вимірами. У нашому випадку він оновлює hedge ratio на кожному новому тіку, зважуючи попередню оцінку та нове спостереження. Це особливо корисно для пар, у яких співвідношення змінюється з часом (наприклад, через хардфорки або зміни ліквідності).Управління ризиками спреду
Stop-loss по Z-score: якщо Z-score розширився до 3+ замість звуження — це може означати структурний зсув. Виходимо з позиції.
Half-life of mean reversion: оцінюємо через модель AR(1):
from statsmodels.regression.linear_model import OLS def calculate_half_life(spread): spread_lag = spread.shift(1).dropna() spread_diff = spread.diff().dropna() result = OLS(spread_diff, spread_lag).fit() half_life = -np.log(2) / result.params[0] return half_life Half-life < 5 днів — швидкий mean reversion, підходить для короткострокової торгівлі. > 30 днів — повільний, вимагає довших позицій.
Lookback window: період для розрахунку mean і std спреду. Оптимізується через walk-forward.
Мультипарний stat arb: диверсифікація та PCA
Замість торгівлі парами — портфельний підхід з кількома коінтегрованими парами:
- Диверсифікація знижує ризик конкретної пари
- Кореляція між парами має бути мінімальною
- PCA для пошуку спільних факторів
Eigenvector portfolio: з матриці коваріацій N активів через PCA витягуємо стаціонарні власні вектори. Торгуємо відхилення від стаціонарного стану.
Execution і транзакційні витрати
Stat arb прибутковий тільки якщо дохідність перевищує транзакційні витрати. Економія на slippage може сягати 30% при оптимізації виконання.
| Стаття витрат | Типовий діапазон |
|---|---|
| Біржові fees (taker) | 0.04–0.07% |
| Maker fees | 0–0.02% |
| Funding rate (perpetual) | залежить від ринку |
| Slippage | 0.01–0.1% залежно від ліквідності |
| Borrowing cost (short) | 0.01–0.03% на день |
Мінімальний Z-score для входу підбирається з урахуванням costs: якщо entry при Z=1.5 не покриває costs з урахуванням імовірності повернення — використовуємо Z=2.0.
Backtesting
Walk-forward validation: навчання на 6-12 місяцях, тестування на наступних 1-2 місяцях, повтор зі зсувом. Ключові метрики: Sharpe Ratio > 1.5, max drawdown < 15%, середня тривалість позиції (half-life збігається з реальним?).
Overfitting check: параметри, оптимізовані на одному періоді, мають працювати на іншому.
Етапи роботи над проєктом
- Відбір коінтегрованих пар за допомогою тесту Енгла-Грейнджера.
- Вибір моделі (OLS або Kalman filter) та налаштування параметрів.
- Бектестінг з walk-forward валідацією та оптимізацією Z-порогів.
- Інтеграція з біржею через CCXT та налаштування виконання.
- Моніторинг у реальному часі та адаптація стратегії.
Що входить в роботу
- Дослідження та вибір коінтегрованих пар
- Розробка алгоритму з Kalman filter або OLS hedge ratio
- Бектестінг на історичних даних з walk-forward
- Оптимізація параметрів і торгових сигналів
- Інтеграція з біржею через CCXT
- Моніторинг і підтримка після запуску
Гарантуємо якість коду та прозорість результатів. Ми використовуємо Python (pandas, numpy, statsmodels, sklearn, pykalman), PostgreSQL для зберігання даних, Celery для розрахунків у реальному часі, Grafana для візуалізації. Розгортаємо на AWS/GCP з низькою затримкою.
Вартість розробки починається від $5,000, але окупається за кілька місяців. Зв'яжіться з нами, щоб обговорити ваш проєкт і отримати консультацію.
Джерело: Engle & Granger (1987) — Co-Integration and Error Correction: Representation, Estimation, and Testing.