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