Why this guide exists
Crypto exchange white-label infrastructure is structurally different from the broker stacks covered elsewhere in Brokerage Atlas. In a traditional FX or multi-asset broker build, the platform vendor governs execution quality and the broker’s primary operational risk is slippage and liquidity fragmentation. In a crypto exchange build, custody is the chokepoint. No matching engine throughput figure, no fiat conversion rate, and no jurisdictional approval compensates for a custody architecture that fails under load or exposes operator funds to hot-wallet compromise.
The three technical differentiators that matter in 2026 are: matching engine throughput measured under realistic volatility load rather than peak marketing benchmarks; custody architecture encompassing MPC, HSM, and cold-storage distribution ratios; and fiat on/off-ramp breadth, which remains the primary conversion barrier for retail-facing crypto exchanges in regulated jurisdictions. VARA in Dubai is the primary regulatory anchor for operators choosing a licensed domicile in 2026, ahead of MAS, CIMA, and offshore alternatives.
This guide draws on the 10-vendor chapter and references the payments chapter for fiat-rail context throughout. It is written for operators who have already decided to build a crypto exchange, not for operators still weighing whether to enter the category.
The four vendor archetypes
The crypto exchange WL market does not segment by feature matrix. It segments by architectural lineage - where the vendor’s core engineering originated, and how that origin shapes custody assumptions, throughput ceilings, and regulatory familiarity. Operators who apply generic broker-stack selection criteria to crypto exchange procurement routinely discover mismatches at the custody integration stage, after the commercial terms are already signed.
1. Broker-stack-bundled crypto modules
These are crypto exchange capabilities extended from a vendor that originated as a traditional multi-asset broker technology provider. The exchange module is one SKU inside a larger catalogue that also includes MT4/MT5 integration, CRM, IB management, and risk management tooling.
Examples: B2BX (within B2Broker’s stack), Soft-FX Crypto Exchange Turnkey, Quadcode Crypto, Match-Trade Crypto.
Best fit: operators already running the parent vendor’s broker infrastructure who want vendor consolidation without building a second procurement process. The integration surface is narrow because CRM, reporting, and back-office flows already share a data model with the exchange module.
The lock-in structure is the most important consideration in this archetype. Switching the exchange component typically requires renegotiating the entire stack contract, not just the exchange module. Custody architecture in broker-stack-bundled modules is frequently retrofitted rather than purpose-built, and throughput ceilings tend to be set by retail-tier assumptions (10,000 to 100,000 transactions per second) rather than institutional exchange volumes. Operators who anticipate rapid volume growth or institutional market-maker participation should model this ceiling explicitly before signing.
2. Institutional crypto-native vendors
These vendors were purpose-built for institutional crypto exchange technology, not adapted from a broker stack. Their custody architecture, matching engine design, and compliance tooling reflect decisions made for crypto from the start.
Examples: ChainUp (Singapore; over 300 exchange deployments globally across centralized, decentralized, and custody products), AlphaPoint (New York; strong LATAM market penetration including regulated deployments).
Best fit: operators who need crypto-native architecture rather than retrofitted broker technology, particularly those expecting institutional market participants, market makers, or high-frequency trading activity on the order book.
Pricing in this archetype is typically quote-only at six-figure initial deployment costs, with ongoing fees structured as percentage-of-volume or AUM-based tiers. The commercial structure is meaningfully different from broker-stack-bundled modules, and first-year P&L projections that assume broker-style pricing will be wrong.
3. High-throughput matching engine vendors
These vendors originate from traditional securities exchange technology - firms that built matching engines for equities and derivatives markets before extending to crypto. Their primary differentiation is throughput and latency performance under institutional load.
Examples: Modulus FE (Tampa, Florida; founded 1997; institutional-grade matching engines for securities and crypto), ETNA Software (Costa Mesa, California; multi-asset platform including crypto across equities, options, and digital assets).
Best fit: institutional operators with throughput requirements above the retail tier - market operators, regulated exchanges, or operators expecting sustained institutional order flow. On-premise deployment options are more commonly available in this archetype than in crypto-native or broker-bundled vendors.
Custody tooling in this archetype is typically partner-integrated rather than natively built. Operators should verify custody partner compatibility and contractual separation before assuming the custody relationship is a package deal.
4. Open-source self-hostable platforms
These vendors offer open-source exchange code with optional managed hosting, support, and custody services layered on top. The operator has access to the full codebase for audit and modification.
Examples: HollaEx (bitHolla) (Seoul; open-source exchange framework with optional cloud and on-premise deployment), Openware (OpenDAX) (Estonia; OpenDAX platform; open-source order book and matching engine with optional managed infrastructure).
Best fit: developer-led operators who want technical autonomy, transparent codebase audit capability, and lower upfront licensing costs relative to institutional crypto-native vendors. This archetype is also appropriate for operators who intend to build proprietary modifications on top of the base platform and cannot do so under a closed-source license.
The tradeoff is operationally significant. Self-hosted custody means the operator carries custody architecture decisions and the associated security burden. Compliance responsibilities - FATF travel rule, VARA reporting, suspicious activity reporting - are not bundled with the software license. Operators choosing this archetype should budget for dedicated security engineering, custody partner integration, and ongoing smart-contract or infrastructure audit costs that institutional crypto-native vendors typically absorb internally.
The five selection axes
1. Matching engine throughput
Throughput is measured in transactions per second alongside order-to-trade latency, typically expressed in microseconds at median and 99th percentile. Marketing numbers almost always reflect peak synthetic benchmarks; the operationally relevant figures are sustained throughput under realistic order book depth and latency at the 99th percentile during volatility spikes.
Institutional vendors in the high-throughput archetype (Modulus, ETNA) target one million transactions per second or above with sub-microsecond median latency. Broker-stack-bundled modules typically operate in the 10,000 to 100,000 TPS range, which is adequate for retail-facing exchanges with modest market-maker participation. Institutional crypto-native vendors (ChainUp, AlphaPoint) span both tiers depending on deployment configuration and commercial tier. Any vendor that declines to provide load-test results under realistic order book conditions - not just peak synthetic numbers - should be treated with skepticism during procurement.
2. Custody integration
Custody is the single most consequential architectural decision in a crypto exchange build. History is clear on this point: Mt Gox (2014), Bitfinex (2016), FTX (2022), and dozens of smaller incidents trace directly or indirectly to custody architecture failures - hot wallet overconcentration, inadequate key management, or absence of institutional-grade custody partners. These are cited as architectural lessons, not vendor critiques.
Operators choose between self-custody (technically possible but operationally demanding) and integrated custody through an institutional partner. The three dominant institutional custody partners in 2026 are Fireblocks, BitGo, and Copper, each with different MPC (multi-party computation) and HSM (hardware security module) architectures, fee structures, and regulatory audit trail capabilities.
WL vendors should disclose which custody partners are deeply integrated (via direct API to cold-storage signing infrastructure) versus loosely integrated (via API to custody partner’s web interface). The distinction is material under VARA and DFSA audit requirements. Operators should verify that the custody integration produces the real-time and end-of-day reporting formats required by their target regulator before deployment.
3. Fiat on/off-ramp coverage
Fiat on/off-ramp breadth is the primary conversion barrier for retail-facing crypto exchanges in regulated jurisdictions. An exchange with technically excellent matching engine performance and institutional custody will still generate poor retail acquisition economics if the fiat deposit flow requires multi-day SWIFT transfers or imposes high conversion costs.
The architecture decision is which payment rails the operator integrates and through which payment processor intermediaries. The payments chapter covers this in detail, including Match2Pay for crypto-specific fiat rails. Regional coverage is the key variable: LATAM operators need local payment rails (PayRetailers integration is relevant here); APAC operators need local bank transfer and e-wallet rails (PaymentAsia and Help2Pay are coverage signals). Operators should map their target user geography against the vendor’s payment rail coverage before procurement, not after.
4. VARA and DFSA jurisdictional fit
VARA (Dubai Virtual Assets Regulatory Authority) is the primary regulatory anchor for crypto exchange operators choosing a licensed domicile in 2026. VARA’s framework distinguishes between Virtual Asset Service Provider (VASP) licenses by activity type - exchange services, broker-dealer, and custody are separately licensed - and imposes specific technology, custody, and AML requirements that vendors must support through audit-compatible reporting.
DFSA (Dubai Financial Services Authority) covers institutional and professional-investor-facing operations within the DIFC. MAS (Monetary Authority of Singapore) and CIMA (Cayman Islands Monetary Authority) are credible alternatives for operators not seeking UAE domicile. SVG (Saint Vincent and the Grenadines) and similar offshore jurisdictions offer lower licensing cost but provide materially weaker institutional counterparty credibility, which affects market maker and institutional liquidity provider relationships.
WL vendors are technology providers, not regulators. The operator carries the license. However, vendors with documented VARA-licensed reference customers have stronger jurisdictional fit signal than vendors claiming VARA compatibility without named references. Due diligence should include direct reference checks with VARA-licensed operators on the same platform version the operator intends to deploy.
5. CEX vs DEX vs hybrid architecture
Traditional centralized exchange (CEX) architecture uses a central limit order book (CLOB) with off-chain order matching and periodic settlement. Decentralized exchange (DEX) architecture uses automated market makers (AMM) or on-chain order books with on-chain settlement. Hybrid architecture combines CEX user experience and order flow with partial on-chain settlement to address regulated operator requirements for auditability.
The 2026 trend among regulated operators is toward hybrid architecture: CEX-grade UX and throughput with on-chain settlement for a subset of assets or settlement windows, providing the VARA and DFSA audit trail that on-chain settlement creates without the latency and throughput constraints of purely on-chain matching. Most WL vendors in 2026 focus on CEX architecture. DEX tooling remains fragmented and is not yet available as a production-ready WL offering from most institutional vendors. Operators considering hybrid architecture should verify which WL vendors have production hybrid deployments under VARA or comparable jurisdictions before treating vendor marketing materials as capability evidence.
Custody and matching engine architecture
Custody architecture operates in three tiers that reflect the tradeoff between liquidity availability and theft-risk exposure.
Hot wallets are online, connected to the exchange’s withdrawal infrastructure, and allow immediate customer withdrawals. Theft risk is highest in this tier. Standard industry practice in 2026 is to hold 5 to 10 percent of total assets under management in hot wallets.
Warm wallets use MPC or multi-signature schemes, require manual approvals for large withdrawals, and support withdrawal windows measured in one to four hours. They hold 20 to 30 percent of AUM and represent the practical middle tier that absorbs daily withdrawal volume without the full theft risk of hot storage.
Cold storage is fully offline, requires multiple authorized signatories for any withdrawal, and has a 24 to 48 hour withdrawal SLA for operational use. It holds 60 to 70 percent of AUM and is the tier where institutional custody partners (Fireblocks, BitGo, Copper) provide the most value through HSM-backed key management and regulatory audit trails.
WL vendors typically integrate with one or more of these custody partners at API depth. Operators should verify whether the integration extends to cold-storage signing operations or terminates at the custody partner’s web interface - the distinction is operationally significant during high-withdrawal-volume events and during regulatory audits.
Matching engine architecture choices affect execution quality and regulatory reporting compatibility. Central limit order books are the standard for CEX architecture and provide the audit trail granularity that VARA and DFSA require. AMM architectures are DEX-native and produce a different audit trail format that is not yet compatible with all VARA reporting requirements as of mid-2026. Hybrid systems introducing on-chain settlement for specific asset classes must produce settlement finality records in formats their reporting infrastructure can consume and transmit to regulators in real time.
Latency under realistic load is operationally more important than peak throughput numbers. Vendors should provide P99 latency figures from load tests run at 80 percent of stated peak capacity with a realistic order book depth, not from synthetic benchmarks at zero order book depth. Regulatory reporting integration - real-time trade reporting, suspicious activity reporting under FATF, and travel rule compliance - must be architecturally compatible with the matching engine’s event stream. Operators who treat compliance reporting as a post-integration concern rather than an architecture requirement routinely discover late-stage incompatibilities that delay go-live.
Cost-of-ownership reality
Crypto exchange WL pricing is heterogeneous across archetypes and largely opaque at the RFP stage. Broker-stack-bundled modules are frequently offered at minimal incremental cost to operators already paying for the parent vendor’s broker infrastructure - the exchange module is a retention and upsell mechanism, not a standalone revenue line for the vendor.
Institutional crypto-native vendors (ChainUp, AlphaPoint) price at quote-only terms with six-figure initial deployment fees plus ongoing percentage-of-volume or AUM-tiered fees. Operators should request three-year total cost of ownership projections at conservative, base, and high-growth volume scenarios before signing.
Open-source platforms (HollaEx, Openware) have lower initial licensing costs but require the operator to fund self-hosted custody integration, ongoing security engineering, and compliance infrastructure that institutional vendors absorb internally. Operators who model open-source entry costs against institutional vendor quotes without including these items produce systematically incorrect comparisons.
Hidden costs that appear in first-year P&L regardless of archetype include: custody partner fees (Fireblocks, BitGo, and Copper all charge per-transaction fees plus AUM-based annual fees that scale with exchange volume); market data licensing (institutional-grade price feed providers such as CoinAPI and Kaiko charge separately from the exchange infrastructure); liquidity provision costs if the operator is not self-supplying order book depth; and ongoing security audits - smart-contract audits for any DEX-adjacent settlement components, and infrastructure audits for CEX deployments. Operators routinely underestimate ongoing custody and compliance costs by three to five times in first-year P&L projections. First-year actuals from comparable deployments, available via reference customer conversations, are more reliable than any vendor-provided cost model.
Three RFP questions to pressure-test the vendor
Question one: depeg-event circuit-breaker scenario
“Walk us through your depeg-event circuit-breaker scenario. If a major stablecoin - USDC or USDT - depegs by two percent within five minutes during high-volume trading, what is your platform’s documented response? Specifically: (a) what is the automated trading halt logic and what are the threshold parameters the operator can configure; (b) does the platform support order book rollback capability, and if so, what is the rollback window; (c) what is the communication path to the operator’s dealing desk during an automated halt event; (d) which historical reference can you provide for how your platform handled the May 2022 UST depeg or the March 2023 USDC depeg - not a hypothetical description of the circuit-breaker, but documented event logs from a production deployment?”
Vendors who respond with marketing descriptions of circuit-breaker features rather than production event logs should be treated as unverified on this axis.
Question two: custody integration architecture
“Disclose your custody integration architecture. For each supported custody partner - Fireblocks, BitGo, Copper, and any others - provide: (a) integration depth, specifically whether the integration extends to direct cold-storage signing operations or terminates at the custody partner’s API gateway; (b) withdrawal SLA at peak load for each wallet tier; (c) MPC and HSM support, including which key management schemes the integration supports; (d) the regulatory audit trail format produced for VARA and DFSA reporting requirements, and whether a current VARA-licensed operator on your platform can confirm this format has passed a VARA inspection.”
Disclosure gaps on any of the four sub-items are operationally significant, not peripheral.
Question three: VARA-licensed reference customers
“Provide VARA-licensed reference customers. For operators holding VARA Provisional or Full Licenses specifically, which are currently running production exchange operations on your platform? Provide at least three operators willing to take a reference call on three topics: the VARA application and documentation support your team provided; ongoing compliance reporting integration - specifically the real-time trade reporting and SAR submission workflow; and matching engine performance during volatility events between 2024 and 2026.”
Vendors with claimed VARA compatibility but no named reference customers willing to take a call should not be treated as VARA-compatible for procurement purposes.
How this guide will be updated
The crypto exchange white-label category evolves at a faster pace than traditional broker technology categories. Three forces drive that pace: VARA framework maturation, with VARA issuing regulatory updates and enforcement guidance on a shorter cycle than most comparable regulators; custody partner consolidation, with institutional custody market structure shifting as Fireblocks, BitGo, and Copper compete for exchange integrations and adjust their fee structures accordingly; and matching engine performance improvements, as institutional vendors extend throughput capabilities to address institutional demand for crypto execution infrastructure.
Updates to this guide are published at /corrections/ when material changes affect vendor coverage, jurisdictional analysis, or cost-of-ownership guidance. Cross-references: /setup/payments/ for fiat-rail architecture; partner programs aggregator for vendor affiliate and referral structures.
This is the tenth chapter guide in the Brokerage Atlas operator series. Phase 2 continues with broker analytics, copy-trading infrastructure, RegTech, and brokerage hosting. Operators who have completed the exchange architecture decision covered here and are moving into operational build should review the relevant custody partner and payment processor chapters before finalizing vendor contracts.