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