Home/Offers/Trading & Capital Markets/Crypto Market Stress API

Trading & Capital Markets

Crypto Market Stress API

Crypto markets break in a recognisable sequence. Spreads widen, depth thins, funding dislocates — and most platforms only notice when liquidations start.

Crypto exchanges
Wallets
Trading platforms
Custody providers

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

The failures in digital asset markets follow a pattern that is visible before the damage. Order book depth thins first, usually hours before price moves violently. Spreads widen across venues at different rates. Funding rates dislocate. Stablecoin pegs drift. By the time a cascade of liquidations is running, the information that could have prevented it was available and unused.

Exchanges and wallets tend to monitor price and volume because those are the easy series. Depth, cross-venue dispersion and funding structure require assembling data from multiple venues and normalising it — real work, but not research-grade difficulty.

The resulting stress measure is useful in two directions. It gives your risk team an early signal for adjusting leverage limits or margin requirements, and it gives your users a legitimate market-condition indicator that is genuinely more informative than a fear-and-greed dial.

Who buys this

Crypto exchanges, Wallets, Trading platforms, Custody providers

Category: Trading & Capital Markets

What the API returns

What comes back

Liquidity stress score per asset from depth, spread and cross-venue dispersion
Volatility regime classification with regime change detection
Order book depth analysis across venues at multiple size levels
Funding rate dislocation indicators for perpetual markets
Concentration measures for holdings and flows from public chain data
Stablecoin peg deviation monitoring
Cross-asset contagion indicators
Historical stress series for backtesting and charting

Endpoints

Method	Path	Returns
GET	/v1/stress/{asset}	Current stress scores for one asset
GET	/v1/stress	Stress across your covered universe
GET	/v1/liquidity/{asset}/depth	Order book depth across venues
GET	/v1/regime/{asset}	Volatility regime with change detection
GET	/v1/stablecoins/pegs	Peg deviation across monitored stablecoins
WS	/v1/stream	Push stress threshold breaches as they occur

Request and response

illustrative

Request

{
  "asset": "ETH",
  "venues": ["your_exchange", "aggregate"],
  "depth_levels_usd": [10000, 100000, 1000000]
}

Response

{
  "asset": "ETH",
  "as_of": "2026-10-21T15:04:00Z",
  "stress": {
    "liquidity_score": 64,
    "band": "elevated",
    "change_24h": 19
  },
  "regime": { "state": "high_volatility", "since": "2026-10-19T22:00:00Z",
              "realised_vol_30d": 0.68 },
  "depth": [
    { "size_usd": 10000,   "slippage_bps": 3.1,  "venues_quoting": 14 },
    { "size_usd": 100000,  "slippage_bps": 18.7, "venues_quoting": 11 },
    { "size_usd": 1000000, "slippage_bps": 142.4,"venues_quoting": 6 }
  ],
  "funding": { "weighted_rate_8h": 0.0412, "dislocation_score": 71 },
  "contagion": { "correlated_assets": ["SOL", "AVAX"], "score": 58 }
}

Where the data comes from

Exchange market data	Order books and trades from venues whose terms permit commercial use of derived analytics
Your own order book	Your venue's depth and flow, which is the most relevant input for your own risk decisions
Public blockchain data	On-chain flows and concentration, available from public nodes
Perpetual funding rates	Published funding across derivatives venues
Stablecoin reference prices	Multiple sources, since peg deviation shows up differently per venue
Historical archive	Stored depth and spread history, which has to be captured continuously because it is not retrievable later

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

The intelligence layer

The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.

Liquidity scoring from realised slippage at multiple size levels rather than top-of-book spread alone
Volatility regime classification with change-point detection rather than fixed thresholds
Cross-venue dispersion analysis, where divergence is often the earliest stress signal
Funding dislocation measured against each market's own historical distribution
Concentration analysis from public chain data with careful handling of exchange-controlled addresses
Contagion modelling from correlation structure shifts during stress episodes
Backtesting against historical stress events to measure how much warning the score actually gave
Continuous monitoring for venue outages, which otherwise look identical to liquidity collapse

What it changes for the business

Earlier risk response

Depth deterioration typically precedes violent price moves, which is time to adjust limits.

Liquidation management

Stress-aware margin policy reduces the cascade risk that damages both users and the venue.

User-facing market conditions

A measured stress indicator is more defensible than a sentiment dial.

Treasury and listing decisions

Liquidity scoring informs which assets to list and how to size exposure.

How it fits into your product

How it embeds

REST for point-in-time queries, WebSocket for threshold breaches
Webhooks into your risk engine for automated limit adjustment
Dashboard components for both internal risk teams and user-facing displays
Deployment inside your infrastructure where order book data cannot leave
Configurable thresholds and asset universe per deployment
Historical endpoints for backtesting your own risk policies

Included in every build

Authentication, scoped API keys and per-customer rate limiting
Input validation with predictable, documented error responses
Versioned endpoints so your integration never breaks without notice
Request and response logging for audit and dispute resolution
Latency, error-rate and usage monitoring with alerting
OpenAPI specification, sandbox environment and client examples
Backups, failover design and a documented recovery procedure
An agreed support arrangement once the service is live

How we would build it

about 20 weeks

Discovery and feasibility

Weeks 1–3

This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.

Architecture and baseline model

Weeks 4–6

A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.

Production build

Weeks 7–16

Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.

Validation and integration

Weeks 17–20

Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.

Commercial models

There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.

Fixed-scope prototype

A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.

Fixed-price build

An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.

Build then retainer

We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.

White-label product

The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.

Questions buyers ask

Which venues do you cover?

That depends on licensing. Many exchanges restrict commercial redistribution of their market data, so we establish during discovery which venues can be included for your intended use and design the coverage around those.

Can this predict a crash?

No, and we would not claim it. It measures conditions in which disorderly moves have historically been more likely. Liquidity deterioration frequently precedes trouble, but it also resolves harmlessly. It is a risk indicator, not a forecast.

Does our order book data leave our systems?

Not unless you want it to. For exchanges the usual deployment is inside your own infrastructure, where your book is analysed locally and only scores are surfaced.

How is on-chain concentration handled?

Carefully. Large addresses are frequently exchange-controlled, so naive concentration measures are misleading. We maintain exchange address classification and report concentration excluding known custodial addresses, with the assumption stated.

What history is needed before it works?

Depth and spread history is not retrievable retrospectively, so the archive has to be captured going forward. Useful regime detection needs a few months; we would normally start capture during the prototype so the archive is building while the rest is built.

All Trading & Capital Markets offers →

Want this built for your platform?

Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.

Discuss This Build Browse All Offers