Не так давно я увидел серию постов на канале ALKO трейдинг, где автор собрал самые важные, на его взгляд, термины для разработки HFT-систем и самого алгоритмического трейдинга. Мне показалось хорошей идеей объяснить вам эти термины в удобном формате.

Потому что сам по себе список мало помогает. Можно запомнить, что такое очередь заявок, идемпотентность и математическое ожидание, но так и не понять, почему эти вещи встречаются в одной торговой программе.

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

По дороге станет понятно, какие термины описывают сам рынок, какие помогают не сломать программу, а какие нужны, чтобы не принять случайное везение за работающую стратегию.

Во всех примерах будет вымышленный актив ABC. Цены, комиссии, задержки и результаты тоже учебные. Они нужны для объяснения механики, а не показывают доходность какой-либо стратегии.

Главная мысль: торговому роботу недостаточно правильно предсказать цену. Он должен получить достоверные данные, успеть действовать, реально исполнить заявку и правильно посчитать результат.

1. Что мы вообще собираемся автоматизировать

Алгоритмическая торговля, или алготрейдинг, означает, что хотя бы часть торговых решений выполняет программа. Например, она сама выбирает момент покупки, рассчитывает объём или разбивает большую заявку на несколько маленьких.

HFT, High-Frequency Trading, относится к области, где особенно важны короткие временные горизонты, высокая скорость обработки событий и исполнения. Здесь задержка может менять не только удобство работы, но и экономический смысл сделки.

Представим, что ABC обычно торгуется около 100. В какой-то момент продавец быстро продаёт большой объём, и цена опускается до 99,95. Робот предполагает, что это временное отклонение: продавец закончит, и цена частично восстановится.

Такая идея называется Mean Reversion, возвратом к среднему или некоторому нормальному уровню.

Но слово "среднее" здесь опасно понимать буквально. Рынок не обязан возвращаться к вчерашней цене, к круглому числу 100 или к линии на графике. Нормальный уровень тоже может меняться. Поэтому робот должен отличить временное отклонение от ситуации, когда появилась новая информация и актив действительно стал дешевле.

Если программа покупает любое падение только потому, что "раньше было дороже", это ещё не модель возврата. Это непроверенное предположение.

Прежде чем обсуждать, как его проверять, нужно понять, что именно программа видит на бирже.

2. У рынка нет одной-единственной цены

Представим, что лучший покупатель готов купить ABC по 99,99, а лучший продавец готов продать по 100,01.

Лучшее предложение купить называется Bid, лучшее предложение продать называется Ask. Их разница, 0,02, называется Bid-Ask Spread, спредом.

Посередине находится Mid Price:

Mid = (Bid + Ask) / 2

В нашем случае Mid равен 100.

Но купить по 100 прямо сейчас может быть невозможно. Mid является удобной точкой отсчёта, а не обещанием исполнения.

Если вы хотите купить немедленно, обычно придётся взаимодействовать с продавцами на Ask. Если хотите продать немедленно, с покупателями на Bid. Поэтому две программы могут показывать одинаковую "рыночную цену", но оценивать стоимость входа и выхода по-разному.

Все ожидающие заявки образуют Limit Order Book, или LOB, стакан заявок. В нём находятся не только лучшие цены. Например, покупатели готовы купить 200 ABC по 99,99, ещё 700 по 99,98 и 1500 по 99,97. Это разные уровни Market Depth, глубины рынка.

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

Биржа также определяет Tick Size, минимальный шаг цены, и Lot Size, допустимый шаг количества. При шаге цены 0,01 нельзя поставить 100,005. При шаге количества 0,1 нельзя отправить 0,15, если правила требуют кратности этому шагу. Минимальный объём заявки и минимальная денежная стоимость могут задаваться отдельными ограничениями.

Для маленьких изменений удобно использовать базисные пункты, bps. Один базисный пункт равен 0,01%. Поэтому 10 bps составляют 0,1%, а при цене 100 движение на 1 bp составляет 0,01.

Запомнить здесь стоит одно: Mid показывает середину рынка, Bid и Ask показывают условия немедленной продажи и покупки.

3. Почему одинаковая цена не означает одинаковую вероятность сделки

Допустим, вы выставили покупку по лучшему Bid. Теперь можно считать, что ближайший продавец продаст именно вам?

Нет. По этой цене уже могут стоять другие покупатели.

Порядок исполнения определяет Matching Engine, механизм сопоставления заявок на бирже. Он решает, какие встречные заявки можно исполнить и кому достанется доступный объём.

При Price-Time Priority сначала учитывается цена, затем время. Покупатель с более высокой ценой получает преимущество. Среди покупателей с одинаковой ценой раньше обслуживается тот, кто раньше занял очередь. Такой порядок на одном уровне связан с FIFO, First In, First Out: первым пришёл, первым обслужили.

Если до вас по 99,99 уже стояло 10 000 ABC, ваша заявка на 100 ABC окажется позади них. Это ваше Queue Position, положение в очереди.

Очередь постоянно меняется. Одни заявки исполняются, другие отменяются, новые добавляются. Эти изменения называются Queue Dynamics. Исчезновение объёма впереди из-за исполнения или отмен называют Queue Depletion, уменьшением очереди.

Но FIFO не является единственным правилом. При Pro-Rata Matching доступное исполнение распределяется между заявками в зависимости от их размера. Существуют гибридные алгоритмы, дополнительные приоритеты и специальные правила для отдельных участников. Поэтому модель очереди должна соответствовать конкретной площадке.

Есть и невидимая часть рынка. Hidden Liquidity означает ликвидность, которую публичный стакан не показывает полностью. Например, Iceberg Order, айсберг-заявка, может иметь общий объём 10 000, но показывать только 100. После исполнения видимой части появляется следующая. Порядок её приоритета зависит от биржевых правил.

Получается важная разница: "я стою по лучшей цене" не означает "я стою первым" и тем более не означает "меня обязательно исполнят".

Цена отвечает на вопрос "по сколько". Очередь отвечает на вопрос "дойдёт ли до нас дело".

4. Как заявкой объяснить бирже, чего мы хотим

Допустим, ABC нужен нам немедленно.

Можно отправить Market Order, рыночную заявку. Мы просим купить по доступным предложениям. Если на ближайшем Ask объёма мало, заявка может пройти по нескольким более дорогим уровням. Срочность повышается, но точная цена заранее не известна. Даже рыночная заявка не отменяет торговые остановки, защитные ограничения и другие правила площадки.

Другой вариант, Limit Order, лимитная заявка. Покупка с лимитом 100 означает: не покупать дороже 100. Продажа с лимитом 100 означает: не продавать дешевле 100. Цена ограничена, но исполнение не гарантировано.

При этом лимитная заявка необязательно будет ждать в стакане. Если Ask равен 99,98, покупка с лимитом 100 может исполниться сразу.

Stop Order, стоп-заявка, сначала ждёт условия активации. Например: когда выбранная биржей контрольная цена опустится до 95, активировать продажу. После активации это может быть рыночная или лимитная заявка в зависимости от типа. Поэтому стоп на 95 не гарантирует продажу по 95. Если рынок перескочил сразу к 90, доступная цена может оказаться намного хуже.

Кроме цены, заявке задают срок и способ исполнения.

При IOC, Immediate or Cancel, биржа исполняет то, что доступно немедленно, и отменяет остаток. Хотели купить 1000, нашли 600, получили 600.

При FOK, Fill or Kill, требуется весь объём немедленно. Если доступно только 600 из 1000, сделка не происходит.

GTC, Good Till Cancelled, оставляет заявку действовать до исполнения или отмены с учётом правил биржи. GTD, Good Till Date, задаёт конкретное время окончания. Day Order действует в пределах соответствующего торгового дня или сессии.

Эти условия называют инструкциями времени действия заявки. Они отвечают не на вопрос "выгодна ли сделка", а на вопрос "как долго и при каких условиях биржа должна пытаться её исполнить".

5. Дополнительные условия, которые меняют поведение заявки

Теперь предположим, что мы хотим именно ждать покупателя или продавца, а не исполняться немедленно.

Для этого существует Post-Only. Такая инструкция требует, чтобы заявка добавила ликвидность, а не сразу забрала чужую. Если цена пересекает встречную сторону, площадка может отклонить, отменить или изменить заявку по своим правилам. Поэтому точное поведение нужно читать в документации, а не выводить из названия.

Для закрытия позиции полезен Reduce-Only. Допустим, у нас куплено 10 контрактов, а программа отправила продажу 20. Без специального ограничения можно не только закрыть покупку, но и открыть продажу ещё на 10. Reduce-Only предназначен для того, чтобы заявка только уменьшала существующую позицию. Порядок обработки нескольких таких заявок тоже зависит от площадки.

Иногда цену заявки привязывают к рыночному ориентиру. Это Pegged Order. Например, заявка должна следовать за лучшим Bid с определённым отступом. Midpoint Order ориентируется на середину между Bid и Ask. На некоторых рынках такие заявки взаимодействуют со скрытой ликвидностью.

Hidden Order скрывает объём заявки от публичного отображения. Это не делает её невидимой для самой биржи и не гарантирует такой же приоритет, как у отображаемых заявок.

Когда нужно поменять цену или количество, используется Cancel/Replace либо предусмотренный площадкой механизм изменения. Важно знать, сохраняется ли очередь. Уменьшение объёма, увеличение объёма и изменение цены могут иметь разные последствия.

Если требуется убрать сразу много заявок, применяется Mass Cancel, массовая отмена.

Наконец, два наших алгоритма могут случайно выставить встречные заявки и заключить сделку друг с другом. Это Self-Trading. Механизм Self-Trade Prevention, STP, позволяет предотвращать такое сопоставление. Например, биржа отменяет одну из конфликтующих заявок. Какую именно, определяется настройкой и правилами.

У всех этих инструкций общий смысл: мы не просто называем цену, а уточняем, какое поведение биржи для нас допустимо.

6. Кто платит за срочность и откуда берутся торговые издержки

Участник, чья заявка добавляет доступную ликвидность, выступает как Maker. Участник, который её забирает, как Taker.

Отсюда различие между пассивными и агрессивными заявками. Пассивная ждёт встречного участника. Агрессивная взаимодействует с уже доступным встречным предложением.

Это не то же самое, что "лимитная против рыночной". Лимитная заявка тоже может быть агрессивной. Более того, часть одной заявки иногда исполняется немедленно, а остаток остаётся ждать.

Комиссии для maker и taker могут различаться. Иногда поставщик ликвидности получает Rebate, небольшое вознаграждение. Но отрицательная комиссия ещё не означает прибыльную сделку: можно получить выплату за исполнение и потерять намного больше на движении цены.

Теперь представим покупку 1000 ABC. Мы увидели Ask 100, но по этой цене доступно только 100 единиц. Остальные пришлось купить дороже. Разница между выбранным ориентиром и фактической ценой исполнения называется Slippage, проскальзыванием.

Здесь важно назвать ориентир. Проскальзывание относительно цены в момент решения и относительно цены в момент прибытия заявки отвечает на разные вопросы.

Наша торговля также может сама изменить рынок. Большая покупка съедает предложения продавцов, после чего цены становятся выше. Это связано с Price Impact и Market Impact. Термины употребляют с пересечением: иногда первым называют изменение цены от потока сделок, а вторым более широкий эффект собственной торговли, включая реакцию других участников. В исследовании нужно прямо определить принятую трактовку.

Комиссия является явным счётом биржи. Проскальзывание и влияние на рынок проявляются в том, какие цены нам действительно достались.

Поэтому покупка по Bid и продажа по Ask не превращают весь видимый спред в чистую прибыль.

7. Почему исполнение может быть плохой новостью

Мы выставили покупку по 99,99. Нас быстро исполнили. Через мгновение рынок оказался на 99,90.

Вроде бы исполнение успешное. Почему результат плохой?

Потому что момент исполнения выбирали не мы. Мы выбрали цену и согласились ждать. Встречный участник решил продать именно тогда, когда наша цена стала привлекательна для него.

Это Adverse Selection, неблагоприятный отбор исполнений.

Представьте 100 ситуаций. В 90 случаях после нашего сигнала цена растёт на 1 цент. В 10 случаях падает на 3 цента. Средний прогноз выглядит положительно:

(90 × 1 - 10 × 3) / 100 = 0,6 цента

Но наша лимитная покупка исполнилась только в 10 хороших случаях и во всех 10 плохих. Среди реальных исполнений результат уже другой:

(10 × 1 - 10 × 3) / 20 = -1 цент

Сигнал в среднем был полезным. Полученные нами сделки оказались убыточными.

Поток, против которого особенно опасно предоставлять ликвидность, называют Toxic Flow, токсичным потоком. Например, более быстрый участник видит новое движение на другой площадке и успевает продать в нашу устаревшую покупку.

Поэтому Fill Probability, вероятность исполнения, рассматривают вместе с Probability of Adverse Move, вероятностью неблагоприятного движения. Нас интересует не просто "исполнят ли заявку", а "что обычно происходит после исполнения именно таких заявок".

Причём исполнение может быть частичным. Заказали 1000, получили 120. Это Partial Fill. Оставшиеся 880 не следует считать ни купленными, ни автоматически отменёнными.

Хорошая модель прогнозирует не только рынок. Она учитывает, какие ситуации рынок разрешит нам реально наторговать.

8. Как проверить качество исполнения через Markout

Чтобы оценить исполнение, посмотрим, куда рынок ушёл после него.

Одна распространённая договорённость для Markout такая: после покупки сравниваем будущий Mid с ценой исполнения, после продажи наоборот. Положительное значение означает, что выбранный будущий ориентир оказался в нашу пользу.

