Building a Secure and Efficient White-Label Crypto Exchange
Many companies choose a ready-made platform for a crypto exchange but face problems: low matching engine performance, vulnerabilities in the custodial system, non-compliance with regulatory requirements. A white-label solution from an experienced vendor is a compromise, but only if the architecture is well-designed. We share our experience: which components are critical, how a Rust-based matching engine works, why fund security is not an option but a necessity, and which jurisdictions are suitable for licensing. A quality turnkey exchange reduces capital expenditure by 2–3 times compared to building from scratch, while providing production-ready code. A typical mistake is choosing a vendor that offers only a frontend and basic API, outsourcing complex components like the matching engine and custodial system. With over 9 years of proven experience and certified security audits, we guarantee a reliable platform.
Key components of a white-label crypto exchange
A turnkey exchange is not just a clone with a repainted logo. It is a full-fledged product: matching engine, custodial system, KYC/AML, liquidity, and compliance. Let's break down the architecture, real-world challenges, and how to distinguish a quality solution from a cheap knockoff.
How does the matching engine work?
The matching engine is the critical component that determines performance. The order book is stored in memory, not in the database. A typical implementation in Rust:
use std::collections::BTreeMap;
struct OrderBook {
bids: BTreeMap<Price, PriceLevel>,
asks: BTreeMap<Price, PriceLevel>,
orders: HashMap<OrderId, Order>,
}
struct PriceLevel {
price: Price,
total_quantity: Quantity,
orders: VecDeque<OrderId>,
}FIFO matching (price-time priority) is standard for spot. Pro-rata is used for derivatives.
Production requirements: 10,000–100,000 orders/sec, latency <1ms matching, <10ms end-to-end. For volumes up to $10M/day, Go or Java is sufficient; Rust/C++ is needed for >$100M/day. A C++ matching engine handles up to 500,000 orders/sec, 10x faster than Python implementations.
| Order type | Description | Complexity |
|---|---|---|
| Market | Executes at best price | Low |
| Limit | Executes at specified price | Low |
| Stop-limit | Trigger → limit | Medium |
| Stop-market | Trigger → market | Medium |
| OCO | One-cancels-other | Medium |
| Trailing stop | Follows price | High |
| Iceberg | Hidden volume | High |
| Post-only | Maker only | Low |
| IOC / FOK | Immediate-or-cancel / Fill-or-kill | Medium |
How is fund storage organized?
Classic scheme: over 90% in a cold wallet (multi-sig, HSM), 5–8% in a warm wallet (automatic replenishment from cold), 2–5% in a hot wallet (small withdrawals). Transition logic: if hot < 1% → transfer from warm; if hot > 10% → surplus to cold.
Addressing: each user receives a unique deposit address via BIP-44 derivation. HD wallet seed phrase is stored only in HSM or AWS CloudHSM.
Deposit detection
class DepositDetector:
async def monitor_evm_deposits(self, network: str):
async with websockets.connect(self.rpc_ws_url) as ws:
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)Confirmations: Bitcoin 2–3, Ethereum 12–20, Polygon/Arbitrum 20–64.
How is the liquidity problem solved?
A new exchange without liquidity is an empty order book. Options:
- External liquidity aggregation: a market-making bot connects to Binance/OKX, places orders in your book, and hedges positions externally. Spread becomes your income.
- B-Book model: the exchange acts as counterparty (high risk, full control).
- Institutional liquidity: providers like B2Broker, Cumberland, Wintermute charge a fee or spread sharing.
A white-label solution costs 2-3 times less than building from scratch ($50,000–$100,000 license fee) while providing the same level of functionality.
Liquidity and compliance: what to consider
KYC levels: from email-only (no deposit) to institutional (no limit). The FATF Travel Rule requires transmitting sender/receiver data for transfers >$1000 between VASPs. Integration with Notabene, Sygna, or OpenVASP is mandatory for EU (MiCA), US (FinCEN), UK jurisdictions. According to a recent report, 70% of crypto exchanges face vulnerabilities in custodial systems — code audits are critical.
| Parameter | White-label | Build from scratch |
|---|---|---|
| Timeline | 3–6 months | 9–18 months |
| Cost | 2-3 times lower ($50k–$100k) | High |
| Customization | Limited | Full |
| Security | Proven code | Requires audit |
Which jurisdictions are suitable for licensing?
Popular options: Estonia (VASP), Lithuania (VASP), BVI (VASP), Seychelles, Dubai VARA, EU MiCA. The choice depends on the target market and budget. Learn more about Virtual Asset Service Provider — what it is and how it is regulated.
What's included in our white-label package
- Complete source code with documentation
- API and integration support (REST, WebSocket, FIX)
- Training for your team (up to 5 sessions)
- 6 months of post-launch support and updates
- Regular security audits and penetration testing
- Deployment on your infrastructure or cloud (bare metal + Kubernetes)
Development process and timeline
Stages: analytics → architecture design → implementation of matching engine, custodial system, frontend → integration of KYC/AML, liquidity → testing (unit, integration, pen test) → deployment on bare metal for matching engine, Kubernetes for market data, API Gateway, databases.
Recommended infrastructure: PostgreSQL + TimescaleDB, Redis Cluster, Kafka, Prometheus + Grafana. Choosing the jurisdiction is a critical decision.
From 9 to 18 months for a team of 8–15 engineers, depending on scope. Licensing a white-label vendor (Openware, B2Broker, Merkeleon) is an alternative for a quick start. The cost is calculated individually. Request a consultation to evaluate the cost and timeline for your case.
How to choose a white-label provider
- Request a technical portfolio: which blockchains are integrated, how many orders per second the matching engine can handle.
- Check if the source code is provided and auditable.
- Clarify compliance modules: which jurisdictions are supported, is Travel Rule implemented.
- Evaluate customization: can you change the interface, add pairs, configure limits.
- Request documentation for APIs and integration with external liquidity providers.
We have been developing turnkey exchanges for over 9 years: 20+ projects launched, load up to $200M/day. Contact us to discuss your project — we will select the architecture and timeline. Request a consultation to evaluate the cost and timeline for your case.