Crypto Custody Segregation Rules — MiCA Practitioner Guide

The most demanding workstream in a custody-providing CASP

Article 75 runs to nine paragraphs. Operationally it is the most demanding single workstream in any custody-providing CASP, because a failure means a direct loss to clients.

The obligations break into six groups:

1. Client agreement (75(1)). Parties, the service, the custody policy, communication and authentication, security systems, fees and the applicable law.
2. Register of positions (75(2)). One per client, matching each client’s rights; movements on client instructions recorded as soon as possible.
3. Custody policy (75(3)). Internal rules that minimise the risk of loss through fraud, cyber threats or negligence; a summary to clients electronically on request.
4. Client rights, statements and return (75(4)-(6)). Facilitating the exercise of rights, recording forks and airdrops immediately, a statement of positions at least every three months, and procedures to return assets as soon as possible.
5. Segregation (75(7)). From the CASP’s own holdings, on the ledger, in law and in operations.
6. Liability and sub-custody (75(8)-(9)). Liability for losses attributable to the CASP, capped at market value; sub-custody only with Article 59 CASPs.

The segregation architecture in practice

Article 75(7) has three layers. Client holdings are segregated from the CASP’s own, and the means of access to client assets are clearly identified as such. On the distributed ledger, clients’ crypto-assets are held separately from the CASP’s own. And the assets are legally segregated from the CASP’s estate, in accordance with applicable law, so that its creditors have no recourse to them, in particular in insolvency, as well as operationally segregated.

MiCA does not prescribe one wallet per client. Two structures meet the text:

Individual segregation. Each client’s crypto-assets in a wallet specific to that client. Easy to demonstrate to supervisors; expensive to run, because each wallet carries its own fees, key management and monitoring. Used by some institutional custodians for high-value clients.

Omnibus segregation. Client crypto-assets pooled in client-only wallets, separate from the CASP’s own, with the register of positions showing each client’s share. Cheaper at scale; it puts more weight on the register and on reconciliation. Used by most retail-facing custodians.

A hybrid, with institutional clients in individual wallets and retail clients in omnibus wallets, is common.

Hot and cold storage

MiCA sets no cold-storage percentage, and we found no ESMA technical standard or guideline that does. The binding rule is Article 75(3): the custody policy must minimise the risk of losing clients’ crypto-assets or the means of access through fraud, cyber threats or negligence. The hot wallet share is therefore the firm’s own risk decision, sized to withdrawal and trading needs, documented, and defensible to the NCA and to auditors. Many custodians keep most client assets in cold storage and set internal limits for hot balances with rebalancing triggers; those limits belong in the custody policy.

Reconciliation — good practice, not a fixed frequency

Article 75 does not set a reconciliation frequency. It requires a register of positions with movements recorded as soon as possible (75(2)), events that change client rights recorded immediately (75(4)), and statements to clients at least every three months (75(5)). A register that does not match the chain fails all three.

The practical answer is automated reconciliation between the register and on-chain balances, by asset and by client, at least daily for active platforms, with a documented procedure for investigating and escalating breaks. For a CASP holding many assets for many clients that is a system, not a spreadsheet. Tooling vendors exist; whichever is used, the CASP must be able to show the NCA the audit trail.

Bankruptcy-remoteness as a legal structure

Article 75(7) requires custody assets to be legally segregated “in accordance with applicable law” so that creditors have no recourse to them. MiCA states the outcome; national property and insolvency law delivers it. How it works depends on the home state:

• Statutory segregation. Some member states’ MiCA implementing laws or insolvency rules state that client crypto-assets held in custody do not form part of the CASP’s estate.
• Trust or fiduciary arrangements. Where national law recognises them, the CASP holds the assets as trustee or fiduciary for clients.
• Separate custody entity. A distinct legal person holds the assets, which separates its insolvency from that of the trading or brokerage entity.

The choice is jurisdiction-specific and warrants a legal opinion on the home-state result before launch.