Купили по 99,99. Через 100 миллисекунд Mid равен 100,02. Markout составляет +0,03.

Купили по 99,99. Через 100 миллисекунд Mid равен 99,96. Markout составляет -0,03.

Если измерять результат через 1, 10, 100 миллисекунд, секунду и дальше, получаются Markout Curves, кривые результата после исполнения. Они показывают, на каком горизонте наши сделки выглядят хорошими и когда начинает проявляться неблагоприятное движение.

Expected Markout является ожидаемым, средним markout для некоторого класса исполнений. Например, для покупок после определённого дисбаланса стакана.

Однако markout не равен зафиксированной прибыли. Мы могли оценить позицию по будущему Mid, но ещё не продали её. Для выхода могут понадобиться комиссия, ожидание или пересечение спреда.

Есть и важная бухгалтерская ловушка. Если мы купили по 99,99, текущий Mid был 100, а будущий стал 99,96, итоговый markout уже содержит первоначальное преимущество +0,01 и последующее движение -0,04.

Нельзя сначала взять этот итог -0,03, а затем ещё раз вычесть те же -0,04 как adverse selection.

То же касается Expected Value после комиссий. Нужно выбрать согласованный способ расчёта. Например, оценить вероятность исполнения, ожидаемый результат при исполнении и ещё не включённые издержки выхода. Нельзя складывать названия расходов так, чтобы один убыток учитывался дважды.

Удобная проверка: каждой вычитаемой величине должна соответствовать отдельная потеря, которой ещё нет в исходной оценке.

9. Заявка живёт дольше, чем вызов функции

В коде легко написать: "Отправили заявку, значит она стоит". Но между этими событиями несколько этапов.

Сначала заявка существует только в нашей программе. Потом сообщение отправлено. Затем оно может быть получено биржей, проверено, принято и исполнено полностью или частично.

Order Acknowledgement, ACK, подтверждает предусмотренный протоколом этап принятия. Это не обязательно исполнение. При быстром исполнении отдельное подтверждение ожидания в стакане вообще может не предшествовать сообщению о сделке.

Если заявка не прошла проверку, приходит отказ с Reject Code. Код объясняет причину: неправильный шаг цены, недостаток обеспечения, недопустимый тип заявки, превышение лимита сообщений и так далее.

Execution Reports сообщают о ходе обработки: принятии, частичных и полных исполнениях, отмене, отклонении, исправлении состояния.

Чтобы не запутаться, заявку представляют как конечный автомат, Order State Machine. Это набор состояний и допустимых переходов между ними. Например: создана, отправлена, подтверждена, частично исполнена, полностью исполнена.

Отмена добавляет отдельное состояние "отмена запрошена". Оно не равно "отменена".

Представим, что наш Cancel ещё едет, а встречная заявка уже исполнила оставшийся объём. Получается race между Fill и Cancel, гонка исполнения и отмены. Мы запросили отмену, но биржа раньше обработала сделку. Это нормальный возможный исход, а не обязательно ошибка биржи.

После отмены остатка также может поздно прийти сообщение о более раннем частичном исполнении. Поэтому "получили отмену" не означает "эта заявка никогда ничего не исполнила".

Команда описывает наше намерение. Отчёт биржи описывает то, что действительно произошло.

10. Потерянный ответ не означает потерянную заявку

Мы отправили покупку 100 ABC. Соединение оборвалось. Ответа нет.

Возможны разные истории: сообщение не дошло, заявка отклонена, заявка стоит, заявка частично исполнена или уже полностью исполнена. Это неопределённое состояние заявки, Unknown Order State.

Самое опасное решение: автоматически считать, что ничего не произошло, и купить ещё 100.

Для восстановления используют идентификаторы заявок, запросы открытых заявок, историю сделок и потоки отчётов. На институциональных площадках бывает Drop Copy, отдельный поток копий торговых сообщений для независимого контроля и учёта.

Но и сообщения нужно обрабатывать внимательно. Duplicate Fill означает повторное получение сведений об одном исполнении. Late Fill означает позднее сообщение о реальной сделке. Первое нельзя прибавлять к позиции повторно, второе нельзя выбрасывать только потому, что оно пришло поздно.

Нужна Reconciliation, сверка. Мы сравниваем собственный учёт заявок, сделок и позиций с данными площадки и других авторитетных систем учёта. Это не просто сравнение двух чисел: важны время снимка, полнота событий, последовательность и возможные исправления.

Если программа считает позицию равной 100, а биржа показывает 120, мы сначала выясняем, какой поток отстал и какие исполнения отсутствуют. Во время сбоя один отдельный снимок тоже может быть запаздывающим.

Отсюда практическое правило: пока истинное состояние неизвестно, нельзя продолжать увеличивать риск так, будто позиция точно известна.

11. Что именно биржа показывает в рыночных данных

Публичные данные бывают разной подробности.

Level 1, L1, обычно описывает вершину рынка: лучшие Bid и Ask, иногда последнюю сделку и связанные размеры.

Level 2, L2, даёт глубину по нескольким ценовым уровням. Мы видим, сколько суммарного объёма находится на каждой цене.

Level 3, L3, обычно обозначает более подробные данные об отдельных заявках. Но названия уровней не полностью унифицированы: всегда нужно смотреть состав конкретного потока.

Более точное различие дают Market-by-Price, MBP, и Market-by-Order, MBO. MBP сообщает: "На цене 100 стоит 5000". MBO позволяет увидеть отдельные заявки, из которых складывается этот объём. Это гораздо полезнее для исследования очереди. При этом скрытый объём и специальные правила всё равно могут ограничивать наблюдаемость.

Теперь о способе обновления.

Snapshot является снимком состояния. Биржа говорит: "Вот стакан на определённый момент".

Incremental Feed передаёт изменения. Но здесь есть тонкость: "инкрементальный" означает, что передаются изменения относительно прошлого состояния, а не обязательно числа, которые нужно прибавлять. Одно API сообщает новый абсолютный объём уровня, другое изменение объёма. Перепутать эти варианты означает неправильно собрать стакан.

Наша программа должна соединить снимок и последующие события по правилам протокола. Именно поэтому подписаться на поток ещё недостаточно: нужен корректный сборщик локальной книги.

12. Как доказать, что локальный стакан не выдуман

Пусть обновления пронумерованы: 1001, 1002, 1003, 1004. Эти номера называются Sequence Numbers.

Мы получили 1001, 1002 и 1004. Пропуск номера позволяет заметить Gap, разрыв последовательности. Его обнаружение называется Gap Detection.

В пропущенном сообщении могли удалить лучшую покупку. Если продолжить как обычно, наша программа будет показывать ликвидность, которой больше нет.

После разрыва нужен Feed Recovery, восстановление потока и состояния. В зависимости от биржи можно запросить пропущенные события, получить новый снимок или полностью повторить процедуру синхронизации.

Отдельная проблема, Out-of-Order Events, возникает, когда события приходят не в ожидаемом порядке. Это особенно важно при объединении нескольких соединений или параллельной обработке.

Дедупликация сделок и котировок убирает повторные сообщения. Но нельзя объявлять дублями любые одинаковые цены и объёмы. Две разные сделки могут иметь одинаковые значения. Нужны идентификаторы и правила конкретного потока.

Если есть два резервных источника одинаковых данных, требуется Feed Arbitration: выбрать корректный источник, распознать одинаковые события и переключиться без двойного применения или пропуска.

Наконец, сообщение может быть правильным, но старым. Это Stale Quote, устаревшая котировка. Открытое соединение не доказывает, что цены свежие.

Правильный стакан требует трёх вещей: полноты, правильного порядка и свежести. Проверять только наличие соединения недостаточно.

13. Почему время на бирже и время у нас не одно и то же

У события может быть несколько временных отметок.

Exchange Timestamp ставит биржа. Но важно знать, чему именно соответствует эта отметка: сопоставлению заявок, подготовке сообщения или другому этапу.

Receive Time показывает, когда сообщение получил наш сервер. Поэтому Exchange Time vs Receive Time является сравнением разных точек пути, а не двух взаимозаменяемых подписей.

Если биржа написала 12:00:00.001, а мы получили сообщение в 12:00:00.008, хочется назвать разницу сетевой задержкой 7 миллисекунд. Но это корректно только при достаточно согласованных часах и понятных точках измерения.

Clock Skew, расхождение часов, может полностью исказить картину. Один компьютер спешит на 5 миллисекунд, другой отстаёт на 3. Тогда события начинают выглядеть расположенными в неправильном порядке.

Точность формата тоже не равна точности измерения. Девять цифр после секунды ещё не доказывают наносекундную точность.

Для синхронизации применяют протоколы времени, например NTP и PTP. Для измерения длительности внутри процесса полезны монотонные часы: их показания не должны внезапно отступать назад после корректировки календарного времени.

Особенно важна Cross-Venue Data Alignment, согласование данных разных площадок. Нельзя просто соединить строки по ближайшему timestamp и считать, что мы доказали, какая биржа двигается первой. Нужно учитывать часы, сетевые пути, накопление сообщений и смысл временных отметок.

Иначе получится стратегия, которая зарабатывает не на запаздывании рынка, а на ошибке наших часов.

14. Почему одинаково выглядящие инструменты могут оказаться разными

Биржи называют поля и инструменты по-разному. Одна пишет bidPrice, другая best_bid, третья b.

Normalization рыночных данных, нормализация, приводит эти форматы к общей внутренней модели. Но хороший перевод сохраняет смысл, а не только переименовывает поля.

Например, количество может означать монеты, контракты или денежный номинал. Если сложить их как одинаковые величины, получится бессмысленная глубина рынка.

Symbol Mapping связывает биржевые обозначения с конкретными экономическими инструментами. BTC/USD, BTC/USDT, поставочный фьючерс и бессрочный контракт связаны с биткоином, но не являются одной и той же вещью.

Чтобы различать их, используются Instrument Reference Data, справочные данные инструмента. В них находятся шаг цены, шаг количества, множитель контракта, валюта расчёта, дата истечения, торговый статус и другие параметры.

Справочник тоже имеет историю. Сегодня контракт торгуется, завтра истёк. Сегодня шаг цены 0,01, позже другой. Исследование должно использовать параметры, действовавшие в рассматриваемый момент.

Это часть принципа Point-in-Time Data: знать не только значение, но и то, когда оно действительно было доступно и применимо.

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

15. Как данные добираются до программы: DNS, TCP и UDP

Прежде чем подключиться к бирже, программа должна найти сервер.

Человек использует имя вроде api.exchange.example, а сеть отправляет пакеты по адресам. DNS, Domain Name System, помогает преобразовать имя в нужные сетевые адреса. Ответы могут кэшироваться, адресов может быть несколько, а инфраструктура за именем может меняться.

Дальше начинается транспорт.

TCP предоставляет приложению упорядоченный поток байтов. Он обнаруживает потери и восстанавливает передачу. Но TCP не знает, где в этом потоке заканчивается одна ваша бизнес-команда и начинается следующая. Границы сообщений определяет протокол приложения.

Если потерян участок потока, последующие байты могут уже находиться на компьютере, но приложение не получит их до восстановления правильного порядка. Это одна из причин скачков задержки. При этом подтверждение TCP ещё не означает, что биржевая программа обработала заявку или записала её в надёжное хранилище.

UDP передаёт отдельные датаграммы без встроенной гарантии доставки и порядка. Потерю, повтор или перестановку должно учитывать приложение либо протокол поверх UDP.

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

TCP помогает восстановить байтовый поток. UDP оставляет больше контроля приложению. Ни один из них сам по себе не гарантирует правильное торговое состояние.

16. WebSocket, HTTP, gRPC и остальные способы общения

API является договором о том, как одна программа обращается к другой: какие команды существуют, какие поля передавать и что означает ответ.

При обычном HTTP-взаимодействии клиент отправляет запрос и получает ответ. Но обмен может быть организован по-разному.

WebSocket устанавливает постоянный канал с сообщениями в обе стороны. Сервер может отправлять обновления без нового запроса на каждое событие. При этом наличие WebSocket не заменяет биржевые правила восстановления стакана.

Long Polling работает иначе. Клиент отправляет запрос, сервер держит его открытым до появления данных или таймаута. После ответа клиент начинает следующий запрос. Это способ имитировать непрерывное получение событий через последовательность запросов.

Server-Sent Events, SSE, позволяют серверу передавать поток событий клиенту через HTTP. Направление такого потока в основном одностороннее. Например, так можно обновлять веб-панель состояния робота.

Webhooks решают другую задачу: внешний сервис сам обращается к нашему адресу после события. Например, система сборки сообщает, что новая версия готова. Получателю нужно учитывать повторы, подпись запроса и возможную задержку. Это не взаимозаменяемая замена каждому биржевому потоку.

HTTP/2 позволяет вести несколько потоков запросов внутри одного соединения. Но если используется TCP, потеря байтов может задерживать данные нескольких потоков на транспортном уровне.

HTTP/3 использует QUIC поверх UDP. Важно: это не означает отказ от надёжности. QUIC сам реализует надёжные потоки и другие механизмы. Независимость потоков уменьшает некоторые межпоточные задержки при потерях, но не отменяет перегрузку сети и ожидание недостающих данных внутри конкретного потока.

gRPC позволяет обращаться к удалённому сервису почти как к набору заранее описанных функций. Обычно используются строгие схемы сообщений и Protocol Buffers, компактный формат сериализации. Это удобно для взаимодействия собственных сервисов, но сетевой вызов всё равно остаётся сетевым вызовом: с задержками, отказами и неопределённым результатом при потере ответа.

