В четверг, 21 августа 2025 года на фондовой бирже в Мумбаи произошла одна из крупнейших торговых ошибок в истории Индии. Брокерская компания Spark Institutional Equities (входящая в состав Avendus Capital) по поручению семьи-основателей компании Clean Science & Technology Ltd. должна была продать пакет акций на $300 млн. Вместо этого было продано акций на $749 млн, что лишило семью мажоритарного контроля над бизнесом. Официальные заявления компаний признают ошибку, но не раскрывают её причин и точную дату инцидента. Давайте разберёмся в известных фактах и возможных сценариях, которые могли привести к сбою.
На основе данных Bloomberg можно восстановить следующую последовательность событий:
Цель: Продажа 24% акций Clean Science (около 25.5 млн акций) для фиксации прибыли с сохранением контрольного пакета.
Первая попытка: Трейдеры Spark Institutional Equities загрузили ордер на продажу. По их данным, он не был исполнен (или система показала, что не был исполнен).
Вторая попытка: Трейдеры повторили операцию.
Обнаружение: Через несколько минут после открытия торгов выяснилось, что оба ордера были исполнены биржей. В результате было продано 59.8 млн акций (56% капитала), а не запланированные 25.5 млн.
Финансовый результат: Общий объём ошибочных сделок составил 65.4 млрд рупий ($749 млн).
Реакция рынка: Акции Clean Science пережили экстремальную волатильность в течение дня, подскочив на 17% и упав на 9.3%, закрывшись в минусе на 2.7%.
Частичное исправление: Брокеру удалось выкупить обратно 32.2 млн акций (30%) по цене, близкой к цене продажи. По данным источников, семья основателей не понесла финансовых убытков.
Не первый сбой в регионе
Инцидент с Avendus произошёл на фоне других аномалий:
Всего за несколько дней до этого доходность индийской госбумаги упала на 10 б.п. из-за «неумелого обращения».
В феврале необъяснимый скачок на 10% акций SBI Cards & Payment Services Ltd в премаркете также наводил на мысли о возможной ошибке.
Проблемы не уникальны для Индии. Яркий пример — инцидент в Citigroup Inc. (2021 г.), когда сотрудник из-за ошибки копирования чуть не перевел $6 млрд не тому клиенту.
Это указывает на общую уязвимость финансовых систем к человеческим и технологическим ошибкам.
Где мог произойти сбой
Точная причина неизвестна, и спекулировать на эту тему без доступа к внутренним системам преждевременно. Однако, основываясь на публичной информации, можно выделить несколько вероятных точек отказа, классических для высоконагруженных финансовых систем:
Сбой взаимодействия на уровне «брокер-биржа» (наиболее вероятно). Запрос мог быть отправлен на биржу, но подтверждение о его получении не вернулось к брокеру из-за сетевого таймаута, сбоя в шлюзе или программной ошибки в API-клиенте. Система брокера, интерпретировав это как неудачу, разрешила повторную отправку.
Проблема с отображением статуса в UI/UX. Интерфейс трейдера мог не обновиться и не показать статус «исполнено» или «в обработке» из-за задержки данных, создав у пользователя ложное впечатление, что первый ордер не прошёл.
Ошибка процедуры и человеческий фактор. Возможно, внутренний регламент компании или скрипт не предусматривали проверки на дубликаты в короткий промежуток времени, а трейдер, действуя в условиях стресса и высокой волатильности, принял решение отправить ордер повторно.
Редкий баг в системе управления ордерами (OMS). Теоретически, могла произойти race condition или сбой в работе очереди сообщений, приведший к дублированию исходящего запроса.
Важно подчеркнуть: в официальном заявлении Avendus не указано, что причиной был исключительно технический сбой. Вероятнее всего, речь идёт о совокупности факторов.
Уроки для IT
Независимо от точной причины, этот инцидент — повод задуматься о проектировании отказоустойчивых систем.
Принцип идемпотентности. Критически важно, чтобы операции (особенно такие как отправка ордера) были идемпотентными. Каждый запрос должен иметь уникальный ключ (Idempotency Key), чтобы биржа или шлюз могли отклонить дубликат.
Чёткий пользовательский интерфейс. UI должен однозначно и быстро отображать статус операции, блокируя возможность повторного нажатия до получения финального ответа от сервера.
Мониторинг и алертинг. Системы должны детектировать аномалии: две идентичные крупные заявки в течение секунд — это повод для автоматического предупреждения оператора, а не слепого исполнения.
Готовность к откату. В архитектуре должны быть заложены не только сценарии исполнения, но и чёткие, быстрые процедуры компенсации (compensation transactions) на случай ошибок.
Источник: habr.com