Why this dispatch exists
This is the fourth dispatch in the Phase 3 synthesis series. The CySEC dispatch, DMCC and VARA dispatch, and hybrid prop firm and broker dispatch covered the three largest broker operating models in 2026. This one covers the fourth: a Crypto-Asset Service Provider operating under the EU Markets in Crypto-Assets Regulation (MiCAR), serving EU residents through a regulated crypto exchange venue.
MiCAR has been operationally in force since December 2024. The 18-month transitional window for existing operators registered under national regimes runs through July 2026, after which the harmonised EU framework is binding. By mid-2026 the operator question is no longer whether to seek CASP authorisation but where to apply, how to architect the operations across the eight CASP service categories, and which of the Phase 2 corpus vendors handle the MiCAR-specific procurement requirements that did not exist twelve months ago.
This dispatch covers what makes CASP procurement different from both CFD broker procurement under MiFID II and from VARA-supervised crypto procurement, the 14 Phase 2 chapters mapped to a CASP stack in dependency order, three archetype stacks, and the three procurement mistakes CASP operators make most often.
What makes CASP procurement different
Five constraints separate CASP procurement from the three broker operating models covered in earlier dispatches:
Eight regulated service categories, separately authorised. MiCAR Article 60 defines eight crypto-asset services: custody and administration, operation of a trading platform, exchange of crypto-assets for funds, exchange of crypto-assets for other crypto-assets, execution of orders, placing of crypto-assets, reception and transmission of orders, advice on crypto-assets, and portfolio management of crypto-assets. CASPs apply for the specific services they intend to provide; the authorisation set determines capital requirements (50,000 EUR through 150,000 EUR initial capital depending on service mix), ongoing prudential requirements, and the operational scope of the supervisory expectation. Procurement decisions follow the authorisation set, not the operator’s product ambitions.
Custody is a separate regulated decision with qualified vendor implications. Operators authorised for custody and administration must either provide custody directly under their own MiCAR authorisation or delegate to a qualified custody provider. Either choice carries procurement consequences. Direct custody requires the operator to architect cold and warm storage with segregation requirements (Article 75), insurance against loss (industry standard 50-100M EUR commercial crime cover), and ongoing security audits. Delegated custody requires the operator to contract with one of the institutional custody providers (Fireblocks, Komainu, BitGo, Anchorage Digital, Hex Trust, Copper) that have explicit MiCAR-aligned offerings. This decision lives partially inside the Phase 2 crypto exchange white-label chapter (which covers the trading venue layer) but the custody procurement is fundamentally distinct from the venue procurement and runs on a different vendor shortlist.
Travel Rule infrastructure is mandatory. The EU Transfer of Funds Regulation (TFR), in force since December 2024 alongside MiCAR, requires CASPs to transmit originator and beneficiary information on crypto-asset transfers above the 1,000 EUR threshold (Article 14) and to maintain records on all transfers regardless of value. The Travel Rule infrastructure is a separate procurement: Notabene, Sumsub’s TRP module, Veriff’s wallet attribution layer, TRP Network, OpenVASP, and Coinbase’s Travel Rule Universal Solution Technology all serve this market. The Travel Rule procurement decision is functionally separate from the KYC and AML procurement decision; many CASPs run their primary KYC vendor for client identity verification plus a Travel Rule specialist for transfer-level compliance.
Market abuse surveillance under MiCAR Title VI replaces transaction reporting. CASPs operating a trading platform are subject to MiCAR Articles 91-95 on market abuse - insider dealing, unlawful disclosure of inside information, market manipulation. The supervisory expectation is trade surveillance comparable to MAR coverage in traditional securities, calibrated for crypto-asset market dynamics including wash trading, spoofing, layering, and cross-venue manipulation. The RegTech procurement therefore looks different from CFD broker procurement: MiFIR transaction reporting drops out entirely; MiCAR Title VI surveillance replaces it with stricter requirements at trading platforms because the venue itself is regulated. Eventus Validus and Nasdaq SMARTS both extend coverage to crypto-asset surveillance; chain-specific analytics vendors (Chainalysis Reactor, Elliptic Lens, TRM Labs) sit alongside the trade surveillance layer and address blockchain-native attack vectors that traditional trade surveillance does not see.
EU passporting via single CASP authorisation. MiCAR Article 67 enables a CASP authorised in one EU member state to provide services across the EU and EEA on a passporting basis. This reshapes the jurisdiction selection: operators choose their authorising member state based on supervisory engagement quality, application processing speed, and ongoing supervisory cost rather than because they need separate authorisations per target market. Cyprus, France, Germany, Ireland, Lithuania, Luxembourg, the Netherlands, Spain, and Malta have all been active in early CASP authorisation. The procurement implication is that vendor selection follows the same passport: CASPs do not need national-specific KYC, surveillance, or custody for each EU market the way CFD brokers under MiFID II often do.
The 14 chapters mapped to a CASP stack
Foundation: what you decide first
Chapter XIV - Brokerage hosting. CASP hosting requires EU data residency under both GDPR and the MiCAR operational resilience expectations (DORA also applies from January 2025). The credible institutional paths are Equinix FR2 for Frankfurt EU-resident deployments, Equinix AM3 in Amsterdam, or Beeks Group at FR2 for managed proximity compute. CASPs operating a trading platform typically run higher infrastructure density than CFD brokers because of order book matching engine throughput, blockchain node infrastructure for the supported chains, and the operational separation between fiat rails and crypto rails. Pulsant is UK-only and not relevant to MiCAR scope. CASPs running cold custody in-house additionally require physically separate facilities for HSM-secured key storage with specific physical security certifications (typically SOC 2 Type II plus a vendor-specific custody audit framework).
Trading layer: your venue and execution
Chapter X - Crypto exchange white-label. This chapter is the most directly relevant of the Phase 2 set for CASP operators. The procurement decision spans broker-stack-bundled platforms (B2BX from B2Broker, Soft-FX, Match-Trade Crypto, Quadcode crypto), institutional crypto-native platforms (ChainUp, AlphaPoint), high-throughput matching engines (Modulus, ETNA), and open-source platforms (HollaEx, Openware). The Phase 2 review surfaced that Match-Trade Crypto and ETNA Software were LIMITED for actual crypto procurement because of disclosed scope gaps; these are not suitable for MiCAR-authorised CASP deployments.
The procurement filter for a MiCAR CASP is specifically: does the platform support the operator’s authorised service categories (custody, exchange, trading platform operation, order routing) with operational separation between fiat and crypto rails, MiCAR-aligned reporting hooks, and integration interfaces for the qualified custody provider the CASP has selected? Most operators running broker-stack-bundled platforms also run B2BX or Soft-FX for the crypto venue specifically because the architectural separation from the CFD platform makes the MiCAR audit story cleaner.
Chapter II - Alternative white-label platforms. Largely irrelevant for pure CASPs. Operators running a hybrid CASP plus CFD broker model maintain MT4/MT5/cTrader on the CFD side and a separate crypto exchange platform on the CASP side; these never share an MT5 instance under MiCAR.
Chapter VIII - Liquidity providers. Crypto-asset liquidity procurement is its own market distinct from FX LP procurement. The vendors are different: B2BX liquidity, AlphaPoint, BitGo, Cumberland (Cumberland’s MiCAR-aligned offering), Wintermute, GSR, Genesis, Falcon X. Most CASPs run 3-5 liquidity providers for spread aggregation and redundancy plus access to one or two centralised exchanges (Binance, Coinbase Institutional, Kraken Pro) for backstop liquidity on long-tail tokens. Decentralised exchange (DEX) aggregator routing is a separate procurement at tier-1 scale only.
Chapter IX - Risk management. CASP risk management is structurally different from CFD broker risk management. The risk dimensions are: market risk on the inventory the operator holds across listed tokens, counterparty risk on liquidity providers and centralised exchange relationships, operational risk on custody arrangements (key compromise, sub-custodian failure, smart contract exploit in DeFi-adjacent products), and conduct risk on the trading venue (wash trading, market manipulation by venue clients). The risk vendor decision is therefore specifically: does the vendor’s product cover crypto-native market risk and counterparty risk with the right asset coverage? Most Phase 2 chapter risk management vendors are calibrated for FX and CFD risk; the subset extending to crypto-asset coverage with explicit MiCAR-aligned reporting is narrower.
Compliance layer: the supervisory stack
Chapter III - KYC / AML for brokers. CASP KYC requirements differ from CFD broker KYC at the wallet attribution layer. The Phase 1 KYC chapter covers identity verification, address verification, sanctions screening, and ongoing PEP monitoring - all required for CASPs. Additionally CASPs need wallet ownership verification (linking the client’s identity to specific blockchain addresses they control) and counterparty risk scoring on incoming and outgoing transfer addresses (chain analytics integration). Sumsub, Veriff, and ShuftiPro all have crypto-specific KYC products with wallet attribution layers; pure CFD-focused KYC vendors require add-on modules or third-party integration.
Travel Rule infrastructure. Not a Phase 2 chapter category but a separate procurement decision sitting between KYC and transaction processing. Notabene, Sumsub TRP, Veriff wallet attribution, TRP Network, and Coinbase TRUST are the credible vendors. Most CASPs run their primary KYC vendor for identity verification plus a Travel Rule specialist for transfer-level compliance; some integrated KYC vendors offer Travel Rule as a bundled module. The procurement question is specifically: does the vendor support both originator-side and beneficiary-side compliance with the EU TFR threshold structure (1,000 EUR transfer trigger, recordkeeping on all transfers), and does the vendor’s network reach the counterparty VASPs the CASP transacts with?
Chapter XIII - RegTech and compliance reporting. CASP RegTech procurement is structurally simpler than CFD broker procurement because transaction reporting drops out:
-
Trade surveillance: Required under MiCAR Title VI for CASPs operating a trading platform. Eventus Validus has the strongest published crypto-asset surveillance coverage at mid-market scale. Nasdaq SMARTS is appropriate at tier-1 scale and has crypto surveillance modules. Chain analytics layered alongside trade surveillance (Chainalysis Reactor, Elliptic Lens, TRM Labs) addresses blockchain-native attack vectors that trade surveillance alone does not capture.
-
Transaction reporting: Drops out. CASPs do not submit MiFIR-equivalent reports. Travel Rule recordkeeping covers transfer-level data; periodic supervisory reporting to the home member state regulator is rule-based rather than transaction-based.
-
Comms surveillance: Required under MiCAR for staff with market-sensitive role exposure. Smarsh or Behavox covering email plus chat plus mobile is the standard procurement.
-
Regulatory change intelligence: CUBE and Corlytics both cover MiCAR and CASP-specific regulatory developments. Useful for tier-1 operators tracking ESMA technical standards updates and the parallel evolution of CASP supervisory expectations across member states.
Operations layer: where the business runs
Chapter IV - Broker CRMs. CASP CRM procurement attaches to crypto-specific operational requirements: wallet address management at the client record level, transaction history with blockchain hash references, supported asset configuration per client jurisdiction (some tokens are restricted in specific EU member states even under MiCAR passporting), and fiat-crypto conversion history for tax reporting purposes. B2Core supports this set natively because of B2Broker’s crypto exchange product positioning; other CRMs require configuration or custom integration.
Chapter VI - Payments. Payment procurement for CASPs is the single hardest operational layer. EU banking relationships for fiat on and off ramps for crypto exchanges remain restricted - many European banks decline CASP merchant accounts entirely. The credible fiat rails are SEPA integration via banks with explicit CASP merchant policies (Bank Frick, Sygnum, BCB Group, Clear Junction), SEPA Instant for retail withdrawals, and stablecoin rails for institutional clients (USDC, USDT through regulated issuers). PSP procurement at the CASP entity is meaningfully more challenging than at the CFD broker entity; many CASPs run a primary banking partner plus 2-3 PSP redundancies.
Chapter VII - IB management. CASP IB networks are smaller than CFD broker IB networks and structurally different. The conversion event is different (account opening plus first trade rather than first deposit), the rebate structure is different (per-trade commission rather than spread-share), and the IB network composition is different (often crypto-native affiliates rather than the trading IB networks that dominate the CFD market). The Phase 2 IB management chapter vendors handle CASP attribution with configuration; the procurement is straightforward at mid-market scale.
Chapter V - Turnkey suites. CASP turnkey procurement diverges from CFD broker turnkey procurement because the Phase 2 turnkey chapter is largely calibrated for FX and CFD operations. B2Broker’s combined offering (B2BX crypto exchange platform plus B2Core CRM plus B2BinPay payments plus B2Prime liquidity) is the closest to a CASP-ready turnkey suite; Soft-FX’s crypto-specific stack is the alternative. Match-Trade and Leverate turnkey suites are calibrated for hybrid CFD plus crypto operations and require explicit configuration for pure CASP deployment.
Retention layer
Chapter XI - Broker analytics and market signals. CASP analytics procurement is narrower than CFD broker analytics. The trader-facing widget vendors in the Phase 2 chapter (Trading Central, Autochartist, FXStreet) are calibrated for FX and CFD signal generation. Crypto-specific analytics vendors (CoinGecko Terminal, Glassnode for on-chain analytics, Messari Pro for institutional signals) are the procurement category most CASPs invest in instead.
Chapter XII - Copy and social trading. Largely irrelevant for pure CASPs. The copy trading vendors in the Phase 2 chapter are calibrated for FX and CFD copy execution; crypto copy trading remains a smaller market with different vendor composition (Bitget Copy, OKX Copy, eToro CryptoCopy at the centralised exchange layer; very few credible white-label crypto copy trading vendors at the CASP scale).
Vertical-specific layers
Chapter I - Prop firm technology. Largely irrelevant for pure CASPs. Some operators are experimenting with crypto-asset prop firm models but the regulatory positioning under MiCAR is unclear and the operating model is not mature.
Three archetype stacks for CASP operators
Lean Cyprus CASP (custody + exchange + execution authorisations only)
For operators with a Cyprus CASP authorisation covering custody, exchange of crypto for fiat, exchange of crypto for crypto, and execution of orders. 1,000-5,000 active accounts, focused on EU retail clients via passporting, lean engineering team. Optimise for: time to market under the MiCAR transitional window, single-vendor accountability where possible, EU banking partnership establishment.
- Hosting: Equinix FR2 direct for the trading venue plus a separate hot wallet infrastructure setup. Cold custody delegated to a qualified custody provider (Fireblocks or Komainu).
- Trading platform: B2BX from B2Broker as the broker-stack-bundled crypto exchange venue; integration with B2BinPay for fiat rails.
- Custody: Fireblocks for institutional custody with MPC key management; cold custody insurance via vendor-provided commercial crime cover.
- Liquidity: B2BX liquidity bundled plus one additional centralised exchange relationship (Kraken Pro or Coinbase Institutional) for redundancy.
- CRM: B2Core (native crypto exchange CRM, supports wallet address management and asset configuration).
- Payments: Primary banking partner (Bank Frick or BCB Group), one SEPA PSP for retail withdrawals, USDC stablecoin rail for institutional clients.
- IB management: Bundled with B2Core at lean scale.
- KYC/AML: Sumsub with crypto-specific configuration including wallet attribution layer.
- Travel Rule: Sumsub TRP module bundled with primary KYC.
- RegTech: Eventus Validus for trade surveillance with crypto-asset configuration. Smarsh for comms surveillance.
- Chain analytics: Chainalysis KYT for ongoing transfer screening.
- Risk management: Vendor-bundled with B2BX at entry scale.
- Crypto-specific analytics: CoinGecko Terminal or similar for trader-facing market data.
Total estimated annual stack cost: $400,000 to $750,000 (CASPs run materially higher operational cost than equivalent-scale CFD brokers because of custody, chain analytics, and banking complexity).
Mid-market multi-service CASP
For operators with full or near-full CASP authorisation across most service categories (custody, exchange of crypto for fiat, exchange of crypto for crypto, execution, order routing, possibly trading platform operation). 5,000-50,000 active accounts across EU passporting, dedicated tech and compliance teams. Optimise for: best-of-breed custody and chain analytics, multi-vendor redundancy for banking and liquidity, regulator-examination readiness for the home member state authority.
- Hosting: Direct Equinix at FR2 and AM3 for redundancy. Separate physically isolated facility for cold custody infrastructure if running custody in-house; otherwise delegated.
- Trading platform: B2BX or Soft-FX for broker-stack-bundled deployments; institutional crypto-native platform (ChainUp or AlphaPoint) at the upper mid-market scale.
- Custody: Either Fireblocks or Komainu for institutional custody; BitGo Trust for US-aligned operations. In-house custody for tier-1 CASPs only.
- Liquidity: 3-5 institutional crypto liquidity providers (Cumberland, Wintermute, GSR, B2BX) plus 2-3 centralised exchange relationships for redundancy.
- CRM: B2Core or specialist crypto exchange CRM with wallet management, asset configuration, and tax reporting modules.
- Payments: 2-3 banking partners (Bank Frick, Sygnum, BCB Group, Clear Junction) plus multi-PSP SEPA stack plus USDC and USDT stablecoin rails plus institutional fiat wire infrastructure.
- IB management: Specialist IB platform with multi-tier attribution.
- Risk management: Specialist crypto-asset risk vendor with multi-venue counterparty risk scoring and inventory risk on listed tokens.
- KYC/AML: Sumsub or ShuftiPro for crypto-specific KYC with wallet attribution. Secondary screening vendor for ongoing PEP and sanctions monitoring. Manual case management.
- Travel Rule: Notabene as the primary Travel Rule infrastructure; TRP Network for counterparty VASP coverage.
- RegTech: Eventus Validus for trade surveillance with crypto-asset and traditional crossover. Chainalysis Reactor for blockchain-native analytics. Behavox for comms surveillance. CUBE for MiCAR regulatory horizon scanning.
- Crypto-specific analytics: Glassnode for on-chain analytics; Messari Pro for institutional signals.
Total estimated annual stack cost: $1.8M to $4.2M.
Tier-1 multi-jurisdiction CASP
For operators with full CASP authorisation across one EU member state plus parallel authorisations elsewhere (DIFC crypto-asset-supervised entity, VARA Dubai entity, FCA-registered UK entity), 50,000+ active accounts, in-house engineering and compliance, institutional client segment. Optimise for: best-of-breed per layer, vendor accountability via SLAs, multi-jurisdiction supervisory examination readiness, institutional-grade custody and chain analytics.
- Hosting: Direct Equinix at FR2, AM3, LD4, NY4, DX1 if VARA-dual-licensed, TY3 if Asia in scope. Avelacom or Lucera for low-latency network. Multiple physically isolated cold custody facilities for in-house custody.
- Trading platform: Institutional crypto-native platform (ChainUp, AlphaPoint) or proprietary venue. Some tier-1 CASPs run B2BX or Soft-FX as the operational venue with proprietary order routing and execution layers on top.
- Custody: In-house institutional custody with multiple physically separate cold storage facilities, MPC plus HSM hybrid key management, 50-100M EUR commercial crime insurance. Some tier-1 operators retain a delegated custody partner (Fireblocks Vault, BitGo Trust) for institutional client segregation.
- Liquidity: 5-10 institutional liquidity providers plus 5+ centralised exchange relationships plus DEX aggregator routing for long-tail tokens.
- CRM: Specialist crypto exchange CRM with in-house customisation. Cross-jurisdiction client segregation enforced at the data layer.
- Payments: 4-6 banking partners across multiple EU jurisdictions plus institutional fiat wire infrastructure plus comprehensive stablecoin rails.
- IB management: Specialist platform with in-house attribution analytics.
- Risk management: Specialist crypto-asset risk vendor plus in-house quant-built market risk and inventory risk analytics.
- KYC/AML: Tier-1 KYC vendor with wallet attribution per jurisdiction plus secondary screening plus continuous monitoring plus in-house compliance ops plus periodic third-party audit.
- Travel Rule: Notabene plus TRP Network plus Coinbase TRUST for counterparty VASP network breadth.
- RegTech: Nasdaq SMARTS for trade surveillance covering all jurisdictions plus Chainalysis Reactor plus Elliptic Lens plus TRM Labs for blockchain analytics breadth plus Behavox plus CUBE or Corlytics for multi-jurisdiction regulatory horizon scanning.
- Crypto-specific analytics: Multi-vendor stack including Glassnode plus Messari Pro plus proprietary on-chain analytics.
Total estimated annual stack cost: $8M to $40M+ depending on jurisdiction breadth and the proprietary custody investment.
Three procurement mistakes CASP operators make most often
Mistake 1: Treating custody as a venue feature rather than a separate regulated decision. Operators commonly select a crypto exchange white-label platform and assume the bundled custody capability is sufficient for CASP authorisation. MiCAR Article 75 specifically addresses custody and administration as a distinct service category with its own segregation requirements, segregation testing, sub-custody disclosure, and insurance expectations. The custody procurement decision should be made independently of the trading venue procurement decision. Operators who treat custody as a venue feature end up either rejecting the venue procurement late in the process when the custody implementation does not meet MiCAR Article 75 expectations or rebuilding the custody architecture post-authorisation at materially higher cost.
Mistake 2: Underspecifying Travel Rule counterparty coverage. The Travel Rule infrastructure procurement looks like a single-vendor decision (pick Notabene, Sumsub TRP, or TRP Network and ship it). The operational reality is that Travel Rule compliance requires the operator’s selected VASP messaging network to reach the counterparty VASPs the operator transacts with. Different Travel Rule networks have different counterparty VASP coverage; an operator whose primary outflow destinations are not on their selected Travel Rule network ends up either making manual compliance attestations (operationally unsustainable above modest transfer volumes) or running two Travel Rule infrastructure providers in parallel (the workaround mid-market CASPs frequently end up at). The procurement question at vendor selection time is specifically: which counterparty VASPs does each candidate Travel Rule network reach, and what percentage of the operator’s expected transfer flow does that coverage represent?
Mistake 3: Treating crypto-asset trade surveillance as analogous to FX trade surveillance. Many CASPs default to the trade surveillance vendor their CFD broker affiliate or their compliance team’s prior FX experience suggests. The crypto-asset market manipulation surface is meaningfully different from FX market manipulation: wash trading by exchange clients on the venue’s own order book, cross-venue manipulation coordinated through social media signals, layering attacks designed to exploit thin order book depth on long-tail tokens, and front-running of large institutional orders by venue insiders or by external observers monitoring blockchain mempool activity. Trade surveillance vendors that handle FX manipulation cleanly may not see crypto-native manipulation patterns. The procurement filter should be specifically: does the vendor have published case studies of detecting crypto-asset market abuse, does the rule library include crypto-native attack vectors, and does the alert engine integrate with blockchain analytics for venues operating on chain-aware infrastructure?
What this dispatch series covers next
Four Phase 3 synthesis dispatches shipped to date: CySEC CFD broker, DMCC plus VARA, hybrid prop firm plus broker, and CASP under MiCAR. The four largest broker and CASP operating models are covered. The remaining Phase 3 roadmap shifts focus from per-archetype synthesis to corpus maintenance:
- Vendor refresh cycle. The Phase 2 chapters most exposed to M&A activity since the original research need targeted refresh dispatches. Specifically: Cappitech under S&P Global Market Intelligence (positioning post-acquisition), TNS Financial Markets transitioning to Waypoint Trading Solutions (novation status for existing contracts), the broker analytics consolidation that has accelerated through 2025-2026, and the KYC vendor mergers driving consolidation across the identity verification market.
- Per-pillar dispatches. Selected Phase 2 chapters where editorial signal has built up (vendor enforcement actions, M&A in flight, regulatory positioning shifts) receive dispatch-format updates rather than full chapter re-audits. Candidate chapters include RegTech (where the surveillance and reporting vendor mix is shifting post-MiCAR), payments (where EU banking regime tightening since 2024 has reshaped fiat rails procurement for both CFD and CASP operators), and crypto exchange white-label (where the institutional crypto-native vendor segment has consolidated meaningfully).
- Cross-archetype synthesis. A future dispatch may map the four operator archetypes (CySEC CFD, DMCC plus VARA, hybrid, CASP under MiCAR) to a single vendor decision matrix surfacing which Phase 2 vendors are procurement-relevant for which archetype combinations. This matrix would close the synthesis arc started with the CySEC dispatch.
If you operate under a CASP authorisation and the synthesis above does not match your actual stack reality, that is the editorial signal we are looking for. The corpus improves through ground-truth from operators.