Чому стратегія ламається без paper trading
Логіка, відлагоджена на історичних даних, майже завжди дає гарну криву дохідності: заявка виконується за ціною свічки, ліквідність нескінченна, сигнал спрацьовує рівно в розрахункову секунду.
Перевірка стратегії на історичних даних підтверджує математику, але мовчить про те, як вона виживе в живому потоці — без цього тестування торгових стратегій залишається неповним.
На реальному ринку між сигналом і угодою з'являється те, чого немає в таблиці: затримка від розрахунку до відправлення, часткове виконання великої заявки, прослизання на тонкій книзі заявок, відмова або втрата місця в черзі.
Помилки виконання заявок окремо виглядають безневинно, але кожна з'їдає частки відсотка, і на довгій серії угод вони складаються в стійке розходження тестових і реальних результатів — модель прибуткова у звіті та збиткова на рахунку.
Частина помилок лежить не у виконанні, а в самій логіці: стратегія розраховує на миттєвий відгук, повторно входить за одним сигналом, не помічає, що частина позиції залишилася незакритою.
На історії це не проявляється, бо тест не відтворює ні обмежень за лімітами, ні стану рахунку в моменті, ні конкуренції за ліквідність.
paper trading закриває саме цей розрив: стратегія працює на живих даних і реальній книзі заявок, але без ризику капіталом. Під навантаженням видно, де ламається виконання, де розходиться облік позицій і наскільки поведінка моделі відрізняється від очікуваної. Розбираємо, як це закривається.
Що дає paper trading: вимірювані ефекти
Тестовий контур повторює промисловий: той самий потік ринкових даних, ті самі ризик-правила, той самий формат заявок — різниця лише в тому, що виконання йде в пісочницю, а не на біржу.
Тому знімається клас відмов, який не бачить ні прогін на історичних свічках, ні ручна перевірка на графіку: невірний розмір позиції, відсутність обробки відхиленої заявки, ділення на нульову ліквідність у тонкій книзі заявок.
Перевірка гіпотези перестає бути окремим проєктом. Раніше на одну ідею йшли дні: вивантаження даних, синхронізація таймфреймів, разові скрипти, звірка очима.
У контурі сигнал, ризик-правило й логіка виходу проганяються на одному зрізі ринку за хвилини, а результат відтворюваний — той самий вхід, той самий вихід, той самий звіт при повторному запуску.
Метрики стратегії рахуються ті самі, що й у бойовому режимі: частка виконаних заявок, середнє та хвостове прослизання, максимальна просадка, час утримання позиції, поведінка на розривах ліквідності.
Вони лягають на панель у Grafana, і порівняння версій стратегії йде за числами, а не за враженням від графіка дохідності.
Окремо контролюється передбачуваність виконання: модель звіряється з фактичними угодами, і розходження вище заданого порогу зупиняє переведення стратегії в бойовий режим. Так відмова знаходиться на тестовому контурі — до того, як вона коштує реальної позиції.
Симуляція, запис потоку, демо-рахунок: порівняння режимів
Тестовий контур обирають не за зручністю інтерфейсу, а за тим, який клас помилок він ловить. Симуляція торгівлі на історії проганяє логіку входів і виходів за місяці за хвилини, але виходить з ідеального виконання.
Запис потоку котирувань і демо-рахунок брокера додають те, чого в історії немає: реальні затримки, часткові виконання та відмови заявок.
| Режим | Коли підходить | Де упирається |
|---|---|---|
| Симуляція торгівлі на історії | Перша перевірка гіпотези, перебір параметрів, відсів явно слабких стратегій | Угода завжди проходить за ціною свічки: прослизання, черга й неповні виконання не моделюються |
| Запис потоку котирувань | Потрібно відтворювати один і той самий ринковий день багаторазово — налагодження логіки виконання та звірка після правок | Записується лише те, що потрапило в підписку: глибину книги заявок і події поза потоком відновити нічим |
| Демо-рахунок брокера | Фінальна перевірка перед бойовим рахунком: живий ринок, реальні затримки, відмови за маржею | Правила та список доступних інструментів відрізняються від робочого рахунку, історія угод обмежена строком життя демо |
Режими не замінюють один одного, а вишиковуються конвеєром: симуляція відсіює гіпотези, відтворення потоку стабілізує виконання, демо-рахунок підтверджує поведінку на живих даних.
Повноцінний тестовий контур для paper trading ми збираємо з усіх трьох ланок — інакше стратегія перевірена рівно настільки, наскільки реалістична її модель виконання.
Етапи впровадження: від аудиту стратегії до передачі контуру
Впровадження йде ітераціями: кожен етап закінчується артефактом, який можна перевірити до переходу до наступного. Так розходження між очікуваною та фактичною дохідністю спливає на ранньому кроці, а не після запуску на реальному рахунку.
- Аудит торгової логіки. Розбираємо сигнал входу та виходу, розрахунок розміру позиції та обмеження ризику. На виході — опис правил, однозначно переведених у код: що вважається подією, а що шумом.
- Налаштування джерела даних. Фіксуємо, які ряди потрібні, з якою частотою та глибиною історії, як відновлюються пропуски й вирівнюються часові пояси.
- Складання контуру. З'єднуємо модуль стратегії, емулятор виконання та журнал позицій; комісії, затримку подання заявки й ліміт за доступним обсягом закладаємо одразу.
- Перевірка на збіг. Прогін на історичному відрізку та звірка з незалежним перерахунком: позиції, середня ціна, підсумковий результат. Розходження вище допуску — шукаємо помилку в даних або в логіці виконання.
- Випробування на стійкість. Зсуваємо параметри, дробимо період на підінтервали, змінюємо комісії та прослизання — видно, де результат тримається, а де розсипається від одного припущення.
- Приймання та передача контуру. Контрольні сценарії, включно з обривом джерела даних і повторним запуском; фіксуємо метрики, за якими далі порівнюються версії стратегії, віддаємо документацію, конфігурації та доступи.
Що передаємо на руки: конфігурації, схеми, регламенти
Після здачі контуру paper trading замовник залишається не із залежністю від підрядника, а з комплектом артефактів, за яким систему можна підняти, перевірити й розвивати власними силами. Передаємо робочу документацію, а не архів файлів.
- Файли конфігурації контуру — параметри симуляції, комісії та затримки виконання, ліміти на позицію, правила аварійної зупинки. Секрети винесені з репозиторію, тестове й передпродуктивне середовища розведені.
- Схема потоків даних — від джерела котирувань до журналу угод: які сервіси задіяні, у якому порядку, де вузькі місця і що відбувається при обриві потоку.
- Схема інтеграції — стикування з брокерським рахунком, сховищем історії та звітністю: входи, виходи, формати обміну, поведінка при недоступності суміжної системи.
- Політики доступу — ролі й права на запуск, зупинку та правку стратегій, окремі облікові записи для аналітиків і сервісних завдань, журналювання дій у контурі.
- Регламент запуску та зупинки — передпольотні перевірки, порядок дій, умови автоматичного зняття стратегії з прогону й повернення до попередньої версії.
- Документація по контуру — опис метрик, методика розрахунку дохідності та просадки, словник полів у журналах, щоб звіти читалися однаково аналітиком і замовником.
- Інструкція з відтворення прогону — як повторити тест на історичних даних і отримати зіставний результат, із фіксацією версії стратегії та зрізу даних.
Підсумок: результат прогону залишається відтворюваним — його можна перерахувати, порівняти й пояснити. Опишіть задачу — повернемося з оцінкою та планом передачі.
Кейс: розходження тестових і реальних результатів
До нас прийшла команда з алгоритмічною стратегією: на історичних даних вона давала стійкий плюс, а на реальному рахунку результат розходився з розрахунковим у рази.
Тестовий контур існував формально — прогін у Backtrader за історичними котируваннями з виконанням за ціною закриття бару та повним заповненням кожної заявки.
Розбір показав, що справа не в логіці стратегії, а в моделі виконання.
Історичний прогін виходив із того, що будь-яка заявка набирає обсяг повністю і за ціною сигналу; на бойовому контурі лімітні заявки частково не виконувалися, ринкові прослизали на волатильності, а затримка брокера й комісія в розрахунок взагалі не потрапляли.
Розходження тестової та реальної дохідності сягало 30–40%, і за цією цифрою не можна було зрозуміти, де закінчується стратегія і починається похибка моделі.
Зібрали тестовий контур, що повторює реальну логіку виконання: потік котирувань, чергу заявок, часткове заповнення, затримку відправлення, комісію та прослизання за історичним розподілом.
Стратегія отримувала ті самі сигнали, що й на бойовому контурі, але виконання рахувалося за тими самими правилами, що в брокера. Прогін став відтворюваним: один набір сигналів на одних даних дає той самий результат за виконанням.
Після кількох ітерацій калібрування метрики зійшлися.
Частка виконаних заявок у тесті впала зі 100% (так було закладено моделлю) до 87%, на бойовому контурі — 86%; розходження дохідності скоротилося з 30–40% до 4–6%; максимальна просадка в тестовому прогоні перестала бути оптимістичною — 18% проти 12% у старій моделі.
Стратегії, відбраковані на тестовому контурі, більше не доходять до реального рахунку, а рішення про запуск спирається на метрики, які відтворюються при повторному прогоні.
Чим тестовий контур відрізняється від демо-рахунку брокера?
Демо-рахунок брокера (наприклад, Interactive Brokers) — це вітрина виконання, а не модель ринку. Потік котирувань у ньому згладжений: заявка на великий обсяг проходить повністю за останньою ціною, навіть якщо на цьому рівні реально лежить у рази менше.
Тестовий контур у режимі paper trading відновлює книгу заявок за рівнями й виконує ордер проти конкретної глибини ліквідності.
Різниця проявляється на трьох речах. Глибина ліквідності задає, скільки обсягу доступно за ціною без її зсуву. Часткове виконання заявки розбиває один ордер на десятки угод із різними цінами та комісіями. Черга «ціна — час» визначає, хто отримає зустрічний обсяг першим.
Демо-рахунок підміняє все це миттєвим виконанням по середині спреду, тому стратегії з щільною торгівлею виглядають на ньому прибутковими там, де на реальному ринку йдуть у мінус.
Відтворюваність тестів — друга принципова відмінність.
Контур працює на зафіксованих зрізах історичних даних і записах потоку заявок, тому прогін із тими самими вхідними умовами дає той самий результат: можна порівняти дві версії логіки й точно знати, що змінився алгоритм, а не ринковий фон. Демо-доступ іде в живому потоці, і вчорашній сценарій на ньому не повторити.
Тому ми збираємо тестовий контур цілком: сховище стрічок, емулятор виконання з частковими угодами, звітність щодо прослизання та частки виконаних заявок. Прогін показує реальну просадку до виходу на ринок, а не після.
Технічні сумніви перед запуском тестового контуру
Інженерні сумніви перед тестовим контуром зазвичай ті самі: чи потрібні реальні доступи до брокера, що робити зі стратегією, яка вже торгує, і як контур переживає обрив потоку котирувань. Це ті питання, які закриваємо до першого запуску, а не після.
Контур будується так, щоб торгові права не вимагалися: підключення йде до пісочниці брокера або до запису ринку, ключі видаються лише на читання. Журнал заявок, розрахунок позицій і комісій живуть усередині контуру — реальний ордер не піде навіть при помилці в конфігурації.
Чи потрібні реальні доступи до брокерського рахунку?
Ні. Достатньо потоку котирувань і правил виконання — їх дає пісочниця або запис ринку. Якщо потрібні дані саме по вашому рахунку, видаємо ключ на читання й обмежуємо список інструментів; торгові методи на стороні брокера залишаються вимкненими.
Що робити зі стратегією, яка вже працює?
Вона підключається без переписування логіки: контур емулює той самий інтерфейс, що й бойовий шлюз, і приймає ті самі заявки.
Ми фіксуємо контрольні точки — історія угод, набір інструментів, таймфрейм — і звіряємо результат прогону з фактичними виконаннями, щоб побачити розходження за комісіями та прослизанням.
Як контур переживає розриви потоку даних?
Розрив зв'язку не вважається збоєм стратегії: потік буферизується, при відновленні дані доганяються із запису, дублі заявок відсікаються за ідентифікатором.
Якщо пропуск довший за задане вікно, торгівля зупиняється і період позначається недостовірним — результат на таких ділянках не враховується.
Обговоримо задачу: підберемо режим тестування під вашу стратегію
Щоб повернутися з оцінкою строків і складом робіт, нам не потрібне готове ТЗ — достатньо опису стратегії та умов, у яких її належить перевіряти. Чим точніший вхід, тим менше припущень у плані й тим раніше ви побачите працюючий контур тестування.
Що корисно надіслати на обговорення задачі:
- логіку прийняття рішень: на яких даних стратегія входить у позицію та виходить із неї, які індикатори або моделі задіяні;
- джерела даних: ринки й інструменти, потрібна історична глибина, чи потрібен живий потік котирувань;
- режим тестування: віртуальний рахунок на реальних котируваннях, прогін на історії або їх поєднання;
- правила ризик-контролю: ліміти на позицію та денну просадку, обмеження кількості угод, поведінка при розриві зв'язку з біржею;
- метрики приймання: що вважаємо успішним прогоном і за якими звітами це видно;
- обмеження за середовищем: де розгортаємо контур, які доступи до брокерських інтерфейсів уже є, вимоги до журналювання операцій;
- склад команди замовника, яка супроводжуватиме систему після передачі.
Далі ми розкладаємо роботу за етапами, узгоджуємо точки перевірки на кожному й фіксуємо, що саме передаємо вашим інженерам: код, конфігурації, опис метрик та інструкції із запуску. Опишіть задачу — повернемося з планом робіт, оцінкою строків і межами відповідальності.