17. Как не отдать торговый доступ вместе с сетевым трафиком

Когда между компьютером и сервером работает TLS, стороны устанавливают защищённое соединение. Оно помогает проверить сервер и защищает передаваемые данные от чтения и незаметного изменения по пути.

Это пример Encryption in Transit, шифрования данных при передаче. Но оно не защищает от всего. Если API-ключ уже лежит в открытом репозитории или заражён сам сервер, TLS не исправит ситуацию.

Поэтому отдельно существует Secrets Management, управление секретами.

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

Например, процесс записи рыночных данных не должен получать право выводить деньги. А торговому процессу может быть не нужен доступ к административным действиям аккаунта.

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

Практический вопрос здесь такой: если один компонент скомпрометирован, какие именно действия сможет выполнить злоумышленник?

Это гораздо полезнее общего заявления "у нас всё зашифровано".

18. Latency, Throughput и редкие задержки, которые портят всё

Представим путь реакции на событие.

Биржа изменила цену. Через 4 миллисекунды событие дошло до нас. Программа потратила 0,2 миллисекунды на обработку и решение. Ещё через 4 миллисекунды заявка добралась обратно. Затем биржа обработала её.

Первый участок относится к Feed Latency, задержке доставки рыночных данных. Обратный путь к Order Entry Latency, задержке доставки заявки. Внутренняя обработка на площадке к Exchange Processing Latency.

Общая Latency зависит от того, какие точки мы выбрали началом и концом измерения. Поэтому "задержка 8 миллисекунд" без описания измерения мало что говорит.

Throughput, пропускная способность, отвечает на другой вопрос: сколько событий система обрабатывает за единицу времени.

Можно быстро обрабатывать каждое событие, но получать их ещё быстрее. Тогда растёт очередь, а вместе с ней возраст реальных решений.

Среднее значение задержки тоже может обманывать. Допустим, большинство событий обрабатывается за 1 миллисекунду, а некоторые за 100. Для срочной отмены важны именно такие неприятные случаи.

P99 Latency является 99-м процентилем наблюдений. Примерно 99% измеренных задержек не превышают это значение. Это не максимальная задержка и не обещание, что каждый сотый запрос обязательно будет медленным.

Tail Latency, хвост задержек, описывает редкие медленные случаи. Его полезно смотреть отдельно во время всплесков нагрузки, новостей и восстановления соединений.

Пропускная способность отвечает "сколько успеем обработать". Задержка отвечает "насколько поздно отреагируем". Нужны обе характеристики.

19. Таймауты, повторные запросы и идемпотентность

Программа не может ждать ответа бесконечно. Timeout, таймаут, задаёт предел ожидания.

Но таймаут говорит только: "Мы не получили ожидаемый результат вовремя". Он не говорит: "Операция точно не выполнена".

Отсюда опасность Retries, повторных запросов. Повторить чтение справочника обычно проще, чем повторить создание новой покупки.

Безопасность повторов связана с Idempotency, идемпотентностью.

Команда "установить температуру 20 градусов" при повторе оставляет то же целевое состояние. Команда "повысить температуру на 5 градусов" каждый раз меняет его заново.

С заявками аналогично. Повтор команды "создать новую покупку 100" может создать ещё одну покупку. Поэтому API иногда принимает уникальный ключ операции и распознаёт повтор как обращение к уже начатому действию.

Однако Client Order ID сам по себе не гарантирует идемпотентность. Нужно знать, что обещает биржа: как долго помнит идентификатор, допускает ли повторное использование, что делает при одинаковом ID с другими параметрами и как отвечает на поздний повтор.

Если сервис недоступен, частые повторы могут дополнительно перегрузить его. Поэтому используют Exponential Backoff: пауза растёт, например 100, 200, 400, 800 миллисекунд. Часто добавляют случайное смещение паузы, чтобы тысячи клиентов не повторяли запрос одновременно.

Circuit Breaker идёт дальше. После серии неудач компонент временно перестаёт обращаться к неисправному сервису, затем осторожно проверяет восстановление. Это похоже на автомат, который размыкает проблемную цепь. В торговой системе отказ критического источника может дополнительно запрещать новые рискованные действия.

Но восстановление доступа и повтор старой сделки являются разными задачами. Сигнал мог исчезнуть, пока мы восстанавливали соединение.

20. Почему нельзя бесконечно переставлять заявки

Биржа ограничивает поток запросов. Это Rate Limiting.

Лимиты могут учитывать количество сообщений, их условный вес, конкретный метод API, аккаунт, соединение или инструмент. Поэтому "100 запросов" не всегда означает 100 любых действий.

Message Rate Limits ограничивают скорость отправки торговых сообщений. Если весь доступный бюджет потрачен на улучшение котировок, в критический момент может не остаться возможности быстро отменить заявки. Значит, планирование потока является частью безопасности.

Есть и отношения активности к результату.

Order-to-Trade Ratio сравнивает поток заявок или ордерных действий с количеством исполнений. Cancel-to-Trade Ratio сравнивает отмены со сделками. Точный состав числителя и знаменателя определяется правилами площадки.

Представим, что алгоритм отправил 10 000 изменений и получил 10 сделок. Это совсем другой профиль нагрузки, чем 100 изменений и 50 сделок.

При этом высокий коэффициент сам по себе ещё не объясняет намерение участника. Частые отмены могут быть нормальным управлением риском. Но площадка вправе ограничивать такую нагрузку по своим правилам.

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

21. Очереди сообщений, Pub/Sub и Backpressure

Представим, что одно рыночное событие нужно стратегии, риск-модулю, архиву и панели наблюдения.

Можно заставить источник по очереди ждать каждый компонент. Но тогда медленная панель начнёт тормозить торговлю.

Message Queue, очередь сообщений, разделяет отправку и обработку. Один компонент помещает событие, другой забирает его позже. Для надёжной работы важны подтверждения, повторная доставка, порядок и политика хранения.

Pub/Sub, Publish/Subscribe, описывает публикацию и подписку. Источник публикует событие, заинтересованные потребители его получают. Это не всегда означает, что все подписчики имеют одинаковую гарантию доставки или одинаковый порядок.

Когда система строится вокруг реакции на такие события, говорят об Event-Driven Architecture, событийной архитектуре. Пришёл Fill, обновили позицию. Потерян стакан, запретили новые котировки. Изменились параметры инструмента, обновили проверки.

Теперь возникает перегрузка: производитель быстрее потребителя.

Backpressure является не названием самой перегрузки, а механизмом обратного давления. Потребитель сообщает, что не успевает, и система ограничивает производство, передачу или приём данных.

С биржевым потоком не всегда можно попросить рынок двигаться медленнее. Тогда нужны ограниченные очереди, подходящая архитектура и заранее определённое поведение при отставании.

Но нельзя бездумно выбрасывать промежуточные изменения стакана. Если каждое необходимо для восстановления состояния, после пропуска книга становится недостоверной. Можно объединять уведомления о пересчёте после корректного применения всех событий или выбирать свежий полный снимок, если протокол это позволяет. Исполнения сделок тоже нельзя отбрасывать как "устаревшие".

Если сообщение многократно не обрабатывается, его могут отправить в Dead Letter Queue, DLQ. Это отдельное место для проблемных сообщений, которые были отклонены, просрочены или исчерпали допустимые попытки. DLQ не исправляет причину, но не даёт одному сообщению бесконечно блокировать основной поток.

22. Кэширование: как ускориться и не начать пользоваться прошлым

Caching, кэширование, означает сохранение данных или результата вычисления для повторного использования.

Например, шаг цены ABC редко меняется. Нет смысла получать его по сети перед каждой заявкой. Можно хранить локальную копию.

Но копия требует правил актуальности. Если биржа изменила шаг, а мы продолжаем использовать старое значение, кэш ускоряет неправильное решение.

Это проблема Cache Invalidation, признания кэша устаревшим.

Есть разные подходы. Обновлять после специального события, проверять версию, ограничивать срок хранения или периодически перечитывать источник. У каждого свой компромисс. Срок хранения в пять минут удобен, но означает, что до пяти минут система потенциально использует старое значение.

Теперь перенесём идею ближе к пользователю. Edge Caching хранит копии на пограничных серверах, расположенных ближе к получателю. CDN, Content Delivery Network, представляет распределённую сеть доставки контента, где такое кэширование помогает быстрее отдавать файлы и разгружать основной сервер.

Для сайта со статистикой это полезно. Для текущего состояния позиции опасно без специальной модели актуальности.

Поэтому вопрос не "использовать ли кэш". Вопрос: какое устаревание допустимо для этих конкретных данных?

Картинка интерфейса, справочник инструмента, последняя котировка и реальная позиция требуют разных ответов.

23. Балансировка, прокси и масштабирование

Допустим, система получает много запросов. Их можно распределить между несколькими серверами. Это Load Balancing, балансировка нагрузки.

Перед внутренними сервисами часто стоит Reverse Proxy, обратный прокси. Клиент обращается к нему, а он пересылает запрос подходящему внутреннему серверу. Он может завершать TLS-соединение, маршрутизировать и распределять нагрузку.

API Gateway обычно решает более широкий набор задач вокруг API: проверяет доступ, применяет лимиты, выбирает версию сервиса, собирает статистику. На практике возможности этих компонентов могут пересекаться.

Теперь про увеличение мощности.

Vertical Scaling, вертикальное масштабирование, усиливает одну машину: больше памяти, более подходящий процессор, быстрый диск.

Horizontal Scaling, горизонтальное масштабирование, добавляет машины или процессы. Например, разные группы инструментов обслуживают разные обработчики.

Autoscaling автоматически меняет число ресурсов в зависимости от нагрузки. Но новый процесс не получает готовый торговый контекст магически. Ему нужны данные, состояние, права владения инструментами и прогрев.

Поэтому HFT-компонент с очередью заявок и открытой позицией сложнее масштабировать, чем сервер, который просто отдаёт статический файл.

Здесь же появляется Cost Optimization, оптимизация расходов. Нужно сравнивать стоимость оборудования, сети и сопровождения с тем, сколько полезного результата даёт улучшение.

Если более дорогой сервер уменьшает задержку, но стратегия после этого не получает лучших сделок, техническое улучшение может не иметь экономической ценности.

Масштабировать нужно найденное ограничение, а не красивую архитектурную схему.

24. База данных: индексы, запросы и соединения

Допустим, после торгового дня нужно найти все исполнения заявки 123 среди сотен миллионов строк.

Без вспомогательной структуры база может просматривать огромный объём данных. Database Indexing, индексация, создаёт структуру для ускоренного поиска, сортировки или отбора.

Индекс похож на указатель в книге: вместо чтения всех страниц можно перейти к нужным. Но он занимает место и требует обновления при изменении данных. Поэтому индекс на каждое поле не является бесплатным ускорением.

Query Optimization, оптимизация запросов, начинается с вопроса, какую работу база действительно выполняет. Иногда проблема в отсутствии индекса, иногда в лишнем объединении таблиц, иногда в запросе всех строк вместо нужного диапазона.

Типичный неудачный шаблон, N+1 запросов. Сначала получаем список 100 заявок одним запросом. Затем отдельно читаем сведения об инструменте для каждой. Вместо нескольких обращений получается 101. Часто это можно заменить объединением данных или пакетным запросом.

Connection Pool, пул соединений, хранит заранее открытые подключения. Программа берёт подходящее соединение, выполняет работу и возвращает его. Это избавляет от постоянного открытия нового соединения, но слишком маленький пул создаёт ожидание, а слишком большой перегружает базу.

Read Replicas, реплики для чтения, позволяют вынести часть аналитической нагрузки на копии базы. Но реплика может отставать. Поэтому исторический отчёт и проверку только что исполненной заявки нельзя бездумно направлять на один и тот же запаздывающий источник.

25. Партиционирование, шардинг, репликация и изменения схемы

Большую таблицу можно разделить на части. Например, сделки за каждый месяц хранить в отдельной части общей таблицы. Это Partitioning, партиционирование.

Если нужен только вчерашний день, база может не читать остальные месяцы. Но полезность зависит от того, совпадает ли способ разделения с реальными запросами.

Sharding, шардинг, распределяет разные части данных между отдельными узлами. Например, инструменты первой группы находятся на сервере A, второй на B. Это увеличивает общую ёмкость, но усложняет запросы и операции, затрагивающие сразу несколько частей.

Replication, репликация, делает копии одних и тех же данных. Поэтому шардинг и репликация решают разные задачи: первый делит набор, вторая копирует его.

Теперь структура данных изменилась. Раньше у заявки была одна временная отметка, теперь отдельно нужны время отправки и время подтверждения.

Изменение структуры базы называется Database Migration, миграцией. Schema Versioning, версионирование схем, позволяет определить, какую структуру понимает конкретная программа.

Проблема особенно заметна при постепенном обновлении: старая версия ещё работает, новая уже пишет другое поле. Хорошая миграция учитывает временное сосуществование версий.

Например, сначала добавить новое поле так, чтобы старая программа продолжала работать. Затем обновить запись и чтение, перенести старые данные и только после этого удалить ненужную структуру.

Откат программы не возвращает автоматически прежнюю структуру и смысл уже записанных данных.

26. Когда несколько потоков одновременно меняют одно состояние

Представим позицию 100. Два потока одновременно получили исполнения по 10.

Оба прочитали 100, оба посчитали 110, оба записали 110. Правильный результат должен быть 120, но одно обновление потерялось.

Это Race Condition, состояние гонки: результат зависит от порядка операций, который программа не контролирует.

Thread Safety, потокобезопасность, означает, что компонент сохраняет корректность при допустимом конкурентном использовании.

