MiCA Compliance for Crypto Custody: How Asset Segregation Actually Works

A compliance officer can write an asset segregation policy in an afternoon. Proving it holds up under an audit is the part that takes wallet architecture you do not fully control.

That gap is the real subject of MiCA's custody rules. The Markets in Crypto-Assets Regulation (MiCA) sets EU-wide obligations for crypto-asset service providers (CASPs), and for anyone offering custody, the segregation requirements are specific about outcomes a provider must be able to demonstrate.

Whether you can demonstrate them comes down to how client assets are held on-chain, how access to them is controlled, and whether your records line up with what actually happened. Those are infrastructure questions before they are legal ones.

This guide walks through what MiCA compliance requires for custody, what asset segregation means under Article 75, and where a wallet platform either helps you evidence it or quietly leaves you exposed.

What MiCA compliance requires from custody providers

MiCA harmonises the rules for crypto-assets and crypto-asset services across the EU. Its custody provisions apply to CASPs from 30 December 2024, with transitional arrangements that depend on national law and the timing of authorisation.

The custody definition is the anchor. MiCA defines "providing custody and administration of crypto-assets on behalf of clients" as safekeeping or controlling, on behalf of clients, crypto-assets or the means of access to those crypto-assets, including private cryptographic keys where applicable.

Read that definition closely, because it sets the scope of everything else. MiCA regulates more than who holds the coins. It regulates who controls the means of access, which in practice means the keys. If your service controls client keys or client assets, the custody obligations apply to you, and asset segregation is one of the first you have to satisfy.

Asset segregation under MiCA: the three layers you have to evidence

Article 75(7) is where segregation lives. It requires custodians to do four things:

• Segregate client crypto-asset holdings from the custodian's own holdings.
• Ensure the means of access to client crypto-assets is clearly identified as such.
• Hold clients' crypto-assets separately from the custodian's own crypto-assets on the distributed ledger.
• Keep client assets legally segregated from the CASP's estate, so creditors have no recourse under applicable law, including in insolvency, and operationally segregated as well.

Those four requirements collapse into three layers you need to be able to show an auditor:

On-chain separation. Client assets sit at addresses that are demonstrably distinct from firm assets, and you can point to the on-ledger structure that keeps them apart.

Access separation. The means of access, the keys and the permissions around them, is identified and controlled so that client access is clearly distinct from firm access.

Record separation. Your books tie every position and every movement back to the right client, on a register you keep current.

A policy document covers the legal layer. The other two are produced by your wallet system, every day, whether or not anyone is watching. That is why segregation reads as a paperwork task and behaves as an engineering one.

Why segregation is a wallet infrastructure problem

MiCA's custody article points at two things at once: the distributed ledger and the means of access. That pushes segregation directly into three parts of your stack.

Address structure decides whether assets are actually held separately on-ledger, or merely tracked as separate in a spreadsheet while sitting in shared addresses. Auditors care about the former.

Key and access structure decides whether "means of access" is identified and controlled per the rule, or whether the same operational key signs for client and firm funds alike.

Operational workflow decides whether movements are evidenced. MiCA requires custodians to keep a register of positions per client, record movements as soon as possible, and evidence those movements against the register. A withdrawal that left your signer with no corresponding register entry is a segregation finding waiting to happen.

If your infrastructure cannot produce a reviewable link between wallet activity and client position records, segregation stops being something you can prove. The policy says one thing, the chain says another, and the auditor writes up the difference.

Custodial, non-custodial, and WaaS models under MiCA

MiCA's definition turns on control of crypto-assets or the means of access. That framing sorts the common models cleanly.

In a custodial model, the provider controls client assets or keys. Article 75 applies directly, and segregation is the provider's obligation to satisfy.

In a non-custodial model, the client retains control of their own keys. Non-custodial means the client holds the means of access, not the service. The custody obligations attach to whoever controls the keys, so the analysis follows control rather than branding.

Wallet-as-a-Service (WaaS) sits in between in a way that trips people up. A WaaS provider supplies the infrastructure while the regulated entity decides how keys and controls are structured. The MiCA obligations generally attach to the entity providing the crypto-asset service to its clients, not to the infrastructure vendor underneath. The vendor does not absorb your compliance. What the vendor's design does decide is what you are able to evidence when the regulator asks.

