Crypto custody versus wallet-as-a-service

Crypto custody and wallet-as-a-service are often marketed interchangeably, but they describe different things. Custody is about who controls client assets and takes responsibility for safeguarding them; wallet-as-a-service is about software that generates and operates wallets, which may or may not involve regulated custody. Understanding where control and responsibility sit is what lets you evaluate the security model, the regulatory treatment and what happens if the provider fails.

Legal and regulatory status was reviewed on 7 July 2026.

Custody

Custody, in the regulated sense, involves holding and safeguarding clients’ crypto-assets — and typically controlling the means to move them — on their behalf. Under MiCA, custody and administration of crypto-assets on behalf of clients is a defined crypto-asset service with safeguarding expectations 1. The defining feature is control of client assets coupled with responsibility for their safekeeping. If a provider controls the keys to your clients’ assets, custody questions are unavoidable.

Wallet infrastructure

Wallet infrastructure is the software and systems that create addresses, hold keys and construct and broadcast transactions. It is a technical capability. Depending on who controls the keys and whose assets are involved, wallet infrastructure may operate inside a custody arrangement or purely as software you run yourself. The technology alone does not settle the regulatory question — control does.

Custody versus wallet-as-a-service compared

Dimension	Custody	Wallet-as-a-service
Core promise	Safekeeping and administration of assets	Wallet creation, key handling and transactions
Key control	Provider controls or safekeeps keys	Varies; control may sit with you or the provider
Regulatory treatment	May be a regulated crypto-asset service under MiCA	May or may not itself be regulated custody
Primary question	Who is legally responsible for the assets?	Where do the keys live and who can move funds?

Where a service sits on this spectrum determines the questions you must ask, so establish it before comparing features.

Key generation

How keys are generated matters as much as how they are stored. Confirm where generation happens, what entropy source is used, whether the process is auditable, and who can observe or influence it. A weak or opaque generation process undermines every later control. Treat key generation as a supervised ceremony, not a background step.

Key management

Key management covers how keys are stored, rotated, backed up, split and accessed over their lifetime. The practical questions are who can access a key, under what approvals, and how access is logged. Strong management limits how a single compromised person or system can move assets. This is the operational heart of both custody and wallet infrastructure.

MPC and HSM concepts

Multi-party computation (MPC) distributes signing across parties so no single party holds a complete key, while hardware security modules (HSMs) protect keys in tamper-resistant hardware. Both are legitimate approaches with different trade-offs in operations, recovery and integration. Neither is universally superior — the right choice depends on your control model, recovery needs and operational maturity. Be sceptical of any provider claiming one approach is simply “best.”

Omnibus versus segregated models

Assets may be held in an omnibus (pooled) structure with entitlements tracked in a ledger, or in segregated arrangements. The model affects reconciliation, transparency and what clients can claim if the provider fails. This mirrors the named accounts, virtual IBANs and pooled accounts trade-offs on the fiat side. Ask which model applies and how entitlements are evidenced.

Policy engine

A policy engine enforces rules on transactions — limits, allowlists, approval thresholds and time locks — before anything is signed. The strength of the policy engine determines how well you can prevent unauthorised or erroneous movements. Confirm what rules can be expressed, who can change them, and how changes are controlled.

Transaction approval

Approval workflows define who must authorise a movement and under what conditions. Multi-person approval, role separation and out-of-band confirmation reduce single-point failure. Map how approvals work for normal, large and emergency transactions, and how the workflow is enforced technically rather than by convention.

Recovery

Recovery covers what happens if a key, device or party is lost. Understand the recovery mechanism, who participates, how long it takes, and whether recovery itself introduces a new way to lose control of assets. A recovery process that is either impossible or too easy is a risk. Test it before you depend on it.

Network support

Providers differ in which blockchain networks and asset types they support, and support depth varies. Confirm the specific networks and tokens you need are supported operationally, not just listed, and how new networks are added. Gaps here can strand assets or block flows described in your stablecoin payment stack.

Smart-contract interaction

If wallets interact with smart contracts, that interaction expands the risk surface to include contract behaviour and approvals. Understand how the provider constrains contract interactions, manages token approvals and prevents unintended exposure. Contract interaction should be governed by the same policy controls as transfers.

Sub-custody

A provider may itself rely on another custodian (sub-custody). This adds a party between you and your assets. Ask whether sub-custody is used, who the sub-custodian is, how assets are segregated at each level, and how the chain of responsibility is documented.

Insurance limitations

