AI-трейдинг-бот: де ламається виконання угод
Сигнал є, а угода йде не туди або не вчасно. Модель упевнено видає точку входу, але заявка виконується за ціною, якої на стакані вже немає — так виникає прослизання ціни, яке з'їдає розрахункову перевагу стратегії. Кілька таких виконань за сесію, і статистика перестає сходитися з бектестом.
Гірше, коли рветься зв'язок із брокером. Термінал показує з'єднання, потік котирувань відстає на секунди, а надіслана заявка залишається без відповіді — у журналі вона активна, у брокера її немає.
Це зависла заявка: бот вважає позицію відкритою, повторний сигнал відкриває другу, і замість однієї угоди на рахунку виявляється подвійна з різними цінами входу.
Далі починається ручне втручання в торгівлю. Інженер або трейдер вручну звіряє таблицю ордерів із логом транзакцій, знімає зайві заявки й править позицію — у момент волатильності, коли ціна ходить швидко.
Година розбору вбиває не лише результат дня, а й довіру до стратегії: незрозуміло, де помилка моделі, а де наслідки збою виконання.
Окрема біда — розходження обліку. Позиція в терміналі й позиція в журналі стратегії живуть окремо, тому дохідність рахується за даними, яких не було на рахунку.
Такий AI-трейдинг-бот не можна ні масштабувати, ні перевести на кілька інструментів: кожен збій доводиться закривати руками.
Корінь зазвичай не в моделі, а в шарі між сигналом і брокером: немає підтвердження угоди, немає ідемпотентності заявок, немає контролю стану рахунку при перепідключенні. Розбираємо, як це закривається.
Що дає автоматизація торгівлі: ефект у метриках
Торговий цикл розкладається на вимірювані відрізки: від події — пробою рівня, зміни черги заявок, публікації звіту — до виставленої заявки. У людини це кілька секунд, і майже завжди вона дивиться не на один інструмент.
Бот у QUIK проходить той самий шлях за частки секунди і не відволікається: швидкість реакції на подію перестає залежати від того, скільки позицій супроводжується одночасно.
Другий зріз — частка ручних операцій. Автоматизація торгівлі забирає собі правила: перестановку захисних заявок, супровід позиції, закриття за часом, приведення часток до цільових при відхиленні.
За журналом видно, яка частина дій виконана без ручної участі, і це число — прямий показник зрілості процесу. За людиною залишається те, де потрібне рішення: нестандартна ситуація, правка логіки, розбір інциденту.
Третій ефект — цілий клас відмов, що зник. Пропущена заявка через відволікання, забутий стоп, подвійне натискання з подвоєним обсягом, помилка в ціні — це не «людський фактор загалом», а конкретні збої, які правило виключає.
До цього додається стійкість до збоїв обв'язки: журналювання кожного кроку, звірка позицій із терміналом, повтор за відсутності відповіді, коректний перезапуск без дублів заявок.
Звідси четверта метрика — ціна простою процесу. Поки торгівля тримається на одному робочому місці, недоступність термінала або каналу до брокера означає пропущені події та неузгодженість позицій, яку потім розбирають вручну.
Рознесені ролі, контроль стану й автопідйом логіки скорочують це вікно до хвилин, а звірка позицій прибирає розходження до того, як вони стануть збитком. Усі чотири метрики описують виконавську дисципліну, а не обіцяну дохідність — її ми не прогнозуємо.
Способи підключення торгової логіки: порівняння варіантів
Режими підключення торгової логіки визначають, де живе стратегія і скільки часу проходить між ринковою подією та заявкою. Нижче — три схеми, між якими реально обирають при інтеграції з торговим терміналом, та їх обмеження підключення.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пряма інтеграція з терміналом | Реакція потрібна в межах секунд, логіка компактна, зовнішні дані не потрібні | Логіка живе в одному процесі з терміналом: перезапуск або оновлення майданчика зупиняє бота. Масштабувати розрахунок і підключати нові джерела даних ніде |
| Проміжний сервіс | Розрахунок моделі, історія угод, кілька рахунків, зовнішні дані | З'являється мережевий перехід і затримка. Потрібен контроль розсинхронізації позицій між сервісом і рахунком та моніторинг обох контурів |
| Відкладений запуск | Стратегія не чутлива до секунд: сигнали за закриттям інтервалу, перевірка на історії, вихід у бій після тестів | Подію всередині інтервалу обробити не можна — арбітраж і новинні спалахи відсікаються. Частина сценаріїв просто не реалізується |
Схеми часто комбінують: розрахунок і зберігання історії виносять у проміжний сервіс, заявки надсилають прямою інтеграцією з QUIK, а відкладений режим залишають для звірки позицій.
На обмеження підключення впливає не лише затримка, а й правила майданчика: ліміти на частоту заявок, вимоги до журналювання дій бота та поведінка при розриві зв'язку.
Порядок впровадження: від аудиту стратегії до передачі
Роботу починаємо не з коду, а з аудиту стратегії: етапи впровадження вибудувані так, щоб до першої реальної заявки були перевірені і логіка сигналів, і межі ризику. Нижче — порядок, за яким іде проєкт і за яким видно, на якому кроці ми перебуваємо.
- Аудит стратегії та меж ризику. Розбираємо, на яких даних будується сигнал, де логіка втрачає стійкість і які ліміти за позицією, просіданням і частотою угод вважаємо допустимими.
- Схема потоків і точок відмови. Фіксуємо, звідки надходять котирування, де вважається рішення і як заявка потрапляє в торговий термінал QUIK через QLUA — включно з поведінкою системи при обриві зв'язку.
- Збирання тестового контуру. Ізольована копія робочого середовища: та сама маршрутизація заявок і ті самі ліміти, але без реального рахунку — помилки тут нічого не коштують.
- Перевірка на історичних даних. Прогін на кількох режимах ринку — тренд, боковик, різкі рухи; дивимося просідання, частку відхилених заявок і розходження з розрахунковою моделлю.
- Обмеження та захисти. Аварійна зупинка за денним збитком, ліміт на кількість угод, блокування при розсинхронізації даних, журнал за кожним рішенням бота.
- Передача в експлуатацію. Регламенти запуску й зупинки, моніторинг і оповіщення, розмежування доступів, інструкція для чергового інженера.
- Супровід. Коригування після зміни волатильності, розбір інцидентів, перегляд перевірок перед кожним розширенням лімітів.
Що залишається у замовника: конфігурації, схеми, регламенти
Комплект передається не як архів «на пам'ять», а як робочий набір, за яким ваша команда зможе експлуатувати бота і змінювати його поведінку без нас. Нижче — що саме передається на руки і навіщо потрібна кожна частина.
- Файли конфігурації — перелік інструментів, обмеження за ризиком, розклад торгових сесій, пороги спрацьовування сигналів. Правляться без перезбирання: змінити ліміт або вимкнути інструмент можна в робочому порядку.
- Схема інтеграції — як бот пов'язаний з терміналом через QLua, які події та таблиці він читає, де точки відмови і як поводиться при розриві зв'язку, зависанні термінала або перезапуску.
- Правила доступу та ліміти — розподіл ролей, порядок видачі й відкликання ключів, максимальна позиція на інструмент і денний стоп. Зняття обмеження потребує другого підтвердження, а не однієї дії.
- Журнал операцій — кожне рішення бота з підставою: вхід, вихід, розмір, відхилені сигнали. Вивантаження за будь-який період — щоб розбирати спірні угоди за фактами, а не з пам'яті.
- Регламент інцидентів — рівні збоїв, хто і за який час реагує, коли торгівлю зупиняють руками і як фіксується результат розбору.
- Інструкція зі зупинки та відновлення — коректний сценарій зняття бота з торгів, перевірки перед поверненням і відкат до попередньої робочої конфігурації.
- Порядок доопрацювань — як передаються нові правила, як вони перевіряються на історії та як версіонуються, щоб зміни не переписували одна одну.
Усе це ми розбираємо з вашою командою на передачі: показуємо, де що лежить, і відповідаємо на питання з експлуатації.
Практика: як прибрали втрати на виконанні заявок
Працювали з брокерським терміналом QUIK: робот виставляв заявки, а фактичне виконання звіряли з розрахунком вручну, вже після закриття зміни.
Впровадження йшло під навантаженням, без зупинки торгів, і вже перші сесії на зростанні волатильності показали, де контур втрачає керованість.
Розходження між розрахунковою та фактичною ціною накопичувалися, частина сесій залишалася незакритою до ранку, а обрив зв'язку з брокером черговий помічав за логами, коли позиція вже висіла відкритою.
| Метрика | До | Після |
|---|---|---|
| Частка заявок з розходженням ціни | 0,7% | 0,04% |
| Незакритих сесій за тиждень | 11 | 0 |
| Відновлення після обриву зв'язку | 35–40 хвилин вручну | 80–100 секунд автоматично |
| Звірка позицій з брокером | раз на добу, вручну | кожні 5 секунд, автоматично |
Що змінили
Потік заявок зробили ідемпотентним: у кожної свій ідентифікатор, повтор після обриву не створює дубль, а повертає статус уже надісланої заявки.
Контроль ризику перенесли всередину циклу — ліміт перевіряється до відправлення, а не після, і при виході відхилення за межу робот знімає заявку сам.
Окремий сторожовий процес стежить за живістю з'єднання: при розриві контур переходить у безпечний режим, нові заявки не йдуть, відкриті позиції фіксуються за останньою підтвердженою ціною. Звірку позицій перевели з ручної добової в автоматичну, з журналом кожного розходження.
Частка відмов на виконанні скоротилася у 17 разів, незакритих сесій більше немає, відновлення займає менше двох хвилин без участі чергового.
Технічні сумніви перед стартом: коротко по суті
Бот працює через торговий термінал, а не через прямі підключення до біржі, — це знімає більшість питань щодо доступів, лімітів і контролю.
Нижче — те, що зазвичай уточнюють до старту: які права отримує бот, що відбувається при обриві зв'язку і як перевірити логіку, не ризикуючи робочим рахунком.
Які права отримує бот і чи можна обмежити ризик?
Права лише на виставлення та зняття заявок у межах виділеного рахунку — виведення коштів недоступне технічно. Обмеження ризику задається в конфігурації: максимальний обсяг позиції, кількість активних заявок, денний стоп за просіданням. При спрацьовуванні будь-якого з лімітів стратегія зупиняється, а не продовжує усереднюватися.
Що відбувається при обриві зв'язку з терміналом?
Стан позицій і відкритих заявок пишеться на диск після кожної операції, тому після перезапуску бот відновлює картину рахунку і продовжує з поточної точки, а не з нуля.
Якщо обрив припав на момент виставлення заявки, при поверненні зв'язку йде звірка з фактичним станом рахунку, і розходження закриваються примусово.
Як перевіряється логіка до реального рахунку і хто її доопрацьовує?
Спочатку прогін на історичних даних, потім тестовий запуск на демо-рахунку з тими самими лімітами й параметрами, і лише після збігу результатів — робочий рахунок з мінімальним обсягом.
Код і конфігурації передаються повністю, без закритих модулів; доопрацювання логіки ведемо ми в межах супроводу, і кожна правка проходить той самий цикл перевірки.
Обговоримо задачу: що надіслати для точної оцінки
Чим точніші вхідні дані, тим менше припущень в оцінці проєкту — і тим нижчий шанс, що строки доведеться переглядати в середині роботи. Достатньо надіслати все текстом, без формального технічного завдання й закритих доступів на цьому етапі.
- Опис стратегії словами: які сигнали, за якими інструментами, що вважається входом і виходом, як система поводиться за відсутності даних.
- Перелік інструментів і режим торгівлі — строковий ринок, фондовий, вечірня сесія — щоб оцінити обсяг перевірок і глибину історії для тестів.
- Вимоги до ризику й лімітів: максимальна позиція на інструмент, денний стоп за просіданням, поведінка при розриві зв'язку з терміналом.
- Доступи до тестового контуру QUIK з QLUA і підтвердження, що на ньому доступні потрібні інструменти.
- Приклади журналів торгової системи й робота: кілька днів записів у вихідному вигляді — за ними видно, як реально виглядає потік заявок і помилок.
- Де запускається бот: той самий комп'ютер з терміналом або окремий сервер, хто і як зупиняє його вручну при збої.
Далі ми розбираємо надіслане, уточнюємо спірні місця і повертаємося з оцінкою та планом робіт: етапи, що перевіряємо на тестовому контурі, що вважаємо прийманням. Якщо частину даних поки не зібрано — приходьте з тим, що є, решту уточнимо питаннями.
Що робити, якщо торговий бот уже розгорнуто?
Розгорнутий торговий бот — працюючий актив, і втручання змінює його поведінку в моменті. Тому питання не в тому, чи переписувати систему, а в тому, який обсяг змін вона витримає без зупинки торгівлі.
Далі розбираємо три сценарії: аудит з точковим доопрацюванням, винесення логіки в окремий шар і перенесення на іншу платформу.
Аудит торгової логіки починається з відновлення фактичної стратегії за кодом і журналами угод: які умови відкривають позицію, як обробляються часткові виконання, що відбувається при розриві зв'язку, чи може бот виставити дубль заявки.
Потім прогін на історії та звірка сигналів з тим, що реально йшло брокеру — розходження зазвичай і є джерелом просідань. На виході — карта ризиків і список правок з оцінкою обсягу.
Якщо логіка загалом робоча, дешевше доопрацювання наявного бота: міняємо лише модулі входу, розрахунку розміру позиції та захисних стопів, решту контуру не чіпаємо. Стійкіше — винести ухвалення рішень в окремий шар, що спілкується з QUIK через тонку прошарку.
Торговий контур залишається незмінним, нова логіка перевіряється паралельно і вмикається перемикачем, відкат займає секунди.
Перенесення на нову платформу виправдане, коли поточна впирається в обмеження за інструментами або швидкістю відгуку. Ризик тут один: поведінку потрібно повторити до останньої умови.
Тому обидва контури рахують сигнали паралельно на одному ринку, розходження розбираються, і лише потім торгівля переводиться на новий.
Супровід після змін — версіонування стратегій, контроль з'єднання та лімітів, регламент оновлень і розбір інцидентів за журналами. Тоді наступна правка не перетворюється на переписування з нуля.
