Ризик-менеджмент у кванті: як не злити рахунок на автоторгівлі через API

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

У цій статті ми (команда MeowQuant) говоримо саме про ризик-менеджмент кванту, та ще й заходимо з боку «як захиститися на рівні коду», а не абстрактно кричимо «контролюй позицію». Ми розберемо кілька класів ризику, унікальних для API-торгівлі, дамо код стоп-лосу, розподілу позиції й повтору, який можна переписати, і чітко поясним безпековий мінімум рахунку й порядок виходу через «холодний старт малою сумою». Прочитавши, ти зможеш поставити своєму скрипту кілька гальм, щоб навіть при помилці він не дотягнув тебе до зливу.

Унікальні ризики API-торгівлі

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

Програма пішла врознос

Це найтиповіше. Десь хибно написана логіка — перевернутий напрямок купівлі/продажу, умова стоп-лосу написана навпаки, у циклі бракує умови виходу — програма не зупиниться подумати «а чи не помилка це десь?», вона раз по раз виконуватиме хибні інструкції. Людина руками, мабуть, помітила б один хибний ордер; скрипт за лічені секунди виставить десятки хибних. Убивча сила «вроздуву» — саме в його «вірності».

Дубль ордера

Найчастіше виникає при коливаннях мережі чи тайм-ауті запиту. Ти надіслав запит на ордер, відповіді не отримав, скрипт вирішив, що не вдалося, і шле повторно — але насправді перший ордер уже виконався, і в результаті в тебе два ордери. На ф'ючерсах це означає подвоєну позицію й подвоєний ризик. Дубль ордера найчастіше не логічна помилка, а наслідок поганої обробки «невизначеного проміжного стану».

Обрив мережі й відвал

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

Керування позицією й розподіл

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

Кілька принципів, яких ми самі завжди тримаємося:

• Постав ліміт на одну угоду. Жодна угода не більша за фіксовану частку всіх коштів (наприклад, 1–2%). Так навіть якщо напрямок цієї угоди повністю хибний, збиток має стелю.
• Постав ліміт усієї позиції. Усі відкриті позиції разом не перевищують загальну суму, не давай програмі шансу поставити на кін усі кошти разом.
• Розподіляй позицію, не заходь усім одразу. Розбий кошти на кілька частин і заходь поетапно, знижуючи вплив помилки судження в одній точці входу.
• Залиш скрипту готівку. Завжди тримай на рахунку частину коштів, що не бере участі в торгівлі — це і буфер, і простір для ручних дій, коли щось піде не так.

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

MAX_PER_ORDER_RATIO = 0.02   # одна угода не більше за 2% усіх коштів
MAX_TOTAL_RATIO     = 0.30   # уся позиція не більше за 30% усіх коштів

def check_position_limit(okx, symbol, order_value_usdt):
    bal = okx.fetch_balance()
    equity = bal['USDT']['total']          # загальний капітал у перерахунку на USDT

    # ліміт на одну угоду
    if order_value_usdt > equity * MAX_PER_ORDER_RATIO:
        raise ValueError('Перевищено ліміт позиції на одну угоду, ордер відхилено')

    # тут можна додати перевірку "поточна позиція + ця угода" <= MAX_TOTAL_RATIO
    return True

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

Стоп-лос мусить бути програмним (код)

Якщо з усієї статті запам'ятати лише одну фразу, то цю: стоп-лос мусить бути програмним. Скрипт працює автоматично, ти не можеш стежити за стаканом 24 години; при різкому розвороті ринку, поки ти побачиш і закриєш руками, найчастіше вже спізнився на кілька цінових рівнів.

Програмний стоп-лос має два підходи, які рекомендуємо використовувати в парі:

Підхід перший: умовний / стоп-ордер на стороні біржі. Виставляючи основний ордер, одночасно постав у OKX стоп-замовлення, щоб біржа автоматично закрила позицію на тригерній ціні. Найбільша перевага: навіть якщо твій скрипт відвалиться, цей стоп-лос усе одно діє на боці біржі. Це найнадійніший спосіб протистояти «голій позиції при обриві мережі».

Підхід другий: локальний моніторинг скрипта + закриття за тригером. Скрипт у циклі безперервно зчитує нереалізований збиток позиції й, щойно той перевищить заданий поріг, сам шле ордер на закриття. Він гнучкіший (можна робити трейлінг-стоп, стоп за часом тощо), але передумова — скрипт має бути онлайн.

