Starting one in 2026 means completing seven things in a specific order: pick an exchange model, secure a jurisdiction and license, open banking and fiat payment rails, contract liquidity, choose build versus buy, ship the platform, and pass a security audit before you take a single real deposit.
- Budget: $29,000–$64,000 for a converter or spot platform on an existing base. $130,000–$330,000 for a full spot exchange with fiat and AML. $500,000+ for a multi-product platform built from scratch.
- Timeline: 2–4 months on a white-label base. 5–6 months for a custom spot platform. 9–18 months if you need a US money transmitter footprint first.
- License: Yes, in practice. Not because code requires it, but because no bank or payment provider will onboard you without one.
- Build vs buy: Building the same spot platform from scratch costs roughly 33% more than configuring a proven base — $48,000 against $36,000 at entry level. Build from scratch only when you need a matching engine nobody else sells you.
This guide is written for founders and CTOs who already know what an order book is and want the parts nobody publishes: what banks reject, where liquidity comes from, what breaks two weeks before launch. Every number below comes from scoped commercial estimates and delivered projects.
Launch Roadmap: Eight Phases
Run these phases in the order below, but overlap phases 2, 3 and 5 with development. Teams that run them sequentially add two to three months to the calendar for no engineering reason.
| Phase | Key deliverable | Duration | Cost range | Blocks launch if missed |
| 1. Discovery & architecture | Technical documentation, user flow, system architecture, UI design | 1 month | Included in build | Yes — every later estimate depends on it |
| 2. Legal structuring & licensing | Entity, license application, compliance policies | 3–12 months (parallel) | $15,000–$150,000+ external | Yes — blocks banking |
| 3. Banking & PSP onboarding | Fiat account, payment provider contracts | 2–6 months (parallel) | Setup fees + rolling reserve | Yes — no fiat, no retail users |
| 4. Core platform build | Trading engine, wallets, admin panel, user app | 1–5 months | $22,400–$330,000 | Yes |
| 5. Node deployment & sync | Running full nodes per supported chain | 1–10 days (parallel, start day one) | $800–$1,000 per chain | Yes — Bitcoin is the long pole |
| 6. Liquidity integration | Provider contract, API integration, monitoring | 2–6 weeks | $4,000 per venue + float | Yes — an empty order book kills conversion |
| 7. Compliance stack | KYC, KYT, Travel Rule, transaction monitoring | 3–6 weeks | $2,500 per service + per-check fees | Yes |
| 8. Security audit & mainnet testing | Penetration test, real-asset deposit/withdrawal cycles | 3–5 weeks | From $20,000 | Yes — do not skip this one |
1. Choose Your Exchange Model
The model decides your licensing load, your custody liability and your time to market before you write any code. Six models are viable in 2026, and they differ mainly in who holds the assets and where the liquidity comes from.
| Model | Custody | Liquidity source | Matching engine | Licensing load | Best for |
| Full CEX | You | Own order book + market maker | Yours | Heaviest | Funded teams targeting volume share |
| Broker layer (A-book) | Tier-1 venue | Routed to Kraken, OKX or similar | None | Medium | Fast market entry with minimal custody risk |
| B-book platform | You | Internal, you are the counterparty | Yours | Heavy + derivatives rules | Operators who can run a risk book |
| Instant exchange | You (short-lived) | Aggregated external venues | Swap engine only | Medium | Regional on-ramps, simplest launch |
| P2P marketplace | Escrow only | Users | Ad matching | Lighter, jurisdiction-dependent | Markets with restricted banking |
| Non-custodial DEX / swap | Users | AMM pools or aggregators | On-chain | Lightest, still evolving | Crypto-native audiences, no fiat |
Two distinctions matter more than the labels. First, custody: the moment you hold customer assets, you inherit money transmission obligations in most jurisdictions and a security problem that never goes away. Second, the matching engine. A platform that routes every order to Binance through an API wrapper is not an exchange — it is a front end to somebody else's business, and the fee goes to them. The centralized vs decentralized crypto exchanges comparison covers the trade-offs in more depth.
Most launches start as an instant exchange or a broker layer and upgrade to a full CEX once volume justifies it. Design for that path from day one — retrofitting an internal order book onto a swap engine costs more than building it right the first time. If your target market has weak banking, read how to start p2p crypto exchange before committing to fiat rails, and put your revenue assumptions into a written crypto exchange business model first.
2. Jurisdiction and Licensing
Licensing is the single largest source of schedule risk in an exchange launch, and it is almost entirely outside your engineering team's control. Start it in week one.
The United States has no single exchange license. You register federally as a money services business with FinCEN, then obtain money transmitter licenses state by state — dozens of separate applications, each with its own net worth, surety bond and examination requirements. New York runs its own regime through the NYDFS BitLicense. On top of that sits the securities-versus-commodities question: the SEC supervises assets sold as investment contracts, while the CFTC covers commodity derivatives and, increasingly, spot digital commodities. The CLARITY Act — successor to 2024's FIT21 — passed the House in July 2025 and cleared Senate Banking in May 2026, but it is not law. Plan for the current split, not the proposed one.
| Jurisdiction | Regulatory path | Minimum capital | Realistic timeline | Best for |
| United States | FinCEN MSB + state-by-state MTL | Varies by state (net worth + surety bond) | 12–24 months for meaningful coverage | Well-funded teams targeting US retail |
| New York | NYDFS BitLicense | Set by the Superintendent per applicant | 12–24 months | Institutional credibility |
| European Union | MiCA CASP authorisation, passports to 27 states | €150,000 for trading platform and custody (Class 3) | 6–12 months | Single license, EU-wide reach |
| United Kingdom | FCA cryptoasset registration | No fixed floor; substance and controls tested | 9–18 months | UK retail and institutional |
| Singapore | MAS Payment Services Act, DPT service | S$250,000 base capital for major payment institution | 9–18 months | APAC operations, high bar |
| UAE (Dubai) | VARA VASP licence by activity | Activity-dependent, set per licence class | 6–12 months | MENA reach, faster than US or UK |
Under MiCA, your capital tier follows the most capital-intensive service you offer: €50,000 for advisory-only, €125,000 for exchange services, €150,000 once you operate a trading platform or hold customer assets, per ESMA's published guidance. Every CASP also needs a bank account with an EU credit institution — an EMI account does not satisfy the requirement, which is exactly where several 2026 applications stalled.
One client's Georgian licence made self-hosted Bitcoin and Ethereum nodes mandatory — a single line in a regulatory filing that added hardware procurement to the critical path and turned node synchronisation from a two-day task into a two-week one. Read the custody clauses of your target licence before choosing between Alchemy, QuickNode, Fireblocks and your own nodes. For the Gulf, how to start a crypto business in dubai covers the VARA path.
3. Banking and Fiat Payment Rails
Fiat is where most exchange launches actually die. Not the trading engine — the bank account. Banks reject crypto businesses for reasons unrelated to your code: correspondent bank policy, jurisdiction of incorporation, absence of a licence, or a compliance officer with a quota of crypto files they will not exceed this quarter.
Budget six months and expect refusals. Apply to several institutions in parallel, and read crypto friendly banks before you narrow the list. Meanwhile, architect so that fiat is a pluggable layer rather than a hard dependency.
Case: shipping fiat before the banking stack was ready
Challenge. A client needed to onboard users in multiple fiat currencies while bank relationships were still being negotiated one currency at a time. Hard-coding each currency into a release meant a deployment for every new market, and a single deposit account per currency created a concentration risk that had already triggered one account freeze elsewhere in their group.
Solution. We pre-created the fiat currencies in the admin panel and made them switchable without a release. Deposit requisites were deliberately not auto-served: with several bank accounts per currency, support issues them manually per user, which lets the operator route flows away from any account under scrutiny.
Withdrawal requisites moved from a free-form text field to structured, per-currency forms — SWIFT, bank, account number as separate validated fields, because each field is a risk control, not a UI element. Fees run on a tier-based configuration of up to ten ranges, fixed plus percentage, with a business rule that every new fiat currency pairs against USDT and nothing else.
Result. New currencies go live in hours instead of release cycles, and the design surfaced two defects early: a $1 mismatch between frontend fee preview and backend calculation, traced to two different configuration sources, and a "no matching fee tier" failure when an operator set a limit above the highest tier. Both are cheap in staging and expensive once users have money in flight. Bank API integration is priced at $2,500 per institution in our 2022–2023 estimates.
4. Liquidity: Providers, Market Makers, Aggregation
A new exchange sources liquidity three ways, and each changes your spreads, available pairs, cost and launch date. Contract a dedicated liquidity provider or market maker — B2C2, Wintermute, GSR, Cumberland — which needs capital and a commercial agreement. Route orders to a Tier-1 venue in an A-book model and take a markup. Or aggregate external order books from several exchanges into one book. Our comparison of the best crypto liquidity provider options covers the commercial side; below is the aggregation approach in production.
Case: solving the cold-start order book
Challenge. A new platform launches with an empty book. Users open the trading screen, see no depth, and leave — before any marketing spend has a chance to work. Building an internal book and buying market making is a six-figure commitment before a single validated user.
Solution. We have shipped three variants. In the aggregation model, the platform pulls quotes from two external venues simultaneously and exposes an admin-side liquidity matrix that switches providers per pair or blends them, with internal matching as a fallback — the user sees a simple converter, the complexity stays server-side.
In the broker model, the platform runs a master account with per-user sub-accounts on a Tier-1 venue and proxies every order through its REST and WebSocket APIs; there is no internal matching engine at all, which removes an entire class of risk.
In the mirroring model, a user sell order triggers a simultaneous margin borrow on the external venue at 3x, executes against that venue's market, credits the user's USDT, and settles the borrow afterwards — the book looks deep from day one because it is backed by the venue's depth.
Result. Time to a populated order book drops from months to the two-to-six weeks an integration takes, at roughly $4,000 per venue integration. The mirroring model carries a real operational cost we state plainly to clients: you must monitor margin utilisation, borrow limits and USDT collateral in real time, with Telegram and Slack alerts on every threshold. If any of those fail, user trades fail. That is the trade you are making, and it should be a conscious one.
5. Build vs Buy
The honest version: from-scratch development costs about a third more than configuring a proven base, and the difference buys you exactly one thing — control over components nobody sells you off the shelf. If your differentiator is a regional fiat corridor or a niche asset list, buy. If it is execution quality, build.
| Approach | Cost (web product) | Time to market | Control | Best for |
| White-label, minimal customisation | $36,000 | 1.5–2 months + 1 month discovery | Branding and config only | Market validation, regional on-ramps |
| White-label + custom modules | $49,000–$64,000 | 2–3 months + discovery | Custom payment and feature modules | Most funded launches |
| Custom build from scratch | $48,000–$81,000 | 3+ months + discovery | Full code ownership | Proprietary execution logic |
| From scratch on C++ or Java | $64,000–$142,000 | 3–6 months | Own matching engine | Latency-sensitive venues |
| Open-source fork | Low licence, high integration | Unpredictable | Full, with maintenance burden | Teams with deep in-house crypto engineering |
| Broker layer over external API | Lowest | 4–8 weeks | Minimal — venue sets the terms | Fastest possible market entry |
Two line items distort build-versus-buy comparisons more than anything else. Microservice architecture is priced as a 20% uplift on platform cost — skip it and you will pay far more to retrofit it, because it determines whether you scale one bottleneck service or rebuild the system. And node integration is per chain: $800 for Bitcoin, Ethereum, Litecoin and Tron, $1,000 for Solana, Arbitrum and Algorand.
Ten networks add roughly $8,500. The decision on the engine itself deserves its own analysis — build or buy matching engine works through the cost and risk of each path, and white label crypto exchange cost breaks down what a licensed base actually includes.
6. Core Platform: Features and Architecture
A production exchange is six subsystems, not one application: a matching engine, a wallet and node layer, a ledger, an admin and compliance console, the client applications, and the infrastructure that keeps all of it standing under load. The crypto exchange architecture guide covers each layer; here are the decisions that actually cost money when you get them wrong.
Accounting. One trade is not one transaction. It is a minimum of four ledger entries — transfer A to B, transfer B to A, fee from A, fee from B — and they belong in a trading-layer ledger, not in the user transaction table. We build a duplicated double-entry ledger in a separate service, compare the two continuously, and halt operations automatically on any divergence. We adopted that pattern after a client lost fee revenue to an opaque matching integration on a third-party API and could not prove where it went.
Identifiers. Sequential order and user IDs invite enumeration. Keep a UUID as the canonical system identifier and add a short Display ID for users and support. On one pre-production environment a test bot pushed internal numbering to seven digits — size the Display ID space accordingly, and prefix bot-generated orders differently so support can triage at a glance.
Scaling. Not every service should autoscale. Order book and wallet services carry state dependencies that make horizontal scaling non-trivial; API gateways and notification services do not. Define that policy before you write Helm charts. One deployment we migrated ran 17 microservices on Kubernetes with Docker and Helm, HashiCorp Vault wired into GitLab CI, per-service autoscaling and a Redpanda message bus.
Set explicit requests and limits per service — we raised a trade service from 512 MB to 768 MB on a cluster that still had spare cores, because the constraint was a pod quota, not hardware. Judge performance on p95 and p99 per endpoint, never the average, and keep the load test in CI: a scheduled job running roughly 100 virtual users against pre-production, results stored as build artifacts. On the engine itself, crypto exchange matching engine covers throughput and design.
costs to develop
your crypto project
7. Security and Compliance
Security architecture and compliance architecture are the same conversation, because both come down to controlling who can move money and proving afterwards that you did. Full detail sits in our crypto exchange security guide; this section covers the stack you need in place before launch.
| Layer | Vendor options | What it does | Integration cost |
| KYC | Sumsub, Jumio, Onfido, Ondato | Identity verification, document and liveness checks | $2,500 per service + ~$0.30 per user |
| KYT / transaction monitoring | Chainalysis, Elliptic, Crystal | Wallet and transaction risk scoring, Travel Rule data | $2,500 per service + per-screening fees |
| Custody | Fireblocks, BitGo, or self-hosted with MPC and HSM | Key management, withdrawal policy enforcement | Vendor-dependent |
| Cold storage | Ledger, Trezor, SecuX, KeepKey; multisig m-of-n | Offline custody of the reserve | $1,300–$2,300 per device integration |
| Node infrastructure | Alchemy, QuickNode, or self-hosted | Chain connectivity, address generation | $800–$1,000 per chain |
| Audit & certification | White-hat penetration test; SOC 2, ISO 27001, PCI DSS | Independent assurance for partners and regulators | From $20,000 |
Case: multi-provider AML that survives a slow vendor
Challenge. One AML provider is both vendor lock-in and a single point of failure in the compliance path. Providers return different risk taxonomies — some with 150-plus categories — on different scales, at wildly different speeds. Screening every transaction against every provider is expensive; screening none is a licence risk.
Solution. We built three configurable thresholds in USDT: below auto-approve, AML is bypassed; above enhanced-check, every active provider is called in parallel; above manual-review, the transaction goes to a compliance officer. Provider responses normalise to a single set of roughly 70 risk categories regardless of source taxonomy — that normalisation layer is what lets you swap vendors without touching business logic.
Aggregation runs on priority, high over moderate. Segmentation is percent-based rather than absolute, so the interface shows both the risk percentage and the actual exposed amount. Every inbound deposit is scored before the balance credits; exceeding the threshold freezes the funds and opens a review task, and the user simply does not see a balance update until it clears. The full lifecycle is a state machine — pending, on hold, manual review, completed, cancelled — with an audit trail storing old and new values on every threshold change, which is what an examiner under FATF standards will ask to see.
Result. Vendor-agnostic screening with a documented decision trail. Two constraints surfaced and got designed around: one provider returned results up to an hour late, so orchestration runs a timeout with fallback to available data; and 2FA prompted on every field change, which at 70-plus categories meant hundreds of prompts per profile — we moved it to profile save behind a feature flag. Real-time KYT screening at around 500 ms latency supports 3,000 to 10,000 wallet screenings a month, with multi-hop graph analysis tracing 50 to 70 hops across roughly 70 chains. Linear 0–10 scoring replaced categorical flags for a blunt reason: each false positive costs about 45 minutes of analyst time.
Second, build forced address regeneration: when an address is flagged, the system issues a new deposit address across every supported network, retires the old one, and notifies the user with a neutral security message that does not disclose the compliance trigger. Both patterns exist because an exchange's worst day is not a hack — it is discovering that tainted funds have been sitting in your hot wallet for six months.
8. What It Costs to Launch
Four scenarios, drawn from scoped commercial estimates. These figures come from proposals dated 2022–2023; rates and scope have shifted since, so treat them as structure rather than a current quote.
| Cost item | A: Instant exchange | B: Spot + margin | C: Full spot with fiat & AML | D: Multi-product from scratch |
| Backend + admin panel | $21,000 | $17,000–$46,000 | ~$135,000 | $542,000 (web total) |
| Web application | $8,000 | $5,400–$17,000 | ~$92,000 | included above |
| Cross-platform mobile | $12,000 | $7,400–$27,000 | ~$104,000 | $796,000 with mobile |
| Blockchain nodes | 12 chains included | $800–$1,000 each | $15,000 for 15 chains | $15,000 |
| External liquidity integration | $4,000 per venue | $4,000 per venue | $4,000 per venue | included |
| Bank / payment gateway | $2,500 per bank | $2,500 per bank | $2,500 per bank | included |
| KYC / AML service | $2,500 per service | $2,500 per service | $2,500 per service | included |
| Cold wallet integration | $1,300–$2,300 | $1,300–$2,300 | $1,300–$2,300 | included |
| Microservice architecture | +20% | +20% | +20% | $12,000 |
| Security audit | from $20,000 | from $20,000 | from $20,000 | from $20,000 |
| Development subtotal | ~$29,000–$41,000 | ~$22,400–$63,000 | ~$331,000 | $542,000–$796,000 |
| Licence & legal (external) | $15,000–$150,000+ depending on jurisdiction | |||
| Liquidity float (external) | Provider-dependent; a real line item, not an afterthought | |||
Scenario C is worth unpacking because it is the most common serious build. A full spot exchange with fiat rails, an AML module, CRM and analytics measured 11,173 engineering hours in one delivered scope. One developer would need 27 months; a team of thirteen delivered it in about 5.4. The admin panel alone was 1,360 hours, roughly $37,500 — teams routinely forget to budget for it because users never see it. Our detailed crypto exchange development cost breakdown includes a calculator for your own scope.
9. How Long It Takes
Development duration is rarely the constraint. Licensing and banking are, and they run on other people's calendars.
| Track | Discovery | Development | Node sync (parallel) | Licensing (parallel) | Total to live |
| White-label, minimal customisation | 1 month | 1.5–2 months | 1–10 days | varies | 2.5–3 months |
| White-label + custom modules | 1 month | 2–3 months | 1–10 days | varies | 3–4 months |
| Custom spot platform | 1 month | 3+ months | 1–10 days | varies | 4–6 months |
| Spot + margin + futures | 1 month | 5–6 months | 1–10 days | varies | 6–8 months |
| Regulated full-scale (US or EU) | 1–2 months | 6 months | 1–10 days | 9–24 months | gated by the licence |
Node synchronisation deserves its own row for a reason. A Bitcoin full node takes five to ten days to sync on dedicated hardware and longer on shared infrastructure; BNB Smart Chain and Tron sync in one to three days. If you start nodes after development finishes, Bitcoin becomes your critical path and you wait. We now spin up nodes in the first week of every crypto project regardless of whether integration work has started, because we have watched that single dependency delay production launches by a week or more.
10. What Goes Wrong: Lessons from Our Exchange Projects
The blockers that actually cost our clients time were not code problems. Across successive deployments the same four recurred, and each one is preventable with a decision made early.
Case: infrastructure timing as the real critical path
Challenge. Three consecutive deployments reached feature completion with staging green, and still could not go live. Development was finished. The platform was not launchable.
Solution. We turned each blocker into a contractual checkpoint. Node synchronisation starts in project week one, in parallel with development. Infrastructure readiness on the client side — production credentials, access provisioning — is now a named client deliverable with a date, after we watched a completed project sit idle waiting for a DevOps handover. Environment parity became a hard gate after identical code behaved differently across development, pre-production and production: charts and order book data failed to load, the admin panel returned 503s, and the frontend went black while the backend was demonstrably processing.
Deployment configuration moved into its own repository under a GitOps model, so a wrong branch cannot reach production and one team cannot deploy into another team's instance. AML and fiat modules now release on a separate stabilisation cycle from the general codebase.
Result. Losses now closed by process: a week or more of delay from an unsynchronised Bitcoin node, and two to three weeks added to finished projects waiting on production access. And one rule we do not negotiate: an exchange is not launch-ready until deposit and withdrawal flows have run end to end with real mainnet assets on every supported network. Testnet does not reproduce confirmation times under congestion, fee estimation against a real mempool, or network-imposed minimum withdrawal amounts. It costs days and a small amount of real cryptocurrency. Skip it and your users find the problems instead.
Two further patterns worth naming. Delayed testing compounds: on one engagement testing slipped by months, the release shipped without full validation, and the bug backlog degraded the system faster than the team cleared it. And crypto test suites fail non-deterministically because network state changes between morning and afternoon — design the suite to separate infrastructure failures from application bugs, or your crypto exchange development team learns to ignore red builds. For a worked example, see our Case Study How We Built a Crypto Exchange with Own Token.
FAQ
What is the difference between an A-book and a B-book exchange?
A-book routes every user order to an external liquidity provider — you are an interface and a risk-management layer, not the counterparty. B-book executes trades internally against your own book, which means you need a matching engine, a risk desk and, in most jurisdictions, a heavier licence. A-book minimises risk and gets you to market faster; B-book monetises the flow but is a materially harder system to run.
Do I need my own matching engine?
Only if execution quality is your product. A platform that wraps a Tier-1 exchange API is a front end to someone else's business — the trading fee accrues to them, not to you. If you plan to compete on volume or list assets nobody else carries, you need your own engine. If you are validating a regional market or a fiat corridor, start with a broker layer and add the engine when the volume justifies it.
Why do crypto exchange launches slip?
Almost never because of code. The recurring causes are an unsynchronised Bitcoin node on the critical path, which costs a week or more; production credentials not provisioned by the client, which has added two to three weeks to otherwise finished projects; environment drift between development, pre-production and production; and banking or licensing approvals arriving later than planned. All four are schedulable if you treat them as parallel workstreams from week one.
Can I start a crypto exchange with no coding experience?
You can commission one, but you cannot operate one without technical leadership. An exchange holds other people's money and runs 24/7 against an adversarial environment. If you do not have a CTO, hire one before you hire a development partner — otherwise you cannot evaluate the architecture you are buying, and every trade-off gets decided by whoever is selling to you.