Один подход, Pessimistic Locking, пессимистическая блокировка. Поток захватывает право работать с данными, остальные ждут.

Другой, Optimistic Locking, оптимистическая блокировка. Мы читаем значение вместе с версией и записываем результат только при условии, что версия не изменилась. Если другой поток уже обновил запись, нужно перечитать данные и пересчитать действие.

Блокировки тоже могут создать проблему. Поток A удерживает ресурс 1 и ждёт ресурс 2. Поток B удерживает ресурс 2 и ждёт ресурс 1. Это Deadlock, взаимная блокировка. Оба могут ждать бесконечно без вмешательства или механизма обнаружения.

Отдельно нужно управлять памятью.

Memory Leak, утечка памяти, возникает, когда память больше не нужна для полезной работы, но остаётся удерживаемой. Это возможно и в языках с автоматической очисткой, если ненужные объекты продолжают оставаться достижимыми.

Garbage Collection, сборка мусора, автоматически освобождает определённые неиспользуемые объекты. Но она сама потребляет ресурсы и может влиять на задержки. Поэтому в чувствительном пути измеряют не только скорость вычислений, но и частоту выделения памяти, работу сборщика и редкие паузы.

27. Несколько компьютеров: лидер, сетевое разделение и CAP

Теперь у нас не два потока, а два сервера. Оба способны отправлять заявки от одного счёта.

Чтобы они не действовали независимо, можно назначить одного активного владельца. Leader Election, выбор лидера, определяет, какой узел выполняет ведущую роль.

Но что произойдёт, если серверы живы, а связь между ними исчезла?

Это Network Partition, сетевое разделение. Его не следует путать с партиционированием таблицы. Здесь сеть разделила работающие узлы на части, которые не могут надёжно обмениваться информацией.

Каждая сторона может решить, что другая умерла. Если обе объявят себя лидером, получится два активных отправителя заявок.

Здесь полезна CAP-теорема. Во время такого разделения нельзя одновременно гарантировать строгую согласованность в смысле единого актуального порядка операций и доступность каждого запроса на работающих узлах.

Это не правило "из трёх букв всегда выбирай любые две". Существенна именно ситуация разделения и конкретные определения гарантий.

Eventual Consistency, согласованность в конечном счёте, допускает временные расхождения копий с последующим схождением при подходящих условиях. Для количества просмотров это может быть приемлемо. Для права отправить следующую заявку такого обещания может быть недостаточно.

Distributed Lock, распределённая блокировка, координирует владение между машинами. Но истечение блокировки в хранилище не останавливает старый процесс физически. Он мог зависнуть, затем проснуться и продолжить работу.

Поэтому иногда применяют fencing: каждое новое владение получает более новый номер, а принимающая сторона отвергает команды старого владельца. Но защита существует только там, где получатель действительно умеет её проверять.

Выбрать нового лидера недостаточно. Нужно ещё не позволить старому продолжать действовать.

28. Распределённая транзакция и Saga: почему сделку нельзя просто отменить назад

Представим перевод 100 между двумя внутренними счетами. Нужно списать с одного и зачислить другому. Нельзя навсегда выполнить только половину.

В одной базе это решается транзакцией: группа изменений подтверждается или отменяется как единое действие.

Distributed Transaction, распределённая транзакция, пытается согласовать подобное действие между несколькими системами. Например, через двухфазное подтверждение: сначала участники готовятся, затем получают решение зафиксировать результат. Это требует координации и может оставлять ресурсы ожидающими при отказах.

Saga предлагает другой подход. Большой процесс разбивается на последовательность локальных операций. Для уже выполненных шагов определяются компенсирующие действия.

Бытовой пример: забронировали гостиницу, затем не смогли купить билет. Компенсацией может быть отмена брони. Но штраф за отмену никуда не исчезает.

В торговле ограничение ещё заметнее. Мы купили ABC на одной площадке, но не смогли продать на другой. Компенсацией может быть новая продажа купленного объёма. Это не стирает первую сделку. Новая продажа происходит по текущей цене, может иметь комиссию и сама может не исполниться.

Поэтому Saga не даёт волшебного "отката рынка". Она организует процесс восстановления после частично выполненного действия. Компенсация тоже требует обработки ошибок.

Отмена записи в базе и экономическое закрытие исполненной позиции являются разными операциями.

29. Как менять программу, не превращая обновление в эксперимент на деньгах

CI/CD объединяет несколько этапов доставки кода.

Continuous Integration, непрерывная интеграция, регулярно проверяет совместимость изменений: проект собирается, запускаются тесты и автоматические проверки.

Continuous Delivery поддерживает версию в состоянии готовности к выпуску. Continuous Deployment дополнительно автоматизирует сам выпуск. Для торговой системы автоматизация не отменяет ограничений доступа и необходимых проверок.

Build Cache, кэш сборки, повторно использует результаты неизменившейся работы. Например, не пересобирает зависимость, исходники которой не менялись.

Но сначала надо правильно определить зависимости. Иначе кэш может подставить результат, собранный для другой конфигурации.

Dependency Hell возникает, когда библиотеки требуют несовместимые версии друг друга. Один компонент ждёт старый интерфейс, другой новый. Поэтому состав зависимостей должен быть воспроизводимым, а обновления проверяемыми.

Semantic Versioning, семантическое версионирование, предлагает формат вроде 2.4.1: крупный номер для несовместимых изменений публичного интерфейса, средний для совместимых возможностей, младший для совместимых исправлений. Но название версии не заменяет проверки того, как конкретный проект соблюдает эти правила.

API Versioning относится к изменению договора между программами. Если биржа заменила смысл поля количества, это может быть важнее, чем его название.

Infrastructure as Code, инфраструктура как код, описывает сервера, сеть и настройки воспроизводимыми файлами. Это помогает понять, что развернуто, восстановить окружение и проверять изменения. Но ошибочная конфигурация тоже становится воспроизводимой, поэтому ей нужны проверки.

30. Feature Flags, постепенный выпуск и реальный смысл отката

Представим, что новый алгоритм уже находится в программе, но пока выключен.

Feature Flag, флаг функции, позволяет включить его настройкой. Например, только для одного инструмента или только в режиме наблюдения.

Canary Release, канареечный выпуск, сначала отдаёт новой версии небольшую контролируемую часть работы. Мы сравниваем поведение, ошибки и риск до расширения.

Rolling Deployment, постепенное развёртывание, обновляет экземпляры по очереди, а не одновременно. Поэтому старые и новые версии должны уметь временно сосуществовать.

Rollback, откат, возвращает предыдущую версию или конфигурацию. Но он не отменяет совершённые сделки, отправленные сообщения и изменённые данные. После неудачного торгового выпуска иногда нужно сначала остановить риск и сверить состояние, а уже потом переключать код.

Новая версия также может начать с Cold Start, холодного старта. Ей ещё нужны полный стакан, история признаков, справочники, позиции и состояние заявок.

Для контроля существуют Health Checks, проверки здоровья. Однако важно разделять два вопроса.

Liveness-проба проверяет, жив ли процесс и не требуется ли его перезапустить. Readiness-проба проверяет, готов ли он обслуживать свою задачу. Живой процесс с несобранным стаканом может быть неготовым.

При этом readiness инфраструктуры не остановит исходящие торговые запросы автоматически. Сам робот должен явно запрещать торговлю, пока условия готовности не выполнены.

Фоновые операции по расписанию выполняют Cron-задачи. Например, ежедневную сверку или обновление справочников. Они должны учитывать повторный запуск, пропуск времени и длительность предыдущего выполнения. Само расписание не гарантирует выполнение ровно один раз.

31. Как видеть не только ошибку, но и её причину

Monitoring, мониторинг, следит за заранее выбранными показателями. Например, задержкой, памятью, состоянием соединений и размером позиции.

Metrics, метрики, являются числовыми измерениями. Они хорошо отвечают на вопросы "сколько", "как часто" и "насколько долго".

Logging, логирование, записывает конкретные события. Метрика покажет, что выросло число отказов. Лог поможет выяснить, какие заявки отклонялись и с какими причинами.

Distributed Tracing, распределённая трассировка, связывает этапы одной операции между компонентами. Можно увидеть путь от входного события через расчёт решения и риск-проверку до отправки заявки.

Вместе эти инструменты помогают добиться Observability, наблюдаемости: способности по доступным данным исследовать внутреннее поведение системы, в том числе отвечать на вопросы, которые заранее не были сформулированы.

Alerts, оповещения, сообщают о состоянии, которое требует внимания. Хорошее оповещение должно помогать действовать. Тысяча одинаковых сообщений "возможна проблема" быстро перестаёт быть полезной.

Для целей качества существуют SLI, SLO и Error Budget.

SLI, Service Level Indicator, является измеряемым показателем. Например, долей событий, обработанных быстрее двух миллисекунд.

SLO, Service Level Objective, задаёт цель: допустим, не менее 99,9% таких событий за выбранное окно.

Error Budget, бюджет ошибок, описывает допустимое отклонение от этой цели. Это не разрешение терять определённый процент капитала или создавать дубли сделок. Разные виды нарушений должны иметь разные ограничения.

Метрики показывают масштаб проблемы, события помогают восстановить историю, а наблюдаемость позволяет выяснить причину.

32. Что делать, когда система ломается в настоящей работе

Production является рабочим окружением, где происходят реальные действия. Production Incident, производственный инцидент, означает нарушение работы, требующее реакции.

Например, робот продолжает отправлять заявки, хотя рыночные данные устарели.

Сначала нужно ограничить ущерб. Только затем спокойно разбираться, какая строка кода виновата.

On-call, дежурство, означает заранее определённую ответственность за реакцию на такие ситуации. Нужны не только телефон и уведомления, но и понятные полномочия, инструкции и возможность передать проблему дальше.

Backup, резервная копия, позволяет восстановить данные. Но реплика не заменяет резервную копию: ошибочное удаление может быстро скопироваться на все реплики.

Disaster Recovery, аварийное восстановление, описывает возврат системы после серьёзной потери. Важно заранее знать, сколько данных допустимо потерять и как быстро нужно восстановить работу. План проверяется реальным восстановлением, а не существованием файла "backup".

Failover переключает работу на резервный компонент. В торговле резерв обязан восстановить права управления, заявки и позицию. Автоматический запуск с пустым состоянием может увеличить риск.

Multi-Region Deployment распределяет компоненты по географическим регионам. Это помогает переживать некоторые региональные отказы, но увеличивает сложность согласования и создаёт разные задержки до биржи.

Chaos Engineering проверяет устойчивость контролируемыми сбоями: обрывом соединения, задержкой ответа, остановкой процесса. Для торговой системы такие эксперименты сначала проводят там, где они не создадут неконтролируемого денежного риска.

Надёжность проверяется не тем, что система делает в хороший день, а тем, как она ограничивает ущерб в плохой.

33. Акции, облигации, валюты и деривативы: чем именно торгует робот

До сих пор ABC был абстрактным активом. Но реальные инструменты имеют разную экономику.

Акция представляет долю в компании. У неё есть корпоративные события, права владельца и возможные дивиденды. Облигация является долговым обязательством: её стоимость связана с платежами, сроками, процентными ставками и риском эмитента.

FX означает валютный рынок. Например, EUR/USD выражает цену одной валюты в другой. Здесь важны единицы котировки, способы расчёта и структура поставщиков ликвидности.

Криптоактивы также различаются по устройству и рискам. Даже когда два инструмента связаны с одной монетой, торговля самой монетой и контрактом на её цену не является одной операцией.

Индекс представляет расчётный показатель, построенный по определённой методике. Сам индекс обычно нельзя купить как физический предмет. Можно купить связанный фонд или дериватив.

ETF является биржевым фондом. Его доля связана с активами фонда и правилами его устройства. Цена доли на бирже и расчётная стоимость соответствующей части активов могут временно различаться.

Базовый актив, underlying, является тем, с чем связан контракт. Дериватив, derivative, получает стоимость из условий, относящихся к этому активу, индексу или другому ориентиру.

К деривативам относятся фьючерсы, опционы и perpetual futures, бессрочные контракты. Их нельзя считать просто другим названием монеты: у них свои обязательства, обеспечение и способы расчёта.

34. Фьючерс: размер контракта, срок и расчёты

Фьючерс задаёт стандартизованные обязательства по будущим расчётам. Его устройство описано в Contract Specifications, спецификации контракта.

Особенно важен Multiplier, множитель. Если одному пункту изменения цены соответствует 10 денежных единиц на контракт, движение на 5 пунктов даёт изменение результата 50 на один контракт. Ошибка в множителе напрямую превращается в ошибку позиции и риска.

У срочного контракта есть дата окончания, Expiration. Если нужно сохранить экономическую позицию после неё, участник переходит в следующий контракт. Это Futures Roll, перенос позиции между сроками. Обычно он требует закрытия старого и открытия нового контракта, поэтому имеет цены и издержки.

Settlement означает выполнение расчётных обязательств. При Physical Settlement может происходить поставка базового актива. При Cash Settlement рассчитывается денежная разница по установленной методике.

Для исследования часто строят Continuous Futures, непрерывную историю из нескольких последовательных контрактов. Но это аналитическая конструкция, а не один реальный инструмент, который торговался много лет.

Способ склейки имеет значение. Если контракты стоят по-разному, простой переход может создать скачок, которого не было в доходности удерживаемой позиции. Корректировка истории, в свою очередь, может изменить старые цены.

Поэтому для исполнения нужен реальный контракт с реальной ценой, а для исследования можно использовать специальную непрерывную серию, понимая её методику.