Sub-custody and the authorisation chain

Article 75(9) is short: a CASP that uses other providers of the custody service may use only CASPs authorised under Article 59, and must inform its clients. The text has no route for credit institutions, Article 60 notifying entities or non-EU custodians as sub-custodians.

Two practical points follow. First, a technology vendor that supplies wallet or key-management software, where the CASP still holds and controls the keys, is not a sub-custodian; it is an outsourcing arrangement under Article 73 and an ICT third-party arrangement under DORA. Second, the CASP’s liability under Article 75(8) does not disappear when it chooses a sub-custodian: losing assets through a provider the CASP selected is hard to present as an event independent of its operations.

Liability for losses — Article 75(8)

A custody-providing CASP is liable to its clients for the loss of crypto-assets, or of the means of access to them, resulting from an incident attributable to it. Liability is capped at the market value of the lost crypto-asset at the time of the loss.

Incidents not attributable to the CASP are those it shows occurred independently of the provision of the service or of its operations, such as a problem inherent in the operation of the distributed ledger that the CASP does not control. In practice:

• Attributable: hot-wallet hacks enabled by weak security, flaws in the CASP’s own custody software, insider theft, operational errors in signing.
• Possibly not attributable: a failure of the underlying ledger or consensus mechanism that the CASP does not control.

The burden is on the CASP to demonstrate the exception. Firms that lose client assets usually compensate rather than litigate it.

What custody means — and the documented obligations

Before the segregation engineering, there is a definitional point that trips firms up. Custody under MiCA is the safekeeping or controlling, on behalf of clients, of crypto-assets or of the means of access to them, where applicable in the form of private keys (Article 3(1)(17)). Two things follow:

• Holding the keys is custody. If the firm controls the private keys, it provides custody, even where the product is framed as a “wallet” or a “non-custodial-feeling” interface.
• Control is custody. A firm that can control client crypto-assets without holding keys outright is in scope too.

So the question is rarely “do we offer custody”; it is more often “have we built a custody service while calling it something else”. Once in scope, four documented obligations get tested line by line:

1. Custody agreement. A written agreement with each client covering the seven items in Article 75(1). A regulatory requirement, not a commercial term sheet.
2. Register of positions. Opened in each client’s name; movements from client instructions recorded as soon as possible. At any moment the firm must be able to show what a specific client is entitled to.
3. Custody policy. Internal rules and procedures for safekeeping and control, with a summary available to clients electronically on request. A template that does not describe the firm’s actual key management and access controls is a substantive deficiency.
4. Segregation. Client crypto-assets separated from the CASP’s own, on the ledger, in law and in operations.

One obligation teams routinely forget is facilitating client rights (75(4)). Any event likely to create or modify a client’s rights, such as a fork, an airdrop or a governance event, must be recorded immediately in the register, and clients are entitled to new crypto-assets or rights in proportion to their positions unless a valid prior agreement expressly provides otherwise.

Custody is a Class 2 service under MiCA Annex IV. A CASP offering it holds permanent minimum capital of EUR 125,000, or a quarter of the previous year’s fixed overheads if higher (Article 67). “Do we hold the keys” is a strategic question at authorisation: it drives the licence class, the capital and the depth of the governance file.

Article 75 custody vs the Article 70 safekeeping duty

Two MiCA provisions are easy to blur. Article 75 governs the custody service. Article 70 is a cross-cutting safekeeping 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. Article 70 is switched on by holding client crypto-assets or funds, not by the label. 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.

What Article 70 demands:

• Safeguard ownership rights, especially against the CASP’s own insolvency, and no own-account use of clients’ crypto-assets (70(1)) or funds (70(2)). Client holdings are not the firm’s working capital.
• Client funds to a bank. Funds other than e-money tokens must be placed with a credit institution or a central bank by the end of the business day after receipt, in accounts separately identifiable from the CASP’s own (70(3)). CASPs that are themselves credit institutions, payment institutions or e-money institutions are exempt from 70(2)-(3) (70(5)).

	Article 70 safekeeping duty	Article 75 custody framework
