White-label crypto exchange development

Development of White-Label Crypto Exchange

White-label crypto exchange is a ready-made cryptocurrency trading platform that a client receives under their own brand. This is not a clone with a rebranded logo: full-fledged product includes matching engine, custodial system, KYC/AML integrations, liquidity and compliance layer. Let's break down what's included in architecture, where real complexity lies and how to distinguish quality solution from cheap knockoff.

What's Included in White-Label Exchange

Mandatory Components

Trading core:

• Matching engine—heart of exchange, order execution
• Order management system (OMS)—lifecycle management
• Market data system—quote generation and distribution, candles
• Risk engine—pre-trade and post-trade checks

Custodial system:

• HD wallet generator—unique addresses for each user
• Cold/hot wallet management—separation of operational and stored funds
• Deposit detection—monitoring incoming transactions
• Withdrawal processor—processing withdrawals with multi-sig

Compliance:

• KYC/AML integration (Sumsub, Jumio, Onfido)
• Transaction monitoring (Chainalysis, Elliptic)
• FATF Travel Rule support
• Reporting tools

User Interface:

• Trading terminal (spot + optionally derivatives)
• Wallet and transaction history
• Admin panel—user management, risk, liquidity

API:

• REST + WebSocket for traders
• FIX protocol for institutional (optional)
• Admin API for integrations

Optional Modules

• Margin / Futures trading
• P2P platform
• Launchpad / IEO
• Staking
• NFT marketplace
• Referral and loyalty programs

Matching Engine Architecture

Matching engine is the most critical component. Performance and reliability here determine quality of entire product.

Order Book Structure

Store order book in memory, not database. Typical implementation in Rust or C++:

use std::collections::BTreeMap;

struct OrderBook {
    // BTreeMap—sorted by price, O(log n) insert/delete
    bids: BTreeMap<Price, PriceLevel>,  // DESC: best price on top
    asks: BTreeMap<Price, PriceLevel>,  // ASC: best price on bottom
    orders: HashMap<OrderId, Order>,    // fast lookup by ID
}

struct PriceLevel {
    price: Price,
    total_quantity: Quantity,
    orders: VecDeque<OrderId>,  // FIFO queue at each price level
}

FIFO matching (price-time priority)—standard for spot exchanges. Pro-rata—on some derivatives.

Order Types

Minimal set for production exchange:

Throughput and Latency

Requirements for serious exchange:

• Throughput: 10,000–100,000 orders/sec
• Latency: <1ms order-to-ack (matching), <10ms end-to-end
• Market data: <5ms from trade to stakan update for all subscribers

Achieved through: lock-free queues (LMAX Disruptor pattern), single-threaded matching core, memory-mapped files for persistence, kernel bypass networking (DPDK or RDMA in HFT).

For most white-label projects with <$10M/day volume, Go or Java sufficient with 5,000-10,000 ops/sec throughput. Rust/C++ needed at >$100M/day.

Custodial Architecture

Hot/Cold/Warm Separation

Classic storage architecture:

Cold Wallet (90%+ funds)
├── Multi-sig 3-of-5 (hardware security modules)
├── Offline transaction signing
└── Manual management, only large withdrawals

Warm Wallet (5-8%)
├── Multi-sig 2-of-3
├── Auto-replenishment from cold
└── Process large withdrawals

Hot Wallet (2-5%)
├── Single-sig or 1-of-2
├── Auto-process small withdrawals
└── Limit: max daily volume

Transition rules:

• If hot < 1% → auto-transfer from warm
• If hot > 10% → transfer surplus to cold
• All inter-level transfers logged and alerted

HD Wallet and Addressing

Each user gets unique deposit address using BIP-44 derivation:

m / purpose' / coin_type' / account' / change / address_index
m / 44'       / 0'         / 0'       / 0      / user_id

Seed phrase stored in HSM or AWS CloudHSM. Never in database or config files.

Deposit Detection

