CASP Hot vs Cold Wallet Architecture — Article 75 Segregation 2026

What Article 75 actually requires

MiCA Article 75 sets the segregation framework for CASP-held client crypto-assets. The article requires:

Segregation from CASP’s own assets. Client crypto-assets must be held in arrangements that keep them separate from the CASP’s own balance-sheet assets. The principle: client assets are not part of the CASP’s insolvency estate.

Identifiability. Each client’s holdings must be separately identifiable through CASP records. The CASP must be able to demonstrate at any time which assets belong to which client.

Adequate safekeeping. The CASP must apply adequate safekeeping measures including operational, technical, and governance controls.

Restriction on use. CASPs cannot use client crypto-assets for their own account or for other clients without explicit client authorisation under the article’s framework.

The four principles look administratively clear. The operational implementation is harder — Article 75 segregation operates on top of physical custody architecture. The architecture choices determine whether segregation actually works in practice.

The hot/cold logic

The hot/cold split is the foundational architectural choice in CASP custody. The split addresses a basic operational trade-off:

Hot wallets are operationally accessible. Private keys are held in online infrastructure that can sign transactions quickly. Client withdrawal requests, internal transfers, and operational movements use hot wallet capacity. Operational efficiency is high.

Hot wallets are attack-exposed. Online infrastructure faces network-borne attack vectors. The longer the hot wallet exposure, the higher the cumulative attack risk. Hot wallet compromise produces immediate asset loss.

Cold wallets are operationally slower. Private keys are held in offline or HSM-isolated infrastructure. Signing transactions requires deliberate operational process. Time-to-transaction is longer.

Cold wallets are attack-resistant. Offline or HSM-isolated keys are not exposed to network-borne attack vectors. Compromise requires either physical access or sophisticated supply-chain or insider attack — both far higher barriers than online compromise.

The hot/cold split balances the trade-off. Hot wallets hold the operationally needed transaction volume — typically 5-15% of client AUM depending on transaction profile. Cold wallets hold the bulk of the client AUM in attack-resistant storage.

The right split depends on the CASP’s operational profile:

Active trading platforms. Higher hot share (10-15%) to support withdrawal flows. The trade-off is greater exposure for greater operational responsiveness.

Custody-focused operators. Lower hot share (5-8%) since withdrawal flows are predictable and bunched. The trade-off is operational lead time on withdrawals for substantially lower attack exposure.

Institutional-only operators. Lowest hot share (2-5%) since institutional withdrawal flows are scheduled, planned, and lower frequency. Cold wallet operations cover most movement.

Multi-signature architecture

Multi-signature private-key handling is the industry-standard approach for hot and cold wallet operations. The framework requires multiple signers to authorise transactions — protecting against single-signer compromise.

Hot wallet multi-sig. Typical 2-of-3 or 3-of-5 multi-sig with signers distributed across operational team members and infrastructure. Hot wallet signing operates at transaction-speed for client withdrawal requests, internal transfers, and operational movements.

Cold wallet multi-sig. Typical 3-of-5 or 4-of-7 multi-sig with signers distributed across senior operational team, security team, and in some cases external custody-tech partners. Cold wallet signing operates at scheduled-process speed — typically requiring deliberate signing ceremonies with formal procedures.

Multi-sig delivers two core protections:

Single-signer compromise resistance. Loss or compromise of one signer’s credentials does not produce loss of client assets. Attacker needs multiple keys.

Operational risk control. Multi-sig requirement forces multi-person operational discipline. Single-operator error or insider risk requires multi-person collusion to materialise.

The multi-sig architecture is not regulatory-mandated under Article 75 directly but is the de facto standard. Single-signer custody operations face supervisor concerns even if not technically non-compliant.

Hardware security module integration

HSMs deliver cryptographically robust private-key handling. The HSM holds private keys in tamper-resistant hardware, performs signing operations within the secure boundary, and never exposes keys to general-purpose computing environments.

HSM standards. FIPS 140-2 Level 3 or higher (transitioning to FIPS 140-3) is the institutional standard. Common HSM vendors include Thales, Utimaco, AWS CloudHSM, and specialty crypto-custody HSMs from custody-tech vendors.

HSM in hot wallet operations. Hot wallet HSMs handle frequent signing operations under controlled access. The HSM operates 24/7 with operational policy controls on what transactions can sign and under what circumstances.

HSM in cold wallet operations. Cold wallet HSMs handle infrequent signing operations under formal signing-ceremony procedures. The HSM may be powered-on only for scheduled signing ceremonies, providing additional attack isolation.

HSM operational discipline. HSM operations require signing-ceremony procedures, signer rotation, hardware lifecycle management, FIPS validation maintenance, and vendor relationship discipline. The technical capability does not automatically deliver operational security — the discipline matters.

For institutional-scale CASP custody, HSM integration is the de facto standard. Software-only signing without HSM produces supervisor concerns and insurance underwriting difficulty.