Scope	Any CASP holding client crypto-assets or funds	The custody service specifically
Nature	Cross-cutting safekeeping 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. The insolvency test is the part that gets skipped: if client assets would be hard to identify, or would fall into the general estate when the firm fails, the arrangement does not meet the standard, however tidy it looks in normal operation.

Signing architecture — multi-sig, MPC and HSMs

MiCA prescribes no signing technology. The custody policy has to minimise loss from fraud, cyber threats and negligence, and the following is how institutional custodians usually do it.

Multi-signature or MPC. Several signers, or key shares, must take part before a transaction moves, so the loss or compromise of one credential does not move client assets, and an insider needs collusion to cause a loss. Hot wallets use smaller quorums that work at transaction speed; cold wallets use larger quorums and scheduled signing ceremonies.

Hardware security modules. HSMs hold keys in tamper-resistant hardware and sign inside the secure boundary. FIPS 140-2 or 140-3 Level 3 validation is a common institutional benchmark. The hardware does not deliver security on its own: signing-ceremony procedures, signer rotation and hardware lifecycle management do.

The architecture runs on policies: hot/cold rebalancing rules, signing-approval thresholds, incident response, audit trail and reconciliation. All of it is ICT under DORA, so the ICT risk-management, third-party, incident-reporting and resilience-testing rules apply to the custody stack.

Insurance and DORA — the cover layer

Article 75 does not require insurance. Article 67(4) lets a CASP hold part or all of its prudential safeguards as an insurance policy, but that is a choice about capital, not a custody-insurance obligation. The pressure comes from elsewhere: institutional clients and banking partners ask for cover in due diligence, and DORA treats insurance as one way to transfer residual ICT risk, which the ICT risk-management framework should document along with what is not covered.

The usual lines are crime (theft, employee dishonesty, fraudulent instructions), cyber (hacks, ransomware, incident response, business interruption), specie (physical loss of cold-storage hardware) and professional indemnity. Capacity and pricing move with the cold-storage share, the key-management architecture, governance maturity and loss history; we do not publish premium figures because we have no source for them we can cite.

Read the exclusions as carefully as the cover. Smart-contract exploits, DeFi-protocol failures, assets held by third-party custodians, regulatory fines, war and customer-side failures (lost keys, phishing) are common exclusions. Insurance pays after a loss; the custody architecture is what prevents it.

The buyer’s view

For a CASP scoping the build:

1. Custody architecture is a structural choice. Individual, omnibus or hybrid segregation shapes operating economics and the supervisory relationship for years.

2. Sub-custody means another authorised CASP. If the firm does not want to hold keys itself, the Article 75(9) route is an EU CASP authorised for custody, with clients informed. Technology vendors are outsourcing, not sub-custody.

3. Make the register provable. Automated reconciliation against the chain, with an audit trail and exception reporting, is how a CASP shows its register is right.

4. Get the insolvency result in writing. Confirm by legal opinion that home-state law delivers the Article 75(7) outcome.

5. Set your own hot-wallet limits. MiCA does not; the custody policy must, with a rationale.

6. Insurance is the backstop, not the protection. Calibrate cover to the actual architecture and document it in the DORA framework.

7. Article 70 reaches you without a custody licence. An exchange or broker holding client balances carries the safekeeping duty, the own-account ban and the bank-placement rule for funds.

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

• Is the CASP authorised for custody, and in which member state?
• What is the segregation structure (individual / omnibus / hybrid)?
• What share of assets is in cold storage, and what are the hot-wallet limits?
• What is the signing architecture?
• Is sub-custody used, and with which authorised CASP?
• What legal opinion supports the insolvency segregation?
• How is the register reconciled with on-chain holdings, and how is that audited?
• What insurance is in place, and what does it exclude?