Разработка системы risk-reporting крипто-фонда

Разработка системы risk-reporting крипто-фонда

Крипто-фонды работают в условиях, которые традиционный риск-менеджмент просто не предусматривал: 24/7 рынок без circuit breakers, позиции одновременно в on-chain протоколах и на централизованных биржах, liquidation риски с нелинейной зависимостью от цены, контрагентный риск кастодиана и смарт-контракта одновременно. Стандартные инструменты (Bloomberg, Advent) не понимают DeFi. Строить систему нужно с нуля — или адаптировать существующие риск-фреймворки к крипто-реальности.

Источники данных: где живут позиции фонда

Первая и главная сложность — агрегация. Позиции фонда могут находиться в:

CeFi: Binance, OKX, Bybit, Kraken — у каждой биржи свой API. REST для снапшотов позиций, WebSocket для real-time PnL. Проблема: API rate limits, нестандартные форматы маржинальных счётов, разные модели риска для cross/isolated margin.

DeFi on-chain:

• Lending: Aave v3, Compound v3, Morpho — позиции через смарт-контракт view functions или subgraph
• Perps: GMX, dYdX v4, Hyperliquid — у каждого своя модель счёта
• LP позиции: Uniswap v3 (concentrated liquidity = нелинейный payoff), Curve, Balancer
• Yield: EigenLayer, Pendle (токенизированный yield), Convex
• Структурированные продукты: Ribbon, Lyra — опционные стратегии on-chain

Custody: Fireblocks, Copper, Anchorage — обычно REST API для балансов. MPC-кошельки видны как обычные on-chain адреса.

Итого: агрегатор данных — это 5-15 разных интеграций с разным качеством API и разной надёжностью источников.

Архитектура системы

Data layer

[CeFi APIs]  [On-chain nodes]  [Price feeds]
      ↓              ↓               ↓
   [Kafka / message queue]
      ↓
[Normalizer Service]    ← единая модель Position, Balance, Trade
      ↓
[Time-series DB]        ← TimescaleDB или ClickHouse
      ↓
[Risk Engine]           ← расчёт метрик
      ↓
[Reporting API + UI]

Нормализованная модель позиции:

interface Position {
  id: string;
  fund_id: string;
  venue: 'binance' | 'aave_v3' | 'gmx' | string;
  venue_type: 'cex' | 'dex_perp' | 'lending' | 'lp' | 'spot';
  asset: string;         // базовый актив (ETH, BTC, SOL)
  quote_asset: string;   // USDT, USDC, USD
  size: Decimal;         // в базовом активе
  size_usd: Decimal;     // USD-эквивалент
  side: 'long' | 'short' | 'neutral';
  entry_price?: Decimal;
  mark_price: Decimal;
  unrealized_pnl_usd: Decimal;
  // для lending
  health_factor?: Decimal;
  liquidation_price?: Decimal;
  // для LP
  tick_lower?: number;
  tick_upper?: number;
  in_range?: boolean;
  snapshot_ts: Date;
}

Risk Engine: ключевые метрики

Net Delta. Суммарная экспозиция по каждому базовому активу с учётом всех позиций:

delta_ETH = Σ(position.size × sign × delta_multiplier)

Для линейных позиций delta = 1, для опционов — греки, для LP в Uniswap v3 — производная от функции ликвидности (нелинейно зависит от текущей цены в диапазоне).

Portfolio VaR (Value at Risk). Для крипто используются несколько подходов:

• Historical simulation — на основе фактической P&L истории за 1-2 года. Проблема: история биткоина короткая, а крипто-корреляции нестабильны (особенно в кризисы).
• Parametric VaR — модель нормального распределения доходностей. Для крипто плохо работает: тяжёлые хвосты, skew. Используется только как grounding estimate.
• Monte Carlo — симуляция ценовых путей с заданными параметрами волатильности и корреляций. Наиболее гибкий, но вычислительно тяжёлый.

import numpy as np
from scipy import stats

def historical_var(returns: np.ndarray, confidence: float = 0.99) -> float:
    """
    returns: дневные доходности портфеля в USD
    confidence: 0.99 → 1% worst case
    """
    return -np.percentile(returns, (1 - confidence) * 100)

