Why Liquid Mercury

The institutional trading stack firms pick when they need sell-side workflows in digital assets

Chicago-pedigree performance, sell-side workflows institutional desks already use, and bespoke per-desk configuration. Built by capital markets veterans for the firms running institutional digital asset flow.

Request Demo See Mercury Pro

Heritage

Forty years of matching-engine and options-trading experience, brought forward into crypto.

Chicago exchange DNA, applied to digital assets

Liquid Mercury was founded by Tony Saliba, the only options trader profiled in Jack Schwager's Market Wizards and a former CBOE and CHX board member. The engineering leadership came out of LiquidPoint and Dash Financial, two Chicago firms that built the execution infrastructure institutional options traders relied on for two decades.

That background shows up in the details of how the platform works. The order management system speaks FIX the way brokers actually use it, including custom tags for allocations and trade reporting. The matching engine is built to exchange-grade throughput standards. The risk checks are modeled after the limits and kill switches that sit inside every institutional options desk.

Liquid Mercury is headquartered in Chicago because that is where our people are. The city's four decades of derivatives infrastructure experience was the advantage we had when we started building for digital assets, and we still carry it.

Workflows

FIX, PMS integration, RFQ, dealer inventory, allocations. The patterns crypto-native systems skipped.

The workflows institutional desks already use

Most crypto trading platforms are built for buy-side retail or prop-desk patterns: a GUI, a REST API, and a wallet. That works for a lot of trading activity, but it does not work for sell-side broker workflows where FIX connectivity is mandatory, PMS integration is a procurement requirement, and post-trade allocations run through a documented compliance surface.

Liquid Mercury supports FIX 4.4 and 5.0 SP2 with custom tags documented. The OMS handles the allocation, amendment, and trade-reporting lifecycle that institutional desks expect. RFQ workflows, dealer inventory management, and bilateral OTC flow are first-class surfaces, not afterthoughts bolted onto an exchange engine.

Our customers include sell-side brokers, market makers, OTC principals, prime desks, and tokenized-asset issuers. The system was designed for their workflows. Buy-side firms can use it. Retail firms cannot.

Configuration

Your workflow, your venue set, your risk policy. Configured during onboarding, not feature-flagged in production.

Bespoke configuration, not a SaaS skin

Most institutional software vendors ship one product and gate features behind customer tiers. Some configuration happens through the UI, some through feature flags, and the hard stuff requires a product ticket that lands on a roadmap.

Liquid Mercury takes a different approach. During onboarding we configure the platform to your desk: which venues you connect to, which order types you surface in your UI, which risk limits apply per trader and per book, which FIX tags you exchange with which counterparties, which allocation and reporting workflows match your compliance surface. The configuration is captured in your tenant and versioned like any other platform asset.

This is why our implementation window is four to twelve weeks rather than six to nine months. The platform was built to be configured, not to be customized through code forks.

Engineering support

No handoff between sales engineering, implementation, and support. One engineer. One accountability chain.

The engineer who builds your integration stays on your Slack

Most software vendors separate sales engineering, implementation, and ongoing support into three different teams with three different accountability chains. Problems get triaged, rerouted, and escalated. Response times degrade. The person you talked to during the demo is not the person who fixes your production issue.

Liquid Mercury does not work that way. The engineer who builds your integration stays with your desk through production and into ongoing support. They are on your Slack. They know your configuration, your venues, your traders, and the failure modes that matter to you. When you escalate, you escalate to someone who can ship a fix.

The number of separate vendor handoffs between discovery and go-live is the single strongest predictor of time-to-production in institutional software procurement. We keep that number at one.

Architecture

Sub-90 nanosecond message processing, 10M+ messages per second, real-time FIX gateway.

Built for institutional throughput

The platform that runs under Liquid Mercury is architected against the same performance targets as the exchange and sell-side systems our engineers used to build. Sub-90 nanosecond message processing. Ten million plus messages per second. A real-time FIX gateway with sub-millisecond order submission. A market-data tier that normalizes order books across centralized exchange, OTC, and decentralized venues without lag.

This matters because institutional workflows are latency-sensitive even when the trading strategy is not. A sell-side desk running RFQ flow needs the quote response to reach the client before they move on. A prime desk reconciling fills across twenty venues needs the ledger to reflect reality within a heartbeat. A market maker adjusting quotes to changing volatility needs the platform to not be the bottleneck.

Exchange-grade performance is not a feature we added later. It was the default from day one.

Get Started

See the platform against your desk's criteria

Tell us about your desk, your venue set, and the workflows you need supported. We will show you how Liquid Mercury configures against your criteria and what implementation looks like from contract to go-live.

Request Demo