Crypto Custody Segregation Rules — MiCA Practitioner Guide

The most demanding workstream in a custody-providing CASP

The procedure looks short on the page. Five paragraphs of regulation plus the ESMA RTS specifying implementation detail. Operationally it is the most demanding single workstream in any custody-providing CASP. The reason: the safeguarding obligation is substantive and the supervisory expectation is detailed, so failure produces direct loss to clients.

The obligation breaks into five operational requirements:

1. Segregation. Client crypto-assets in wallets distinct from the CASP’s own assets and (where individual segregation is offered) distinct from other clients’ assets.
2. Ledger accuracy. Internal ledger tracks each client’s holdings continuously; daily reconciliation with on-chain holdings.
3. Bankruptcy-remoteness. Client crypto-assets ring-fenced from the CASP’s insolvency estate under home-state insolvency law.
4. Loss compensation. CASP liable for loss except where the strict Article 75(7) defence applies.
5. Sub-custody rules. Permitted only with authorised sub-custodians; CASP retains primary liability.

Each requirement involves substantial operational engineering. Together they produce a custody infrastructure that costs orders of magnitude more than the marketing-website screenshot suggests.

The segregation architecture in practice

The segregation framework segregation can be operationalised through two structures:

Individual segregation. Each client’s crypto-assets held in a wallet specific to that client. Easy to demonstrate to supervisors; expensive operationally — each wallet carries its own gas costs and key-management overhead, plus a monitoring requirement. Used by some institutional custodians for high-value clients.

Omnibus segregation. Client crypto-assets pooled in an omnibus wallet (or set of wallets) separate from the CASP’s own assets. Internal ledger tracks each client’s share. Operationally cheaper at scale; requires more rigorous ledger and reconciliation. Used by most retail-facing custodians.

The ESMA RTS allows both structures under conditions. Omnibus is permitted but requires:

• Internal ledger system that identifies each client’s holdings at any moment
• Daily reconciliation between internal ledger and on-chain holdings
• Documented procedure for handling reconciliation discrepancies
• Capability to demonstrate each client’s share on demand

In practice, a hybrid model, with institutional clients in individually-segregated wallets and retail clients in omnibus, is common. The choice depends on operating economics and client preference.

The hot/cold storage allocation

ESMA’s RTS sets a minimum cold-storage percentage for client crypto-assets. The current standard:

• 80% minimum cold storage for retail client crypto-assets
• Up to 20% in hot wallets for trading and withdrawal liquidity
• Deviations require documented risk assessment justified to the home NCA

The 80% cold floor is more conservative than industry pre-MiCA practice. Several large pre-MiCA exchanges operated with 50-60% cold; the MiCA standard raised the bar substantially.

Hot wallet allocation is one of the more frequently inspected aspects of CASP custody. Enforcement actions in Q1 2026 specifically targeted CASPs whose hot wallet percentages exceeded the RTS standard without documented risk justification. The number is not arbitrary — exceeding it produces immediate supervisory engagement.

Daily reconciliation — what it actually means

The reconciliation requirement is operationally specific:

• Frequency: At least daily, typically end-of-day
• Scope: Internal ledger vs on-chain holdings, by crypto-asset and by client
• Procedure: Documented, repeatable, formal
• Discrepancy handling: Investigated, escalated to compliance and CASP management, resolved within 24 hours

For a CASP custodying 100+ crypto-assets across 500,000+ clients, the daily reconciliation is a substantial operational workstream. Specialised vendors (Fireblocks, Anchorage, BitGo, Copper) provide tooling; in-house systems are typically more expensive to maintain.

The supervisory expectation has evolved. ESMA’s 2026 Q&A clarifies that the reconciliation must be system-level, not a spreadsheet exercise, with audit-trail capabilities and exception reporting that the home NCA can inspect.

Bankruptcy-remoteness as a legal structure

The framework requires client crypto-assets to be bankruptcy-remote from the CASP’s insolvency estate. This is not a marketing claim; it is a legal structure that has to actually produce that outcome under home-state insolvency law.

The principal structures used:

Trust-style arrangement. Client crypto-assets held in a structure governed by trust law (where home-state law recognises trusts — Ireland, UK historically, Luxembourg). The CASP is trustee; clients are beneficiaries. The structure produces bankruptcy-remoteness because trust assets are not part of the trustee’s estate.

