Best execution only counts if you can prove it. When a partner or a regulator asks why an order routed the way it did through Paxos Crypto Brokerage, the answer, the answer has to come from data that shows exactly what the market looked like at the millisecond the decision was made.

This post is about the analytics behind that claim: the pipelines under our transaction cost analysis (TCA), execution reporting and dispute investigations. Our order books absorb thousands of updates per millisecond, and any one of them still resolves to a single authoritative state:  for the order, for the routing decision, and for what the customer saw at the time that decision was made. That's what makes the analysis defensible.

We've written before about upgraded multi-venue order routing and how we measure best execution. Both sit on this data foundation.

For partners, this is what makes execution quality provable in practice

You can benchmark fills against the real multi-venue market, reconstruct the visible book around any order, and tie every execution to an explainable state. The evidence is the same whether the question arrives today or a year from now. The rest of this post is how we built that.

The problem we needed to solve

When we spoke with partners about execution quality, two themes came up again and again: They wanted deeper liquidity and smarter routing and they needed to prove, with data, that execution was good.

The latter is harder than it sounds. Historically, that's where many crypto stacks fell short: order-routing data and market data landed on different cadences, and analytics surfaces sat on top of batch processes. Teams came to assume analytics were batch even when fresher signals existed upstream. TCA ended up running on last week's data against a single venue's snapshot. This is not an argument you want to bring to a regulator.

So we rebuilt around four properties: 

• Order routing and market data as first-class streaming sources

• Analytics that don't wait on an overnight batch 

• A durable raw history to reconstruct from 

• Centralized metric logic

The architecture: one foundation, two serving layers

Brokerage and market-data systems publish into a shared streaming layer. Data lands in a real-time analytics store where core metrics are computed as events arrive, and persists to object storage feeding our analytics warehouse.

How order-routing and market-data events reach both analytics layers

The real-time store keeps metrics current; the warehouse holds the depth and retention TCA and reporting run against. That store is a purpose-built time-series engine, fed by a managed streaming platform and its connector framework.

The reason for the split is that important metrics need one definition and one owner: the engine computes them once and publishes them downstream, so nobody reinterprets the same events for every dashboard, report and TCA model.

Two ingestion patterns

Order routing: A transactional database powers production traffic. Rather than querying it from analytics tools, we capture row-level changes and publish them to the streaming layer, landing in the time-series engine and in object storage for the warehouse.

The detail that makes this provable: every routing decision carries the unique ID of every source point for that market at that instant. The decision correlates directly to the market-data state that produced it, down to the individual update from each venue in view when it was made.

Market data: Exchange systems publish to customer-facing and internal consumers in parallel, under a shared identifier so the same record tracks across both paths. Before publication, each update is applied to a real-time running book per venue; that aggregated book represents the market as we see it, and both sides read from that view rather than raw feeds.

Every update carries a Paxos message ID (globally unique and time-ordered) so we can trace a decision to the exact update and millisecond. When a customer disputes a fill, they hand us the same ID and we replay the market state behind it. Each venue has its own logical stream, but the schema and ingestion pattern stay consistent.

What this unlocks

Once order routing and market data share the same streaming and metric foundation, the capabilities partners actually use come nearly for free.

Benchmark against the real market, not a proxy: TCA measures fills against an independent, multi-venue view of the market, rather than a single-venue snapshot.

Reconstruct the book at any point in time: For a given asset and venue we rebuild the visible book around an order and compare the router's choices to what was actually available.

The visible book around a single fill, rebuilt from stored market data

Tie every execution to an explainable state: With stable identifiers and timestamps on both sides, we can show what filled and why the system chose that path.

Give support and trading teams one map: Internal tools sit on one shared analytics plane instead of stitched-together exports. And the tooling does more than explore: teams dig deep into a single order's execution flow end to end against both internal and external data points.

One order's full execution path, checked against internal and external data

That's what transforms best execution from a compliance box to check into something you can monitor, tune and defend with data.

Two design choices that paid off

Raw first, modeled second: We land a raw representation of the stream before building typed models: a forensic trail when models misbehave, plus replay and backfill support. In a regulated environment that pays for itself the first time you answer a hard question six months after the fact.

Reference, don't duplicate: Rather than copying market-data payloads into every downstream record, we reference already-published data by stable ID. A routing decision points at the exact updates it consumed, keeping our data footprint small while preserving full reconstructability.

Boring choices. Both are why the interesting things above are possible.

Every source mapped to its pattern, destination and freshness target

Because the same streamed events and governed metrics power both routine reporting and historical investigations, firms can give internal stakeholders and regulators a consistent, data-backed account: the same evidence, whether the question arrives today or next year.

Get Started

Whether you're a broker-dealer launching crypto for retail clients, a bank exploring digital assets across wealth and prime brokerage, or a fintech scaling an existing integration, we'd like to show you what upgraded routing can do for your execution quality. Reach out to your Paxos account team or contact us here.

This is the first in a series of posts about how we build and run the data platform behind our crypto brokerage. Next up: How the same real-time layer runs production operations, from our order triage bot to venue-quality alerting, and what changes when the consumer is an on-call engineer rather than an analyst.