Нижче найпростіший каркас локального стоп-лосу, демонструє логіку (перед реалом обов'язково перевір на демо):

import ccxt, time

okx = ccxt.okx({
    'apiKey':   'твій_apiKey',
    'secret':   'твій_secret',
    'password': 'твій_Passphrase',
    'enableRateLimit': True,
})

symbol      = 'BTC/USDT'
entry_price = 60000      # твоя середня ціна входу (приклад)
amount      = 0.001      # обсяг позиції
stop_ratio  = 0.05       # стоп-лос при падінні на 5%

while True:
    ticker = okx.fetch_ticker(symbol)
    last = ticker['last']
    drawdown = (entry_price - last) / entry_price

    if drawdown >= stop_ratio:
        okx.create_order(symbol, 'market', 'sell', amount)
        print(f'Спрацював стоп-лос, закрито за ринком @ {last}')
        break

    time.sleep(10)   # лишай достатню паузу, не бий по інтерфейсу

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

Захист від дублів ордерів і обриву мережі

Корінь дублів ордерів — «я не впевнений, чи попередній ордер пройшов». Захист зводиться до одного: не шли повторно наосліп, спершу підтверди статус.

Два способи в парі:

Використовуй клієнтський власний номер ордера (clientOrderId). Виставляючи ордер, додай згенерований тобою унікальний ID; біржа, побачивши дубль ID, відхилить його — це природний механізм захисту від повтору. Навіть якщо ти повторно надіслав через тайм-аут, біржа зарахує лише перший ордер.

import uuid

cid = 'meow-' + uuid.uuid4().hex[:16]   # згенерований тобою унікальний номер ордера

order = okx.create_order(
    symbol, 'limit', 'buy', 0.001, 50000,
    params={'clientOrderId': cid},       # додай його, повтор зарахується лише раз
)

Після тайм-ауту / обриву — спершу перевір, потім добивай. Запит на ордер вийшов за тайм-аут — не шли повторно одразу; спершу через запит відкритих ордерів чи позиції підтверди, чи попередній ордер узагалі пройшов, а потім вирішуй, чи добивати. Після відновлення так само — спершу fetch_open_orders, fetch_positions, побач чітко поточний реальний стан, а потім дай стратегії продовжити. Зроби «спершу перевір статус, потім дій» сталим першим кроком після відновлення — це відсікає переважну більшість повторних дій через втрату зв'язку.

Ліміт частоти, тайм-аут і повтор

Ризик-менеджмент — не лише про захист від втрати грошей, а й про те, щоб скрипт «сам себе не завалив». Погано оброблені ліміт частоти й тайм-аут можуть зробити твою стратегію недієздатною в критичний момент.

Ліміт частоти: при ініціалізації увімкни 'enableRateLimit': True, ccxt сам уставлятиме паузи між запитами. У частих циклах додай ще експоненційний відкат (уперся раз — чекай 1 с, ще раз — 2 с, 4 с). Цю частину ми детальніше розбираємо у статті Поширені помилки API, тут лише підкреслимо: б'єш по інтерфейсу в будь-якому циклі — обмеження швидкості це стандарт.

Тайм-аут: задай запитам чіткий час тайм-ауту, не давай скрипту намертво застрягти через один запит. У ccxt можна налаштувати 'timeout' (мілісекунди):

okx = ccxt.okx({
    'apiKey':   'твій_apiKey',
    'secret':   'твій_secret',
    'password': 'твій_Passphrase',
    'enableRateLimit': True,
    'timeout': 10000,     # тайм-аут одного запиту 10 с, щоб не зависнути
})

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

Права й білий список IP: безпековий мінімум

Найнижчий шар ризик-менеджменту — безпека рахунку. Хоч як надійно написано скрипт, витекли облікові дані — і все обнулилося. Тут два майже безвинятковні мінімуми:

Став лише «Читання» й «Торгівля», ніколи не став «Виведення». Кванту дія виведення взагалі непотрібна. Доки ключ не має права виведення, навіть якщо твій набір із трьох — apiKey, secret, Passphrase — колись витече, той, хто його отримав, зможе максимум безладно виставляти ордери (це теж погано, але є ті обмеження позиції й стоп-лосу як підстраховка), а не вкрасти твої монети. А поставиш виведення — витік дорівнює тому, що ти віддав ключ від сейфа.

Постав білий список IP. Якщо твій скрипт крутиться на машині зі сталим IP (хмарний сервер, домашній інтернет зі статичною публічною адресою), додай цей IP у білий список ключа, приймай лише запити з нього — і безпека підніметься на ще один щабель. Якщо IP часто міняється, білий список щодня помилково блокуватиме; у такому разі можна поки не ставити, але обов'язково надійно бережи облікові дані — не зашивай у код, що синхронізується, перейди на змінні оточення чи несинхронізований конфіг.

Ці два пункти разом із позицією й стоп-лосом вище утворюють захист «навіть якщо станеться найгірше, збиток має межу». Конкретні кроки створення ключа є в нашій статті Квант на OKX API, а ще перед створенням ключа можна звіритися з чек-листом самоперевірки прав API.

Холодний старт малою сумою: чек-лист перед справжніми грошима

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

• Спершу безперервно крути на демо. Покрий кілька циклів зростання/падіння, переконайся, що ордер, скасування, стоп-лос, колбек — усе відповідає очікуванням. Цей крок безкоштовний, пропустити його — це взяти справжні гроші за тестове середовище.
• Потім зроби холодний старт на дуже малих справжніх грошах. Сума така мала, що навіть повна втрата не шкода — сприймай як плату за навчання. Прослизання й глибина, які демо не відтворює, спливуть саме тоді.
• Постеж перші кілька днів. Не кидай напризволяще; переконайся, що поведінка на реалі збігається з демо, стоп-лос справді спрацьовує, дублів ордерів немає — і лише тоді поступово нарощуй.
• Ф'ючерси й плече — наостанок. Поки спот не працює стабільно, не чіпай плече. Плече кратно підсилює кожен із наведених класів ризику; на початковій стадії наполегливо радимо лише спот.

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

На практиці: підводний камінь, на який ми наступили

Поширені запитання

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