Ризик-орієнтований алгоритм розрахунку розміру позиції для трейдингу

Чому система розрахунку позиції ламається на різких рухах

Типова система розрахунку позиції калібрується за спокійною ділянкою: стоп ставлять кратно середньому розмаху ціни за останні тижні, а розмір позиції виводять із допустимого ризику на угоду — скажімо, частки відсотка від капіталу.

На рівному ринку конструкція сходиться ідеально: серія збитків обмежена, просадка рахунку передбачувана, розрахунок збігається з фактом під час закриття.

Відмова настає в момент розриву ліквідності. Ціна проходить рівень стопа без угод за цією ціною, ордер виконується помітно далі, і фактичний збиток перевищує розрахунковий у кілька разів.

Волатильність ринку за хвилини зростає кратно, але правило продовжує рахувати розмір за діапазоном, якого більше немає.

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

Ризик на угоду перестає бути незалежним: позиції стають пов’язаними, і просадка рахунку складається не за формулою, а за найгіршим сценарієм.

Тому розрахунок позиції перевіряють не на історичній статистиці, а на сценаріях: ціновий розрив, тонка книга заявок, каскад примусових закриттів, довга смуга збитків.

Розбираємо, як це закривається — які обмежувачі вбудовуються в систему розрахунку позиції та як перевіряється їхнє спрацьовування.

Що дає ризик-орієнтований розрахунок позиції

Алгоритм рахує розмір позиції від допустимого ризику на угоду, а не від вільного залишку на рахунку. Вхідні дані — волатильність інструмента, дистанція до стопа та доступна ліквідність; на виході обсяг, за якого помилка в прогнозі коштує рівно стільки, скільки закладено в ліміт.

Чотири ефекти, які перевіряються на історичних даних до виведення системи в роботу:

• Передбачувана просадка. Частка ризику на угоду зафіксована, тому серія збитків дає заздалегідь пораховану глибину, а не випадкову. Управління ризиком стає параметром стратегії, а не наслідком удачі.
• Єдиний розмір ризику. Інструменти з різною волатильністю дають однаковий внесок у ризик портфеля: рухливий актив автоматично отримує менший обсяг, спокійний — більший.
• Знятий клас відмов під час розривів ліквідності. Обсяг обмежений глибиною книги заявок і очікуваним прослизанням, тому вхід не рухає ціну й не зриває захисний стоп.
• Відтворюваність результатів. Ті самі вхідні дані дають той самий обсяг на історії, на тестовому контурі та у бою — розходження пояснюване, а не списується на «ринок».

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

Порівняння підходів до управління ризиком на угоду

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

На практиці підходи комбінують: базовий ліміт на угоду задається на рівні портфеля, усередині нього розмір рахується від волатильності, а фіксований обсяг залишається жорсткою стелею, яку не можна перевищити за жодних сигналів.

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

Етапи впровадження: від аудиту угод до регламенту

Робота йде послідовно: спочатку фіксуємо, як розмір позиції визначається зараз, потім переносимо логіку в перевірювану схему і лише згодом допускаємо її до реальних угод.

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

1. Аудит торгових правил. Вивантажуємо історію угод і відновлюємо, чим фактично обмежувався обсяг: залишком коштів, чуттям трейдера чи формальним лімітом. Розходження між заявленою та реальною поведінкою — відправна точка розрахунку.
2. Схема розрахунку. Фіксуємо ризик на угоду в частках від капіталу, дистанцію захисної заявки та коефіцієнт, що пов’язує її з волатильністю інструмента. Отримуємо формулу, яку можна перевірити, а не описову інструкцію.
3. Налаштування під інструменти. Враховуємо мінімальний крок обсягу, ліквідність і вартість входу-виходу: на тонкій книзі заявок розрахунковий розмір може бути фізично невиконуваним, і це закладається заздалегідь.
4. Перевірка на історичних даних. Проганяємо алгоритм на кількох режимах ринку — тренді, боковику, різких провалах. Дивимося не на дохідність, а на глибину просадки та її відновлення.
5. Перевірка на малому обсязі. Запускаємо на обмеженому капіталі та звіряємо розрахунковий розмір із фактичним виконанням: де пройшло прослизання, де спрацював ліміт ризику.
6. Регламент ризик-менеджменту. Передаємо таблицю лімітів, порядок дій під час досягнення порогу просадки та правила перегляду параметрів у разі зміни волатильності.

Кожен етап закривається артефактом: вивантаженням, формулою, звітом перевірки, документом регламенту. Впровадження алгоритму вважається завершеним, коли розрахунок повторює інша людина за документом — без звернення до автора.

Документація, схеми та регламенти замість ручних налаштувань

Алгоритм розрахунку розміру позиції живе не в голові інженера і не в листуванні, а в артефактах, за якими система супроводжується роками.

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

Тому разом із робочим контуром замовник отримує комплект документів, за яким розрахунок можна перевірити, змінити й передати іншій команді.