This is the point worth being precise about. Choosing a WaaS platform does not make you compliant, and any provider that tells you otherwise is selling you a future finding. The right question is narrower and more useful: does this infrastructure let me evidence each Article 75 outcome, or does it get in the way?

How WaaS infrastructure supports MiCA compliance

Here is where the three layers meet real capabilities. The mapping below uses CoinsDo's WaaS infrastructure as the worked example. Read it as a checklist you can apply to any provider, including your own build.

On-chain separation maps to address structure. CoinGet generates and manages deposit addresses programmatically, so client funds can be collected and held at distinct, attributable addresses rather than pooled into one operational wallet. Distinct addresses are what let you point an auditor at on-ledger separation instead of asserting it.

Access separation maps to key and permission controls. Sub-account role management assigns granular roles per sub-account, and the main account governs each sub-account's session validity. CoinSign, the transaction-approval layer built into CoinSend, signs movements with RSA and HMAC-SHA256 and enforces approval workflows before value moves. Together these keep the means of access identified and controlled, which is the exact language Article 75 uses.

Record separation maps to workflow and logging. Automated transaction screening (Know Your Transaction checks on sending addresses) and the platform's transaction logs create a reviewable trail of what moved and when.

That trail is the raw material for the register of positions and the movement records MiCA expects you to maintain. Cold-storage routing for collected funds adds a safekeeping control on top.

One more signal that matters to an auditor reading for operational maturity: CoinsDo operates under ISO/IEC 27701:2019 for privacy information management, an audited controls regime rather than a marketing line. MiCA rewards evidenced controls, and an external certification is evidence.

The boundary holds throughout. The infrastructure supplies separation, access control, and records. You remain responsible for configuring sub-accounts to match your client structure, setting approval thresholds, and keeping your register reconciled. The platform makes compliance demonstrable. It does not make it automatic.

Common segregation failure modes

Most segregation findings are not exotic. They cluster in three places, and each maps back to a layer above.

Commingled holdings. Client and firm assets share addresses, so on-ledger separation cannot be shown without a narrative the chain does not support. This is the failure that survives a clean policy and a tidy spreadsheet, because both live above the ledger.

Unclear means of access. Operational teams cannot evidence how client access differs from firm access, usually because one set of keys and permissions covers everything. The policy claims separation the key structure never implemented.

Broken register linkage. Wallet activity and the client register drift apart. Movements happen faster than they are recorded, or get recorded without a clean tie to the originating transaction, and the register stops being a reliable account of positions.

Picture the two versions of an audit. In the first, the reviewer asks how you separate client assets on-ledger, and your answer is a policy PDF and a promise. In the second, you show distinct client addresses, the role and approval record for who can move them, and a register that reconciles to on-chain movements. Only one of those is segregation. The difference was decided when you chose the wallet architecture, not when you wrote the policy.

FAQ

Does MiCA require one wallet per client?

No. MiCA requires that client crypto-assets be held separately from the custodian's own crypto-assets on the distributed ledger. It does not prescribe a specific wallet-per-user design in the text. Distinct, attributable client addresses satisfy the on-ledger separation requirement without mandating a fixed structure.

Is asset segregation only relevant in insolvency?

No. Article 75 covers operational segregation and ongoing controls, including the register of positions and periodic statements. Those apply during normal operations, and insolvency is one part of the rule rather than its whole scope.

What client reporting does MiCA require for custody? Custodians must provide a statement of position at least once every three months, and at the client's request, identifying the assets, the balance, the value, and the transfers over the period.

Does MiCA certify "MiCA-compliant wallets"?

No. MiCA sets obligations for services such as custody. It does not create a product certification for wallets. Treat any "MiCA-compliant wallet" badge as marketing, and assess the infrastructure against the Article 75 outcomes instead.

Does using a WaaS provider make my firm MiCA compliant?

No. The obligations attach to the CASP providing the service to clients. A WaaS platform can make each requirement demonstrable through address structure, access control, and records. Configuring and operating those controls compliantly stays with you.

Where to start

If you are scoping MiCA custody obligations now, start by mapping your current wallet setup against the three layers: can you show on-chain separation, identified access, and a register that reconciles? Wherever the answer is "in a spreadsheet, not in the architecture," that is your first finding to close.

If you want to see how the address structure, sub-account roles, and approval workflows behind this come together in practice, book a demo with our team.