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

Естественно, всё это хорошо автоматизировано уже очень давно, но проблемы случаются. Рассмотрим конкретно ИТ-риски в процессе.

Участок от вас до брокера

Раньше этот участок выглядел очень просто. Вы набирали номер брокера и говорили ему: «Покупай яблоки!». Он спускал задачу орать на торговый этаж и таким образом покупал вам акции компании Apple (на самом деле нет, Apple тогда на бирже не было). Если вместо вас ему звонил злоумышленник, а брокер выполнял его поручение – это безусловный его косяк, проистекающий из отсутствия авторизации пользователя (вас). Соответственно, риски нёс брокер (его компания). Ещё брокер мог вас неверно услышать, неправильно понять или ещё как-то накосорезить. Это был риск искажения информации при передаче и риск интерфейса. В данном случае неоднократно поднимались судебные дела на тему «я сказал продавай, а не покупай». Был даже исторический период, когда брокеры реально боялись того, что клиент при неожиданном скачке рынка «пойдёт на попятную» и начнёт судиться по поводу того, что он давал совсем другие торговые приказы.

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

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

Проблемы могут быть в обмене клиентской программы и торговой платформы. Базовый риск – заражение терминала и компрометация или подмена транзакции. Как правило, распространён довольно редко.

Второй риск – неверное восприятие сигнала торговой платформой. Это когда вы решили покупать акции Google, а в результате купили акции Уральского вагоностроительного завода. И не две штуки, а контрольный пакет.

Естественно, подобные баги довольно редки. Самая популярная в России система торгов вылизывается как самолёт уже, наверное, лет двадцать точно. И это решение используют в качестве платформы почти все игроки рынка. При возникновении проблемы, об этом узнают почти мгновенно и почти все, поэтому, тьфу-тьфу, за последние годы ярких случаев не было. Для самой платформы каждая байка – репутационный случай, поэтому, наверное, мало кто подходит к процессу тестирования так же тщательно, как они. Можно сказать, что это люди, которые не знают про фразу EULA «Не несём ответственности за потерю данных пользователя в результате использования ПО». Несут, но не напрямую, а репутацией.

Самая популярная система называется QUIK и разрабатывается в Новосибирске. Базовая функциональность — обеспечивает оперативное получение информации и доступ к различным рынкам и режимам торгов через единый терминал. Есть отложенные заявки («Карман транзакций») с пакетным выставлением в торговую систему, есть условные заявки, выставляемые при наступлении определенного условия, импорт транзакций из других источников, плюс поддерживается программный ввод заявок средствами встроенных языков программирования и ввод заявок с графика. Поверх базовых вещей навешиваются различные модули сервера и пользовательские приложения на местах. Именно пользовательские приложения и создают тот разнообразный «зоопарк» торгового ПО, который вы видите у разных игроков рынка. Пример — та же торговая система Tradematic Trader FIX (конструктор торговых роботов), которая работает напрямую с QUIK-сервером.

Вторая по распространённости система уровня платформы – Transaq.

Естественно, возможны риски на уровне отладки работы роботов (особенно, если они «доморощенные») и на точках интеграции различного ПО в этом стеке. Также крайне редко встречаются проблемы с реализацией протоколов, но за последние годы таких случаев я вспомнить не могу.

На самой бирже

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

На нашей Московской бирже система позволяла проводить до 20 тысяч сделок в секунду. Функции торговли и клиринга (расчёта по заключенным сделкам) исторически были прописаны прямо в ядре как минимум с 2007 года. Рано или поздно биржи приходят к выносу этих функций в отдельные модули: например, в Лондоне и Нью-Йорке на текущий момент эти подсистемы уже разделены. Это не спасает от сбоев (они бывают и на NYSE, и на NASDAQ), но позволяет уменьшать их масштаб до размеров инкапсулированного модуля.

В архитектуре с кодом торгов и клиринга в ядре ошибки клиринга могли привести к остановке торгов. Как показали немногочисленные приостановки торгов за два года, примерно половина связана с кодом, остальное – телеком и железо (сбой балансировщика 28 июня, некорректная работа телеком-оборудования 12 августа, сбой в М1 и «сетевой шторм» 8 сентября).

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

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

Надо отметить, что ранее, в 2013 году, код биржи существенно модифицировался (поверх ядер 2007 года), потому что добавлялся функционал перехода на режим расчетов Т + 2, создание центрального депозитария, начало перехода на расчеты с централизованным клирингом в сегменте РЕПО, запуск торгов физическим золотом и ПФИ. При этом сбоев было довольно мало, что говорит о достаточно хорошо поставленном процессе. Наверное, довольно весело чувствовать себя разработчиком, чья ошибка в коде может стоить стране пару миллиардов рублей минимум.

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

Третий тип риска

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

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

Как это лечится

Мгновенные сделки не лечатся никак. Именно поэтому очень важно иметь «чистый» код в продакшне.

Сделки с отложенным расчётом (например, наши ETF считаются на Т+2, то есть в течение двух дней) вполне можно пересчитать после устранения сбоя. Собственно, в секции «медленных» сделок так и происходит. Например, в случае падения «перевёрнутого стакана» биржа выловила все транзакции и отменила их до истечения Т+2. Режим Т+2 возможен при трёхсторонней сделке – не моментальном обмене с кем-то, а при проведении операции через национальный клиринговый центр, который и «придерживает» всё до подтверждений и перепроверок.

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

Резюме

В прошлом посте вы спрашивали, зачем нам нужно 5 дата-центров для торговли ETF в России даже при работе в режиме Т+2, при проверке двумя независимыми организациями (Лондон, Ирландия) и через европейский клиринг. Надеюсь, теперь я подробно ответил на ваш вопрос. Сам по себе инструмент ETF убрал операционные риски (завязанные на человеческий фактор). Своей инфраструктурой и ПО мы постарались минимизировать IT-риски. Остались только рыночные (рост или падение рынка).

Ещё ссылки:

• Про то, почему нужно всего 10 человек для управления активом в миллиарды долларов (ИТ-инфраструктура на Хабре)
• Что такое ETF (покупка кусочка кластера акций по Т+2)
• И сегодняшний пост на Гиктаймс про то, чем вообще торгуют на бирже и почему цены так быстро меняются.