Key Takeaways
- A centralized crypto exchange is four systems, not one: a trading core, a ledger, a custody layer, and a compliance pipeline. Most failed launches get the trading core right and the other three wrong.
- You have four build paths — custom, white-label, hybrid, and licensed source code. The choice sets your cost, your timeline, and how much of the platform you actually control.
- Development is rarely the critical path. Banking partners, licensing, and blockchain node synchronization run in parallel and usually finish later.
- Launching the software does not create liquidity. Plan market making, aggregation, or provider routing before the code is done, not after.
- KYC and KYT are different systems. Verifying a user once at signup tells you nothing about the transaction they send you six months later.
- In our exchange projects, a full platform built from scratch runs into the six-figure range and six months of engineering; a branded white-label deployment has gone live in under two weeks.
If you want to create a centralized crypto exchange, the first decision is not which language your matching engine runs in. It is which of four paths you take: build custom, deploy a white-label platform, run a hybrid where you own the frontend and route order flow to a partner, or license source code and take it in-house. Each one produces a different cost curve, a different regulatory footprint, and a different answer to the question your investors will ask — what do you actually own?
This guide covers the decisions in the order you have to make them. It is written from delivery experience: the platforms we have shipped, the parts that took longer than the estimate said, and the failures we ran into in production. Where a number appears, it comes either from our own projects or from a named external source. For the engineering deep-dive on components, see our breakdown of how trading platforms are built at scale.
Stage 1. Pick the Business Model Before the Architecture
Scope is not a feature list. It is the variable that determines your license class, your liquidity strategy, your custody obligations, and roughly 70% of your budget. Five models dominate, and they are not interchangeable.
Spot. Users trade asset for asset against an order book. Simplest risk profile: no leverage, no liquidation engine, no funding rates. Still the hardest ledger to get right, because every fill has to post correctly across two balances.
Margin. You lend against collateral. That means a liquidation engine, real-time collateral valuation, and a credit ledger that can never drift into an uncontrolled negative. In one of our platforms, the overdraft and credit contour was isolated at the balance layer rather than pushed into node infrastructure — a deliberate choice to avoid making blockchain integration carry financial logic it was never designed for.
Futures and perpetuals. A different product, not a bigger one. Funding rates, mark price, insurance fund, auto-deleveraging, and a testing burden that has nothing in common with spot. We scoped roughly three months for a perpetual futures integration on top of an existing platform — and that was integrating an external venue's liquidity, not building a derivatives engine. See our breakdown of the white label futures trading platform route if derivatives are the goal.
OTC and brokerage. No public order book. Quotes, negotiated settlement, larger tickets, heavier counterparty diligence. Architecturally the lightest, commercially the most relationship-dependent — worth reading up on OTC crypto exchange development before assuming a CEX is the right shape at all.
P2P. Users trade directly; you hold escrow and adjudicate disputes. In our implementations, funds lock for 15–30 minutes per trade and the platform manages lock/unlock plus a dispute queue. This is the model that keeps working in markets where banking rails do not — which is exactly why teams targeting emerging markets should look at how to start a P2P crypto exchange as a first product rather than a bolt-on.
None of it was in the original scope. Adding fiat staking to a platform whose accounting model never anticipated fiat is expensive. Adding it to a microservice architecture that did is a matter of weeks.
If you are still deciding whether an exchange is the right business at all, our crypto exchange business model framework works through revenue mix and unit economics before any of this becomes a build question.
Stage 2. Build vs. Buy vs. Hybrid
Make this call before you touch architecture. It changes what "architecture" even means.
| Path | Time to live | What you own | Best for | Main risk |
| Custom build | 6+ months of engineering, plus ~2 months of specification work before it | Everything: matching, ledger, custody, admin | Regulated entities, unusual products, teams raising on technology | You carry every bug and every audit finding yourself |
| White-label | Under 2 weeks in our fastest deployment; 2–4 months when the base platform needs configuration and infrastructure work | Brand, configuration, business logic settings | Speed-to-market, proven mechanics, limited engineering team | Feature ceiling set by the vendor's roadmap |
| Hybrid / broker layer | Comparable to white-label, plus integration time per venue | Frontend, users, fee logic, risk layer | Launching derivatives or deep pairs without owning liquidity | Your uptime is the venue's uptime |
| Licensed source code | White-label speed at first, custom-build cost over time | The code, once you can maintain it | Teams with in-house engineering that want to fork and diverge | You inherit an unfamiliar codebase and its technical debt |
The white-label numbers are real but conditional. Our fastest platform deployment went from contract to live in under two weeks: deploy the existing platform to a dedicated server, connect the client's domain with SSL, swap API credentials for every third-party service, apply the brand, smoke-test the critical user flows, hand over admin access. That is only possible because the underlying product was already in production somewhere else. Across our white-label deployments, the reuse model cuts cost by 60–80% against building from scratch and takes core trading mechanics close to zero risk.
What clients are paying for is configuration and the years of engineering already inside the base — the full economics are in our white label crypto exchange cost guide, and the product itself in white label centralized exchange.
The hybrid path deserves more attention than it gets. In one proposal we built the platform as a thin broker layer over a Tier-1 venue on an A-book model: users trade spot and perpetuals, orders proxy through to the venue's API, positions and history sync back, and the platform never runs a matching engine at all. Isolated margin only, because venue APIs restrict cross-margin in broker mode.
If the matching engine specifically is the decision on the table, we wrote a separate cost and risk analysis: build or buy a matching engine.
Stage 3. Target Market and Jurisdiction
Licensing runs on a slower clock than development and it constrains architecture, not just paperwork. A license that requires locally hosted key material changes your custody design. A jurisdiction with a travel-rule mandate changes your withdrawal flow. Decide this before Stage 4.
| Jurisdiction | Regime | Practical impact on the build |
| United States (federal) | Money services business registration with FinCEN under the Bank Secrecy Act | AML program, recordkeeping, suspicious activity reporting wired into the transaction pipeline — not a policy PDF |
| United States (state) | Money transmitter licensing state by state, tracked through NMLS; New York operates its own regime via NYDFS | Geo-restriction logic per state, jurisdiction blocklists in the admin panel, surety and net-worth requirements that hit runway |
| European Union | MiCA authorization as a crypto-asset service provider; consolidated text on EUR-Lex, supervisory guidance from ESMA | Segregation of client assets, disclosure obligations, incident reporting timelines |
| UAE (Dubai) | VARA licensing — see the regulator's framework | Activity-specific licenses; our guide to starting a crypto business in Dubai covers the process |
| Singapore | Payment Services Act licensing via MAS | Technology risk management expectations that shape your DevOps and incident process |
The US-specific problem
There is no single American exchange license. You register federally and then license state by state, and the two processes ask for different things. If your token list includes anything a regulator could read as a security, the SEC's position on that asset becomes a listing constraint, not a legal footnote. Build the listing workflow with a compliance gate in it from the start.
Two mechanisms you should design in regardless of jurisdiction: an admin-level jurisdiction blocklist that actually blocks registration and trading rather than hiding a UI element, and a corporate onboarding path. In one platform we split account type into Individual, Legal Entity, and Not Set. Legal entities never enter the individual verification flow — they get a separate document package and instructions. Not Set handles the user who registered but has not chosen yet, which turns out to matter for compliance analytics: without it, incomplete registrations pollute your verified-user counts.
None of this is legal advice. Licensing requirements change and vary by activity and asset. Retain counsel in every jurisdiction you intend to serve before committing to an architecture.
Stage 4. Architecture and the Matching Engine
Split the platform into three domains that fail independently: trading (order intake, matching, market data), ledger (balances, postings, fees, audit trail), and custody (keys, deposits, sweeps, withdrawals). Teams that merge these ship faster for two months and then cannot debug a balance discrepancy without reading the matching engine's logs.
Deterministic order processing
Price-time priority is the baseline. What separates a production system from a demo is what you can prove after the fact. Two entities that must never be conflated: Order ID and Matching ID. One identifies the user's instruction; the other identifies a specific match against a counterparty order. A single limit order can carry many fills from market or limit orders on the other side, and the fill list is a detail view of the parent order, not a set of duplicate orders.
We learned this the hard way. On one platform, distinct new orders were displaying the same Order ID — a defect that breaks dispute resolution and reconciliation simultaneously, even though the trades themselves executed correctly. The fix is structural: every order gets a unique identifier, execution returns an array of fills with price, amount, timestamp, and counterparty, and the admin order detail view exposes fills, status logs, and a raw JSON export for engineering diagnosis alongside a CSV export for the operations team.
Where financial logic lives
A related failure: we shipped a pricing bug on a USDT/RUB pair that lived entirely in frontend calculation logic. The engine was fine. The number the user saw was not. The working boundary we settled on — the frontend calculates for instant feedback, the backend revalidates on submit, and no business rule survives on the client alone. The same principle killed a subtler bug: a fiat pairing rule ("new fiat currencies pair only against USDT") that was enforced by the dropdown but not by the API, which allowed invalid fiat/ETH and fiat/BNB pairs to be created by an admin mistake.
Idempotency is not optimization. On one build, rapid multi-clicking the exchange button returned a 403 while the transaction still executed. Debounce on the client plus idempotent request handling on the server is the minimum bar for anything that moves money.
Order book recovery and failover
Design the platform so a liquidity provider outage degrades rather than stops the market. We put a per-pair external provider switch into the trading settings. Turn the provider off and the external chart, market data, and external liquidity disappear — but the pair stays tradable: users still place limit and market orders, orders match internally, and the platform builds its own price history from executed trades. Every execution is tagged at the source: Platform for internal matching, External Platform for provider execution or sync.
Infrastructure that survives launch day
One of our exchange deployments migrated from a monolithic VM setup to full Kubernetes orchestration as part of going to production: 17 microservices rewritten as Docker containers, Helm charts for deployment, HashiCorp Vault for secrets integrated with GitLab CI, a Horizontal Pod Autoscaler configured per service, and a Redpanda (Kafka) message bus between services.
The part that trips up teams new to this: not everything should autoscale. Order book and wallet services have state dependencies that make horizontal scaling non-trivial. Define the scaling policy that separates stateless services — API gateway, notifications — from stateful ones before you write a single Helm chart. Doing it afterward means rewriting them.
We deliberately did not fix it immediately — pooling went into the queue behind two or three more load-test runs to confirm it was a real bottleneck rather than a theoretical one. Optimize what the metrics prove, not what the architecture diagram implies.
For the component-level view of how these pieces fit together, our crypto exchange matching engine breakdown goes deeper on the trading core specifically.
Stage 5. Custody and Compliance
Custody is where an exchange either survives an incident or does not. Two decisions come first: where keys live, and who can move funds.
Hot, warm, and cold — and the model in between
Industry practice is a three-tier split: a hot wallet sized for immediate withdrawals, a warm tier requiring manual approval, and cold storage under multi-signature control holding the bulk of user funds. In our own deployments we run a hybrid model: part of the assets sit on self-hosted nodes, part are accessed through external RPC providers. The driver is usually regulatory — some licenses require locally operated nodes — combined with infrastructure cost. Node providers give you more freedom to list new tokens; your own nodes are about compliance, not convenience.
Wallet balances are isolated per product: separate spot, margin, P2P, and futures balances moving through an internal transfer layer. That isolation is what lets you enforce different risk rules per product without rewriting the accounting model.
Operational controls that actually get used
Two mechanisms from our production platforms that most build plans omit:
Hot wallet liquidity monitoring. We set a minimum balance threshold per asset — the demonstrated baseline was the equivalent of 800 USDT — and a bot posts an alert to a dedicated Telegram group when the balance drops below it. The message carries the coin, the network, the current native balance, its USDT equivalent, the configured threshold, and the exchange rate used for the conversion.
Alerts repeat up to five times at ten-minute intervals and then stop; if the balance recovers after the first, second, or third message, the series halts. Capping the escalation is the part teams forget — an alerting system that never stops is an alerting system nobody reads.
Withdrawal audit trail. After one Kubernetes migration we found that viewing a deposit address was logged but an actual hot wallet withdrawal produced no audit record — most likely a logging function that did not make it into the deployment. The required fields we now treat as mandatory: who initiated it, when, the requested amount, the amount actually sent, the balance after the operation, and the final status. An external deposit is triggered by a blockchain transaction and cannot be treated purely as an admin action; an admin-triggered withdrawal must be fully traceable.
KYC is not KYT
Verifying identity at signup tells you nothing about the transaction that arrives six months later. In our platforms, KYT runs on every inbound deposit: each transaction receives an AML risk score before the balance is credited. When a score exceeds the threshold, the system creates an admin review task and freezes the deposit — the user does not see a balance update until a compliance officer clears it.
The layer above that is forced wallet regeneration. When a deposit address is flagged, either by the scoring system or manually by a compliance officer, the platform generates a new deposit address for that user across every supported network and retires the flagged one. Future deposits to the old address are rejected or quarantined, and the user gets a neutral security notice rather than a disclosure of the compliance trigger.
Design the compliance pipeline for provider degradation, and decide in advance what the platform does when the scoring service is unavailable. "Credit the deposit and check later" is a decision, and it should be made deliberately rather than by default.
Sanctions screening and travel-rule obligations sit on top of this. The originator and beneficiary information requirements from the FATF standards apply to transfers above defined thresholds in most regulated markets, which means your withdrawal flow needs a field set your first architecture draft probably does not have. Transaction-monitoring vendors such as Chainalysis publish annual data on illicit flow patterns that is worth reading before you set your own risk thresholds. For the wider attack surface, see our crypto exchange security guide.
Stage 6. Liquidity and Fiat Rails
This is the section most build guides skip, and it is the one that kills exchanges.
Four ways to get depth
Internal liquidity. Your own market-making bots quoting both sides. Full control, full inventory risk, and it only works if you have capital to commit.
External providers. Connect to established venues and route or mirror. Our instant-exchange deployments connect two providers simultaneously — typically a pair of Tier-1 venues — with the admin panel mapping each trading pair to a specific provider or letting the system route by best rate. Rate display and balance updates run over WebSocket connections to both providers in parallel so the user sees a live rate rather than a cached one. Comparison of the options is in our rundown of the best crypto liquidity providers.
Order book mirroring. The most aggressive solution to cold start. On one platform we implemented mirroring against a major venue's spot book: when a user places a sell order, the system simultaneously borrows the equivalent amount on that venue using 3x margin, executes the sell on its market, credits the user's USDT balance, then settles the borrow when funds are available.
The user sees a populated book from day one. The tradeoff is operational: you need real-time monitoring of margin utilization, borrow limits, and USDT collateral, because if any of those fail, user trades fail. We run Telegram and Slack alerts on every critical threshold.
Provider-agnostic routing. Whatever you choose, keep the switch. Pairs should exist independently of any single external source, with execution origin tagged per fill — that is what lets you add or drop a provider without a migration.
Fiat is a parallel critical path
Banking integration is not a development task with a sprint estimate. It is a partner-dependent process that runs alongside engineering and frequently finishes later. Two design principles from our fiat work:
Settlement windows differ and the ledger must know it. EUR and USD deposit flows have different settlement characteristics — SEPA instant versus SEPA standard is not a cosmetic distinction — and the platform has to handle pending fiat deposits separately from confirmed crypto balances. Mixing them in the accounting model creates reconciliation problems that are painful to fix after launch.
Currency lifecycle belongs in the admin panel, not in a release. We added a global Active flag per currency, sitting above the operational Deposit, Withdrawal, and Convert flags. When Active is false, the currency disappears from the user wallet, spot balances, the fee and limit tables, deposit and withdrawal dropdowns, the fiat deposit and withdrawal pages, and account balances in user management — even when a user holds a non-zero balance in it.
The balance is not deleted on the backend; it stops being visible. That distinction is what lets an operator pull a currency for a regulatory restriction, a payment provider outage, or a liquidity risk without shipping code.
The same registry drives the other direction. A new fiat currency must flow automatically into fee management and limits, then into user deposit and withdrawal flows, user management balances, and the admin dashboard aggregates. Get that chain right and launching a new market becomes an operational procedure instead of a development project.
Separately, we keep user-side fees and platform costs as distinct entities: what a user pays to send an asset is not what the exchange spends consolidating a deposit, and merging them destroys your blockchain unit economics.
A concrete example of that cost side. Moving USDT from deposit addresses to the hot wallet on Tron previously meant sending roughly 15 TRX to each deposit wallet to cover network fees. We replaced that with an external Tron resource provider: the system delegates the required network resources, executes the USDT transfer, then reclaims the delegation. The blockchain fee in internal reporting can be zero because the platform used a delegated resource instead of spending TRX — and an empty TRX balance on a deposit wallet no longer blocks the sweep.
If fiat on/off-ramps are central to your model, our guide on how to create a crypto payment gateway covers the integration layer in detail.
costs to develop
your crypto exchange
Stage 7. Test, Launch, and Operate
Three things gate a real launch, and none of them are feature completeness.
Test with real assets
We do not consider an exchange ready until deposit and withdrawal flows have been tested with actual mainnet assets — real USDT, real BTC, real ETH. Not testnet coins. Testnet behavior differs from mainnet in ways that matter for money: confirmation times vary with network congestion, fee estimation algorithms behave differently under real mempool conditions, and minimum withdrawal amounts enforced by network economics only appear with real assets.
Our final testing phase funds test wallets with small amounts of real cryptocurrency and runs full deposit → trade → withdrawal cycles on every supported network. It costs time and a little money, and it is non-negotiable.
Load test the launch scope, not the roadmap
Before load testing one platform, we disabled the endpoints that would not be part of the first release so they would not distort the statistics. Then we staged the runs: a checkpoint at 100 users first, and only after that stability held did we move to business scenarios — order creation, mass order creation, mass order cancellation, and withdrawal.
Read-heavy API tests prove very little on their own. Mass creation and cancellation model what traders actually do during volatility; withdrawal testing catches the case where a platform survives web traffic and degrades on financial operations.
Know what your observability is telling you
During one pre-production cycle we hit intermittent 500s, 502s, a 400 in the KYC flow, unloaded balances, and unstable order history — much of it coinciding with deployments and continuous load testing. The team's conclusion was worth more than the fixes: the message bus was the channel through which we could see where the failure happened, not the cause of the failure. Saying "the feature is broken because of Kafka" is a category error. Separate the observation channel from the component that actually failed.
We standardized the minimum evidence package for any server-side error: exact HTTP status, full server response, a screenshot of the UI context, the JSON payload or response body, the environment, the reproduction time, and the responsible backend or frontend engineer plus DevOps. Functionality that worked hours earlier and broke during a deployment or load test is not automatically a product defect — but it does not get written off as "infrastructure" either without re-verification in a stable environment.
Roll out in stages
Stabilize the core before adding features. On one platform we deliberately stopped parallel feature development and split the release: iteration one stabilized the existing spot and orders functionality and went to production; iteration two added the new modules — overdraft, analytics — through pre-production and a second stabilization pass.
Incomplete modules were hidden behind feature toggles rather than deleted, keeping margin, futures, and options out of the UI while preserving the technical base. Sometimes the best engineering decision is not to finish a feature but to hide it properly.
How Much Does It Cost to Build a Centralized Crypto Exchange?
Separate two budgets: what engineering costs, and what launching costs. They are not the same order of magnitude.
Development cost by module
The numbers below come from our internal project estimates for exchange platforms. They are per-module, which is more useful than a single platform figure because your scope decision from Stage 1 drives them directly.
| Module | Web | Mobile apps | Desktop | Admin |
| Standard base version (light) | $25,000 | $37,000 | $20,000 | $5,000 |
| Spot wallet and trading | $70,000 | $105,000 | $55,000 | $15,000 |
| Margin wallet | $20,000 | $30,000 | $16,000 | $6,000 |
| Futures wallet | $30,000 | $45,000 | $24,000 | $6,000 |
| P2P module | $18,000 | $27,000 | $15,000 | $6,000 |
| Account and consolidated balances | $18,000 | $27,000 | $15,000 | $6,000 |
| Referral system | $15,000 | $22,000 | $12,000 | $4,000 |
| Blockchain node integration (15 assets) | $15,000 | |||
A full multi-product platform across web, mobile, desktop, and admin in that same estimate totals well past seven figures. A focused web-plus-admin spot exchange is the realistic entry point for most founders. For a granular walk-through with a calculator, see crypto exchange development cost.
An hours view from a different estimate, for a spot + convert + P2P platform with web and both mobile apps: 708 backend hours, 720 web frontend hours, 744 hours each for iOS and Android, plus 200 design, 240 project management, and 80 business analysis — 3,436 hours total, landing at roughly $108,000 at our role rates. Within that, spot trading is 80 backend hours, the P2P module is 160, wallets with node-service integration across 20 blockchains is 40, and the admin system is 160 backend plus 208 frontend.
The costs that are not development
- Licensing and legal. Ranges from moderate in permissive jurisdictions to seven figures across multiple US states. This is a capital requirement, not an expense line.
- Liquidity. Either committed inventory for internal market making or provider fees and collateral for routing. Budget it as working capital.
- Security audit and penetration testing. Before launch, and again after any significant architecture change.
- Infrastructure. Nodes, clusters, storage, monitoring, secret management — and it scales with volume, not with headcount.
- Operations. Compliance officers reviewing frozen deposits, support handling disputes, DevOps on call. An exchange is a 24/7 operation from the first user.
How Long Does It Take?
There is no single number, because four workstreams run in parallel and the longest one wins.
| Workstream | Realistic duration | Notes from our projects |
| Specification and analysis | ~2 months | Precedes development in our from-scratch estimates |
| Core platform development | ~6 months | Some modules land earlier; the ledger and admin usually land last |
| White-label configuration and deployment | 2–4 months, or under 2 weeks for a pure branding deployment | Assumes infrastructure is ready; design adaptation alone takes 2–3 weeks |
| Derivatives integration on an existing platform | ~3 months | Scoped for perpetual futures via external venue API |
| Blockchain node synchronization | 1–3 days for BNB Chain or Tron; 5–10 days for a Bitcoin full node | Start on day one, in parallel with development — not after |
| Licensing and banking | Jurisdiction-dependent, frequently the longest path | Runs alongside everything else and rarely finishes first |
The node timing is not a footnote. If synchronization has not started on day one of the project, development finishes and the launch waits on Bitcoin. We have seen that delay production go-live by a week or more, which is why spinning up nodes in the first week is now standard practice on every crypto project we run.
What We Learned From Building Centralized Crypto Exchanges
- Liquidity is an architectural decision, not a marketing task. Mirroring an external order book fills your book from day one, but only if you also build the provider-agnostic switch — otherwise one venue's outage stops your market.
- The matching engine is not the hard part. The ledger is. Overdraft depends on balances, balances pull in accounting, accounting requires a transactions UI. In financial systems there are no independent modules, and that breaks every plan to develop them in parallel.
- Order ID and Matching ID are different entities, and confusing them surfaces during reconciliation, not in code review. One limit order can have many fills; the fill list is a detail of the parent order, not a set of duplicates.
- Blockchain nodes are a critical path that runs parallel to development. Bitcoin takes 5–10 days to sync; other chains take 1–3. Start in week one or the launch waits.
- Financial calculation on the frontend is a UX win and a financial risk in the same line of code. Calculate on the client for responsiveness, revalidate on the server on submit, and never let a business rule live only in a dropdown.
- Multiple AML providers do not mean reliable AML. Of four integrations, one worked, one timed out, two returned data without risk categories. Design for provider degradation, not provider availability.
- Test with real money on mainnet. Fee estimation, confirmation timing, and network minimum withdrawals all behave differently under real mempool conditions than they do on testnet.
Case Study
For a worked example of these decisions applied end to end — including the token economics layer on top of the exchange core — see our published case study on how we built a crypto exchange with its own token.
CEX Launch Checklist
Business
- Product scope locked: spot, margin, futures, OTC, P2P — and which come later
- Revenue model defined beyond trading fees: withdrawal, listing, spread, margin interest, premium tiers
- Build path chosen: custom, white-label, hybrid, or licensed source
Legal
- Target jurisdictions selected and counsel retained in each
- Registration and licensing applications filed on their own timeline
- Jurisdiction blocklist enforced in the backend, not the UI
- Corporate and individual onboarding paths separated
- Listing workflow includes a compliance gate
Technology
- Trading, ledger, and custody separated into independently failing domains
- Unique Order IDs; fills exposed with price, amount, timestamp, counterparty
- Idempotent handling on every money-moving endpoint
- Per-service scaling policy defined before infrastructure code is written
- Secrets in a managed vault, not in application configuration
- Centralized logging plus dashboards; exit codes on background jobs monitored
- Nodes provisioned in week one
Liquidity
- Depth strategy contracted before launch: internal, provider, mirroring, or a mix
- Per-pair provider switch implemented with execution origin tagging
- Fiat rails contracted; settlement windows modeled separately from crypto balances
- Currency registry driven from the admin panel with a global active flag
Security
- Hot, warm, and cold tiers defined with a documented sweep policy
- Multi-party authorization on cold withdrawals
- Hot wallet balance thresholds with capped alert escalation
- KYT scoring on inbound deposits before crediting
- Forced deposit address regeneration on a risk flag
- External security audit and penetration test completed
Operations
- Full audit trail on admin financial actions, including balance before and after
- Standardized incident evidence package agreed across QA, backend, and DevOps
- Load tests run against the launch scope, including mass order and withdrawal scenarios
- Full deposit → trade → withdrawal cycle verified with mainnet assets on every network
- Staged rollout plan with feature toggles for unfinished modules
For the full service overview, see our centralized exchange development page, or read how to build a crypto exchange from scratch if you want the step-by-step engineering view. Ready-made options are covered in our centralized exchange script overview.
About the author. Yuriy Musienko is Co-founder and CTO at Merehead. He has led delivery of centralized and decentralized exchange platforms, custody infrastructure, and fiat integration work for clients across the US, EU, and MENA.
FAQ
Do I need my own matching engine to call it an exchange?
Not legally, but commercially it matters. Without your own engine you are running an interface to somebody else's business, and the trading commission flows to the venue you route through. That is a valid model — a broker layer launches faster and carries less risk — but be clear with investors about which one you are building.
Can I launch with one blockchain and add more later?
Yes, and it is usually the right call. The constraint is architectural: build the wallet and currency registry so adding an asset is a configuration change rather than a release. If new currencies do not flow automatically into fee management, limits, balances, and reporting, each addition becomes its own project.
What actually delays exchange launches?
In our delivery experience, rarely the code. The recurring blockers are infrastructure timing: production credentials and access that the client side has not provisioned, Bitcoin node synchronization that started too late, and banking partners moving on their own schedule. We now list infrastructure readiness milestones as dated client deliverables in the contract.
How is a centralized exchange different from a decentralized one in practice?
Custody and control. A CEX holds user assets and runs an internal order book, which is what makes fiat rails, instant execution, and compliance workflows possible. A DEX settles on-chain and never takes custody. We compare the two in detail in our piece on centralized vs decentralized crypto exchanges.
Should the platform hold customer keys?
If you are building a centralized exchange, yes — custody is definitional to the model, and the engineering question is how you segment and control it, not whether to take it. If you would rather not hold keys, you are describing a different product, and a non-custodial architecture is a different build entirely.
What is the fastest realistic path to a live platform?
A branded deployment of a production-tested base. Our fastest went from contract to live in under two weeks with the client's domain, payment gateway keys, and branding — no custom features. That timeline exists because the product was already mature, not because the process was rushed. Anything requiring new modules moves into months.