DORA crossover

CASP custody architecture is critical ICT infrastructure under DORA Regulation (EU) 2022/2554. The DORA framework applies fully:

ICT risk management framework. Custody architecture risks need to be identified, assessed, treated, and monitored under the broader DORA framework. Board-level governance covers custody architecture risk specifically.

ICT third-party risk management. Custody-tech vendors (custody platform providers, HSM vendors, multi-sig orchestration providers, blockchain analytics) are ICT third parties. Vendor risk management framework, contracts, monitoring, and exit planning apply.

ICT incident reporting. Custody architecture incidents — credential compromise, signing infrastructure failure, HSM compromise — fall under DORA incident reporting framework. The 4-hour/72-hour/1-month reporting cadence applies.

Digital operational resilience testing. Custody architecture testing — including penetration testing, signing infrastructure testing, and tabletop scenario exercises — fits within the DORA TLPT framework for operators above the relevant thresholds.

The DORA framework reinforces the architecture discipline. CASPs treating DORA as a checkbox exercise produce architecture-related compliance gaps. CASPs treating DORA as the operational architecture discipline framework produce robust custody outcomes.

Insurance interaction

Crypto-asset insurance covers specific perils against the custody architecture. The principal coverage layers:

Crime insurance. Coverage for theft including insider theft. Typically covers hot wallet exposure where attack-related loss is operationally credible. Cold wallet exposure is more difficult to underwrite and often self-insured.

Specie insurance. Coverage for physical asset loss. Less commonly used for purely-digital custody but available for some architectures.

Cyber insurance. Coverage for cyber-attack-related loss including some custody-related scenarios. Coverage scope varies by policy.

Professional indemnity insurance. Coverage for operational errors producing client loss. Includes some custody-related operational scenarios.

Insurance underwriting interacts with architecture quality. Insurers conduct technical due diligence — architecture review, multi-sig framework verification, HSM standard confirmation, operational discipline assessment. Better architecture produces lower premiums and higher coverage limits. Weaker architecture produces difficult underwriting or restricted coverage.

The principle: architecture is the primary protection; insurance is the backstop. Operators that treat insurance as a substitute for architecture face premium escalation, coverage gaps, and the operational risk of relying on insurance recovery rather than asset preservation.

Operational policies that govern the architecture

The technical architecture works through operational policies. The principal policy categories:

Hot/cold rebalancing policy. Defined rules for moving assets between hot and cold. Typical triggers: hot exceeds target percentage band, hot below operational minimum, scheduled rebalancing for risk discipline. Automated rebalancing is common.

Signing approval policy. Defined approval framework for signing operations. Hot wallet operations typically operate under automated approval thresholds with manual review above threshold. Cold wallet operations require formal multi-person approval.

Signing-ceremony policy. Defined procedures for cold-wallet signing ceremonies — when ceremonies happen, who attends, what documentation, audit trail. Discipline in ceremonies prevents shortcuts that produce operational risk.

Incident response policy. Defined response framework for custody incidents — signer compromise, signing infrastructure failure, anomalous transaction attempts. Linked to DORA incident reporting framework.

Audit trail policy. Defined audit trail requirements for all custody operations. Movement records, signing approvals, ceremony documentation, anomaly investigations all need documented trail for supervisor reporting and incident reconstruction.

Reconciliation policy. Defined reconciliation framework — on-chain holdings reconciliation against internal accounting, multi-source reconciliation against blockchain analytics, exception handling. Operates daily for hot wallet, weekly to monthly for cold wallet depending on architecture.

The policies are the connection between technical architecture and operational reality. Strong technical architecture under weak operational policies produces real custody risk. The full framework needs both.

Practical takeaways

CASP custody architecture is one of the most consequential aspects of MiCA compliance. Article 75 segregation operates on top of the architecture — the architectural choices determine whether segregation actually protects clients in practice.

Three principles for operators building custody architecture:

Build governance discipline alongside technical capability. Multi-sig and HSM are necessary but not sufficient. The operational policies that govern hot/cold rebalancing, signing approvals, ceremonies, incident response, audit trails, and reconciliation are what make the architecture work in practice. Build both.

Treat the DORA framework as the operational discipline scaffolding. DORA risk management, third-party management, incident reporting, and resilience testing reinforce the custody architecture. The DORA framework is not a separate compliance exercise — it is the operational discipline scaffolding for the architecture.

Use insurance as backstop, not primary protection. Architecture is the primary protection against custody loss. Insurance is the backstop for residual scenarios. Operators that treat insurance as substitute for architecture face premium escalation and operational risk concentration.

The architecture is one of the most-tested aspects of CASP supervision. NCAs increasingly request detailed architecture documentation during authorisation review and ongoing supervision. Building it well produces clean supervisor relationship and operational resilience.

For corrections, updates, or counsel referrals on CASP custody architecture or Article 75 segregation, email [email protected].