Separate corporate entity. A subsidiary or sister company holds the client assets. The CASP and the custody entity are separate legal persons with independent insolvency exposure. Used in jurisdictions where trust law is not available (Germany historically, France).

Statutory ring-fence. Some jurisdictions have introduced specific statutory provisions creating bankruptcy-remoteness for client crypto-assets at MiCA-authorised CASPs. Lithuania’s Law on Crypto-Asset Service Providers (amended 2024) is an example.

Each approach has trade-offs around tax, governance, and operational complexity. The choice is jurisdiction-specific and warrants legal opinion before launch.

Sub-custody and the authorisation chain

The segregation framework permits sub-custody arrangements where the sub-custodian is:

• A MiCA CASP authorised in any EU member state
• A CRR credit institution
• An entity notifying under Article 60 to provide crypto-asset services
• A non-EU institution subject to equivalent supervisory standards

The CASP retains primary liability for sub-custody arrangements. Using a non-authorised sub-custodian is a substantive breach.

The sub-custody decision is one of the bigger structural choices for a CASP setting up custody operations. Building custody in-house produces full control but requires substantial infrastructure investment. Using a sub-custodian (Fireblocks, Anchorage, BitGo, Copper) produces faster time-to-market but introduces vendor risk and the operational dependency.

For mid-sized CASPs, sub-custody via a specialised provider is typically the right answer. For large CASPs with substantial custody volume, in-house custody plus selective sub-custody for specific asset classes (e.g., L2 chains) is common.

Loss compensation and the high-bar defence

Article 75(7) imposes a high standard for the CASP-defence to loss compensation. The CASP must demonstrate:

• The loss was caused by an event external to the CASP and beyond its reasonable control
• The loss could not have been avoided despite all reasonable efforts

The standard explicitly excludes:

• Smart-contract vulnerabilities in custody software (CASP responsibility)
• Hot-wallet hacks where security was sub-standard (CASP responsibility)
• Sub-custodian failures (CASP retains primary liability)
• Internal fraud (CASP responsibility)

The defence successfully applies to:

• Genuine force majeure events (war, natural disaster impacting infrastructure)
• Cryptographic-protocol failures at the consensus layer (extremely rare)
• Genuinely unforeseeable bugs that no reasonable security review would have caught

In practice the defence is hard to mount. CASPs that lose client crypto-assets typically pay compensation rather than litigate the defence.

What custody actually means — and the documented obligations

Before the segregation engineering, there’s a definitional point that trips firms up. Custody under MiCA is the safekeeping of crypto-assets or the means of access to them (typically private cryptographic keys) or the exercise of control over crypto-assets on behalf of clients. Two things follow:

• Holding the keys is custody. If the firm controls the private keys, it’s providing custody, even where it frames the product as a “wallet” or a “non-custodial-feeling” interface.
• Control is custody. Even without holding keys outright, a firm that can exercise control over client crypto-assets is in scope.

So the question is rarely “do we offer custody” — it’s more often “have we accidentally built a custody service while calling it something else.” And once a CASP is in custody scope, the rulebook is a governance rulebook, not just a technical one. Four documented obligations get tested line by line:

1. Custody agreement. A written agreement with each client setting out the CASP’s duties and responsibilities. Not a commercial term sheet — a regulatory requirement.
2. Register of positions. A register opened in each client’s name, showing that client’s entitlement; movements from client instructions recorded as soon as possible. This is the evidentiary heart of custody — at any moment the firm must show what a specific client is entitled to.
3. Custody policy. Internal rules and procedures for safekeeping and control. A summarised version must be available to clients electronically on request. A generic template that doesn’t describe the firm’s actual key-management and access controls is a substantive deficiency.
4. Segregation. Client crypto-assets clearly separated from the CASP’s own — in operations and in records.

There’s one obligation teams routinely forget: facilitating client rights. A custody-providing CASP must facilitate the exercise of rights attached to the crypto-assets, and any event likely to create or modify a client’s rights (forks, airdrops, governance events) must be recorded immediately in that client’s register of positions. A custody model built only to store and release assets misses this active duty.

And custody is a Class 2 service under MiCA Annex IV. A CASP offering it carries the Class 2 prudential floor of 125,000 euros, plus the ongoing fixed-overheads requirement, plus custody-liability insurance. “Do we hold the keys” is a strategic question at authorisation, not an operational detail — it drives the licence class, the capital, and the depth of the governance file.

Segregation under Article 75 vs the cross-cutting safeguarding duty

