Cross-Margin Across Asset Classes: Design Decisions for Venue Operators

Multi-asset venues sell one thing above everything else — the ability for a trader to post capital once and deploy it across every product on the platform. From the operator's side, that promise is a set of design decisions inside the margin engine, the collateral model and the risk waterfall. Get them right and you host cross-asset flow that segregated-account venues cannot compete for. Get them wrong and you ship the same experience as a broker with five separate logins hidden behind one dashboard.

This is a playbook for operators shipping cross-margin across asset classes — the design decisions made when the margin engine gets built, not the ones the trader makes on the order ticket.

What Cross-Margin Means at the Platform Layer

Cross-margin across asset classes means one number — account equity — backs every open position simultaneously. Implementing it requires three components to agree:

• A single collateral pool. Deposited balance, unrealised P&L, reserved initial margin and accrued fees roll into one equity figure that any position on any product can draw against
• A portfolio margin engine. Requirements compute against the net risk of the whole book, not the gross sum of per-position requirements. Correlated positions offset. Uncorrelated positions do not
• A matching engine that respects the pool. Pre-trade risk checks read the same equity number the risk engine uses for liquidation, so a fill that clears the book never leaves the account under-margined

Each of these is a build cost. Segregated sub-accounts are trivial by comparison — separate ledgers per product, no cross-asset logic, no netting matrix. Operators shipping a multi-asset venue with segregated margin get told very quickly by any institutional desk that they might as well be five different platforms behind one login.

Choosing a Portfolio Margin Methodology

Three methodologies dominate the industry:

• SPAN-inspired scenario stress. Simulate the portfolio across a fixed set of price and volatility shocks — typically sixteen scenarios in the classical implementation — and charge margin against the worst outcome. Battle-tested on regulated futures for four decades. Computationally cheap. Poorly suited to fat-tailed crypto instruments unless the scenarios are recalibrated aggressively
• Regime-based correlation matrices. Maintain an empirical correlation matrix across every listed product on a rolling window, and charge margin against the diversified portfolio variance under a stressed regime. Captures the reality that crypto-equity correlation flips from 0.1 in calm markets to 0.7 in a de-risking event. Requires disciplined correlation-window governance or the matrix drifts
• Simple gross netting. Sum initial margin on each position, apply a fixed haircut to opposing exposures on the same underlying. Fast, transparent, and hostile to any cross-asset hedge. Ships in a week and loses the flow it was supposed to attract

The team's ~30 years of combined experience shipping matching engines and hedging stacks converge on a hybrid: SPAN-style scenario stress as the outer bound (regulatory-defensible, insurance-fund-friendly), overlaid with a correlation matrix that reduces requirements when positions genuinely offset in current market conditions. Neither alone is enough. SPAN alone over-charges under normal conditions and loses flow. Correlation alone under-charges when a de-risking event flips the sign of every correlation on the book.

Whichever methodology an operator ships, two things are non-negotiable — publish the model, and never change the requirement on a live position without a scheduled cutover. Institutional traders read margin methodology like a contract.

Single-Collateral-Pool vs Per-Market Sub-Accounts

The single-pool design lets an EUR/USD long, a BTC-PERP short and an AAPL-PERP long share one equity number, offset where they correlate and draw down together when the book moves. It is the design that makes one wallet across five asset classes a real product.

The build cost is real. The matching engine's pre-trade risk check has to read the same equity number every liquidation decision reads, on every tick, across every product. The collateral module has to reconcile deposits, funding accruals, fees and unrealised P&L into one number that never drifts from the sum of the ledger. The risk engine has to run portfolio stress across every combination of open positions, not per-market.

Per-market sub-accounts are the shortcut. Each product has its own ledger. Cross-margin only works within a product. Traders wanting a multi-asset hedge post three separate margin balances, watch three separate liquidation queues, and manually rebalance capital between them. Every institutional desk asked to trade a segregated multi-asset venue does the same thing — they trade one product on it and put the rest of their book at a competitor.

Any operator ambitious about cross-asset flow ships the single pool. Anyone shipping segregated sub-accounts is building a single-asset venue in multi-asset clothing.

