Paper trading: де симуляція розходиться з реальною торгівлею
Тестовий прогін стратегії закінчується рівним графіком угору, а та сама логіка на реальному рахунку дає результат, який не збігається з розрахунком ні за кількістю угод, ні за середньою дохідністю.
Помилка не в коді: paper trading за замовчуванням вважає виконання ідеальним — заявка наливається повністю за ціною з потоку котирувань, скасування спрацьовує миттєво, а стакан під нашим ордером не змінюється.
Кожне припущення окремо виглядає нешкідливо, але разом вони зсувають оцінку стратегії настільки, що форвард-тестування стратегій перестає передбачати результат.
Прослизання в симуляції з'являється лише там, де його явно заклали в модель. Якщо обсяг заявки можна порівняти з видимим обсягом на ціновому рівні, реальне виконання проходить через кілька рівнів книги, і середня ціна угоди виявляється гіршою за тестову.
Симулятор же наливає весь обсяг за найкращою ціною — на вузьких інструментах це дає розбіжність, яка на довгій серії угод перекриває всю заявлену дохідність стратегії.
Друге джерело — затримка виконання. Сигнал рахується за закриттям бару, до торгового шлюзу доходить із мережевою затримкою, а зустрічний потік встигає переставити ціни: у тесті між сигналом і угодою минає нуль часу, у реальності — помітна частка секунди.
Сюди ж додається неповний потік котирувань: розрив з'єднання тест переживає мовчки й продовжує рахувати за останньою відомою ціною, тоді як у реальній торгівлі в цей момент ні увійти, ні вийти не можна.
Окремо розходиться логіка скасування заявок. У симуляції зняття й перестановка ордера безкоштовні та миттєві, тому будь-яка стратегія з підтягуванням лімітника виглядає вигіднішою, ніж є.
На біржі скасування може прийти після часткового виконання або бути відхилене лімітом на частоту запитів — і тоді позиція залишається відкритою, а слідом надходить сигнал протилежного напрямку. Розбираємо, як розбіжність тесту й реальних угод закривається в архітектурі форвард-тесту.
Що дає форвард-тестування до виведення стратегії в бій
Форвард-тестування (paper trading) проганяє стратегію на живому потоці ринкових даних, але заявки йдуть не на біржу, а в емулятор виконання.
Тестовий контур підключається до того самого торгового API, що й бойовий: на Binance та інших майданчиках набір методів збігається, тому розбіжність між прогоном і реальним рахунком дає логіка гіпотези, а не різниця інфраструктури.
Перевірка торгової гіпотези вкладається в дні замість тижнів, а метрики тестового прогону рахуються тим самим кодом, що й у проді. Зниження ризику стратегії перестає бути декларацією: ефекти видно у звіті, а відмови знімаються до того, як стратегія отримає реальний рахунок.
Ефекти, які видно у звіті
- Час перевірки гіпотези — дні замість тижнів, прогін іде безперервно.
- Частка відтворюваних угод — понад 95% за фіксованого снапшоту стакана й повтору запуску.
- Простій тестового контуру — хвилини на перезапуск замість годин ручного складання стенда.
- Передбачуваність просідання — розрахункова й фактична криві сходяться, ліміти ризику задаються заздалегідь.
- Класи відмов — закриваються на тестовому контурі, а не на реальному рахунку.
Стан до і після
| Клас відмови | До форвард-тесту | Після |
|---|---|---|
| Скасування заявки в момент виконання | Гонка, подвійна позиція | Ловиться на прогоні |
| Часткове виконання | Перекіс розміру позиції | Перевіряється кожен прогін |
| Повтор запиту при обриві зв'язку | Дублювання ордерів | Підтверджена ідемпотентність |
| Розрив потоку даних | Стратегія мовчки чекає | Аварійне закриття й оповіщення |
Формати paper trading: історія, живий потік, тіньовий режим
Історію, живий потік і тіньовий супровід не замінюють одне одного — вони відповідають на різні питання: чи витримає логіка дані минулого, як стратегія поводиться на реальних спредах і що зміниться, якщо поставити її поруч із робочим контуром.
Історичні зрізи підтягуємо з архівів на кшталт CoinGecko і нормалізуємо в єдиний формат, щоб прогони були відтворювані.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Тестовий прогін на історії | Первинний відбір гіпотез, налаштування параметрів | Немає прослизання й черги заявок, ризик підгонки під минуле |
| Живий потік котирувань | Перевірка виконання на реальних спредах і затримках | Рідкісні розриви ліквідності залишаються непоміченими |
| Тіньовий режим торгівлі | Порівняння нової версії з робочою на тому самому ринку | Подвійне навантаження, потрібен роздільний облік сигналів |
Як вибирати режим під тип стратегії
Для стратегій із високою частотою угод вирішальним стає живий потік: на історії комісія й прослизання виглядають зовсім інакше, ніж у реальній книзі заявок.
Позиційні стратегії дешевше перевіряти прогоном по історії — там важливіша стійкість на довгому горизонті та поведінка при рідкісних подіях, а не мікроструктура виконання.
Як влаштований тіньовий прогін паралельно з робочим контуром
Тіньова копія отримує той самий потік даних, що й робочий контур, але заявки не виставляє — сигнали й розрахункові ціни пишуться в окремий журнал.
Звірка двох журналів показує розбіжність за часом входу й за ціною виконання: якщо нова версія сигналить раніше й закриває позицію на 2-3% вигідніше, її можна просувати в основний контур; якщо розбіжність у зворотний бік — правки повертаються на прогін.
Етапи впровадження системи тестування: від аудиту до передачі
Впровадження системи тестування починається не з коду, а з інвентаризації: поки не описані стратегії, інструменти й режими, стенд повторить бойову систему в гіршому вигляді. Ми ведемо проєкт кроками, на кожному фіксуємо перевірюваний результат.
- Аудит торгових стратегій: збираємо перелік, таймфрейми, набори інструментів і правила ризик-контролю, відзначаємо, що тестується ізольовано, а що потребує спільного рахунку.
- Схема потоків даних: описуємо, звідки приходять котирування, стакан і події блокчейну, як вони нормалізуються в загальний журнал і де проходить межа між бойовим і тестовим контуром.
- Складання стенда: розгортаємо середовище paper trading з ізольованими рахунками, емуляцією біржових обмежень і окремим сховищем результатів.
- Калібрування моделі виконання: налаштовуємо затримки, прослизання, часткове виконання лімітних заявок і комісії, щоб змодельований результат сходився з фактичним.
- Звірка на еталонних угодах: проганяємо набір відомих угод і порівнюємо з фактом за ціною входу, обсягом і часом, розбіжності розбираємо до прийнятного рівня.
- Передача й навчання: показуємо команді, як додавати стратегії, читати звіти й оновлювати модель виконання без нашої підтримки.
Критерії приймання
Приймання йде за відтворюваністю: той самий набір даних і конфігурація дають однаковий результат від прогону до прогону.
Окремо фіксуємо, що розбіжність з еталонними угодами вкладається в узгоджений коридор, а журнал зберігає вхідні дані та версію моделі виконання для кожного запуску.
Запуск без зупинки робочого контуру
Стенд піднімаємо поруч із бойовою системою й підключаємо до тих самих джерел через окремі підключення й ліміти — робочий контур не зупиняється й не змінює поведінку.
Переведення стратегій іде по одній, з відкатом: якщо тест заважає навантаженню або спотворює дані, підключення відключається без сліду в бойовому контурі.
Що замовник отримує на руки: стенд, схеми, регламенти
Стенд для paper trading здаємо не «як є», а комплектом, за яким ваша команда запускає та перевіряє його без нашої участі. У передачу входять конфігурації, схеми, правила доступу й регламенти — нижче перелік артефактів.
- Конфігурації стенда: файли середовища, набори параметрів стратегій, сценарії прогонів і стартові умови, за яких результат відтворюється повторно.
- Схема інтеграції з торговими майданчиками: які потоки йдуть у реальному часі, які беруться з історії, де стоять буфери й як обробляється розрив з'єднання.
- Правила доступу й ролі: поділ на спостерігача, аналітика й адміністратора, окремі ключі до тестових кабінетів, журнал дій користувачів.
- Звіт про калібрування: як звіряли потік заявок і угод з еталонним джерелом, які розбіжності знайшли, чим закрили й що залишилося у відомих обмеженнях.
- Документація з тестового стенда: опис модулів, формати вхідних даних, точки розширення під підключення нових майданчиків та інструментів.
- Регламент супроводу: періодичність оновлення довідників, порядок дій при зупинці джерела, кому надходить оповіщення і в який строк.
- Чек-лист приймання: сценарії, які проганяються на вашій стороні перед тим, як стенд стає робочим.
Як передаємо знання команді
Проводимо розбір стенда з вашими інженерами: показуємо запуск, ручне втручання в параметри й зняття метрик. Ваша команда самостійно проганяє один сценарій від початку до кінця — це умова приймання, а не формальність.
Далі підтримка йде за регламентом супроводу: правки стратегій ви вносите самі, розширення інтеграцій беремо на себе.
Кейс: скоротили розрив між тестом і реальними угодами
На старті проєкту форвард-тестування рахувалося за історичними свічками: заявка закривалася за ціною бару, затримки доставки й часткові виконання не враховувалися.
Звіти сходилися між собою, але розходилися з реальними угодами — ціна входу не збігалася приблизно в третині випадків, і рішення щодо стратегій ухвалювалися на даних, яким команда не довіряла.
Модель виконання угод і облік затримок
Стенд переписали на програвання записаного біржового стакана через конектор до Binance: заявка стає в чергу й виконується за доступною ліквідністю, враховуються частковий обсяг, комісія, ставка фінансування й окремо — затримка між сигналом і постановкою ордера.
Її знімали замірами на робочому контурі й підставляли в симуляцію. Прогін прив'язаний до знімка даних і версії параметрів, тому повторний запуск дає ідентичний результат — раніше плаваючі налаштування робили порівняння прогонів безглуздим.
Порівнювали три метрики: розбіжність ціни входу впала з третини випадків до 4%, розрив за середньою дохідністю між стендом і живим рахунком скоротився з 40% до 6%, добовий прогін історії прискорився вчетверо.
Перенесення налаштувань стенда в робочий контур
Налаштування більше не живуть у двох місцях: знімок параметрів — комісії, затримки, ліміти за обсягом — вивантажується зі стенда й підставляється бойовому модулю як є, розбіжності логуються.
Якщо стратегія на стенді та на рахунку розходиться сильніше за поріг, прогін позначається недостовірним: це ловить помилку конфігурації до того, як вона стане збитком.
Чим форвард-тестування відрізняється від перевірки на історії
Перевірка на історії працює з фіксованим набором даних: весь ряд уже лежить у сховищі, і стратегія бачить ринок повністю. Так зручно швидко відбраковувати гіпотези — за один прогін перевіряються тисячі комбінацій параметрів.
Зворотний бік у тому, що гладка крива дохідності тут виходить надто легко: підгонка під минуле майже не зустрічає опору.
Форвард-тест, або paper trading, бере те саме ядро стратегії, але отримує дані по одній свічці — без доступу до майбутнього. Сигнали рахуються на надхідних даних, а угоди не йдуть у мережу: виконання емулюється за поточною книгою заявок із комісією та прослизанням. Стратегія поводиться так само, як поводилася б у бою, але без ризику втратити кошти.
Лише в цьому режимі стають видні речі, яких у збереженій історії немає: прослизання на тонкому стакані, часткові виконання, пауза між сигналом і постановкою ордера, поведінка після обриву зв'язку й перезапуску. Історична вибірка такі деталі згладжує й тому їх не показує.
Головне, що ловить форвард-тест — перенавчання стратегії. На історії параметри підбираються до красивої кривої, яка розсипається на першій же незнайомій ділянці ринку.
Перевірка на надхідних даних іде за відрізком, якого при налаштуванні не існувало, і показує реальну стійкість логіки, а не якість підгонки.
Тому одного підходу недостатньо: історія відповідає на питання «що було б», форвард — «що відбувається зараз, поки ринок рухається сам».
Перша відсіює наперед слабкі ідеї, друга підтверджує, що правила виживають на незнайомих даних і що результат не розсипався разом із налаштуванням.
Технічні питання перед стартом проєкту
Перед стартом проєкту замовники приносять той самий набір інженерних сумнівів: чи не виявиться модель виконання в paper trading надто «теплічною», чи вистачить історичних даних і чи не почне симулятор заважати бойовому контуру. Короткі відповіді нижче зазвичай знімають ці питання до обговорення оцінок і плану.
Наскільки модель виконання збігається з реальною угодою?
Симулятор не «малює» ідеальну ціну — заявка зіставляється із зустрічними котируваннями з урахуванням спреду, прослизання й часткового виконання обсягу.
Моделюємо комісії, затримку доставки заявки й спрацьовування лімітів, тому розбіжність із бойовим запуском залишається в одиницях відсотків, а не в рази.
Які вимоги до історичних даних?
Потрібен безперервний ряд котирувань з однаковим кроком і повним набором полів, включно з обсягом. Історію перевіряємо на пропуски, дублікати й розриви сесій до старту тесту — інакше на графіку з'являються угоди за ціною, якої в той момент не існувало.
Що робити з рідкісними інструментами?
Для низьколіквідних паперів і пар піднімаємо збережені знімки стакана й рахуємо виконання за найгіршою доступною ціною. Якщо даних об'єктивно мало, позначаємо інструмент як обмежено тестований — його результат не змішується із загальною статистикою.
Чи навантажить симулятор робочий торговий контур?
Тестовий контур ізольований: свій обліковий запис, окремий потік даних, обмеження частоти запитів. Бойові стратегії не бачать тестових заявок, і пікове навантаження симулятора не додає затримок реальним угодам.
Що змінюється в системі після передачі?
Віддаємо конфігурацію, правила зіставлення заявок, документацію з розширення й набір сценаріїв для регресії. Новий інструмент або поле в моделі виконання додаються правкою конфігурації, без переписування ядра.
Обговоримо задачу тестування ваших стратегій
Щоб оцінка проєкту була точною, а не приблизною, потрібен зріз вашої інфраструктури й того, що саме має показувати система paper trading. Нижче — що надіслати в першому повідомленні: за цим списком ми зафіксуємо вимоги до системи й повернемося з планом впровадження за етапами.
- Опис стратегій: логіка входу й виходу, використовувані індикатори й таймфрейми, як сигнали рахуються зараз — вручну, у таблицях чи вже кодом.
- Джерела даних: майданчики й інструменти, потрібна глибина історії, чи потрібен потік котирувань у реальному часі та з якою частотою оновлення.
- Схема контурів: скільки середовищ потрібно — прогін на історії, paper trading на живому потоці, звірка з реальною торгівлею — і як вони пов'язані між собою.
- Вимоги до звітності: які метрики рахувати (дохідність, просідання, частка прибуткових угод), у якому вигляді віддавати — панель моніторингу, вивантаження в таблицю, регулярний звіт.
- Обмеження: строки, доступи до майданчиків і даних, правила розмежування прав, системи, у які потрібно вбудуватися.
- Поточні напрацювання: що вже є й має зберегтися, а що можна замінити без втрати логіки.
З цим набором ми розберемо вузькі місця, зафіксуємо вимоги до системи й повернемося з оцінкою проєкту та планом впровадження. Якщо частину даних поки не зібрано — опишіть словами, уточнювальні питання поставимо самі.