def conditional_var(returns: np.ndarray, confidence: float = 0.99) -> float:
    """Expected Shortfall / CVaR — среднее потерь хуже VaR"""
    var = historical_var(returns, confidence)
    tail_returns = returns[returns <= -var]
    return -tail_returns.mean() if len(tail_returns) > 0 else var

Stress testing. Сценарии специфичные для крипто:

Liquidation distance. Для каждой lending позиции:

def liquidation_distance(
    health_factor: Decimal,
    liquidation_threshold: Decimal,
    collateral_price: Decimal,
) -> dict:
    """
    Aave v3 liquidation: health_factor < 1
    health_factor = Σ(collateral_i × LT_i) / total_debt
    """
    # При каком падении цены коллатерала наступает ликвидация
    price_drop_to_liquidation = 1 - (1 / health_factor)
    return {
        'current_hf': health_factor,
        'price_drop_pct': price_drop_to_liquidation * 100,
        'liquidation_price': collateral_price * (1 - price_drop_to_liquidation),
    }

Concentration risk. Доля каждого актива/протокола/контрагента в портфеле. Herfindahl-Hirschman Index для концентрации:

HHI = Σ(s_i²)  где s_i — доля i-го актива

HHI = 1 — полная концентрация, HHI → 0 — полная диверсификация.

Counterparty risk score. Субъективная но необходимая метрика:

Алерты и триггеры

Real-time мониторинг с порогами:

alerts:
  - name: health_factor_critical
    condition: health_factor < 1.2
    severity: critical
    channels: [telegram, pagerduty]
    
  - name: net_delta_breach
    condition: abs(net_delta_usd) > max_allowed_delta
    severity: high
    
  - name: var_limit_breach
    condition: daily_var > var_limit * portfolio_nav
    severity: high
    
  - name: concentration_limit
    condition: single_asset_pct > 0.4
    severity: medium
    
  - name: exchange_withdrawal_anomaly
    condition: cex_balance_change > 0.1 * cex_total
    severity: medium

Доставка алертов: Telegram Bot API для оперативных уведомлений, PagerDuty для критических, email для дневных отчётов.

Отчётность

Дневной риск-отчёт

Структура (автоматически генерируется в PDF или отправляется в Telegram/email):

1. Snapshot NAV — общая стоимость портфеля с разбивкой по venues
2. Delta exposure — нетто экспозиция по каждому активу
3. VaR metrics — 1-day VaR at 95%/99%, CVaR
4. Liquidation watchlist — позиции с HF < 1.5, расстояние до ликвидации
5. Concentration — топ-5 активов и протоколов по доле
6. Realized PnL — за день/неделю/месяц с attribution по стратегиям
7. Stress scenarios — результаты стандартных сценариев

Compliance reporting

Для институциональных инвесторов (LP) часто нужны:

• ILPA-совместимые отчёты — стандартные форматы для прайвит-фондов
• Risk disclosure — описание рисков на понятном языке для non-technical LP
• Exposure limits compliance — подтверждение соблюдения инвестиционной декларации

Если фонд регулируется (например, через MiCA в EU или как VASP), отчётность должна соответствовать требованиям регулятора.

Технологический стек

Этапы реализации

Этап 1 — Интеграции (3-5 недель). Подключение к CeFi API и on-chain sources для конкретных venues фонда. Нормализация в единую модель позиции. Исторический бэкфилл.

Этап 2 — Risk engine (2-3 недели). Расчёт delta, VaR, liquidation distance, concentration metrics. Стресс-тесты. Валидация на исторических данных.

Этап 3 — Алерты (1-2 недели). Real-time мониторинг, конфигурируемые пороги, интеграция с Telegram/PagerDuty.

Этап 4 — Reporting UI (2-3 недели). Дашборд для портфельного менеджера, автоматическая генерация отчётов, экспорт для LP.

Итого: 8-13 недель для фонда со стандартным набором venues (2-3 CeFi + 3-5 DeFi протоколов). Каждая новая нестандартная интеграция добавляет 3-7 дней.