Most "how to build a crypto exchange" articles are written by people who have never operated one. They list features, quote a price and stop. This guide is different: it is structured around the decisions that actually determine whether an exchange launches on time, survives its first incident and passes due diligence from banking and compliance partners. The examples come from our work on BitXChange, a crypto-to-crypto exchange with a large catalogue of pairs and separate back offices for admins, owners and partners.
Decide what kind of exchange you are building
"Crypto exchange" covers at least four different products with different risk profiles:
| Model | What it is | Hardest part |
|---|---|---|
| Centralised spot (CEX) | You hold user funds and run an order book | Custody, matching, compliance |
| Crypto-to-crypto only | CEX without fiat on/off-ramps | Liquidity, listing operations |
| Brokerage / instant swap | Quotes from a liquidity provider, no order book | Pricing, hedging, slippage |
| DEX front end | UI over on-chain protocols, non-custodial | Wallet UX, MEV, RPC reliability |
The choice drives everything downstream. A crypto-only CEX, like BitXChange, avoids banking integrations and card processors, which removes months from the compliance roadmap, but it still needs custody, a matching engine and a listings operation. A brokerage model lets you launch with a single liquidity provider in weeks but caps your margin. A DEX front end has the lightest compliance burden but the least control over the trading experience.
If you have not made this decision explicitly, make it before anything else. Everything below assumes a centralised exchange, which is what most founders mean when they ask us for an estimate.
The core components
A production CEX has seven subsystems. You can buy some, build some and defer some, but every one of them exists on day one whether you plan for it or not.
1. Accounts, KYC and permissions
User registration, two-factor authentication, session management, device tracking and API keys. KYC is usually delegated to a provider (Sumsub, Onfido, Veriff and others) through a webhook flow: the user completes verification in the provider's widget, the provider calls your backend, your backend changes the account tier and the associated limits. Model tiers and limits as data from the start; you will change them more often than you expect.
2. Ledger
The ledger is the heart of the exchange and the part most teams underestimate. Every balance change — deposit, trade, fee, withdrawal, adjustment — must be a double-entry transaction that references its source. The ledger must be append-only, idempotent and reconcilable against on-chain balances and the matching engine's state.
Two rules we never break:
- Balances are derived from ledger entries, never updated in place without a corresponding entry.
- Every external event (a confirmed deposit, a filled order) has an idempotency key so a retried webhook or a replayed message cannot credit a user twice.
3. Matching engine
The matching engine takes orders and produces trades. For a launch with a curated set of pairs, a single-process, in-memory order book per market with a persistent event log is fast enough and far easier to reason about than a distributed design. Price-time priority, limit and market orders, cancels, and a sequence number on every event is all you need to start. Partial fills, post-only orders, stop orders and self-trade prevention follow once there is real volume.
Design the engine as a pure function over an event stream: given the same inputs, it produces the same book and trades. That makes it testable, replayable after a crash and auditable when a user disputes a fill.
4. Market data
Order book snapshots and deltas, trade ticks, candles and tickers, distributed to the browser over WebSockets. The pattern that worked for us: the engine publishes events to a message bus, a market data service maintains per-market state and fans out to clients, and the front end keeps a local, normalised store so every widget — book, chart, recent trades, open orders — renders from one source of truth. We described the front-end side of this in detail in the TradeBot case study.
5. Wallets and custody
Deposits require address generation per user and per asset, confirmation tracking with chain-specific finality rules, and reorg handling. Withdrawals require hot-wallet signing with limits, cold storage for the majority of funds, velocity checks and a manual approval queue above a threshold.
Options range from building on node infrastructure yourself to using a custody provider (Fireblocks, BitGo, Copper). For a first launch, a custody provider is almost always the right call: it shortens the roadmap by months and gives compliance partners something they recognise. Build your own only when fees or control justify the operational burden.
6. Back offices
Operators need tooling from day one: listings and pair configuration, fee schedules, user management and limits, withdrawal approvals, incident controls (halt a market, freeze an account) and reporting. On BitXChange we built three separate back offices with distinct permission sets — admins, owners and partners — because the people managing listings are not the people who should see user PII or approve withdrawals. Role-based access and audit logs on every action are non-negotiable.
7. Trading front end
The trading interface is what users judge you on, and it is also a hard engineering problem: continuous market updates, dense information, keyboard-driven order entry and zero tolerance for stale data. We build this layer in Next.js and TypeScript with a real-time store feeding independent widgets. Server rendering keeps marketing and account pages fast and indexable; the trading screen itself is a client application.
Compliance: what you actually need
Compliance is where exchange projects stall, usually because founders either ignore it or try to solve everything before launch. The practical minimum for a centralised exchange:
- Licensing or registration in your operating jurisdiction. Requirements vary enormously (EU MiCA, Lithuania and Poland VASP registration, Dubai VARA, US state money-transmitter licences). Decide the jurisdiction before architecture, because data residency and reporting requirements follow from it.
- KYC/AML programme: identity verification tiers, sanctions and PEP screening, transaction monitoring with risk scoring, suspicious activity reporting and record keeping. Most of this is delivered by providers; your system must store the evidence and act on the results.
- Travel Rule for transfers above thresholds, implemented through a provider or protocol (Notabene, Sumsub Travel Rule, TRP).
- Audit trail for every balance change and every administrative action, with retention measured in years.
- Terms, privacy and risk disclosures written by a lawyer familiar with digital assets.
We are engineers, not lawyers. What we do is translate the compliance programme into technical controls: data models for tiers and limits, webhook flows for KYC, monitoring hooks for transaction screening, immutable logs and exportable reports. Budget for a compliance advisor from the start; it is cheaper than retrofitting.
Security: the non-negotiables
Exchanges are attacked continuously from the day they appear in a block explorer. The baseline:
- Hot/cold wallet separation with strict limits on the hot wallet and multisig or MPC for cold storage.
- Withdrawal controls: address whitelisting, 2FA confirmation, time locks after security changes, velocity limits and manual review above thresholds.
- Least-privilege infrastructure, secrets in a vault, no shared credentials, and signing keys that never touch application servers.
- Rate limiting and anti-automation on authentication and trading endpoints.
- Dependency scanning, mandatory code review and an incident runbook that has been rehearsed.
- An external penetration test before launch and after major changes.
None of this is exotic. What matters is that it is designed in, not added after the first incident.
Team, timeline and budget
For a crypto-to-crypto CEX MVP — spot trading on a curated set of pairs, custody through a provider, KYC via a provider, admin back office and a web trading interface — a realistic plan is:
- Team: one tech lead, two backend engineers, one or two front-end engineers, one QA engineer, a part-time designer and a part-time project lead. Five to seven people.
- Timeline: four to six months to a controlled public launch, with internal trading on testnets by month three.
- Budget: a first milestone in the range of 40–80k USD for a focused scope with providers for custody and KYC; 150–300k USD for a platform with multiple back offices, margin products or self-managed custody. Ongoing costs include provider fees, infrastructure, security reviews and a support rotation.
A brokerage or instant-swap product can launch in six to ten weeks and a fraction of the budget; a DEX front end sits in a similar range. The reason CEX projects cost more is not the UI, it is the ledger, custody and operations.
Lessons from BitXChange
Three things we would tell anyone starting an exchange today:
Separate listings from releases. Operators must be able to add a pair, set its fees and limits and open it for trading without an engineering deployment. We built pair configuration as data with a staged rollout (hidden, read-only, live) and it removed the single biggest source of friction between the business and the engineering team.
Build the back offices early. It is tempting to ship the trading UI first and manage operations through database queries. Every exchange that does this regrets it the first time someone approves the wrong withdrawal at 3 a.m. Role-based back offices with audit logs are part of the MVP.
Treat market data as a product. Users forgive a slow settings page; they do not forgive a stale order book. A dedicated market data path — engine to bus to fan-out service to normalised client store — is what keeps the interface trustworthy under load.