Чому AI-трейдинг-бот втрачає угоди на стику з брокерським API
AI-трейдинг-бот ухвалює рішення за власною моделлю стану, а реальні позиції живуть на боці брокера. Варто з'єднанню обірватися в момент підтвердження заявки — і настає розсинхронізація позицій: бот вважає вхід відкритим, хоча його вже немає. Виявляється це не одразу, а коли керування ризиком рахує просадку за неіснуючою позицією.
Після реконекту починається друга половина проблеми — дублі ордерів. Запит пішов, відповідь не повернулася, з'єднання піднялося знову, і бот надсилає заявку повторно, бо ідентифікатор генерується заново при кожному запуску.
На вході обсяг тихо подвоюється, на виході частина позиції залишається незакритою, і ризик рахується за неправильною базою.
Часткове виконання додає третій клас збоїв: заявка закрита не повністю, а стоп і цілі вже перераховані за повним обсягом. Залишок живе на рахунку окремим рядком і видно лише під час звірки, а не в інтерфейсі бота.
Поки ці стики не закриті, в процес входить людина — ранковий розбір розбіжностей, ручні правки угод, звірка позицій за вивантаженнями. Це з'їдає години робочого часу команди й маскує системну помилку під разову.
Ми розбираємо зв'язку бота з рахунком як окремий шар: що вважати джерелом істини, як звірятися після будь-якого обриву з'єднання з брокером і як зробити надсилання заявок стійким до повторів. Далі — як це закривається на рівні інтеграції.
Що дає керована інтеграція: швидкість, стійкість, контроль
Керована інтеграція змінює масштаб часу, у якому працює бот. Замість періодичного опитування рахунку й котирувань ми підписуємося на ринкові події та тримаємо постійне з'єднання з Interactive Brokers — час реакції бота на зміну ціни скорочується із секунд до часток секунди. Заявка встигає піти до того, як рівень піде, а не після нього.
Стійкість торгової логіки тримається на трьох рішеннях: правила входу й виходу разом із ризик-лімітами винесені з коду в конфігурацію, стан позиції відновлюється з журналу угод, а повторне надсилання заявки відсікається унікальним ключем.
Під час обриву зв'язку бот не сліпне — він дораховує стан за фактами виконання й продовжує з тієї точки, де зупинився, а не з нуля.
Із цього складається частка автоматичних угод: закриття за стопом і ціллю, обробка часткових виконань, перенесення рівня захисту й розворот позиції відбуваються без ручного втручання.
Заодно зникає цілий клас відмов — подвійні заявки, заявки без підтвердження, позиції, що залишилися без захисного ордера.
Звірка позицій перетворюється на регламент, а не на ручну перевірку. Позиції, активні ордери, середня ціна й вільна маржа звіряються під час старту, після розриву з'єднання та за розкладом; розбіжність логується й піднімає оповіщення.
Торгова логіка при цьому залишається керованою: ліміти, стопи й правила змінюються в конфігурації, без перезбирання бота.
Варіанти підключення бота до торгового рахунку
Підключення до рахунку в Interactive Brokers будується за одним із чотирьох режимів, і вибір визначає, що бот знає про рахунок і як швидко реагує на зміни.
| Варіант | Коли підходить | Обмеження підключення |
|---|---|---|
| Періодичні синхронні запити | Низька частота угод і налагодження логіки | Затримка між опитуванням і реакцією, зайве навантаження на канал, пропуск швидких рухів ціни |
| Потокові підписки на події рахунку | Реакція на виконання заявок і зміну позиції | Залежність від безперервності з'єднання: під час розриву події губляться, потрібна повторна синхронізація |
| Підписки плюс локальний стан бота | Основний режим: багато інструментів, часті угоди | Потрібна звірка локального стану з брокерським після кожного розриву й перезапуску |
| Проміжний шар між ботом і рахунком | Кілька стратегій, загальний контроль ризику, журнал дій | Ще одна точка відмови: падіння шару зупиняє торгівлю цілком |
Гібрид виграє на практиці: бот тримає позиції, заявки й залишки у власному стані, а потокові підписки лише підтверджують зміни. Тоді розрив з'єднання не призводить до хибних рішень — після відновлення звірка повертає стан до ладу, а дублі заявок не надсилаються.
Проміжний шар виправданий, коли стратегій кілька: він тримає єдиний ліміт ризику й журнал дій. Але в нього своя ціна — додаткова затримка на шляху сигналу та ще один компонент, який потрібно обслуговувати.
Як проходить інтеграція: етапи інженерної роботи
Інтеграція торгового бота з брокерським рахунком — не підключення бібліотеки, а збирання контуру, де помилка в одному вузлі обнуляє роботу стратегії.
Тому порядок такий: спочатку розбираємо наявну логіку й схему виконання, потім будуємо, перевіряємо на історії, запускаємо обмежено та передаємо регламенти вашій команді.
Порядок робіт
- Аудит торгової логіки та поточної схеми. Розбираємо правила входу й виходу, джерела сигналів, розрахунок розміру позиції. Результат — карта рішень: де бот діє сам, а де потрібне підтвердження.
- Проєктування контуру виконання. Визначаємо, як зберігається стан позицій і заявок та що вважаємо джерелом істини — потік котирувань чи звіти брокера.
- Шар доступу до рахунку. Запити ідемпотентні, є повторні спроби, контроль дублів і відновлення після розриву зв'язку. Кожна заявка позначена ідентифікатором і потрапляє до журналу — збій розбираємо за фактами.
- Перевірка на історичних даних. Прогін на минулих котируваннях із поправкою на прослизання, комісії та затримки виконання. Дивимося просадку й поведінку на розривних рухах, а не лише дохідність.
- Тестовий контур. Звіряємо сигнали бота з тим, що було б реально виконано: розбіжності видно до старту.
- Обмежений запуск. Малий обсяг операцій, жорсткі ліміти за позицією та втратами, щоденний контроль. Обсяг зростає лише після збігу поведінки з очікуваною.
- Передача регламентів. Документація: розгортання, аварійне вимкнення, ознаки втручання, відновлення стану після збою.
Що замовник отримує на руки: конфігурації та регламенти
На руки замовник отримує не лише працюючого бота, а й комплект, за яким його можна експлуатувати, передати іншому інженеру й підняти заново після збою.
Усе перелічене лежить у репозиторії поруч із кодом і оновлюється разом із ним — інакше документація розходиться з реальністю за пару місяців.
- Робочі конфігурації бота. Профілі для тестового й реального рахунку: інструменти, ліміти на позицію та денний обіг, робочі інтервали, пороги захистів. Перемикання середовища — зміною профілю, без правок коду.
- Схема взаємодії з рахунком. Як влаштований обмін із брокерським шлюзом Interactive Brokers: підписка на котирування, надсилання заявок і підтверджень, часткові виконання, обриви зв'язку та точки, де бот зобов'язаний зупинити торгівлю сам.
- Політики доступу й ключів. Які облікові дані потрібні, де зберігаються, хто й як їх змінює, що робити при витоку. Право торгувати й право змінювати налаштування розведені за різними ролями.
- Інструкція з відновлення. Порядок дій: підняти бота з нуля, звірити позиції зі звітом брокера, закрити розбіжності, повернутися до торгівлі після аварійної зупинки.
- Регламент супроводу. Що вважається аварійною подією, за чим стежить черговий, час реакції, порядок оновлення стратегії та склад регулярного звіту.
- Журнал змін і прогони на історії. Кожна правка стратегії супроводжується перевіркою на історичних даних і на тестовому рахунку — видно, що саме вплинуло на результат.
Кейс: прибрали обриви ордерів і скоротили ручні правки
Замовник торгував через Interactive Brokers, а AI трейдинг бот виставляв ордери за власною моделлю. Зв'язка трималася на одному довгоживучому з'єднанні: планові роботи брокера, падіння каналу або перезапуск шлюзу — і потік подій губився. Бот продовжував вважати, що позиції відкриті, хоча картина на рахунку вже була іншою.
Ціна такого обриву — не сам простій, а тиха втрата стану рахунку. Частина виконань до бота не доходила, дублікати заявок відсікалися вручну, ліміти за інструментами рахувалися за застарілими даними.
Черговий правив приблизно третину спрацьованих сигналів, і кожен розбір — це ризик виставити позицію двічі або пропустити стоп.
Як перебудували зв'язку
Локальна пам'ять бота перестала бути джерелом істини. Кожне виконання, скасування та часткове заповнення пишуться до журналу, а під час старту бот не довіряє своїй моделі, а звіряє її з брокером за відкритими заявками й позиціями.
Окремо поставили автоматичну звірку: стан рахунку, позиції та активні заявки зіставляються з локальним станом на короткому інтервалі. Розбіжність піднімає алерт і блокує нові входи за ураженим інструментом до звірки — помилка не встигає перетворитися на зайву позицію.
Метрики до й після: частка ручних правок — з третини сигналів до менш ніж 2%, відновлення після збою — з півгодини розбору до автоматичного підйому за секунди, розбіжності під час планової звірки — нульові за місяць спостережень. Клас відмов «бот не знає, що позиція є» закрито на рівні логіки запуску.
Чим відрізняється синхронний обмін від потокового і що вибрати
Це два різні режими отримання стану рахунку, і вибір між ними визначається не зручністю реалізації, а тим, скільки живе торгове рішення. За синхронного обміну бот сам запитує позиції, баланс і котирування за розкладом. За потокового — один раз підписується на події й далі отримує зміни в міру їх появи.
Ціна вибору видна в затримці оновлення. Поки між двома запитами йде пауза, рахунок уже змінився: частина заявки виконалася, маржа просіла, ціна пішла від рівня входу.
Логіка, побудована на зрізі, ухвалює рішення за застарілими даними й отримує виконання за ціною, якої на момент розрахунку вже не було. На спокійному ринку це майже непомітно, на сплеску волатильності розбіжність стає основною статтею збитку.
Різниця у вимогах:
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Синхронний обмін | Ребалансування за розкладом, звітність, стратегії на денних барах | Між запитами рахунок змінюється — рішення за застарілими даними |
| Потоковий обмін | Супровід відкритих позицій, стоп-заявки, контроль маржі | Потрібні відсікання дублів, обробка розривів і повторна підписка |
| Змішаний | Торгівля всередині дня з контролем розбіжностей | Дорожче в підтримці: два контури потрібно узгоджувати |
На практиці частіше працює гібрид: під час старту беремо повний знімок синхронно, далі тримаємо потокові підписки, а опитування залишаємо для періодичної звірки — воно ловить розбіжності після розривів з'єднання.
Вибір режиму — це питання допустимого віку даних: якщо торгове рішення живе довше за інтервал опитування, синхронного обміну достатньо.
Технічні сумніви перед стартом: розбираємо за пунктами
Інженерні заперечення перед стартом повторюються від проєкту до проєкту: що буде при обриві зв'язку, як не надіслати заявку двічі, хто відповідає за ризик-ліміти. Розбираємо їх до початку робіт — на інтеграції з Interactive Brokers ці місця закриваються конкретними механізмами.
Як виключити дублі угод при обриві зв'язку?
У кожної заявки унікальний ключ у журналі, а перед постановкою шар виконання звіряє намір із фактичними позиціями та активними заявками в брокера. Після розриву відновлення йде за номером заявки, а не сліпим повтором.
Що відбувається при падінні процесу або втраті каналу?
Бот працює під сторожовим процесом: піднімається заново й відновлює стан із журналу, а не з нуля. Якщо канал недоступний довше за поріг, спрацьовує аварійний сценарій — зупинка торгівлі або зведення позицій, за вашими правилами.
Хто відповідає за ризик-ліміти і чи можна вести кілька рахунків?
Правила задаєте ви, ми зашиваємо їх в окремий шар перевірок перед надсиланням заявки: ліміт на інструмент, на портфель, денний стоп. Стратегія їх не обходить. Рахунки ведемо роздільними контурами, ліміти й журнал рахуються для кожного окремо.
Як проходить передача управління й доступів?
За регламентом: зупиняємо торгівлю, фіксуємо позиції, передаємо доступи, конфігурацію та документацію. Далі контур працює під вашим контролем — із супроводом або без.
Обговоримо задачу: з чого починається інтеграція
Перше обговорення задачі потрібне, щоб зібрати вихідні дані, а не показати презентацію. Нам важливо зрозуміти торгову логіку: за якими подіями бот входить і виходить, як рахує розмір позиції, де стоять жорсткі обмеження за ризиком.
Від цього залежить архітектура — де тримати стан, як часто звертатися до брокера й що робити при розбіжності між нашими даними та його звітом.
- торгова логіка: сигнали, робочі інтервали, список інструментів, правила входу й виходу з позиції;
- обмеження ризику: ліміт на позицію, денний ліміт збитку, кількість одночасних заявок, поведінка при спрацюванні захисної заявки;
- умови роботи: реальний рахунок або тестовий контур, доступи, джерело ринкових даних, режим — лише сигнали або автоматичне виконання;
- що вже готово: код стратегії, вивантаження історії угод, наявні скрипти, вимоги до журналу подій;
- правила відмов: повторне надсилання заявки, обробка розриву зв'язку, ручний стоп-кран і порядок закриття відкритих позицій.
За цими відповідями збираємо план робіт — від підключення до API брокера й звірки даних із терміналом до переведення на реальний рахунок. Повертаємося з розбивкою за етапами, оцінкою строків за кожним і переліком того, що знадобиться з вашого боку.
Наступний крок — визначити, хто у вас ухвалює рішення з торгової логіки та коли можна отримати тестові доступи.