График непрерывного фьючерса и история реально совершимых сделок не являются одним и тем же набором данных.

35. Margin, Funding, Borrow и стоимость удержания

Для фьючерса обычно не требуется сразу платить всю стоимость базового актива. Но требуется Margin, обеспечение.

Initial Margin определяет необходимое обеспечение при открытии. Maintenance Margin задаёт уровень, который нужно поддерживать. Если средства становятся недостаточными, могут потребоваться дополнительные деньги, сокращение позиции или принудительное закрытие по правилам соответствующей системы.

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

У Perpetual Futures нет обычного срока истечения. Для связи цены контракта с ориентиром используется Funding Rate, ставка периодических платежей. При положительном финансировании часто платят держатели длинных позиций, но направление, формула и моменты платежей определяются конкретной площадкой.

Если мы продаём актив, которого у нас нет, на соответствующих рынках может понадобиться заимствование. Short Locate означает проверку или подтверждение доступности бумаги для заимствования по применимым правилам. Borrow относится к самому заимствованию и его стоимости. Доступность может исчезнуть, а плата вырасти.

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

Все доходы и расходы от удержания позиции объединяют понятием Carry. Сюда могут входить процентный доход, стоимость финансирования, заимствования, дивиденды и другие элементы.

Поэтому фраза "цена не изменилась" не означает "результат позиции равен нулю".

36. Basis, Term Structure и кривые доходности

Если ABC на споте стоит 100, а фьючерс на него 102, между ними есть разница. Это Basis, базис. Часто его считают как цену фьючерса минус спот, но знак и способ расчёта нужно заранее закрепить.

Разница не обязательно является бесплатной прибылью. Она может отражать стоимость капитала, доходы от владения активом, ограничения заимствования, срок и риск.

Interest Rates, процентные ставки, определяют стоимость денег во времени. Получить 100 сегодня и через год экономически не одно и то же.

Term Structure, временная структура, показывает зависимость показателя от срока. Например, фьючерс через месяц стоит 101, через три месяца 103, через полгода 104. Нас интересует не только каждая цена отдельно, но и форма всей зависимости.

Yield Curve, кривая доходности, показывает доходности по разным срокам для выбранного набора долговых инструментов или ставок. Она может подниматься, опускаться или иметь более сложную форму.

Представим стратегию, которая купила ближний контракт и продала дальний. Если весь рынок вырос одинаково, часть направленного движения может взаимно компенсироваться. Но изменение разницы между сроками останется.

Именно поэтому "мы захеджированы" не означает "мы ни от чего не зависим". Можно убрать часть риска общего движения цены и оставить риск базиса, сроков или ставок.

37. Опционы: почему у цены появляется несколько независимых причин двигаться

Опцион Call даёт покупателю право купить базовый актив по установленной цене. Put даёт право продать. Установленная цена называется страйком, а за право платят премию.

У продавца опциона возникает соответствующее обязательство, если выполнены условия исполнения. Поэтому купленный опцион и проданный опцион имеют принципиально разные профили риска.

Цена опциона зависит не только от текущего базового актива. Важны срок, страйк, ставки, выплаты по активу и оценка будущих колебаний.

Implied Volatility, подразумеваемая волатильность, получается, когда рыночную цену опциона переводят в параметр модели. Вопрос звучит так: "При какой волатильности эта модель дала бы наблюдаемую цену?"

Это не обещание того, насколько сильно рынок действительно будет двигаться.

Volatility Surface, поверхность волатильности, описывает, как подразумеваемая волатильность меняется по страйкам и срокам. Это уже не одно число "волатильность ABC", а целый набор взаимосвязанных оценок.

Для управления чувствительностями используют Greeks, греки. Они показывают, как модельная стоимость позиции меняется при небольших изменениях отдельных факторов, когда остальные условно фиксированы.

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

38. Delta, Gamma, Vega, Theta и Rho без магии

Начнём с Delta. Она показывает чувствительность стоимости к небольшому движению базового актива.

Допустим, дельта опциона равна 0,5 в выбранных единицах. При небольшом росте базового актива на 1 модельная стоимость опциона изменится примерно на 0,5 при прочих равных. Для позиции результат дополнительно учитывает число контрактов и множитель.

Но дельта сама меняется. Gamma показывает, насколько она чувствительна к движению базового актива. Если после роста дельта увеличилась с 0,5 до 0,6, наш прежний хедж уже не соответствует новой позиции.

Vega описывает чувствительность к подразумеваемой волатильности. Если рынок стал дороже оценивать будущие колебания, опционная позиция может изменить стоимость, даже когда базовый актив стоит на месте.

Theta описывает влияние течения времени при прочих равных. Право, которое заканчивается завтра, экономически отличается от права, которое будет действовать ещё год.

Rho показывает чувствительность к процентной ставке. Она особенно важна там, где стоимость будущих платежей заметно зависит от ставок и срока.

Для Vega, Theta и Rho критичны единицы: изменение на один процентный пункт, один день или один год не является одной и той же величиной. Перед сложением рисков нужно привести их к общей системе.

Греки не предсказывают рынок. Они показывают, какие изменения рынка повредят или помогут нашей позиции.

39. Put-Call Parity, Delta Hedging и Gamma Scalping

У цен связанных опционов существуют ограничения, следующие из их будущих выплат.

Put-Call Parity связывает европейские Call и Put с одинаковыми страйком и сроком, базовый актив и стоимость будущего платежа страйка. В упрощённом случае без дивидендов:

Call - Put = цена актива - текущая стоимость страйка

Почему? Потому что две определённые комбинации активов дают одинаковую выплату в конце срока. Если их цены сильно различаются, возникает возможность обменять одну комбинацию на другую, учитывая реальные издержки и ограничения.

Теперь Delta Hedging, хеджирование дельты. Если опционная позиция реагирует на маленькое движение цены примерно как покупка 100 ABC, можно продать около 100 ABC, чтобы уменьшить суммарную дельту.

Оставшаяся чувствительность называется Residual Delta, остаточной дельтой. Но даже нулевая дельта не убирает Gamma, Vega и остальные риски.

Gamma Scalping связан с повторным изменением такого хеджа. У позиции с положительной гаммой при росте цены дельта обычно увеличивается, и для возврата к нейтральности приходится продавать больше базового актива. При падении дельта уменьшается, и часть продажи выкупается.

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

Поэтому Volatility Trading торгует не только направление, но и относительную стоимость колебаний. А Options Market Making должен согласованно котировать множество опционов и управлять всеми этими чувствительностями, а не просто ставить два уровня цены.

40. Несколько площадок: локальный рынок, общий рынок и Last Look

Один актив может торговаться на нескольких площадках. Fragmentation ликвидности означает, что доступные предложения распределены между ними.

Локальный стакан показывает одну площадку. Консолидированный стакан объединяет несколько источников в выбранной модели.

Однако сложить объёмы одинаково названных инструментов недостаточно. Нужно учитывать валюту расчёта, комиссии, ограничения доступа, задержку, контрактные различия и то, доступен ли нам этот объём.

В американских акциях существует NBBO, National Best Bid and Offer, общерыночный ориентир лучших предложений по установленным правилам. SIP относится к инфраструктуре консолидации и распространения данных. Direct Feeds идут непосредственно от площадок и могут отличаться детализацией и путём доставки. Самодельная сводная цена криптобирж не становится от этого официальным NBBO.

Иногда консолидированный Bid равен Ask. Это Locked Market, закрытый спред. Если Bid выше Ask, получается Crossed Market, пересечённый рынок. Между площадками такая картина может отражать реальную краткую возможность, несинхронность или недоступность части котировок. В одном непрерывном стакане совместимые встречные заявки обычно должны сопоставляться, но специальные режимы требуют отдельного рассмотрения.

На некоторых FX-механизмах существует Last Look. После получения запроса поставщик ликвидности выполняет предусмотренную проверку и принимает или отклоняет исполнение. Это не универсальное свойство всех биржевых стаканов. Показанная цена и окончательно принятая сделка здесь требуют различения.

41. Где рождается цена: Price Discovery и Lead-Lag

Представим, что после новой информации сначала меняется площадка A, затем B.

Price Discovery, процесс формирования цены, описывает, как информация участников превращается в рыночную оценку. Некоторые площадки или инструменты могут в конкретных условиях участвовать в этом раньше других.

Lead-Lag означает временное опережение и запаздывание. Например, движение фьючерса статистически помогает предсказывать ближайшее изменение связанного спотового инструмента.

Если программа использует эту связь для торговли, это Lead-Lag Trading. Если источник находится на другой площадке, речь также идёт о Cross-Venue Signal. Если это другой актив, о Cross-Asset Signal.

Latency Arbitrage пытается использовать временно устаревшие цены до их обновления. Но видимое расхождение ещё не доказывает доступную прибыль.

Пока заявка добирается до площадки, цена может исчезнуть. На одной стороне исполнение произойдёт, на другой нет. Комиссии могут съесть разницу. А найденное запаздывание может оказаться ошибкой часов.

Поэтому исследование должно ответить на три разных вопроса: действительно ли один рынок раньше отражает информацию, доступна ли эта информация нашему процессу вовремя и остаются ли исполнимые цены после нашей задержки.

Это последовательность доказательств, а не один график с красивым сдвигом.

42. Сессии, аукционы и остановки торгов

Рынок не всегда находится в режиме непрерывного сопоставления.

Trading Calendar, торговый календарь, определяет рабочие дни, праздники и особые расписания. Trading Sessions и Trading Phases описывают сессии и фазы: предварительный сбор заявок, аукцион, непрерывные торги, закрытие.

Во время Opening Auction заявки сначала собираются, а затем сопоставляются по правилам определения цены открытия. Closing Auction помогает сформировать цену закрытия. Там нельзя автоматически применять модель исполнения из обычного непрерывного стакана.

Volatility Auction может включаться при необычном движении цены. Рынок получает время собрать новый набор заявок, прежде чем продолжить работу.

Trading Halt означает остановку торгов. Она может быть связана с новостями, технической ситуацией или установленными ограничениями.

Limit Up/Limit Down и связанные механизмы ценовых границ ограничивают торговлю вне определённых диапазонов. Конкретная реализация различается между рынками: где-то используются динамические диапазоны и паузы, где-то дневные пределы.

Все эти вещи относятся к правилам конкретной биржи, а не к универсальному абстрактному рынку.

Для робота календарь определяет допустимость действий. Для исследователя он определяет смысл данных. Отсутствие сделок в закрытую сессию нельзя считать доказательством спокойного ликвидного рынка.

43. Из каких наблюдений рождается сигнал

Чтобы проверить идею, нужны измеримые признаки.

Return, доходность, описывает изменение цены между моментами. Простой вариант:

Return = новая цена / старая цена - 1

Движение со 100 до 101 даёт 1%. Но горизонт обязателен: доходность за миллисекунду и за день имеет разный смысл.

Mid-Price Returns используют изменение середины Bid и Ask. Это помогает не путать движение рынка с чередованием сделок по покупке и продаже.

Momentum предполагает продолжение движения. Mean Reversion предполагает возврат отклонения к некоторому ориентиру. Short-Term Reversal относится к короткому обратному движению после локального импульса.

Эти идеи могут одновременно существовать на разных горизонтах. После покупки рынок может ещё 20 миллисекунд двигаться вверх, затем частично откатиться в течение секунды.

Short-Term Alpha означает прогнозируемую полезную составляющую изменения на коротком горизонте. Здесь alpha не обязательно равна привычной оценке доходности относительно рыночного индекса: смысл нужно задавать в исследовании.

У сигнала есть Signal Decay, затухание предсказательной силы. Информация постепенно отражается в цене и перестаёт давать преимущество.

Half-Life сигнала описывает время снижения эффекта примерно вдвое, если такой способ описания подходит. Но это не всегда то же самое, что время возврата отклонения к среднему.

Если модель говорит, что отклонение сокращается вдвое за секунду, это не означает, что полезность любой заявки по нему живёт ровно секунду.

Сигнал всегда должен иметь объект прогноза, горизонт и точку, относительно которой измеряется результат.

44. Order Flow, Trade Flow и три разных дисбаланса

Стакан можно изучать как фотографию или как фильм.

Order Flow показывает поступление, изменение и отмену заявок. Trade Flow показывает состоявшиеся сделки.

У сделки есть покупатель и продавец, поэтому фраза "объём покупок" без уточнения двусмысленна. Часто имеется в виду сторона агрессора: кто инициировал немедленное исполнение.

Signed Volume присваивает объёму знак. Например, агрессивной покупке плюс, агрессивной продаже минус. Если биржа не даёт сторону напрямую, её приходится оценивать, и такая классификация может ошибаться.

Trade Imbalance сравнивает агрессивные покупки и продажи за окно. Он описывает уже совершённые действия.

Queue Imbalance обычно сравнивает размеры очередей на лучших Bid и Ask. Order Book Imbalance может учитывать более широкую глубину и выбранные веса уровней.

Простой вариант дисбаланса:

(объём Bid - объём Ask) / (объём Bid + объём Ask)

При объёмах 900 и 100 получаем 0,8. Это сильная асимметрия выбранных объёмов, но не 80-процентная вероятность роста.

Order Flow Imbalance, OFI, оценивает направленный вклад изменений книги: добавления, отмены и исполнения на соответствующих сторонах. Он способен отличить два одинаковых текущих стакана, к которым рынок пришёл разными путями.

Например, сейчас по обе стороны стоит по 1000. Но в первом случае Bid вырос со 100, а Ask уменьшился с 5000. Во втором было наоборот.

Текущее равновесие объёмов и направление изменения ликвидности являются разными наблюдениями.