• Документація з алгоритму: формули розрахунку, вхідні параметри, допустимі межі значень і поведінка системи за неповних ринкових даних.
• Схеми розрахунку ризику: шлях ринкових даних від джерела до рішення про позицію, точки, де рахуються ліміти, і момент, коли угода відхиляється.
• Конфігурації правил: файли з порогами ризику та обмеженнями на інструмент і на портфель, з коментарем під кожен параметр.
• Регламент змін: хто і в якому порядку править пороги, які перевірки обов’язкові, як діяти під час термінової правки в аварійній ситуації.
• Контроль версій правил: кожна зміна — окрема версія з причиною, автором і результатом прогону на історичних даних.
• Політики доступу: розподіл ролей на правку параметрів, читання журналу та вивантаження звітності про ризик.
• Журнал змін та інцидентів: що змінювалося, до якого відхилення призвело, яке обмеження додали після розбору.
• Інструкції супроводу: типові операції — перерахунок лімітів, зупинка розрахунку, відкат до попередньої версії правил.

Усе це лежить поруч із кодом, а не в окремих папках: під час наступного доопрацювання команда бачить не підсумкові числа, а логіку, з якої вони отримані.

Кейс: як просадка скоротилася втричі за того самого обороту

Як було до впровадження

Розмір позиції рахували в таблиці, правила лежали в регламенті, а ліміти перевірялися вручну перед кожним входом. На волатильному ринку рішення розходилися з регламентом: частка угод із перевищенням ризику сягала 6,8%, максимальна просадка за квартал — 34%.

Правка правил займала до трьох днів: аналітик описував нову логіку, розробник переносив її в торговий скрипт і проганяв на історії.

Що змінили і що отримали

Розрахунок винесли в окремий сервіс: він приймає потік цін від оракула Chainlink, рахує волатильність за ковзним вікном і віддає розмір позиції, який торговий контракт може зменшити, але не перевищити.

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

За зіставний період просадка — 11% проти 34%, частка угод із перевищенням ризику — 0,4% проти 6,8%, правка правил — 15–20 хвилин замість трьох днів: параметри змінюються в конфігурації сервісу й підхоплюються без перезбирання контракту.

Оборот залишився тим самим, а стійкість до волатильності зросла за рахунок управління ризиком, а не за рахунок паузи в торгівлі.

Чим модель ризику на угоду відрізняється від фіксованого обсягу

Фіксований лот задає обсяг угоди, але не ризик. За однакового розміру позиції збиток до захисного рівня залежить від відстані до нього, а ця відстань змінюється разом із волатильністю.

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

Модель ризику працює від зворотного: спочатку фіксується допустима частка капіталу на угоду та точка виходу, а обсяг виводиться з них.

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

Перерахунок під час волатильності йде за кожною зміною режиму ринку, а не один раз під час налаштування.

Ліквідність входить у розрахунок окремим доданком.

У тонкій книзі заявок реальний обсяг виконання відрізняється від розрахункового, тому модель заздалегідь занижує розмір на інструментах із високою очікуваною просадкою ціни виконання — інакше розрахунковий ризик залишається на папері, а фактичний зростає. На ліквідних парах той самий капітал дозволяє взяти більший обсяг без виходу за межу ризику.

У виконанні це виглядає так: перед кожною угодою модуль заново перераховує розмір позиції за свіжими даними, а параметри моделі зберігаються в перевірюваному вигляді — зміна волатильності автоматично змінює обсяг, але не логіку.

Результат — зіставна експозиція в різних режимах ринку: просадка перестає залежати від того, у яку фазу потрапила серія угод, а порівняння стратегій стає коректним.

Технічні сумніви: волатильність, прослизання, ліквідність

Інженерні сумніви рідко стосуються самої ідеї — вони про дані та межі застосовності. Розбираємо чотири, які виринають майже на кожній зустрічі.

Як система поводиться під час падіння ліквідності?

За тонкої книги заявок розрахункова ціна виконання розходиться з фактичною, і прослизання з’їдає очікування. Тому розмір позиції рахується від доступного обсягу на стороні книги, а не від номіналу: ліквідність звужується — позиція стискається сама.

Чи потрібно зупиняти торгівлю на час впровадження?

Ні. Контур іде в тіньовому режимі на живих даних: він видає розмір позиції, але команди на біржу не надходять. Чинні стратегії працюють як раніше, а розходження розрахункового та фактичного виконання накопичуються у звіті.

Як перевірити алгоритм до виведення на реальний рахунок?

Три кроки: прогін по історії з комісіями та прослизанням, тіньовий період на потоці, обмежений ліміт на рахунку. У кожного свій критерій переходу — частка відмов, відхилення розрахункового розміру від фактичного, поведінка на волатильних ділянках. Критерій не виконано — залишаємося в попередньому контурі.

Обговоримо задачу: з чого почати впровадження

Щоб розмова була предметною, а не оглядовою, починаємо з вхідних даних для розбору. Що точніше опишете поточну логіку ризику та обмеження, то швидше ми скажемо, що потребує переробки, а що можна залишити як є.

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

На першій зустрічі розберемо, де проходить межа між розрахунком розміру позиції та виконанням, які перевірки потрібні перед кожною угодою і як система має поводитися в пограничних режимах ринку.

У відповідь надішлемо план впровадження за етапами, оцінку строків і перелік того, що потрібно буде з вашого боку. Опишіть задачу — повернемося з оцінкою та планом.