Trade surveillance для брокеров, торговых площадок и криптобирж: купить продукт, воспользоваться инструментами своей платформы или построить собственные алерты

Trade surveillance — это программа, которая следит за собственными заявками и сделками фирмы на предмет возможных злоупотреблений на рынке, например спуфинга или wash trades, и поднимает алерты, чтобы их проверил человек. Брокер, торговая площадка или криптобиржа может купить продукт, воспользоваться тем, что даёт торговая платформа или партнёр, или построить собственные алерты. По правилам ЕС и разъяснениям FINRA фирма остаётся ответственной, даже когда работу делает кто-то другой. Выбор зависит от того, насколько полны ваши данные по заявкам и кто будет проверять алерты.

Что делает trade surveillance?

Surveillance-программа читает ваши записи заявок и сделок и поднимает алерт, когда активность совпадает с шаблоном возможного злоупотребления. Затем аналитик проверяет алерт и либо закрывает его, либо передаёт выше. Если у фирмы есть обоснованное подозрение, она сообщает об этом регулятору; в ЕС и Великобритании это делается через сообщение о подозрительных операциях и заявках (STOR). Делегированный регламент Комиссии (ЕС) 2016/522, процитированный здесь в принятой редакции, описывает первые два шаблона из этого списка:

• Layering и спуфинг. Несколько или крупные заявки размещаются на одной стороне стакана, «чтобы совершить сделку на другой стороне книги заявок». Они часто стоят «вдали от лучшей цены», то есть вдали от наибольшей цены покупки и наименьшей цены продажи. После сделки «заявки, которые не предполагалось исполнять, снимаются».
• Wash trades. Сделки, «при которых нет изменения бенефициарных интересов или рыночного риска», либо при которых эти интересы переходят между сторонами, «действующими согласованно или в сговоре».
• Инсайдерская торговля. Торговля на основе внутренней информации, то есть точной непубличной информации, которая, если бы стала публичной, с высокой вероятностью заметно повлияла бы на цену. Европейский орган по ценным бумагам и рынкам (ESMA) — регулятор рынка ценных бумаг ЕС. В его руководящих принципах от 9 июля 2025 года приведён пример: «сотрудник CASP, знающий о решении включить новый токен в листинг на торговой платформе». CASP — это поставщик услуг в сфере криптоактивов. Алерты для такой схемы сопоставляют сделки с новостями, которые появились позже.

Что требуют правила ЕС от брокеров и площадок?

Обязанность задана в статье 16 Регламента ЕС о злоупотреблениях на рынке (MAR). Для брокеров статья 16(2) гласит: «Любое лицо, профессионально организующее или исполняющее операции, обязано создать и поддерживать эффективные механизмы, системы и процедуры для выявления подозрительных заявок и операций и сообщения о них». У операторов рынков и инвестиционных фирм, управляющих торговой площадкой, есть обязанность по статье 16(1), «направленная на предотвращение и выявление» злоупотреблений. Обе категории должны сообщать регулятору «без промедления».

Детали добавляет Делегированный регламент Комиссии (ЕС) 2016/957. MAR и этот регламент процитированы в принятой редакции, по legislation.gov.uk, поэтому проверьте актуальный текст. Все страницы регуляторов и поставщиков открывались 9 ноября 2026 года, а принятый текст Делегированного регламента (ЕС) 2025/885 — 10 ноября 2026 года. Эти части важнее всего, когда вы выбираете путь:

• Охват. Согласно статье 3(1), системы должны позволять анализировать «каждую исполненную сделку и каждую поданную, изменённую, отменённую или отклонённую заявку».
• Алерты и люди. Системы должны «формировать алерты, указывающие на действия, которые требуют дополнительного анализа», а статья 3(4) требует «надлежащего уровня анализа силами людей».
• Воспроизведение для площадок. Статья 3(3) требует, чтобы операторы рынков и фирмы, управляющие площадкой, имели «программное обеспечение, способное к отложенному автоматическому чтению, воспроизведению и анализу данных книги заявок».
• Соразмерность и проверка. Статья 2(5) требует механизмов, соответствующих масштабу вашего бизнеса, «регулярно оцениваемых, как минимум через ежегодный аудит и внутреннюю проверку», и «чётко документированных в письменной форме».

Что должны делать криптобиржи по MiCA?