45. Microprice: как сдвинуть середину и не принять оценку за истину

Обычный Mid не учитывает размеры очередей. Поэтому используют более содержательные оценки.

Один простой вариант, взвешенная середина:

(Ask × объём Bid + Bid × объём Ask) / (объём Bid + объём Ask)

При Bid 99,99, Ask 100,01, объёме Bid 900 и объёме Ask 100 получаем 100,008.

Почему большой объём покупателей сдвигает оценку к Ask? В такой простой модели тонкую очередь продавцов легче исчерпать, чем толстую очередь покупателей.

Эту оценку часто называют microprice. Но важно не смешивать её со всеми моделями, использующими это название. В более строгих работах Microprice строится как оценка ожидаемой будущей средней цены с учётом переходов состояния стакана. Это не просто другое имя одной универсальной формулы.

Microprice Signal может измерять разницу такой оценки и текущего Mid. Например, модельная цена выше середины на 0,008.

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

Поэтому сначала задаём формулу или модель, затем проверяем, что её отклонения действительно предсказывают, на каком горизонте и после каких расходов.

46. Волатильность, интенсивность событий и Hawkes Processes

Для торговли важно не только направление, но и скорость изменений.

Volatility Estimation, оценка волатильности, измеряет масштаб колебаний. Realized Volatility строится по фактически наблюдавшимся изменениям, в отличие от подразумеваемой волатильности опционов.

На очень коротких горизонтах способ расчёта важен. Например, перескоки сделок между Bid и Ask могут создавать движение последней цены без соответствующего изменения середины рынка.

Теперь посмотрим не на размер движения, а на частоту событий.

Arrival Rate описывает интенсивность поступления: сколько заявок или сделок ожидается за единицу времени в заданных условиях.

Cancellation Intensity описывает интенсивность отмен. Если видимая глубина велика, но исчезает очень быстро, её устойчивость может быть низкой.

Hawkes Processes позволяют моделировать ситуации, где прошлые события временно увеличивают интенсивность следующих.

Представим базовый уровень две покупки в секунду. После крупной покупки модельная интенсивность на короткое время повышается до пяти событий в секунду, затем постепенно возвращается. Следующее событие может снова увеличить её.

Это не обещание, что за следующую секунду произойдёт ровно пять покупок. Речь об условной интенсивности случайного процесса.

В многомерной модели один поток может влиять на другой: например, сделки на интенсивность отмен. Но статистическая связь сама по себе не доказывает конкретную причинную историю.

Hawkes полезен там, где важна зависимость частоты событий от недавней истории. Он не заменяет корректные исходные данные и проверку торговой ценности.

47. Режимы рынка, Online Learning и калибровка вероятностей

Один и тот же сигнал может вести себя по-разному в разных условиях.

Volatility Regime описывает режим колебаний. Liquidity Regime состояние доступной ликвидности. Spread Regime характер ширины спреда.

Можно также различать Trending Market, рынок с продолжением движений, и Mean-Reverting Market, где выбранные отклонения чаще возвращаются на рассматриваемом горизонте.

Normal vs Stressed Market отделяет обычные условия от напряжённых, например с резким исчезновением ликвидности и ухудшением исполнения.

Regime Detection, определение режима, пытается распознавать такие состояния. Но оно тоже ошибается и запаздывает. Нельзя считать, что метка "спокойный рынок" автоматически делает риск безопасным.

Concept Drift означает изменение связи между признаками и прогнозируемым результатом. Вчера определённый дисбаланс был полезен, сегодня новые участники иначе реагируют на него.

Online Learning обновляет модель по мере поступления данных. Это помогает адаптации, но может и быстро испортить модель, если она обучается на ошибочном потоке или короткой аномалии.

Отдельно нужна калибровка вероятностей. Если модель много раз говорит "вероятность исполнения 80%", примерно соответствующая доля подобных прогнозов должна заканчиваться исполнением. Хорошее ранжирование ситуаций и честные численные вероятности не являются одним и тем же свойством.

Поэтому полезно проверять не только общую точность, но и соответствие прогнозов реальным частотам в разных режимах.

48. Маркет-мейкинг и управление накопленной позицией

Market Making, маркет-мейкинг, предполагает предоставление цен покупки и продажи с управлением возникающим риском.

Самая простая идея: купить по 99,99 и продать по 100,01. Но обе стороны не обязаны исполниться симметрично.

Если покупку исполнили пять раз, а продажу ни разу, у нас накопился Inventory, запас актива или позиция. Inventory Management управляет этим запасом, чтобы стратегия не превратилась из посредника в случайного направленного инвестора.

Spread Management выбирает ширину котировок. Узкий спред может увеличить число исполнений, но оставляет меньший запас на издержки и неблагоприятный отбор.

Reservation Price можно понимать как внутреннюю оценку цены, относительно которой нам сейчас разумно котировать с учётом риска и запаса. Если актив уже сильно накоплен, нам может быть выгоднее продавать его охотнее и покупать осторожнее.

Inventory Skew меняет котировки из-за позиции. Например, продажа становится ближе к рынку, покупка дальше.

Quote Skew является более общим смещением котировок. Причиной может быть не только запас, но и прогноз направления.

Dynamic Widening расширяет котировки при росте неопределённости, волатильности или риска исполнения.

Предоставление таких заявок относится к Liquidity Provision. Немедленное забирание чужой ликвидности к Liquidity Taking.

Rebate Capture пытается использовать выплаты за предоставление ликвидности. Но смысл появляется только тогда, когда выплата превышает связанные потери. Получать rebate на постоянно токсичных исполнениях невыгодно.

Маркет-мейкер управляет не двумя ценами, а обменом между вероятностью исполнения, доходом на сделку и риском накопленной позиции.

49. Статистический арбитраж и торговля относительной стоимостью

Statistical Arbitrage, статистический арбитраж, ищет воспроизводимые относительные отклонения. Несмотря на слово "арбитраж", такая стратегия может иметь существенный риск.

Relative-Value Trading, торговля относительной стоимостью, сравнивает связанные инструменты: какой из них дорог или дёшев относительно другого.

Pairs Trading, парная торговля, является частным примером. Допустим, два инструмента обычно связаны определённым соотношением. Один сильно вырос относительно другого. Стратегия продаёт относительно дорогой и покупает относительно дешёвый.

Но высокой корреляции цен недостаточно. Два актива могут часто двигаться в одну сторону и при этом не иметь устойчивого отклонения, которое возвращается к прежнему уровню.

Order Flow Prediction использует изменения заявок и сделок для прогноза ближайшего потока или цены. Такой прогноз может применяться и в пассивной, и в агрессивной торговле.

Event-Driven HFT реагирует на конкретные события: публикацию данных, изменение связанного рынка, обновление состава индекса. Это следует отличать от Event-Driven Architecture. Первая характеристика относится к торговой идее, вторая к устройству программы.

Auction Trading использует особенности аукционов: накопление заявок, ожидаемую цену сопоставления и дисбаланс. Здесь модель исполнения отличается от непрерывного рынка.

Все эти семейства могут пересекаться. Одна стратегия может быть одновременно событийной, относительной и основанной на опережающей площадке.

Но они не обязаны быть высокочастотными только потому, что используют знакомые HFT-термины.

50. Межбиржевой, фьючерсный, индексный и треугольный арбитраж

Начнём с Cross-Venue Arbitrage. На площадке A можно купить ABC по 100, на B продать по 101. Теоретическая разница равна 1.

Практически нужны деньги и активы на соответствующих площадках, доступ к исполнению обеих сторон и учёт расходов. Перевод актива после обнаружения возможности может оказаться слишком медленным.

Futures-Spot Arbitrage сравнивает срочный контракт и базовый актив на споте.

Cash-and-Carry является характерной конструкцией: купить актив и продать относительно дорогой фьючерс, удерживая позицию до подходящего момента или расчёта. Нужно учитывать финансирование, обеспечение, хранение или заимствование и условия поставки. Это может быть совсем не HFT по длительности удержания.

Basis Trading шире: стратегия торгует базисом и его изменением. Calendar Spread торгует разницей контрактов разных сроков. Можно почти убрать общую направленность и оставить риск изменения этой разницы.

Index Arbitrage сравнивает связанный с индексом инструмент и стоимость соответствующей корзины. ETF Arbitrage сравнивает цену доли фонда со стоимостью активов и экономикой доступных операций создания или погашения. Не каждый участник имеет одинаковый доступ к этим механизмам.

Triangular Arbitrage проверяет согласованность трёх курсов. Например, обмен из валюты A в B, затем в C и обратно в A должен после издержек давать экономически согласованный результат. Если нет, возникает потенциальная цепочка.

Но три положительно выглядящих обменных курса ещё не гарантируют прибыль: цены и доступный объём могут измениться между исполнениями.

Арбитражная идея является сравнением связанных выплат. Реализация всё равно несёт риск времени, ликвидности и неполного исполнения.

51. Как выбрать площадку и разбить большую задачу

Допустим, нужно купить 10 000 ABC. Одна большая заявка может дорого пройти по стакану.

Order Splitting разбивает задачу на части. Большую задачу называют родительской, а отдельные заявки Child Orders, дочерними.

Execution Scheduling решает, когда выпускать эти части. Можно растянуть исполнение во времени или ускориться при благоприятных условиях. При этом ожидание снижает непосредственное давление на рынок, но оставляет риск изменения цены.

Venue Selection выбирает площадку. Лучшая отображаемая цена не обязательно даёт лучший итог: различаются комиссии, объём, скорость, доступность и вероятность исполнения.

Smart Order Routing, SOR, автоматизирует выбор маршрута и распределение объёма между площадками.

Queue-Aware Execution учитывает положение в очереди. Например, наша старая заявка стоит почти первой. Новая цена выглядит немного лучше, но перестановка отправит нас в конец другой очереди.

Тогда нужно сравнить не только две цены, но и две вероятности исполнения, время ожидания и качество сделок, которые обычно достаются в этих состояниях.

Получается, исполнение не является механической командой после сигнала. Это отдельная задача оптимизации: как превратить нужную экономическую позицию в реальные сделки с приемлемыми издержками и риском.

52. Математическое ожидание, разброс и связь между величинами

Теперь проверим, есть ли у стратегии основание работать.

Математическое ожидание является средним результатом с учётом вероятностей. Если половина сделок приносит 2, а половина отнимает 1:

0,5 × 2 + 0,5 × (-1) = 0,5

Но среднее не показывает, насколько результат нестабилен.

Дисперсия, Variance, измеряет разброс относительно среднего через квадраты отклонений. Квадраты нужны, в частности, чтобы положительные и отрицательные отклонения не уничтожили друг друга. Стандартное отклонение возвращает меру разброса в исходные единицы.

Две стратегии могут иметь одинаковое ожидание. Одна почти всегда даёт около 0,5. Другая часто зарабатывает 10 и иногда теряет очень много. Для капитала это разные истории.

Ковариация показывает совместное изменение величин. Если два результата склонны одновременно быть выше своих средних, ковариация положительная.

Корреляция нормирует такую связь относительно разбросов. Но она описывает определённый вид зависимости и не доказывает причину.

Ложная корреляция может возникнуть случайно или из-за общего скрытого фактора. Две монеты могут одновременно расти потому, что движется весь рынок, а не потому, что одна надёжно предсказывает другую.

Поэтому полезный вопрос не "нашёл ли я красивую корреляцию", а "какую именно зависимость она показывает и сохранится ли она в новых условиях".

53. Условная вероятность и Байес на понятном примере

Обычная вероятность отвечает: "Как часто происходит возврат цены?"

Условная вероятность уточняет: "Как часто происходит возврат, когда мы видим конкретный сигнал?"

Это различие важно, потому что сигнал должен менять исходную оценку.

Представим 100 наблюдений. В 40 цена вернулась, в 60 не вернулась.

Некоторый признак появился в 30 случаях из 40 возвратов и в 12 случаях из 60 невозвратов.

Значит, признак появился 42 раза. Из них 30 закончились возвратом:

30 / 42 ≈ 71%

До учёта признака частота возврата составляла 40%. После наблюдения признака в этой выборке оценка стала около 71%.

Это понятная иллюстрация Bayesian Updating, байесовского обновления: исходное знание меняется с учётом того, насколько наблюдение характерно для разных вариантов.

Но нельзя просто произвольно повышать вероятность с 50 до 60, а затем до 80, потому что "сигнал выглядит сильным". Нужны исходные частоты и условные вероятности либо модель, которая их оценивает.

Также нельзя считать несколько почти одинаковых сигналов независимыми доказательствами. Если три признака получены из одного изменения стакана, они могут многократно пересказывать одну информацию.

Байесовское обновление не создаёт уверенность из воздуха. Оно связывает прежнюю оценку с доказательной силой новых данных.

54. Проверка гипотез и доверительные интервалы

Мы заметили: после определённого состояния стакана цена через 500 миллисекунд в среднем растёт.

Hypothesis Testing, проверка гипотез, спрашивает, насколько наблюдаемый результат совместим с заданной исходной гипотезой и моделью случайности. Например, с отсутствием среднего эффекта.

При этом маленький p-value не означает "вероятность того, что гипотеза неверна, равна 99%". Он оценивает, насколько необычны такие или более экстремальные данные при принятой нулевой гипотезе и предпосылках теста.

Confidence Interval, доверительный интервал, показывает неопределённость оценки через процедуру, которая при повторении экспериментов обладает заданным покрытием.

Если метод строит 95-процентные интервалы корректно, в длинной серии таких экспериментов около 95% интервалов будут накрывать истинный параметр. Это не то же самое, что без дополнительных оговорок приписать фиксированному параметру 95-процентную вероятность находиться в уже рассчитанном интервале.