Cross vs Isolated — The Default and the Override

Cross-margin as the account default with a per-position isolated override is the pattern professional flow expects. The reasoning is symmetric:

• Cross as default matches how most active traders think about their book — one equity figure, one risk waterfall, positions that back each other where they hedge
• Isolated as override exists for the specific case of a large or low-conviction position the trader refuses to let contaminate the shared pool. Isolated margin caps the loss on that position at its dedicated allocation

Operators shipping the reverse — isolated by default, cross as opt-in — find traders manually toggling every position to cross on entry, complaining about the UX, and eventually leaving for a venue that shipped the right default. The choice is not neutral.

The engineering cost of supporting both modes on the same account is straightforward — a per-position flag, distinct liquidation logic for isolated positions, and a ticket UI that surfaces the choice clearly on entry. The cost of shipping only one mode is losing the flow that needs the other.

The Buying-Power Surface and Pre-Trade Risk

Every new order needs a pre-trade check that answers one question fast: does this account have the margin to open this position without breaching maintenance requirements post-fill? On a single-pool venue, that check has to run against the full portfolio-margin calculation, not against a per-market sub-account balance.

The pattern that works:

• Maintain a rolling buying-power surface per account, updated on every mark-price tick and every position change
• Expose the surface to the matching engine's pre-trade risk hook, keyed by account
• Return a hard reject on any order that would push post-fill equity below aggregate maintenance
• Cache aggressively — buying power changes at mark-price frequency, not at order-submission frequency, so a per-tick recompute plus per-position delta is sufficient

Operators who skip the buying-power surface and recompute portfolio margin from scratch on every pre-trade check ship a matching engine that stalls under load. The pre-trade path lives on the critical latency budget and cannot afford a full portfolio revaluation per order.

Cross-Margin Cascade — The Failure Mode Operators Plan For

The design failure mode of cross-margin is the cascade — one position's liquidation pulls account equity down to a level where unrelated positions on the same account also fall into maintenance breach and get liquidated in the same waterfall.

Three levers dampen it:

• Mark-price integrity. A blended, throttled, outlier-rejecting mark feed prevents a single upstream print from spiking one position's liquidation and cascading through the rest. The mark-price hardening described in matching engine architecture is the same mechanism that protects the cross-margin book from feed spikes
• Tiered liquidation prioritisation. When maintenance breaches, the risk engine liquidates in a defined order — largest-loss position first, or largest-notional first, or least-correlated first depending on the venue's design. A well-designed order clears the account faster with less collateral damage than a naive simultaneous close-all
• Insurance-fund coverage. Residual losses after liquidation land in the insurance fund, not on other traders' books. A well-provisioned fund is the last line of defence against a cascade that outruns the liquidation engine

None of these eliminate cascade risk. They contain it. Operators who plan for cascade get to survive the tail events that expose venues that did not.

What Basis Points Ships

Basis Points ships a single-collateral-pool margin engine with a hybrid SPAN-plus-correlation portfolio margin methodology by default. Cross-margin is the account default with a per-position isolated override. The pre-trade risk check reads a per-account buying-power surface refreshed on every mark tick. The mark-price feed is blended from at least three independent sources with median filtering. Liquidation prioritisation is configurable per operator; the default clears largest-loss positions first, with tier ladders that step maintenance up on very large notional to protect the book.

Operators licensing the platform inherit these defaults and can tune methodology weights, tier ladders and isolated-margin availability per their own risk tolerance. The ops surface exposes portfolio margin decomposition per account — which offsets are being credited, which positions drive the current requirement, which accounts sit close to maintenance — so the risk team can see the shape of the book before it becomes a cascade. The funding-arb flow that a well-designed cross-margin engine attracts pays for the platform layer above it.

Every default in the stack reflects the team's ~30 years of combined experience shipping matching engines, hedging stacks and venue infrastructure. Cross-margin across asset classes is the part of a multi-asset venue that most quietly separates a product built by people who have run this book before from a product built to look like they have.

Frequently Asked Questions

Evaluating the platform?

Related articles