Регламент о рынках криптоактивов (MiCA) читается здесь в том виде, в каком он опубликован в онлайн-своде правил ESMA. Статья 92(1) гласит: «Любое лицо, профессионально организующее или исполняющее операции с криптоактивами, обязано иметь эффективные механизмы, системы и процедуры для предотвращения и выявления злоупотреблений на рынке». Оно должно сообщать о «любом обоснованном подозрении относительно заявки или операции, включая любую её отмену или изменение», а также о подозрениях, связанных с работой блокчейна, например с «механизмом консенсуса», когда обстоятельства могут указывать на злоупотребление на рынке.

О мониторинге блокчейна: в итоговом отчёте ESMA от 17 декабря 2024 года ожидание ограничено «теми транзакциями, которые доходят до PPAET», то есть до лица, профессионально организующего или исполняющего операции. Мониторинг должен «охватывать внецепочечные транзакции, на которые приходится основная часть торговли», и данные в цепочке «в той мере, в какой это касается деятельности PPAET». Принятые стандарты — это Делегированный регламент Комиссии (ЕС) 2025/885 от 29 апреля 2025 года, который указан и в руководящих принципах ESMA от 9 июля 2025 года. Его статья 3(1)(c) задаёт требования прямо к «поставщикам услуг в сфере криптоактивов, управляющим торговой платформой», поэтому бирже стоит ожидать, что регламент на неё распространяется. В итоговом отчёте ESMA решила не определять в стандартах, кто ещё подпадает, поэтому другим криптокомпаниям стоит спросить юриста, как они ограничены.

Что говорят о trade surveillance правила США и Великобритании?

FINRA, саморегулируемая организация американских брокеров-дилеров, требует в правиле 3110, чтобы каждый член «создал и поддерживал систему надзора за деятельностью каждого связанного лица». В дополнительном материале .05 к этому правилу сказано: «Член не обязан проводить подробную проверку каждой сделки, если использует обоснованно разработанную систему проверки на основе рисков». Правило 5210 добавляет, что члены «должны иметь политики и процедуры, обоснованно предназначенные для проверки их торговой активности», чтобы выявлять и предотвращать схему самосделок от одного алгоритма, одного деска или связанных между собой. Самосделка здесь — это заявки одной фирмы, которые непреднамеренно исполняются друг против друга без смены владельца ценной бумаги. Эта статья касается только членов FINRA, поэтому фьючерсным фирмам и другим американским компаниям стоит свериться со своими правилами.

Британский регулятор Financial Conduct Authority (FCA) пишет: «Лица, профессионально организующие или исполняющие операции, также обязаны выявлять подозрительные операции и заявки и сообщать о них». На той же странице сказано, что операторы британских торговых площадок тоже обязаны их выявлять и сообщать о них. В Market Watch 86, своём бюллетене за октябрь 2026 года, FCA сообщает: «Мы посетили 7 розничных брокеров, чтобы оценить эффективность их механизмов мониторинга рыночных злоупотреблений». Она «обнаружила существенные недостатки в том, как эти механизмы были спроектированы, внедрены и работали на практике».

Какие данные по заявкам нужны для trade surveillance?

Алерт может работать только с теми данными, которые получает. В Market Watch 68 от ноября 2021 года FCA пишет: «Фиксация и мониторинг заявок, а не только сделок, необходимы, чтобы эффективно и последовательно выявлять возможные злоупотребления на рынке». О layering и спуфинге там сказано: «Если фирмы не фиксируют все неисполненные заявки, они могут не заметить такую активность». В Market Watch 69 от мая 2022 года обнаружено, что фирмы «не отслеживают все заявки и сделки, включая отменённые и изменённые заявки».

Прежде чем сравнивать продукты, проверьте в собственных записях четыре вещи:

• События по заявкам. Каждая подача, изменение, отмена, отклонение и исполнение должны нести один идентификатор заявки. По выгрузке одних сделок спуфинг не увидеть.
• Часы. Делегированный регламент Комиссии (ЕС) 2017/574 в редакции при принятии привязывает часы торговых площадок ЕС и их участников к UTC, международному эталонному времени. Для участников допустимое расхождение составляет от одной секунды при голосовой торговле до одной миллисекунды в большинстве других видов торговли, а при высокочастотной торговле оно ещё меньше. Правило FINRA 4590 устанавливает «допуск в 50 миллисекунд относительно часов NIST», эталонного времени американского агентства по стандартам, для компьютерных часов. Оно распространяется на события с NMS-ценными бумагами и внебиржевыми акциями, то есть с бумагами, обращающимися на американских биржах, и акциями, которыми торгуют на внебиржевом рынке.
• Идентификация клиентов. В Market Watch 67 от мая 2021 года сказано, что неверное сопоставление кодов клиентов «может привести к тому, что торговые площадки будут хранить неверные данные». В Annual Regulatory Oversight Report FINRA за 2026 год среди эффективных практик указан «мониторинг счетов, признанных связанными (или действующими согласованно)».
• Хранение. Делегированный регламент 2016/957 требует хранить пять лет анализ заявок и сделок, которые вы рассматривали, и «причины подачи или неподачи STOR». Правило FINRA 4511 устанавливает «не менее шести лет» для записей, для которых иной срок не указан.

Кто разбирает ложные тревоги?

Многие алерты оказываются пустыми, но каждый всё равно требует участия человека. В отчёте ESMA о криптоактивах сказано: «Автоматизация также может приводить к высокой доле ложных срабатываний при выявлении подозрительных операций». Анализ человеком, по словам ESMA, «должен присутствовать всегда при выявлении заявок и операций, которые могут быть злоупотреблением», отчасти для того, чтобы слабые алерты не «захлёстывали» регуляторов в виде сообщений.

Пороги определяют, сколько будет ложных тревог. Market Watch 69 предупреждает, что единый порог для всех инструментов может пропустить активность или «породить много “шума”». В Market Watch 86 обнаружены брокеры с «фиксированным порогом изменения цены», который не учитывал волатильность бумаги. У других минимальная стоимость сделки была «установлена слишком высокой, из-за чего значительная доля торговли клиентов выпадала из мониторинга».

Решите, кто разбирает алерты, до выбора инструмента. Делегированный регламент 2016/957 требует регулярного обучения сотрудников, которые этим занимаются, а в отчёте FINRA за 2026 год фирмам вменяют «Отсутствие документирования результатов проверки алертов». Market Watch 86 критикует процедуры, которые «подталкивали аналитиков искать причины закрыть алерт». Криптоплощадка торгует круглосуточно, поэтому назовите, кто отвечает за алерты ночью и в выходные.

Стоит ли полагаться на то, что нам дают торговая платформа или партнёр?

У этого пути меньше всего частей, которые нужно эксплуатировать, потому что данные уже находятся у другого. Trading Technologies, производитель торговых платформ, продаёт TT Trade Surveillance, который может «импортировать торговые данные из любой системы через биржевой drop copy, FIX drop copy, прямую загрузку файлов». Drop copy — это живой дубликат ваших сообщений по заявкам, а FIX — общий формат сообщений, которым пользуются брокеры и площадки. В комплекте идут «объяснимые готовые модели». В Report Center FINRA есть отчёт Cross Market Equities Supervision, показывающий возможные случаи layering и спуфинга. Статья 3(6) Делегированного регламента 2016/957 также позволяет лицу, профессионально организующему или исполняющему операции, по письменному соглашению передать мониторинг компании из своей группы.

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

Передав работу, вы сохраняете обязанность за собой. Статья 3(7) Делегированного регламента 2016/957 относится к лицу, профессионально организующему или исполняющему операции. Такое лицо может передать третьей стороне «анализ данных, включая данные о заявках и сделках, и формирование алертов», но «остаётся полностью ответственным». Оно должно сохранять компетенцию для оценки исполнителя и «прямой доступ ко всей соответствующей информации об анализе данных и формировании алертов». В Regulatory Notice 21-29 FINRA сказано, что аутсорсинг «не снимает с членов окончательной ответственности за соблюдение всех применимых федеральных законов и правил о ценных бумагах».

Статьи 3(6) и 3(7) не упоминают операторов торговых площадок, поэтому площадке стоит спросить юриста, что именно она вправе передавать. Правило для криптоактивов идёт дальше. Статья 3(4) Делегированного регламента 2025/885 позволяет лицам, профессионально организующим или исполняющим операции с криптоактивами, передавать на аутсорсинг мониторинг и выявление, а также анализ данных и алерты. Они «остаются полностью ответственными».

Стоит ли покупать продукт для surveillance?

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