Для практики смысл простой: оценка "средний эффект 2 bps" должна сопровождаться пониманием того, насколько точно мы её знаем и насколько уместны предпосылки расчёта.

Далее различаем Statistical Significance и Economic Significance.

Первое говорит о статистической убедительности эффекта в выбранной процедуре. Второе о его экономической значимости.

Если эффект составляет 0,05 bps, а минимальные реальные издержки 1 bp, очень уверенное обнаружение эффекта ещё не создаёт выгодную торговлю.

Нужно доказать не только существование отклонения от нуля, но и достаточный размер полезного результата после расходов.

55. Multiple Testing, Data Snooping и переобучение

Представим, что мы проверили одну идею и получили красивый результат.

Теперь другая история: мы проверили 20 000 комбинаций параметров и выбрали самую красивую.

Во втором случае положительный результат мог появиться просто из-за огромного числа попыток. Это проблема Multiple Testing, множественного тестирования.

Data Snooping возникает, когда исследователь снова и снова использует одни данные, адаптируя решение к увиденному. Даже без программной утечки человек постепенно подгоняет систему под историю.

P-Hacking означает подбор вариантов анализа, остановки эксперимента, фильтров или представления результатов ради получения формально убедительной статистики.

Overfitting, переобучение, описывает ситуацию, когда модель слишком хорошо выучила особенности и шум конкретной выборки.

Backtest Overfitting относится к этому эффекту в процессе выбора торговых стратегий и параметров. Мы можем создать систему, которая отлично описывает уже известную траекторию и плохо работает на новых данных.

Пример: сначала выбрали окно 100 миллисекунд, затем 120, затем 117. Убрали несколько плохих инструментов, исключили вторники, добавили ограничение по времени. Каждый шаг может выглядеть разумным. Но вместе они способны превратить случайную историю в "идеальную стратегию".

Защита начинается не с красивого показателя, а с дисциплины исследования: фиксировать попытки, причины изменений и действительно неиспользованные данные.

Чем больше вариантов мы посмотрели, тем меньше удивляет один выдающийся результат.

56. Selection Bias, Survivorship Bias и утечка будущего

Selection Bias, смещение отбора, возникает, когда исследуемая выборка систематически отличается от того мира, к которому мы хотим применить вывод.

Например, выбрали только дни, когда соединение работало идеально, а потом объявили результат оценкой всей торговой системы.

Survivorship Bias, ошибка выжившего, является частным случаем. Мы тестируем только сегодняшние живые инструменты и не учитываем те, которые исчезли, обесценились или были исключены из торгов.

Look-Ahead Bias означает использование информации, которой в момент решения ещё не было.

Feature Leakage, утечка в признаки, может быть менее заметной. Например, окно расчёта средней случайно захватывает будущие события. Или параметры нормализации рассчитаны по всей истории, включая тестовый период. Или итоговая исправленная запись используется так, будто исправление было известно сразу.

Здесь снова нужен Point-in-Time: когда наблюдение было известно и когда применялось.

Особая история, Corporate Actions, корпоративные действия. При дроблении акции два к одному цена условно меняется со 100 на 50, а количество акций удваивается. Это не обычный убыток владельца в 50%.

Но для исследования исполнения нельзя бездумно заменить реальные исторические цены будущими скорректированными значениями. Полезно отдельно хранить исходные торговые данные, события и правила корректировки.

Очистка ошибочных тиков тоже требует осторожности. Подозрительную цену нужно проверять, а не удалять все сильные движения. Иначе фильтр может выбросить настоящие кризисы и оставить только удобный рынок.

57. Нестационарность, автокорреляция и тяжёлые хвосты

Нестационарность означает изменение статистических свойств процесса со временем. Средний уровень активности, разброс, связи между инструментами и вероятность исполнения не обязаны быть постоянными.

Автокорреляция связывает ряд с собственным прошлым. Например, положительное изменение может чаще сопровождаться следующим положительным изменением. Но зависимость уровней цен, доходностей и абсолютных доходностей имеет разный смысл.

Гетероскедастичность означает непостоянный условный разброс. Рынок может долго быть спокойным, затем перейти в период сильных колебаний.

Fat Tails, тяжёлые хвосты, описывают более высокую частоту экстремальных наблюдений по сравнению с некоторыми привычными тонкохвостыми моделями, например нормальной. Нельзя автоматически переносить оценку редкости из удобного распределения на реальный рынок.

Extreme Value Theory, теория экстремальных значений, изучает поведение экстремумов и сильных превышений порогов. Она помогает сосредоточиться на хвосте, но всё равно требует предпосылок и достаточной информации. Мало наблюдений в самой опасной области означает большую неопределённость.

Bootstrap оценивает неопределённость повторным формированием выборок из имеющихся данных. Но случайное перемешивание отдельных торговых событий может разрушить временную зависимость. Поэтому для временных рядов используют подходящие блочные варианты.

И ещё ограничение: перестановка уже увиденных спокойных дней не создаёт автоматически кризис, которого в исходных данных не было.

Редкие убытки нельзя надёжно оценивать только тем, что они пока не встретились.

58. Walk-Forward, Purging, Embargo и честная проверка

Out-of-Sample Testing проверяет модель на данных, которые не участвовали в её построении и выборе.

Но если после каждого результата мы меняем модель и снова смотрим тот же тест, он постепенно становится частью разработки. Называть его "вневыборочным" уже недостаточно.

Walk-Forward Validation повторяет естественный ход времени. Обучаемся на прошлом, проверяем на следующем периоде, затем сдвигаемся вперёд. Так виднее, как стратегия переносит изменения рынка.

У финансовых примеров могут пересекаться интервалы результата. Сигнал в 12:00:00 оценивается по следующей секунде. Сигнал в 12:00:00.100 использует почти тот же будущий участок.

Если один попал в обучение, другой в проверку, возникает зависимость, которая способна завысить оценку.

Purged Cross-Validation удаляет из обучающей части наблюдения, чьи интервалы информации или меток конфликтуют с тестовой частью.

Embargo добавляет временной буфер, например исключая часть обучающих наблюдений сразу после тестового интервала в соответствующей схеме разбиения. Это снижает определённые виды утечки, но не исправляет неправильные признаки автоматически.

После истории полезны два режима.

Paper Trading имитирует сделки на текущем рынке без обычного реального исполнения. Качество зависит от модели исполнения.

Shadow Trading запускает стратегию рядом с реальной системой: она получает живые данные и выдаёт решения, но не отправляет настоящие торговые команды.

Оба режима помогают проверить работу на живом потоке. Ни один не доказывает, что реальная очередь и реальные исполнения будут такими же.

59. Реалистичный бэктест начинается с последовательности событий

Свеча сообщает максимум, минимум, начало и конец интервала. Но она не рассказывает, в каком порядке менялся стакан и когда могла исполниться наша заявка.

Event-Driven Simulation моделирует отдельные события. Tick-by-Tick Replay воспроизводит доступную историческую последовательность мелких рыночных обновлений.

Если история содержит снимок и изменения, нужна L2/L3-реконструкция стакана. Симулятор должен правильно восстановить книгу, а не опираться на уже испорченные уровни.

Затем требуется модель Matching Engine. Она учитывает правила приоритета и допустимого исполнения.

Самая известная ошибка выглядит так: поставили покупку по 100, историческая сделка прошла по 100, значит нас исполнили.

Но перед нами могли стоять 50 000 контрактов, а сделка была на 10.

Поэтому нужна модель позиции в очереди и её уменьшения, Queue Depletion. На L2 часто невозможно точно узнать, какая отмена произошла впереди, а какая позади. Тогда требуется явно обозначенная вероятностная или консервативная модель, а не ложная точность.

Partial Fill Simulation учитывает частичное исполнение. Если до нашей заявки дошло 20 единиц встречного объёма, нельзя считать исполненными все 1000.

Моделирование Cancel/Fill Race оставляет заявку активной до фактического момента обработки отмены. Решение стратегии убрать заявку не должно мгновенно стирать её из исторического рынка.

Касание цены является наблюдением рынка. Исполнение нашей заявки является отдельным событием, которое ещё нужно обосновать.

60. Задержки в симуляции и пределы исторического воспроизведения

Latency Model определяет, когда событие становится доступно роботу и когда его действие достигает биржи.

Если событие произошло в момент 0, а Feed Latency равна 5 миллисекундам, робот не может реагировать в момент 0.

После обработки добавляется Order Entry Latency, затем Exchange Processing Latency. За это время другие участники продолжают действовать.

Задержка может зависеть от нагрузки, типа сообщения и состояния сети. Постоянное число удобно как первый сценарий, но не обязательно описывает реальный хвост.

Нужно учитывать и реакцию других участников. Историческая запись показывает рынок без наших конкретных новых заявок. Если мы добавили крупный объём, другие алгоритмы могли бы изменить поведение. Обычный replay не умеет восстановить эту альтернативную историю точно.

Market Impact Model и Slippage Model приближают соответствующие эффекты. Но их предположения нужно проверять, а не считать любой результат симулятора фактом.

Реалистичная симуляция также учитывает комиссии и rebates, минимальный шаг цены, ограничения типов заявок, торговые паузы, аукционы и действовавшие правила площадки. Delisted и expired instruments, удалённые и истёкшие инструменты, не должны исчезать из прошлого только потому, что их нет сегодня.

Deterministic Replay, детерминированное воспроизведение, означает одинаковый результат при одинаковом входе, конфигурации и заданных источниках случайности. Это необходимо для нормального расследования расхождений.

Но одинаковый результат двух запусков не доказывает правильность модели.

Поэтому отдельно изучают расхождение backtest, simulation и production: какие исполнения, задержки и расходы отличились и почему.

61. Как считать прибыль и не вычесть один расход дважды

P&L, Profit and Loss, означает финансовый результат.

Gross P&L обычно показывает результат до определённых расходов. Net P&L после них. Но набор включённых расходов нужно прямо перечислять.

Представим, что мы купили 100 ABC по 99,99 и продали по 100,01. Результат движения денежных средств от цен:

100 × (100,01 - 99,99) = 2

Если комиссии за обе стороны составили 0,8, остаётся 1,2 до других расходов.

Если реальные цены исполнения уже использованы, нельзя ещё раз вычесть из этого результата то же проскальзывание, которое ухудшило эти цены. Его можно отдельно показать в аналитике относительно другого ориентира, но не повторно списать деньги.

Realized P&L относится к результату закрытой части позиции. Unrealized P&L к оценке ещё открытой. Конкретный учёт зависит от выбранного метода сопоставления покупок и продаж.

Если мы купили, но ещё не продали, результат зависит от цены переоценки. Mid удобен для сравнения, но крупную позицию нельзя обязательно закрыть по Mid.

Spread Capture оценивает, насколько стратегия получает выгоду от размещения по разные стороны рынка. Но для незавершённой пары сделок нужно быть осторожным: покупка по Bid ещё не гарантирует будущую продажу по Ask.

Funding, borrow, rebates и другие платежи должны попадать в согласованный учёт.

Финансовый результат сначала считается по реальным сделкам и денежным потокам. Объясняющие модели строятся уже поверх него.

62. Fill Rate, Win Rate, Sharpe и остальные показатели результата

Fill Rate показывает долю исполнений, но знаменатель нужно определить. Доля исполненных заявок и доля исполненного объёма могут сильно различаться.

Hit Rate ещё менее однозначен. В одной команде так называют долю правильных прогнозов, в другой успешных торговых попыток. Поэтому рядом с числом должно стоять определение.

Win Rate показывает долю прибыльных сделок или завершённых торговых эпизодов. Но 90 маленьких выигрышей и 10 огромных проигрышей могут дать высокий Win Rate и общий убыток.

Profit Factor делит сумму положительных результатов на абсолютную сумму отрицательных зафиксированных результатов в выбранном учёте.

Sharpe Ratio сравнивает средний избыточный результат с его стандартным отклонением. Он полезен для оценки доходности относительно изменчивости, но не полностью описывает хвостовые риски. Пересчёт на год требует внимания к зависимости наблюдений, а не механического умножения любого числа на корень из количества интервалов.

Sortino Ratio использует меру отрицательных отклонений относительно выбранного целевого результата. Нужно понимать, какой порог принят.

Maximum Drawdown показывает максимальное падение капитала от предыдущего пика. Если капитал вырос до 120, затем упал до 90, просадка от пика составляет 30, или 25%.

Turnover, оборот, показывает объём торговли, часто относительно капитала. Но и здесь бывают разные определения.

Capacity описывает масштаб, после которого добавление капитала или объёма заметно ухудшает стратегию. Capital Efficiency оценивает результат относительно задействованного капитала.

Margin Usage показывает использование обеспечения. Inventory Distribution распределение накопленных позиций, включая редкие крайние значения. Holding Time продолжительность удержания позиции.

Ни один из этих показателей не заменяет остальные. Высокая доходность при неизвестных хвостах позиции может быть опаснее умеренной, но понятной системы.

63. P&L Attribution: за счёт чего именно получились деньги

Общий результат полезно разложить. Это P&L Attribution, объяснение источников прибыли и убытка.

Alpha P&L относят к полезному прогнозу направления. Spread P&L к получению выгодных цен по обе стороны рынка. Inventory P&L к переоценке накопленного запаса.

Hedge P&L показывает результат хеджирующих сделок. Fee и Rebate P&L отдельно учитывают комиссии и выплаты.