Insurance is frequently cited but often narrower than it sounds. Confirm what is actually covered, the limits, the exclusions, who the policyholder is, and how a claim would work. Insurance is not a substitute for sound key management, and headline figures rarely reflect real recoverable amounts. Read the terms, not the summary.

Insolvency treatment questions

If the provider fails, how are client assets treated? Understand whether assets are held in a way intended to keep them separate from the provider’s estate, how entitlements are evidenced, and what practical steps clients would face. These are questions for legal analysis, but you should raise them before contracting, not after failure.

Operational control

Beyond technology, evaluate day-to-day operational control: access management, monitoring, change control, personnel controls and incident response. Most losses trace to operational gaps rather than cryptographic breaks. Treat the provider’s operational maturity as a first-class selection criterion.

MiCA custody service

Where a provider offers custody and administration of crypto-assets on behalf of clients, that is a defined MiCA service with associated safeguarding and organisational expectations 1. ESMA’s interactive single rulebook helps navigate how the provisions connect 2. Confirm the authorisation position of any provider acting as custodian for your clients’ assets.

Wallet software that may not itself be custody

Providing wallet software does not automatically mean the provider is performing regulated custody — for instance, where you retain sole control of keys and the provider merely supplies tooling. The classification depends on control and whose assets are held 1. Do not assume “wallet provider” and “custodian” are the same regulated position; analyse control.

Provider-selection checklist

• Whether the arrangement is custody, wallet software, or a mix is clearly established
• Who controls the keys, and whose assets are held, is documented
• Key generation and management processes are auditable
• The signing approach (e.g. MPC, HSM) and its trade-offs are understood
• Omnibus versus segregated holding is confirmed with entitlement evidence
• Policy engine and approval workflows meet your control needs
• Recovery is tested and does not create new loss paths
• Required networks and tokens are operationally supported
• Sub-custody, if any, is disclosed with the responsibility chain
• Insurance scope, limits and exclusions are read in full
• Insolvency treatment questions are raised before contracting
• Incident and exit planning are agreed in writing

Incident and exit planning

Plan for both incidents and eventual exit. DORA frames ICT risk management, incident handling, resilience testing and third-party risk for in-scope entities, and using a provider does not remove the regulated entity’s responsibility 3. Agree how incidents are detected and communicated, how you would migrate assets and keys to another arrangement, and over what period. Exit terms are far harder to negotiate after go-live.

Questions to ask providers

• Is this regulated custody, wallet software, or a combination — and who controls the keys?
• How are keys generated, stored, rotated and recovered, and who can access them?
• What signing approach do you use, and what are its recovery trade-offs?
• Are assets held omnibus or segregated, and how are entitlements evidenced?
• What can the policy engine enforce, and who can change the rules?
• Do you use sub-custody, and if so, who and how is it segregated?
• What exactly does your insurance cover, and what are the exclusions?
• How would client assets be treated if you became insolvent?
• How do you handle incidents, and what does exit and migration involve 3?

Common failure modes

• Treating wallet software as equivalent to regulated custody without checking control 1.
• Accepting “MPC” or “HSM” as proof of safety without examining the model.
• Overlooking who controls keys and how recovery could be abused.
• Assuming insurance covers losses without reading limits and exclusions.
• Ignoring sub-custody chains and where responsibility actually sits.
• Not raising insolvency treatment until after a failure.
• Skipping incident and exit planning, leaving assets hard to migrate 3.

What this does not cover

This article does not endorse any provider, assess any specific insurance policy, or determine how assets would be treated in an insolvency — those are legal and fact-specific questions. It does not resolve authorisation status for any provider and is not legal, financial or tax advice.

FAQ

Is wallet-as-a-service the same as custody?

Not necessarily. Custody turns on control of client assets and responsibility for safeguarding them; wallet software may be provided without the provider performing regulated custody 1.

Is MPC safer than HSM?

Neither is universally superior. They have different trade-offs in operations, recovery and integration, and the right choice depends on your control model and maturity.

Does insurance mean my assets are protected?

Only to the extent of the policy. Confirm coverage, limits, exclusions and the policyholder, because insurance is often narrower than headline figures suggest.

What happens to client assets if the custodian fails?

That depends on how assets are held and on applicable law. Raise insolvency-treatment and segregation questions before contracting, and seek legal analysis.

How does DORA relate to custody providers?

DORA frames ICT risk, incident handling, resilience testing and third-party risk for in-scope entities, and it does not transfer the regulated entity’s responsibility to a provider 3.