• Eventus пишет, что у Validus «более 150 процедур из коробки» и что он может работать «либо в режиме, близком к реальному времени, либо по схеме T+1», то есть на следующий день после торгов. Компания также заявляет: «Автоматизация в среднем разрешает 90% ложных срабатываний».
• О SURVEIL-X от NICE Actimize компания пишет, что он «значительно сокращает ложные срабатывания», но на странице нет цифры, которая подтверждала бы это, а ещё он «отслеживает различные каналы связи, включая электронную почту, чаты и голосовые звонки».
• Solidus Labs пишет, что её платформа HALO способна «выявлять согласованные манипуляции на спотовых, производных, ончейн- и офчейн-рынках», а клиенты могут «проводить A/B-бэктесты и смотреть эффект до запуска».
• Scila описывает «рыночный надзор и расчёт рисков в реальном времени для участников рынка».

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

Купленный продукт всё равно может оказаться тем, что вы не в состоянии объяснить. В Market Watch 86 FCA пишет: «Мы обнаружили случаи, когда сотрудники, отвечающие за мониторинг, не могли толком объяснить, как работают их системы». И добавляет: «Некоторые, судя по всему, полагались на готовые настройки сторонних поставщиков». В Market Watch 56 за сентябрь 2018 года сказано: «Каждая фирма сама отвечает за свои решения по калибровке алертов».

Когда стоит строить собственные алерты для surveillance?

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

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

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

Как проверить, работают ли алерты?

Считать алерты — слабая проверка. В Market Watch 86 сказано, что некоторые фирмы «опирались на простые метрики тестирования, такие как сравнение числа алертов с объёмом торгов или проверка результатов алертов только по историческим торговым данным». Хорошей практикой там названо «тестирование алертов на разных порогах с помощью проверок “выше” и “ниже линии”», а другим подходом — «использование синтетических торговых данных, чтобы проверить, сработают ли алерты как ожидается». План тестирования состоит из четырёх частей:

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

Что у нас останется, если мы уйдём от поставщика?

Продумайте выход до подписания. Обязанность хранить записи пять лет по статье 3(8) Делегированного регламента 2016/957 действует и после окончания договора. В статье 3(7) сказано, что в соглашении должны быть «определены основания, позволяющие лицу, передающему функции, расторгнуть такое соглашение».

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

О чём спросить поставщика surveillance или фирму, которая построила бы наши алерты?

• Читает ли система каждое событие по заявке, включая изменения, отмены и отклонения, и можем ли мы убедиться в этом на выборке нашего собственного потока?
• Какие типы алертов покрывают наши рынки и продукты, а какие нет?
• Могут ли наши сотрудники менять пороги, и записывается ли каждое изменение с указанием, кто и почему его сделал?
• Как мы проводим тестирование «выше линии» и «ниже линии» и можем ли мы вставлять придуманные заявки?
• Какие метки времени вы храните и как поступаете с площадками, у которых часы расходятся?
• Как проверяющий записывает причину закрытия алерта и можем ли мы экспортировать эту историю?
• Кто может видеть логику алертов и можете ли вы письменно объяснить, почему сработал тот или иной алерт?
• Можете ли вы показать, как это работает на системе, которая работает сегодня?

Где здесь место amBrain?

Этот блог публикует amBrain. Об одной части своей работы в трейдинге компания пишет одной строкой: «amBrain создаёт инфраструктуру для алгоритмического трейдинга: исполнение заявок, рыночные данные и предторговые контроли рисков». В этой строке о trade surveillance ничего не сказано.

О своей истории компания пишет: «amBrain разрабатывает программное обеспечение с 2019 года». О том, как она работает с клиентами, сказано: «Три формата: полная поставка, выделенная команда или инженеры, встроенные в вашу команду». О владении: «Клиент полностью владеет продуктом и кодом, кроме наших повторно используемых компонентов». Попросите перечень этих компонентов по названиям до подписания.

Эта статья не кейс и не описывает работу с клиентами. Ничто в ней не говорит о том, что amBrain создавал, лицензировал или интегрировал для какого-либо клиента систему surveillance. Цитаты взяты с опубликованных страниц ESMA, FCA, FINRA, Trading Technologies, Eventus, NICE Actimize, Solidus Labs и Scila, а также с legislation.gov.uk и EUR-Lex. Статья не заявляет о каких-либо отношениях между amBrain и ими, не рекомендует ни один из их продуктов и не приводит цен и сроков amBrain.

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