Как оценить эффективность торгового бота и вести учёт результата

Чтобы оценить эффективность торгового бота и вести учёт результата, помимо сделок записывают три вещи: версию настроек, дату и время каждого изменения параметров и периоды, когда бот был остановлен. Без этих записей выгрузка сделок описывает неизвестного бота — у неё нет автора правил. Журнал сделок отвечает на вопрос «что произошло». Версии и остановки отвечают на вопрос «у какого именно бота».

Какая задача решается учётом помимо сделок

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

Отсюда и ценность скучных записей. Они не улучшают результат, зато делают его адресным. Для схем вроде бота усреднения это критично: там каждый параметр меняет и объём, и частоту сделок. В обращениях читателей редакция видит одну и ту же картину: журнал сделок есть у всех, журнал правок — почти ни у кого, и оценивать по такому набору нечего.

Что записывать: шаги с параметрами

1. В журнале сделок — время решения и время исполнения, сторона, тип заявки, цена заявки, цена исполнения, объём, комиссия, идентификатор сделки.
2. В журнале версий — номер версии, дата и время правки, изменённый параметр, прежнее и новое значение, причина правки.
3. В журнале состояний — начало и конец каждой остановки.
4. Туда же — сбои связи, отклонённые заявки, смена источника данных, смена ключей доступа.
5. При оценке соедините три журнала по времени и разбейте период на отрезки по версиям.
6. Считайте результат по каждому отрезку.

Пятый шаг и есть смысл всей затеи. Пока журналы лежат порознь, они бесполезны: ценность возникает в момент, когда вы можете сказать, что версия четвёртая работала с 3 по 19 августа, дала сорок одну сделку и такой-то результат при таких-то издержках.

Расчёт на примере периода

Соотношение говорит само. Десяток записей определяет, можно ли вообще доверять тысяче восьмистам. Это дешёвая страховка: минута на запись правки против квартала бессмысленной статистики. Причём восстановить эти десять строк задним числом почти невозможно — память даёт месяц вместо даты, а приложение истории изменений обычно не хранит.

Как состав записей описан в профессиональных требованиях

Состав обязательных полей по заявкам прописан довольно подробно, и этот перечень полезен как образец. Правило 613 Регламента NMS в редакции Свода федеральных правил США, доступной на 18 октября 2026 года, относит к существенным условиям заявки символ бумаги, тип инструмента, цену, размер отображаемый и неотображаемый, сторону сделки, тип заявки, признак открытия или закрытия позиции и срок действия. Тот же документ требует хранить сведения центрального репозитория не менее пяти лет.

Там же введено понятие доли ошибок — процента событий, в которых переданные данные не отражают фактическое событие на рынке. Идея прикладная. Журнал оценивают не только по полноте полей, но и по тому, насколько записи совпадают с тем, что происходило. Здесь же пригодится отметка об источнике цены: расхождение биржевой и ончейн-цены иначе выглядит как ошибка бота.

Изменения параметров регулируются отдельно. Делегированный регламент Европейской комиссии 2017/589 применяется с 3 января 2018 года: статья 11 требует, чтобы существенному изменению в рабочей среде предшествовала проверка назначенным лицом, а любое изменение функциональности доводилось до трейдера, комплаенса и риск-функции. Статья 28 того же регламента обязывает хранить записи заявок при высокочастотной технике пять лет с даты отправки. Правка — не запись в дневнике. Это документированное изменение объекта оценки.

Ошибки, из-за которых учёт не помогает

• Правки фиксируются числом, без времени.
• Записана новая величина параметра, а прежняя — нет.
• Периоды остановки не отмечены, и простой попадает в знаменатель.
• Журналы лежат в разных форматах и не соединяются по времени.
• Причина правки не указана, и повторить решение нельзя.
• Экспорт сделок берётся из интерфейса сетки заявок без цены решения, и расчёт издержек становится неполным.

Итог

Учёт — не отчётность для кого-то, а условие осмысленности оценки. Три журнала. Одна связка по времени. Заводятся они один раз, заполняются минутами, а дают возможность сказать не «бот прибыльный», а «версия пятая на таком-то режиме рынка за такой-то срок дала такой-то результат при таких-то издержках». Это касается и обычных пар, и традиционных активов на криптобирже, где к журналу остановок добавляется расписание сессий. Первая формулировка ничего не значит. Вторая проверяема и годится как основание для следующего решения о параметрах.

Частые вопросы