Как мы делаем качество исполнения доказуемым? Технологические процессы за Paxos Crypto Brokerage
Наилучшее исполнение имеет значение только тогда, когда его можно доказать. Когда партнер или регулятор спрашивает, почему ордер был маршрутизирован именно так через Paxos Crypto Brokerage, ответ должен основываться на данных, которые точно показывают состояние рынка в ту миллисекунду, когда принималось решение.
Эта статья посвящена аналитике, лежащей в основе этого утверждения: процессам, обеспечивающим наш анализ транзакционных издержек (TCA), отчетность об исполнении и расследование споров. Наши книги ордеров поглощают тысячи обновлений в миллисекунду, и каждое из них сводится к единому достоверному состоянию: для ордера, для решения о маршрутизации и для того, что видел клиент в момент принятия этого решения. Именно это делает анализ обоснованным.
Мы уже писали ранее об обновленной маршрутизации ордеров по нескольким площадкам и о том, как мы измеряем наилучшее исполнение. Оба этих аспекта опираются на данный фундамент данных.
Для партнеров это то, что делает качество исполнения доказуемым на практике
Вы можете сравнивать исполнение с реальным рынком нескольких площадок, реконструировать видимую книгу ордеров вокруг любого ордера и привязать каждое исполнение к объяснимому состоянию. Доказательства остаются неизменными, независимо от того, поступил ли вопрос сегодня или год спустя. В остальной части этой статьи рассказывается, как мы это построили.
Проблема, которую нам нужно было решить
Когда мы общались с партнерами о качестве исполнения, постоянно возникали две темы: им нужна была более глубокая ликвидность и более умная маршрутизация, и им нужно было доказать с помощью данных, что исполнение было качественным.
Последнее сложнее, чем кажется. Исторически сложилось так, что именно здесь многие крипто-стеки не справлялись: данные о маршрутизации ордеров и рыночные данные поступали с разной периодичностью, а аналитические инструменты работали поверх пакетных процессов. Команды привыкли считать, что аналитика — это пакетная обработка, даже если выше по потоку существовали более свежие сигналы. TCA в итоге выполнялся на данных прошлой недели по снимку одной площадки. Это не тот аргумент, который вы захотите представить регулятору.
Поэтому мы перестроили систему вокруг четырех свойств:
- Маршрутизация ордеров и рыночные данные как потоковые источники первого класса
Маршрутизация ордеров и рыночные данные как потоковые источники первого класса
- Аналитика, которая не ждет ночной пакетной обработки
Аналитика, которая не ждет ночной пакетной обработки
- Надежная история необработанных данных для реконструкции
Надежная история необработанных данных для реконструкции
- Централизованная логика метрик
Централизованная логика метрик
Архитектура: один фундамент, два уровня обслуживания
Системы брокерских услуг и рыночных данных публикуют информацию в общий потоковый уровень. Данные попадают в хранилище аналитики реального времени, где основные метрики вычисляются по мере поступления событий, и сохраняются в объектном хранилище, питающем наше аналитическое хранилище данных.
Как события маршрутизации ордеров и рыночных данных достигают обоих уровней аналитики
Хранилище реального времени поддерживает актуальность метрик; хранилище данных содержит глубину и историю, по которым работают TCA и отчетность. Это хранилище представляет собой специализированный движок временных рядов, питаемый управляемой потоковой платформой и ее фреймворком коннекторов.
Причина разделения заключается в том, что важные метрики должны иметь одно определение и одного владельца: движок вычисляет их один раз и публикует вниз по потоку, чтобы никто не интерпретировал одни и те же события по-разному для каждой панели мониторинга, отчета или модели TCA.
Два шаблона приема данных
Маршрутизация ордеров: Транзакционная база данных обеспечивает производственный трафик. Вместо того чтобы запрашивать ее из аналитических инструментов, мы фиксируем изменения на уровне строк и публикуем их в потоковый уровень, откуда они попадают в движок временных рядов и в объектное хранилище для аналитического хранилища.
Деталь, которая делает это доказуемым: каждое решение о маршрутизации содержит уникальный идентификатор каждой точки источника для этого рынка в тот момент времени. Решение напрямую коррелирует с состоянием рыночных данных, которое его породило, вплоть до отдельного обновления от каждой площадки, видимой в момент принятия решения.
Рыночные данные: Биржевые системы публикуют данные для внешних и внутренних потребителей параллельно, под общим идентификатором, чтобы одна и та же запись отслеживалась по обоим путям. Перед публикацией каждое обновление применяется к книге ордеров реального времени для каждой площадки; эта агрегированная книга представляет рынок в том виде, в котором мы его видим, и обе стороны считывают данные из этого представления, а не из «сырых» потоков.
Каждое обновление несет идентификатор сообщения Paxos (глобально уникальный и упорядоченный по времени), поэтому мы можем проследить решение до точного обновления и миллисекунды. Когда клиент оспаривает исполнение, он передает нам тот же идентификатор, и мы воспроизводим состояние рынка, стоявшее за ним. У каждой площадки свой логический поток, но схема и шаблон приема данных остаются неизменными.
Что это дает
Как только маршрутизация ордеров и рыночные данные начинают использовать один и тот же потоковый фундамент и метрики, возможности, которые действительно используют партнеры, становятся практически бесплатными.
Сравнение с реальным рынком, а не с прокси: TCA измеряет исполнение относительно независимого представления рынка по нескольким площадкам, а не снимка одной площадки.
Реконструкция книги ордеров в любой момент времени: Для заданного актива и площадки мы восстанавливаем видимую книгу вокруг ордера и сравниваем выбор маршрутизатора с тем, что было доступно на самом деле.
Видимая книга вокруг одного исполнения, восстановленная из сохраненных рыночных данных
Привязка каждого исполнения к объяснимому состоянию: Благодаря стабильным идентификаторам и меткам времени с обеих сторон мы можем показать, что было исполнено и почему система выбрала именно этот путь.
Единая карта для команд поддержки и трейдинга: Внутренние инструменты работают на одной общей аналитической плоскости вместо разрозненных экспортов. И инструменты делают больше, чем просто исследование: команды глубоко погружаются в поток исполнения одного ордера от начала до конца, используя как внутренние, так и внешние точки данных.
Полный путь исполнения одного ордера, проверенный по внутренним и внешним данным
Именно это превращает наилучшее исполнение из формального требования комплаенса в то, что можно отслеживать, настраивать и защищать с помощью данных.
Два проектных решения, которые оправдали себя
Сначала «сырые» данные, потом модели: Мы сохраняем необработанное представление потока перед созданием типизированных моделей: это криминалистический след на случай сбоя моделей, а также поддержка воспроизведения и дозагрузки данных. В регулируемой среде это окупается при первом же ответе на сложный вопрос спустя полгода после события.
Ссылаться, а не дублировать: Вместо копирования полезной нагрузки рыночных данных в каждую запись, мы ссылаемся на уже опубликованные данные по стабильному идентификатору. Решение о маршрутизации указывает на точные обновления, которые оно использовало, сохраняя малый объем данных и обеспечивая полную восстанавливаемость.
Скучные решения. Именно они делают возможными интересные вещи, описанные выше.
Каждый источник сопоставлен со своим шаблоном, местом назначения и целевой свежестью
Поскольку одни и те же потоковые события и управляемые метрики обеспечивают как рутинную отчетность, так и исторические расследования, фирмы могут предоставить внутренним заинтересованным сторонам и регуляторам последовательный отчет, подкрепленный данными: одни и те же доказательства, независимо от того, поступил ли вопрос сегодня или в следующем году.
Начало работы
Независимо от того, являетесь ли вы брокером-дилером, запускающим криптоуслуги для розничных клиентов, банком, изучающим цифровые активы в рамках управления капиталом и прайм-брокериджа, или финтех-компанией, масштабирующей существующую интеграцию, мы хотели бы показать вам, что обновленная маршрутизация может сделать для качества вашего исполнения. Свяжитесь со своей командой по работе с клиентами Paxos или напишите нам здесь.
Это первая публикация из серии статей о том, как мы создаем и эксплуатируем платформу данных, лежащую в основе нашего криптоброкера. Далее: как этот же уровень реального времени обеспечивает производственные операции — от нашего бота для сортировки ордеров до оповещений о качестве площадок, и что меняется, когда потребителем данных становится дежурный инженер, а не аналитик.
