Некоторые технические детали робота-облигационера для Quik

Моя торговля облигациями проходила такие шаги:
— советник и ручная покупка, продажа из кармана квика;
— советник и ручная покупка, продажа роботом;
— покупка и продажа роботом.
где «советник» — это Excel-таблица, сделанная примерно так.

 

Схема робота

Фу, почему Quik, а не торговый API?

У моего брокера нету торгового API, зато есть Quik. Помимо этого, как правильно отмечали на СЛ, в Quik уже «из коробки» решены некоторые проблемы, к примеру, сделаны heartbeat к серверу и не надо морочиться с транспортом. Однако, серьёзные минусы тоже есть, о чём будет сказано в этой и последующих статьях.

Код робота = Lua + Rust

Lua — максимально простой мост, передающий данные из Quik в DLL, строго никакой логики в Lua.
Вся логика выполняется в DLL, написанной на Rust (tokio-райнтайм).
Почему Rust? При возможности выбрать другие языки, Rust обладает рядом преимуществ:
— Бинарник всё-в-одном, без зависимостей в виде рантайма, интерпретатора, доп.скриптов и т.п.
— Строгая типизация избавляет от страданий, испытываемых при долгосрочной работе с жидкой типизацией.
— Первоклассная поддержка многопоточности.
— Действительно отсутствие segfault-ов и race condition, бороться с которыми в коде, вызываемом из Lua-скрипта, выполняющегося в Quik на Windows, желания нет.
— Он классный ^_^
Список не полный, но этого вполне достаточно. Да, что-то частично есть в других языках, но одновременно всех пунктов (особенно последнего) нет нигде.

Заявки отправляются из Rust при помощи Trans2quik для большего (по сравнению с отправкой через Lua) контроля. Заявки на продажу отправляются с признаком PUT_IN_QUEUE, на покупку — FILL_OR_KILL (на рынке облигаций с т.з. комиссий нету разницы между лимитками и рыночными заявками).
В начале каждого аукциона открытия делается отправка нескольких тысяч заявок, на это уходит чуть больше 2-х минут:


Для каждого торгуемого инструмента делается предрасчёт и кеширование доходностей каждого шага цены. Для нескольких сотен инструментов это занимает немного оперативной памяти, Quik для скрипта показывает 40Mb в колонке «Память».

Коллбэк или не коллбэк? Второе, т.е. не коллбэк. Причина — надёжность, которой коллбэк не обладает. Как минимум:
* Коллбэк может поступить от нуля до нескольких раз.
* Поступивший коллбэк может и не содержать пользовательского ID транзакции, а может и содержать.
Гораздо проще постоянно сканировать таблицы, это достаточно быстро, а микросекундная точность мне не требуется.

Из Quik постоянно сканирую следующие таблицы:
— depo_limits
— trades
— orders
Сделки за текущую торговую сессию логично кешировать в память, что и делается.

Хранение данных

В SQLite хранятся сделки и позиции. Хоть в Quik и есть сделки, но только за текущий день, а мне требуется вся история. Позиция мне требуется в формате «столько-то лотов по такой-то цене», а не среднее по бумаге, как даёт Quik.
Кстати, если бы всё это было в Quik, то всё равно я хранил бы это на своей стороне. Хотя бы потому, что биржа может отменить сделки (такое было).
Файл SQLite бэкапируется в облако, которое подключено папкой в ФС.
Размер БД ~12Mb, на все таблицы ~70_000 записей.
Почему не PostgreSQL/Clickhouse/недайбогRedis? Потому что не надо лишних точек отказа. В случае с SQLite мониторить по большому счёту надо только бэкап в облаке.

Подготовка конфига

Робот торгует (точнее, покупает) ровно то, что указано в конфиге. Список инструментов для покупки готовится в несколько этапов. На некоторых этапах задействован ИИ (категоризация, проверка).
Это самый важный этап, цена ошибки тут весьма высока, что видно по моему графику доходности (см. ниже). Рейтинги и нахождение в индексах не дают гарантии того, что у эмитента не будет дефолта. Никто и ничто таких гарантий не даёт. Поэтому к подбору надо подходить очень внимательно.
О некоторых идеях выбора инструментов рассказывал в предыдущей статье.
Инструменты тянутся из https://iss.moex.com
Один из этапов подготовки выполняется проектом, который написан полностью Claude-ом (тоже на Rust). И да, в части угадывания Claude-у конкурентов нет.

Разработка

С какого-то момента 99.9% задач стали выполняться промптами в opencode. Задействую разные сети (и китайские, и не очень китайские), уже отказываюсь от openspec, это у меня на личных и рабочих проектах не взлетело.
Разумеется, тщательно проверяю то, что сгенерили железные друзья, есть система самовалидации для помощников. В основном пишу (промпты) на Linux или Macos, хотя иногда приходится на Windows (в виртуалке). Но собираю релиз всегда на Windows, что и понятно, т.к. требуется DLL-ка для Quik.
Весь бандл робота (Lua-скрипт, DLL-ка, конфиг) заворачивается в MSI-пакет и отправляется на торговый ноутбук. Да, торговый ноутбук — это отдельная машина, которая всегда работает в торговую сессию независимо от того, рядом ли я или в отпуске, или ещё где-то. До ноутбука сделан удалённый доступ при помощи RustDesk, настроенного на дешёвую виртуалку в хостинге.

Прочее

В день проходит десятки-сотни сделок, а в некоторые моменты бывают тысячи сделок (редко — отсутствие сделок, включая выходные).
С ростом позиции стали проявляться разные интересные проблемы, как технические, так и алгоритмические, о чём попробую рассказать дальше.

Доходность