Но эти категории не возникают автоматически из биржевой выписки. Их нужно определить через согласованные ориентиры и правила. Например, прибыль от удержания актива после сигнала можно одновременно назвать alpha и inventory, если не разделить расчёт.

Adverse Selection Cost оценивает ухудшение из-за неблагоприятного отбора исполнений. Latency Cost пытается измерить, насколько результат ухудшился из-за задержки. Последнее обычно требует сравнения с модельным вариантом, потому что в реальности мы не можем одновременно прожить одну сделку с двумя задержками.

Opportunity Cost, стоимость упущенной возможности, описывает не полученный потенциальный результат. Например, сигнал был, но лимит риска не позволил торговать. Это не фактическое списание со счёта и зависит от того, насколько реалистична альтернативная сделка.

Затем результат раскладывают по площадкам, инструментам и режимам. Общие +10 могут скрывать +100 на одном рынке и -90 на другом.

Атрибуция нужна не для красивых названий прибыли, а чтобы понять, какое конкретное решение улучшать.

64. Ограничения риска должны учитывать ещё не исполненные заявки

Position Limits ограничивают количество актива или контрактов. Notional Limits ограничивают денежный номинал. Exposure Limits учитывают экономическую чувствительность, которая может складываться из нескольких связанных инструментов.

Order Size Limits ограничивают одну заявку. Fat-Finger Controls ловят очевидные ошибочные размеры и цены. Price Collars запрещают заявки слишком далеко от выбранного ориентира.

Message Rate Limits защищают от чрезмерного потока команд. Inventory Limits ограничивают накопленный запас стратегии.

Maximum Loss Limit останавливает работу при достижении заданного убытка. Intraday Drawdown Limit ограничивает падение от внутридневного пика.

Но проверять только уже исполненную позицию недостаточно.

Пусть позиция равна +20. Ещё стоит покупка 50 и продажа 30. Если исполнится только покупка, получим +70. Если только продажа, -10. Поэтому нужно оценивать возможные будущие состояния, а не просто видеть текущие +20.

Неопределённые и находящиеся в пути заявки тоже могут исполниться. Их нельзя считать нулевыми, пока не доказано обратное.

Pre-Trade Risk Checks выполняют такие проверки до отправки. Kill Switch запрещает новые действия и запускает предусмотренную процедуру отмены или ограничения риска.

Cancel-on-Disconnect позволяет площадке отменять связанные заявки при потере соединения, если такая функция поддерживается. Но она не отменяет уже произошедшие исполнения.

Проверки, контроль изменений и возможность остановки являются частью управления алгоритмической торговлей, а не необязательным дополнением.

65. Почему даже захеджированная позиция остаётся рискованной

Concentration Risk возникает, когда слишком большая доля риска сосредоточена в одном активе, факторе или месте хранения средств.

Basis Risk остаётся, когда хеджирующий инструмент движется не точно так же, как исходная позиция. Hedge Risk дополнительно включает проблемы самого хеджирования: отказ, частичное исполнение, задержку и изменение доступности.

Correlation Risk появляется, когда связь, на которой построен хедж, меняется. То, что два актива раньше двигались вместе, не гарантирует такой же связи во время кризиса.

Для опционов остаются Residual Delta и риски Gamma, Vega, Theta, Rho. Уменьшить один фактор не означает убрать все.

Liquidity Risk связан с невозможностью быстро изменить позицию по приемлемой цене. Gap Risk с перескоком цены через уровни, где мы надеялись исполниться.

Overnight Risk описывает риск удержания через периоды ограниченного контроля, закрытия рынка или накопления новой информации. Даже на круглосуточной площадке команда и связанные рынки не обязательно доступны одинаково всё время.

Event Risk относится к новостям и другим событиям, резко меняющим условия.

Model Risk означает ошибку самой модели или её применения. Execution Risk ситуацию, когда экономическая идея не реализуется из-за исполнения. Например, одна сторона парной сделки прошла, другая нет.

Venue Risk относится к работе площадки. Counterparty Risk к невыполнению обязательств другой стороной. Clearing Risk к проблемам процесса определения и обеспечения обязательств после заключения сделок.

Margin Risk связан с нехваткой обеспечения. Liquidation Risk с принудительным закрытием, которое может произойти в особенно плохих условиях.

Эти риски могут усиливать друг друга. Например, падение цены повышает требования к обеспечению именно тогда, когда ликвидность для выхода исчезает.

66. Независимый риск-контроль, стресс-тесты и неизвестная позиция

Real-Time P&L обновляет оценку результата по текущим сделкам и рынку. Real-Time Greeks пересчитывает чувствительности опционной позиции по мере изменения факторов.

Но быстрый расчёт не полезен, если входное состояние неправильное.

Поэтому Independent Risk State означает достаточно независимый учёт риска. Стратегия не должна быть единственным источником ответа на вопрос, сколько она уже купила. Риск-модуль может отдельно учитывать исполнения, открытые заявки и данные сверки.

Если стратегия не знает настоящую позицию, нельзя автоматически "закрыть всё" по предположению. Неправильная закрывающая заявка способна открыть новый риск.

Сначала ограничивают новые риск-увеличивающие действия, выясняют статус заявок и восстанавливают учёт. Конкретная аварийная процедура должна быть заранее определена.

Stress Testing проверяет неблагоприятные условия: резкое движение, исчезновение глубины, рост задержки, недоступность хеджа.

Scenario Analysis рассматривает конкретные совместные сценарии. Например: ведущая площадка перестала обновляться, локальная продолжает торговать, отмены задерживаются, а обеспечение уменьшается.

Нужно проверять не только максимальный убыток по формуле, но и последовательность действий системы: что она заметит, что остановит и какие заявки ещё могут исполниться.

Безопасное поведение при неизвестном состоянии должно быть частью проекта до первой такой ситуации, а не решением в момент паники.

67. Сезонность, конкуренты и исчезновение преимущества

Активность рынка меняется во времени.

Open, Close и Lunch Effects описывают особенности открытия, закрытия и менее активных промежутков. Intraday Seasonality является более общей внутридневной сезонностью.

Expiration Effects возникают вокруг истечения контрактов. Month-End и Quarter-End Effects связаны с концом месяца и квартала. Index Rebalancing меняет состав или веса индекса и может создавать связанные потоки сделок.

Futures Roll переносит ликвидность между сроками. Earnings и другие Corporate Events меняют информацию о компаниях. Новости и макрособытия способны резко изменить и цену, и качество исполнения.

Но робот конкурирует не с календарём, а с другими участниками.

Поведение конкурирующих маркет-мейкеров влияет на спред, доступную глубину и скорость отмен. Queue Wars описывает борьбу за выгодное место в очереди.

Quote Stuffing употребляют для описания чрезмерного потока котировок и отмен, часто в контексте подозрительного поведения. Однако высокая активность сама по себе не доказывает манипуляцию.

Spoofing и Layering относятся к созданию вводящей в заблуждение картины спроса или предложения с использованием заявок и их размещения по уровням. Существенны намерение, поведение и применимые правила. Обычная отмена из-за изменившегося риска не равна автоматически spoofing.

Наши заявки тоже меняют поведение рынка. Это стратегическая реакция на собственные заявки. Конкуренты могут начать раньше занимать очередь или иначе котировать.

Alpha Decay после запуска означает ослабление преимущества после начала реальной работы. Crowding возникает, когда много участников используют похожую идею. При увеличении объёма проявляются Capacity Limits, ограничения масштаба.

Поэтому прибыльная история не является обещанием бессрочной прибыли после запуска.

68. Сделка исполнена. Почему работа ещё не закончилась

После Fill начинается Post-Trade, обработка совершённой сделки.

Trade Capture надёжно фиксирует её экономические параметры: инструмент, стороны, цену, количество, время, идентификаторы и связанные счета.

Clearing, клиринг, определяет обязательства сторон и применяет соответствующие механизмы их учёта и обеспечения. Settlement, расчёты, выполняет предусмотренное перемещение денег, активов или денежных разниц.

Это не всегда происходит в тот же момент, когда стратегия увидела исполнение.

Большая сделка может относиться к нескольким портфелям. Allocations распределяют её между ними. Например, из покупки 1000 единиц 600 предназначены одному счёту, 400 другому.

Confirmations подтверждают согласованные детали сделки. В институциональном процессе могут дополнительно выполняться сопоставление и подтверждение сторонами, чтобы расхождения были найдены до расчётов.

Give-Up означает передачу сделки для клиринга или учёта другой соответствующей организации по установленным соглашениям. Например, исполнение организовал один брокер, а клиринговое обслуживание выполняет другой.

Смысл этого блока простой: "сделка произошла" ещё не означает, что все участники одинаково записали её, правильно распределили и окончательно рассчитались.

69. Сверка позиций, денег, комиссий и исправленных сделок

Position Reconciliation сравнивает позиции разных систем. Cash Reconciliation денежные остатки и движения. Fee Reconciliation начисленные комиссии, rebates и другие сборы.

Представим, что количество ABC совпадает, но денежный остаток нет. Причина может быть не в потерянной сделке, а в комиссии, финансировании или корректировке. Поэтому одной проверки позиции недостаточно.

Exchange Busts означают аннулирование сделок по предусмотренным правилам. Corrections исправляют их параметры. Broken Trades обычно обозначают отменённые или признанные недействительными сделки, но конкретную терминологию нужно сверять с площадкой.

Late Trades поступают в учёт с задержкой. Их нельзя автоматически относить к моменту получения, если экономически они относятся к более раннему времени.

В системе должны быть правила изменения ранее учтённого результата. Если сделку отменили, нужно корректно изменить позицию, деньги, комиссии и связанные отчёты. Просто удалить строку из одного журнала недостаточно.

Corporate Actions Processing применяет дробления, выплаты и другие корпоративные действия к позициям и учёту.

Funding и Borrow Costs отражают финансирование и заимствование. Margin Calls требуют дополнительного обеспечения или иных действий при его нехватке.

End-of-Day Positions фиксируют состояние на конец выбранного расчётного периода. На круглосуточном рынке это всё равно может быть необходимая бухгалтерская граница.

Сверка нужна не потому, что мы заранее не доверяем одной стороне. Она нужна потому, что разные процессы видят события в разное время и могут ошибаться по-разному.

70. Audit Trail, отчётность и возможность объяснить каждую заявку

Books and Records являются системой необходимых записей: заявок, сделок, позиций, денег и изменений.

Audit Trail, проверяемая история действий, связывает их в последовательность.

Для конкретной заявки полезно восстановить, какие данные получила программа, какое состояние построила, какую версию модели использовала, какое решение приняла, какие проверки риска прошла и что ответила площадка.

Это не означает, что на каждое событие нужно синхронно писать огромный текстовый лог. Нужна достаточная и надёжная информация с приемлемой стоимостью записи.

Clock и Timestamp Requirements относятся к требованиям точности, согласования и сохранения времени. Конкретные нормативные требования зависят от рынка и статуса участника. Формат с большим числом знаков не заменяет проверенную точность.

Регуляторная отчётность передаёт предусмотренные сведения соответствующим органам. Что именно, когда и в каком формате, определяется применимыми правилами, а не универсальным списком HFT-терминов.

Market Abuse Surveillance ищет подозрительное поведение: манипулятивные заявки, сделки с самим собой, необычные последовательности действий и другие признаки возможного злоупотребления.

Для разработчика практический смысл шире формальной отчётности. Без нормальной истории невозможно уверенно отличить ошибку модели, задержку, неправильный стакан и потерянное исполнение.

Если мы не можем восстановить, почему появилась позиция, мы пока не полностью управляем системой.

71. Соберём весь путь на одном примере

Теперь вернёмся к ABC.

Локальная площадка показывает Bid 99,99 и Ask 100,01. Модель замечает состояние, после которого исторически наблюдалось небольшое движение вверх.

Первый вопрос: правильно ли собран стакан? Последовательность целая, восстановление не требуется, данные достаточно свежие.

Второй: что именно предсказывает модель? Не абстрактный "рост", а изменение выбранного ориентира на определённом горизонте.

Третий: останется ли эффект после нашей задержки? Если информация отражается в цене быстрее, чем мы можем действовать, правильный прогноз бесполезен.

Четвёртый: как мы собираемся получить сделку? Пассивная покупка требует оценки очереди и качества условных исполнений. Агрессивная требует доступного объёма и учёта цены срочности.

Пятый: положителен ли ожидаемый результат после тех издержек, которые ещё не включены в расчёт? Не вычитаем adverse selection повторно, если он уже отражён в ожидаемом markout.

Шестой: допустим ли риск? Учитываем не только текущую позицию, но и открытые, находящиеся в пути и неопределённые заявки.

После отправки не объявляем заявку исполненной заранее. Обрабатываем подтверждения, частичные исполнения, отмены и поздние сообщения по правилам состояния.

Затем сверяем фактические сделки и деньги, оцениваем результат и сравниваем реальность с моделью. Если исполнения систематически хуже симуляции, не объясняем это "неудачным днём", пока не разобрались в причине.

Вот ради этой последовательности и существует весь большой набор терминов.

Не ради того, чтобы поставить между двумя лимитками максимальное количество технологий. И не ради обещания, что достаточно выучить словарь и рынок начнёт платить.

Стакан объясняет, что доступно. Сеть и программа определяют, когда мы это увидим. Модель оценивает смысл. Исполнение превращает решение в сделку. Риск ограничивает последствия. Учёт показывает, что получилось на самом деле.

Когда эти части согласованы, можно обсуждать улучшение стратегии. Когда нет, даже очень умная формула может торговать неправильными данными, получать вымышленные исполнения в тесте и терять реальные деньги по причинам, которых разработчик пока не видит.