MiCA Article 75: What It Means for Client Asset Custody in Practice

For the broader MiCA authorisation and supervision picture, see What is MiCA? The Complete Guide to EU Crypto-Asset Regulation. This article deals with one narrow but frequently mislabelled point: the custody and administration obligations for crypto-asset service providers sit in Article 75 of the Markets in Crypto-Assets Regulation, read with the general safekeeping duty for client funds in Article 70. Article 68 is commonly cited as the custody provision because it appears in the same part of the regulation and sets baseline organisational requirements, prudential safeguards, governance and conflicts of interest arrangements that every CASP must have in place. It does not itself impose the segregation, register of positions, custody policy or liability standard that a custodian is actually assessed against. Those operative custody duties are in Article 75, and the equivalent duty for client fiat funds is in Article 70.

Article 75 governs providers offering custody and administration of crypto-assets on behalf of clients. It requires an agreement with each client setting out duties and responsibilities, a register of positions opened in the name of each client, segregation of client holdings from the provider's own holdings, and a custody policy setting out internal rules and procedures.

It also imposes a return obligation and a liability standard. Assets must be returned to clients promptly, and the provider is liable for loss of crypto-assets or means of access resulting from an incident attributable to it, up to the market value of the assets lost.

Read together with Article 67 on prudential requirements and Article 70 on the safekeeping of clients' crypto-assets and funds, the effect is that a crypto-asset service provider must know, at all times and provably, which assets it holds, for whom, and where. Article 70(3) also requires clients' funds other than e-money tokens to be placed with a credit institution or central bank by the end of the business day following receipt, in an account separately identifiable from the provider's own.

Neither article uses the word reconciliation, and neither sets a frequency. What they require is that the register is correct and that entitlement is determinable at any time, which cannot be evidenced without continuous checking. A register that is accurate at the moment of writing but not continuously proved against on-chain and exchange reality does not satisfy a rule whose entire purpose is that clients can be made whole.

The register of positions is the document that determines who owns what if the provider fails. Every other control exists to keep it correct.

Its integrity depends on three independent references agreeing: the internal ledger recording client entitlement, the wallet and account balances actually controlled by the provider, and the transaction population that moved assets between them. A two-way check between ledger and wallet proves internal consistency, not correctness.

Multi-signature arrangements, omnibus wallets, sub-account structures at exchanges and staking positions each add a layer where entitlement and control diverge. Assets delegated to a validator are still client assets, and their absence from a hot wallet must be explained by the register rather than treated as a discrepancy.

Safeheld reconciles across three or more independent records rather than performing a two-way match, so a divergence between the transaction population and the ledger is detectable even where the ledger and the wallet agree.

Segregation under Article 75 does not require a separate wallet per client, but it does require that client assets are distinguishable from the provider's own assets at all times, and that individual client entitlement is determinable from the register.

The practical risk is commingling that occurs through operations rather than intent. Fee collection, gas funding, rebalancing between hot and cold storage and market making inventory all create paths by which proprietary and client assets can share an address.

Each of those paths needs a control that proves the split remains correct after every movement, not a policy stating that it should. Continuous reconciliation of pooled addresses against sub-ledger entitlement is the only reliable form of that control at transaction volume.

Excess is as much a finding as shortfall. Proprietary assets sitting in a segregated address weaken the segregation the address exists to provide, and an examiner will treat it as evidence that the boundary is not enforced.

Supervision under MiCA is exercised by national competent authorities, and their examination will focus on whether the custody policy is operated rather than whether it exists.

The testable questions are consistent: on a named historic date, what did the register say, what did the provider actually control, what variance existed, who reviewed it, and how was it resolved. A provider that answers by reconstructing from block explorers and exchange exports has already demonstrated the weakness.

Safeheld seals each reconciliation run with a SHA-256 Merkle root fixing the inputs, the logic applied, the outcome and the reviewer. Because the root can be verified independently, the record produced during an examination is provably the record produced at the time.

That distinction matters more in crypto than elsewhere, because the underlying data is public and mutable records on the provider's side are the obvious point of challenge.

Crypto custody reconciliation is harder than fiat reconciliation for reasons that have nothing to do with regulation. Chains finalise at different speeds, exchange APIs report balances with differing conventions, tokens migrate across bridges, and the same asset can exist in several representations.

A reconciliation process that assumes instantaneous, unambiguous settlement will generate a permanent population of false breaks, and a permanent population of false breaks trains a team to ignore breaks.

Handling this requires the platform to model expected settlement behaviour per chain and venue, so that an item in flight is recognised as in flight rather than reported as missing.

Autonomous investigation then clears the explainable residual by assembling the surrounding records and retaining the reasoning, leaving only genuinely ambiguous items for a named reviewer.

Most providers approach MiCA authorisation through documentation, because documentation is what the application requires. The supervisory relationship afterwards is about operation.

A useful readiness test is whether the provider can produce, without engineering effort, a complete custody control record for an arbitrary week: register position, controlled balances, movements, variances, investigations, corrections and reviewer attribution.

Where that is achievable in hours, the custody policy is real. Where it takes a week, the policy describes an intention.

Building the reconciliation and evidence layer first, and writing the custody policy to describe what the layer actually does, produces a document that survives examination because it is descriptive rather than aspirational.