It’s worth being precise here, because two MiCA provisions are easy to blur. The Article 75 custody framework (segregation, the register, the policy, liability for losses) governs the custody service. But MiCA also carries a broader, cross-cutting safeguarding duty that binds any CASP holding clients’ crypto-assets or funds, whatever services it offers.

The trap is the “we don’t do custody” defence. The safeguarding duty isn’t switched on by calling yourself a custodian — it’s switched on by holding clients’ crypto-assets or funds. An exchange that keeps client balances on the platform holds client crypto-assets. A broker that holds client money holds client funds. Both are in scope, in full, whether or not custody appears anywhere in their list of services.

The core demands of the safeguarding duty:

• Safeguard clients’ ownership rights — specifically against the CASP’s own insolvency
• Segregate clients’ crypto-assets and funds from the CASP’s own holdings
• No own-account use. A CASP must not use clients’ crypto-assets or funds for its own account. Client holdings are not the firm’s working capital — a cash-flow model that quietly depends on client balances has built a breach into its business plan.
• Client funds get bank protection. Funds that aren’t e-money tokens must be placed promptly with a central bank or a credit institution, under protective arrangements.

	Cross-cutting safeguarding duty	Article 75 custody framework
Scope	Any CASP holding client crypto-assets or funds	The custody service specifically
Nature	Cross-cutting safeguarding duty	Operational rulebook for one service
Triggered by	Holding client assets or funds	Being authorised to provide custody

A firm authorised for custody is subject to both. A firm that never offers custody, whether an exchange or a broker, is still subject to the safeguarding duty the moment it holds a client balance. The insolvency test is the part that gets skipped: safeguarding arrangements aren’t judged only by how they look while the firm is healthy. If client assets would be hard to identify, or would fall into the general estate when the firm fails, the arrangement doesn’t meet the standard — however tidy it looks in normal operation.

Hot/cold architecture — multi-sig and HSM signing

The 80/20 cold-storage floor is the headline number, but the segregation framework only protects clients if the signing architecture underneath it is sound. Two architectural layers carry most of the weight.

Multi-signature. Multi-sig is the de facto standard for both hot and cold operations — multiple signers must authorise a transaction, so loss or compromise of one signer’s credentials doesn’t move client assets.

• Hot wallet multi-sig. Typically 2-of-3 or 3-of-5, with signers distributed across operational team and infrastructure. Operates at transaction speed for withdrawals and internal transfers.
• Cold wallet multi-sig. Typically 3-of-5 or 4-of-7, with signers across senior operations, security, and in some cases external custody-tech partners. Operates at scheduled-process speed — deliberate signing ceremonies with formal procedures.

Multi-sig isn’t directly mandated by Article 75, but single-signer custody draws supervisory concern even where it isn’t technically non-compliant. It does two jobs: single-signer compromise resistance, and operational-risk control — single-operator error or insider risk needs multi-person collusion to materialise.

Hardware security modules. HSMs hold private keys in tamper-resistant hardware and sign within the secure boundary, never exposing keys to general-purpose computing. FIPS 140-2 Level 3 or higher (transitioning to FIPS 140-3) is the institutional standard; common vendors include Thales, Utimaco, and AWS CloudHSM. Cold wallet HSMs are often powered on only for scheduled signing ceremonies, adding attack isolation. HSM operations carry their own discipline — signing-ceremony procedures, signer rotation, hardware lifecycle, FIPS-validation maintenance. The technical capability doesn’t automatically deliver operational security; the discipline does. Software-only signing without an HSM produces supervisory concern and insurance-underwriting difficulty at institutional scale.

The architecture runs on operational policies — hot/cold rebalancing rules, signing-approval thresholds, signing-ceremony procedures, incident response, audit trail, and the daily reconciliation already covered above. Strong technical architecture under weak operational policies still produces real custody risk. And all of it is critical ICT under DORA Article 8 — the full ICT risk-management, third-party, incident-reporting, and resilience-testing framework applies to the custody stack.

Insurance and DORA — the cover layer

Article 75 mandates segregation, not insurance — the regulation doesn’t directly require a custody-providing CASP to carry commercial cover against client crypto-asset loss. But customer-protection expectations and operational-resilience obligations create a de facto requirement for any serious operator. NCAs review insurance arrangements during authorisation. The largest customers require demonstrable cover as a condition of the relationship. Banking partners include insurance requirements in counterparty due diligence. The regulation doesn’t mandate insurance; the market does.