class DepositDetector:
    async def monitor_evm_deposits(self, network: str):
        """Monitor EVM deposit addresses via WebSocket"""
        async with websockets.connect(self.rpc_ws_url) as ws:
            # Subscribe to new blocks
            await ws.send(json.dumps({
                "id": 1,
                "method": "eth_subscribe",
                "params": ["newHeads"]
            }))

            async for message in ws:
                block_data = json.loads(message)
                if "params" in block_data:
                    block_hash = block_data["params"]["result"]["hash"]
                    await self.process_block(block_hash, network)

    async def process_block(self, block_hash: str, network: str):
        block = await self.get_block_with_txs(block_hash)
        deposit_addresses = await self.db.get_all_deposit_addresses(network)

        for tx in block["transactions"]:
            if tx["to"] in deposit_addresses:
                await self.process_deposit(tx, network)

            # ERC-20 transfers via logs
            if tx.get("to") in self.supported_token_contracts:
                logs = await self.get_tx_logs(tx["hash"])
                await self.process_erc20_deposits(logs, deposit_addresses)

Minimum confirmations before crediting:

• Bitcoin: 2-3
• Ethereum: 12-20 (depends on amount)
• Polygon, Arbitrum: 20-64 (depends on finality)

Liquidity and Market Making

Liquidity Problem at Start

New exchange without liquidity—empty order book. Traders won't come without liquidity, liquidity won't appear without traders. Classic chicken and egg.

Solutions:

External liquidity aggregation—integrate Binance, OKX, Kraken APIs through market making bot. Bot places orders in your book, hedges on external exchange. Spread = your income, risk = execution risk on fast moves.

B-Book model—exchange acts as counterparty. Higher risk, full liquidity control.

Liquidity aggregator integrations—B2Broker, Cumberland, Wintermute provide institutional liquidity for white-label projects for fee or spread sharing.

Market Making Bot Architecture

class MarketMaker:
    def __init__(self, symbol, external_exchange, internal_exchange):
        self.symbol = symbol
        self.hedge_exchange = external_exchange  # Binance, OKX
        self.target_exchange = internal_exchange

        self.spread_bps = 5  # 0.05% spread
        self.order_size_usd = 10_000
        self.layers = 5  # depth levels

    async def update_quotes(self):
        mid_price = await self.get_reference_price()

        for i in range(1, self.layers + 1):
            spread_multiplier = i * self.spread_bps / 10000
            bid_price = mid_price * (1 - spread_multiplier)
            ask_price = mid_price * (1 + spread_multiplier)
            size = self.order_size_usd / mid_price / i  # decrease further levels

            await self.target_exchange.place_order('buy', bid_price, size)
            await self.target_exchange.place_order('sell', ask_price, size)

KYC/AML and Compliance

KYC Levels

Travel Rule

FATF Travel Rule requires transferring originator/beneficiary info for transfers >$1000 between VASPs. Integrate with Notabene, Sygna, TRP or OpenVASP.

Ignoring Travel Rule creates legal risks in EU (MiCA), USA (FinCEN), UK.

Deployment and Infrastructure

Recommended infrastructure:

Matching Engine ────── bare metal or dedicated VPS
                        (no VMs for latency-critical)

Market Data Service ── Kubernetes + Redis Cluster

API Gateway ─────────── Kubernetes + NGINX (rate limiting, auth)

Database ────────────── PostgreSQL primary + 2 read replicas
                        (TimescaleDB for time-series)

Cache ───────────────── Redis Cluster

Queue ───────────────── Kafka (audit log, event sourcing)

Monitoring ──────────── Prometheus + Grafana + PagerDuty

Regulatory Requirements

Choosing jurisdiction is critical. Popular options:

Development of full white-label exchange: 9-18 months for team of 8-15 engineers, $500,000–$2,000,000. Existing white-label vendors (Openware, B2Broker, Merkeleon) offer basic solutions from $30,000/year—reasonable starting point for most.