Торговые платформы в МФЦА (AIFC): границы периметра, MTF/OTF и требования к модели
На практике “торговая платформа” — это не витрина и не кабинет пользователя, а организация торгового процесса: правила допуска, order handling, matching, управление приоритетом исполнения, мониторинг злоупотреблений, а также связка с пост-трейд контуром (подтверждение, клиринг/расчёты, custody — в зависимости от модели).
- Ключевой вопрос: вы формируете рынок (правила и matching) или даёте технологический сервис доступа?
- Грань между brokerage и platform operation проходит по роли в order-flow и правилам исполнения.
- MTF/OTF — это не “маркетинг”, а периметр: инструменты, клиенты, доступ, отчётность, surveillance.
Если у вас есть order book или matching, а также собственные правила доступа и исполнения — это сигнал, что вы ближе к “оператору платформы”, чем к поставщику IT.
Как описывать торговую платформу: через функции
Ниже — функциональные блоки, которые обычно “поднимают” регуляторные вопросы: роль в order-flow, устройство торгов, допуск участников, надзор, пост-трейд и аутсорс критических частей.
Кто торгует, чем торгует, где происходит matching и кто задаёт правила исполнения.
- clients & instruments
- market rules
- execution model
Как обычно различают режимы и почему “называть” платформу недостаточно.
- admission & discretion
- rules vs judgement
- risk controls
Как идут ордера, кто принимает/отклоняет, кто определяет приоритет и условия исполнения.
- order handling
- routing
- execution priority
Мониторинг злоупотреблений и аномалий: алерты, расследования, evidence trail.
- monitoring
- case management
- enforcement
Подтверждение сделок, клиринг/расчёты и ответственность в ошибках и отменах.
- confirmation
- clearing/settlement
- error handling
Matching engine, облако, surveillance vendor: SLA, аудит, доступы, exit plan.
- SLA/KPI
- audit rights
- exit strategy
Торговая платформа почти всегда “подтягивает” соседние контуры: брокерские функции, custody, market activities, AML/санкции, IT-устойчивость и обработку инцидентов.
ЧТО ВАЖНО ПОНИМАТЬ: торговая платформа = правила + порядок исполнения
Чтобы корректно “квалифицировать” платформу, нужно описать не UI, а правила, order-flow и ответственность: кто принимает решения, как обеспечивается честность торгов, и как документально подтверждается ход операций.
Периметр платформы начинается с того, кому и к чему вы даёте доступ — и какие ограничения реально действуют.
- категории клиентов и правила допуска (member / client access)
- инструменты и правила их листинга/допуска
- ограничения по юрисдикциям, санкциям, профилю риска
- roles: participant, member, market maker, issuer, broker
- документы: market rules, participant rules, disclosures
В проектах чаще всего важно не “угадать аббревиатуру”, а доказать, что правила и дискреция соответствуют модели.
- есть ли дискреция оператора в исполнении/матчинге
- как устроен matching: правила vs ручное вмешательство
- как обрабатываются отказы, приостановки, ограничение доступа
- конфликты интересов и “связанные” участники
- как реализуется surveillance и меры к участникам
Чек-лист торговой платформы: что обычно смотрят по модели
Функции, документы, IT-реализация и доказуемость контроля
| Блок | Что нужно описать | Типовые “красные флаги” |
|---|---|---|
| Order-flow и исполнение | приём/отклонение ордеров, приоритет, routing, отмены/изменения, правила исполнения | нет формальных правил исполнения, ручные правки без контроля, “непонятно кто отвечает” |
| Matching engine | алгоритм матчинга, очередность, ограничения, процедуры при сбоях | движок у провайдера без аудит-прав, нет тестирования, нет DR-плана |
| Surveillance | мониторинг аномалий, кейсы, эскалации, меры к участникам, хранение доказательств | нет evidence trail, нет реагирования на манипуляции, “логов не хватает” |
| Post-trade | подтверждение, клиринг/расчёты (если применимо), реконсиляции, ошибки/отмены | серые зоны ответственности, ручные корректировки без протокола, нет обработки исключений |
| Access & governance | допуск участников, конфликты интересов, управление изменениями правил, комитеты/полномочия | “открытый доступ”, изменения правил без процедуры, конфликты интересов не раскрыты |
| Outsourcing | SLA/KPI, audit rights, доступы, субподрядчики, exit plan, контроль данных | критическая функция “вне контроля”, нет права аудита, нет плана миграции/выхода |
Сопутствующие страницы для корректного позиционирования: Рыночная деятельность, Брокерская деятельность, Кастодиальные услуги.
Типовой путь подготовки платформы к регуляторному диалогу
Практическая последовательность, которая помогает “собрать” платформу в управляемый контур — с документами, IT и доказуемостью контроля.
Описываем функции: platform vs broker vs post-trade. Фиксируем периметр, роли и ответственность.
Market rules, допуск, исполнение, изменения правил, контроль конфликтов интересов и governance.
Сценарии мониторинга, кейсы, evidence trail, эскалации и меры к участникам.
BCP/DR, security, change management, SLA/KPI, права аудита и exit plan по критическим провайдерам.
Для платформ чаще всего обсуждают лицензии на управление MTF и/или управление OTF — в зависимости от устройства торгов и роли оператора.
Глоссарий
Ключевые термины по платформам и торговой инфраструктуре.
Механизм сопоставления ордеров по правилам (приоритет, цена/время, ограничения). Важны контроль изменений и устойчивость.
Путь ордера: приём, валидация, routing, исполнение/отмена, фиксация результатов и логирование действий.
Режимы организации торгов. На практике ключевое — правила vs дискреция, доступ, инструменты и контуры надзора.
Доказуемость: логи, данные, кейсы расследований и история решений, достаточная для контроля и разборов инцидентов.
FAQ
Короткие ответы на частые вопросы о торговых платформах.
Если есть “matching”, это всегда MTF/OTF?+
Где граница между платформой и брокером?+
Можно ли использовать внешний matching engine / surveillance vendor?+
Какие документы обычно требуются для описания платформы?+
Материал подготовлен для общего информирования и не является юридической консультацией или заключением. Квалификация деятельности зависит от фактической модели, функций, договоров и IT-реализации.