DORA recognises insurance as a legitimate ICT risk-transfer mechanism — crime and cyber cover reduce residual ICT risk and form part of the operational-resilience framework. The ICT risk-management framework documentation should reference insurance arrangements and identify residual risks not covered, then explain the rationale for the cover chosen. Where the operator relies on third-party custody, the sub-custodian’s insurance forms part of the DORA Article 30 third-party risk-management framework.

The 2026 commercial market offers four main coverage categories:

• Crime insurance — theft, employee dishonesty, fraudulent instruction. Covers hot- and warm-wallet theft; cold-storage cover varies. Premiums roughly 1-2% of insured value.
• Cyber insurance — hack, ransomware, business interruption, incident response. Premiums roughly 0.8-1.8%.
• Specie insurance — physical loss of cold-storage hardware. Premiums roughly 0.3-1%.
• Professional indemnity — professional-services errors and regulatory-defence costs. Varies by scope.

Market capacity aggregates to roughly USD 1.5-2 billion across Lloyd’s syndicates, AIG, Munich Re, and specialist MGAs (Coincover, BitGo Trust, Evertas). Per-operator limits typically run USD 50-500 million. Overall premiums sit around 0.5-2.5% of insured value annually, and the pricing moves with cold-storage percentage (more cold = lower premium), key-management architecture (multi-sig with M-of-N authorisation = lower premium), governance maturity, and prior loss record.

The gaps matter as much as the cover. Standard policies exclude smart-contract exploits — operators with material DeFi exposure need separate, thin, expensive, tightly-worded cover (around 3-7% of insured value). Also commonly excluded: DeFi-protocol failures, third-party-custody-held assets (the operator’s own policy may not extend to them — read the wording), regulatory-action losses, war and cyber-war, customer-side failures (lost keys, phishing), and consequential losses.

A guiding principle runs through all of it: architecture is the primary protection; insurance is the backstop. Insurance pays out after a loss — strong operational controls prevent it. Operators that under-invest in controls and lean on insurance face higher premiums, more exclusions, and lower payouts when loss happens. Self-insurance via a segregated reserve fund can make sense for smaller operators or those with overwhelming cold-storage profiles, and in jurisdictions where the regulatory framework already mandates reserves — but it requires the same documented discipline as commercial cover: a fund segregated from operator capital, governance for administration, claim-handling procedures, periodic actuarial review.

The buyer’s view

For a CASP scoping the lift in 2026:

1. Custody architecture is a structural choice, not a tactical one. Individual segregation, omnibus segregation, or hybrid — the choice shapes operating economics and supervisory relationship for the operating life of the CASP.

2. Sub-custody is often the right answer for non-specialist CASPs. Building in-house custody is a substantial engineering investment. Using a specialised sub-custodian (Fireblocks, Anchorage, BitGo, Copper) produces faster time-to-market with manageable vendor risk.

3. Daily reconciliation is non-negotiable. Plan for system-level reconciliation tooling with audit-trail and exception-reporting capabilities.

4. Bankruptcy-remoteness requires legal-structure work. Trust arrangements, separate corporate entities, or statutory ring-fence — pick the structure that fits home-state law and implement it properly.

5. The 80% cold-storage floor is real. Operating models that depend on hot-wallet liquidity above the RTS standard need to be re-engineered before authorisation.

6. Insurance is the backstop, not the protection. Build crime, cyber, specie, and PI cover calibrated to the actual hot/cold split — but treat it as the layer behind robust architecture, not a substitute for it. Document the cover in the DORA framework.

7. The safeguarding duty reaches you even without a custody licence. An exchange or broker holding client balances carries the cross-cutting safeguarding obligation (segregation, the own-account ban, the insolvency test) whether or not custody appears in its list of services.

For customers evaluating a custody-providing CASP, the questions to ask:

• What is the segregation structure (individual / omnibus / hybrid)?
• What is the cold-storage percentage?
• What is the signing architecture — multi-sig threshold and HSM standard?
• Is sub-custody used and with which authorised provider?
• What is the legal structure producing bankruptcy-remoteness?
• What is the daily reconciliation procedure and how is it audited?
• What insurance cover is in place, and what does it exclude?

The procedure produces meaningful protection for client crypto-assets when properly operationalised. The operational complexity that protection requires is substantial. CASPs that invest in the infrastructure once and operate at scale realise economies; those that treat custody as a tactical bolt-on rarely operate it cleanly.