Волатильність крипто і хеджування
TL; DR
Крипто-платежі дають швидкий TtW, низьку вартість і глобальне покриття, але несуть ціновий ризик. Базова стратегія - моментальна конверсія (auto-sell в стейбл/фіат) і NWP-хедж (хеджувати тільки нетто-виплати). Для утримання ризику: ліміти експозиції (у хвилинах/годинах), хедж-інструменти (спот/перп/ф'ючерс/опціони), дисципліна он/офф-рампів, дашборди VaR/TtH (time-to-hedge) і жорстка операційна ідемпотентність.
1) Джерела волатильності в платіжному контурі
Ціна базового активу: BTC/ETH/TON та ін.
Depeg стейблкоінів: UST кейс → керуємо часткою на емітента/ланцюг.
Ф'ючерсна база і funding: перпи ↔ спот (премія/дисконт).
Ліквідність і прослизання: нічні години, локальні ринки, «тонкі» пари/ланцюги.
FX поверх крипто: баланс фіатних валют vs USD-номінація активів.
Операційне вікно: затримки он/офф-рампів, підтвердження блокчейна (конфи).
2) Політика трежері (опорна модель)
Мета: мінімізувати P&L від ціни при збереженні UX і маржинальності.
2. 1 Принципи
1. Auto-hedge on receipt: в момент депозиту конвертувати в стейбл (USDC/USDT/... з лімітами по емітентам) або фіат.
2. NWP-hedge (Net Withdrawal Position): хеджувати нетто-виплати: «нетто = очікувані висновки - залишки стейблів».
3. Time-to-Hedge (TtH) SLO: p95 ≤ 2 хв (ліквідні пари), ≤ 10 хв (тонкі мережі).
4. Ліміти «живого» ринку: макс. нотаional на не-хеджованому базовому активі (наприклад, ≤ 0. 5% денного GGR).
5. Диверсифікація стейблів: не більше X% на одного емітента/ланцюг, баланс on-chain/офлайн-кастоді.
6. Fail-safe: при падінні ліквідності - тимчасовий перемикач «deposit→steybl тільки на мережі Y».
2. 2 Організаційна матриця
Treasury - відповідає за хедж-книгу, ліміти, SOR/exec.
Risk/MLRO - ліміти контрагентів, санкційний комплаєнс, SoF/SoW.
Ops - он/офф-рамп операції, конфігурація гаманців, моніторинг конфів.
Finance - облік, звітність, переоцінка, P&L атрибуція.
3) Інструменти та їх роль
4) Метрики ризику та цільові SLO
Exposure (Нета): 'E = Σ нетто-баланс по базовому активу'( в USD). Мета: 'E ≤ ліміту L'.
VaR(99%, 1d): історичний/парам. для кошика активів/стейблів.
TtH p95: час від отримання депозиту до хеджу.
5) Типові стратегії
5. 1 «Auto-sell to Stable» (база)
На вході (депозит в BTC/ETH/etc) → моментально продати в обраний стейбл по SOR (кілька CEX/OTC).
Зберігати стейбли по лімітах емітентів/ланцюгів; частина - у фіаті на off-ramp.
Для висновків в крипто - купувати «назад» у міру необхідності.
Плюси: простота, майже нульова дельта-експозиція.
Мінуси: витрати обороту, ризик стейбла (depeg), операційні лаги.
5. 2 «Perp-hedge» (нейтралізація дельти)
Тримаємо спот-крипту як зворотну позицію (для висновків), коротим перп еквівалентно нетто.
Балансуємо funding: якщо funding> цільового, частково конвертуємо в стейбли/фіат.
Плюси: можна тримати ліквідний спот для UX; гнучкість.
Мінуси: funding-вартість і ризик біржі.
5. 3 «Collar» для прогнозованих нетто-виплат
Купівля шляхів на базовий актив + продаж колів (або короткий перп) в обсязі нетто-виплат на вікно T (наприклад, 7-14 днів).
Бюджет на премію обмежує tail-risk.
Плюси: обмеження осідання; Керована вартість.
Мінуси: ліквідність опціонів, складніше операційно.
5. 4 «NWP-hedge» (Net Withdrawal Position)
Розраховуємо нетто-потреба в крипто на горизонті'T'з поведінкових моделей (seasonality, cash-out rate).
Хеджуємо тільки цей обсяг; вхідні депозити паркуємо в стейбли.
Плюси: менше обороту; хедж «у справі».
Мінуси: модельний ризик прогнозу.
6) Архітектура виконання та обліку
6. 1 Компоненти
Crypto Payments Gateway: адреси/інвойси, конфи, AML-скринінг.
Treasury Router/SOR: вибір біржі/ОТС, алго-виконання (TWAP/VWAP/POV), ліміти.
Hedge Engine: розрахунок експозиції, розміщення перп/ф'юч/опціонів, моніторинг HR/VaR.
Ledger/Accounting: позиції, переоцінка по марк-ту-маркет, P & L-атрибуція: `Trading P&L`, `Funding`, `Slippage`, `Fees`.
Risk & Compliance: ліміти контрагентів, санкційний скринінг, SoF/SoW, on/off-ramp політики.
6. 2 Потік (auto-sell приклад)
1. Deposit. detected конфи N 'SOR. quote()`
2. Execute TWAP (ідемпотентний exec_id) →'trade. fills` → `convert→stable`
3. Hedge. update(): 'E↓','HR→1'→ події в Kafka
4. Ledger. mark2mkt: ціна закриття/індикатив, розрахунок P&L
5. Dashboard: TtH, VaR, HR, funding, slippage/fees
6. 3 Ідемпотентність і ризики виконання
Ідемпотентні ключі на ордери і висновки (повтор вебхука ≠ повторна угода).
Kill-switch на деградацію ліквідності (алерти по latency/філам).
Circuit-breakers з прослизання і розбіжності котирувань (oracle vs book).
7) Модель даних (спрощено)
json
{
"ts": "2025-11-03T12:15:42Z",
"asset": "BTC",
"side": "SELL",
"notional_usd": 25000.0,
"avg_px": 68250.5,
"slippage_bps": 3.2,
"fees_usd": 7.5,
"venue": "CEX_A",
"exec_algo": "TWAP_2min",
"exposure_after_usd": 1200.0,
"hedge_ratio": 0.98,
"funding_24h_bps": 8,
"var_99_1d_usd": 5200.0
}8) Ліміти і контроль
9) Облік і репортинг
Mark-to-Market (MtM): щоденна переоцінка позицій за незалежним прайсом (цінові оракули/індекси).
P&L Attribution: розкладання на'Price P&L','Funding','Fees','Slippage','FX'.
Hedge Effectiveness: '(Δ P&L портфеля без хеджу − Δ P&L фактична )/ Δ P&L без хеджу'.
Mapping к GGR: окремо зберігайте «платіжний результат» vs «трежері-результат».
Аудит трейдів: exec_id, клірингові звіти, вивантаження по майданчиках.
10) Комплаєнс, KYC/AML і санкції
Політика он/офф-рамп: допускаються тільки whitelisted контрагенти, KYC-перевірені рахунки.
Санкційний скринінг on-chain: адреси/кластеризація, мітки «високий ризик», заборона на взаємодію.
Source of Funds/Wealth: пороги ескалації для великих вводів/висновків.
Регіональні правила: статус крипто-платежів, оподаткування, звітність.
Custody: провайдер/самостійне зберігання, мультисиг/HSM, політики лімітів виведення.
11) Дашборд і алерти (мінімальний набір)
1. Exposure & HR: за активами і в агрегаті.
2. VaR / ES: щоденний апдейт, стрес-сценарії (−20%, + 20%, depeg −2%).
3. TtH p50/p95, exec latency, fill ratio.
4. Funding/Carry і Fees/Slippage по майданчиках.
5. Stable Diversification: за емітентами/мережами, індекс depeg.
6. Venue Risk: баланси/маржа/ліміти/інциденти.
- `E > 0. 8L_asset' → P1;'E> L_asset' → P0 з авто-хеджем.
- `VaR > L_VaR` → P1; `TtH p95 > SLO` → P1.
- `Depeg spread > 0. 5%'( за емітентом) → авто-ребаланс стейблів.
12) Плейбуки
Різкий обвал (−10% за годину): авто-sell в стейбл, закрити коротким перпом залишок, звузити ліміти, включити TWAP c малим кроком.
Depeg стейбла: миттєвий ребаланс на альтернативний стейбл/фіат, ліміт на емітента = 0, закрити перпи проти цього стейбла.
Заморожування виведення на біржі: SOR перемикає виконання на альтернативи, OTC RFQ, зниження розмірів ордерів, партіонування заявок.
Сплеск funding: частковий перехід з перпів на спот + частковий sell, перерахунок carry-вартості.
Тонкий ринок/ніч: збільшити вікно TWAP, ліміт на слippage bps, відкласти великі ребаланси.
13) Тест-кейси (UAT/Prod-готовність)
1. Idempotent Exec: повтор вебхука → 1 угода, не два.
2. TtH SLO: симулювати 100 депозитів → p95 ≤ цільового.
3. Kill-switch: імітація затримки біржі → SOR перемикається.
4. Depeg Drill: −1% до паритету стейбла → спрацьовує авто-ребаланс.
5. Stress VaR: стрибок ціни ± 20% → VaR/ES в межах лімітів.
6. Ledger Reprice: добова переоцінка та звірка зі звітами бірж/ОТС.
7. Limits Enforcement: спроба перевищити L_asset → відмова/авто-хедж.
14) Часті помилки і як їх уникнути
Довге вікно без хеджу (інтеграційні лаги): фіксуйте'TtH'як SLO, тримайте «швидкий» он-рамп.
Монопровайдер: диверсифікуйте майданчики/емітентів, ліміти на venue/стейбл.
Відсутність MtM і P & L-атрибуції: немає прозорості ефективності хеджу.
Сліпа віра в перпи: ігнор funding → негативний carry.
Немає сценарію depeg: висока частка одного стейбла без плану виходу.
Неідемпотентні операції: дублі ордерів/висновків при дребеззі вебхуків.
15) Резюме
Успішна крипто-монетизація в iGaming спирається на три стовпи: моментальна нейтралізація цінового ризику, сувора лімітна дисципліна/дашборди та операційна надійність он/офф-рампів. Комбінуючи auto-sell, NWP-хедж і інструменти перпів/опціонів - при жорсткому комплаєнсі і обліку - ви утримуєте TtW низьким, P&L стабільним, а UX швидким і передбачуваним.