Request a demo
Request a demo to see how teams model custodial and non-custodial positions in a single ledger, or explore Formance Ledger on GitHub.
For teams choosing between non-custodial vs. custodial wallets, the custody model defines who controls private keys. It also determines who can initiate transactions and which operational and compliance systems must be in place for the product.
You are three weeks from launch. The wallet works in staging, users can deposit and withdraw, and someone in the product review asks whether you should hold private keys or let users hold their own. Whoever controls the private key controls who can sign and broadcast a transaction. That single fact changes the legal and engineering surface area for years.
Moving funds from one model to the other typically requires provider-initiated transfers, which may implicate money transmission obligations under FinCEN's control-based framework. Treat the custody model as an architecture decision before onboarding goes live.
This guide explains how private keys define the architecture, and how to choose between non-custodial and custodial wallets.
Custody is decided at the cryptographic layer, and no product design overrides it. Possession of the private key, or of enough key shares in a multi-party scheme, is the operational boundary that determines who can initiate a transaction.
If your platform holds the key, your platform can move the funds. If the user holds the key, you cannot, no matter what your support team promises.
The SEC frames custody in terms of possession or control of client funds or securities. A common launch mistake is letting the design team treat custody as a preference, while the architecture carries compounding regulatory and operational consequences. Here’s how to tell the difference between custody wallets and what works for each team.
A custodial wallet is one where the provider retains control of the private keys on behalf of users. The user sees a balance, while the provider holds the ability to sign.
Custodial providers commonly use a hot-to-cold storage hierarchy, often with a warm signing layer, with the cold layer holding the majority of funds. In a tiered model, cold storage holds long-term assets while warmer signing paths and hot wallets handle planned transactions, immediate withdrawals, and automated trading. If hardware security modules (HSMs) are used, key material is processed inside a secure boundary.
User balances in this model are internal ledger entries against an omnibus account, not distinct on-chain addresses. Many centralized exchanges manage omnibus blockchain addresses and track user balances internally; deposits and withdrawals are batched, and internal transfers are off-chain. The blockchain shows one pooled total. An off-chain ledger is both a source of operational efficiency and a source of counterparty risk.
As an open-source core ledger, Formance offers a unified platform for fiat and digital assets with regulatory-grade traceability. This custody type should be a ledger dimension, so teams preserve per-user traceability and avoid reconciliation drift, even when assets are in pooled custody.
Custodial architecture delivers real operational benefits to your product team, including account recovery, transaction fee abstraction, fiat on- and off-ramp integration, and delegated compliance onboarding and key management. Users who forget their password can regain access, but the password complexity is hidden. Your team absorbs the mechanics so the end user never sees a seed phrase.
Custodial architecture also concentrates risk. When a provider controls the keys, users depend on the provider's solvency, internal controls, and segregation practices to ensure that what customers are told about their balances actually matches.
Historical failures of centralized crypto custodians have shown that pooled custody can mask commingling, misappropriation, or shortfalls that only become visible in insolvency. The custodian controls the keys, and the keys can move regardless of what the user interface shows.
A non-custodial wallet gives the user sole control of their private keys. The provider ships software and cannot unilaterally initiate, modify, block, or reverse transactions on the user's behalf.
Non-custodial wallets generate and store keys or BIP-39 seed phrases locally, so every transaction is signed on the user's device and broadcast directly to the network.
The local signing flow for an Ethereum account has several steps. It builds the transaction, RLP-encodes and hashes it with Keccak-256, then ECDSA-signs it with the private key to produce the (v, r, s) components. The wallet then broadcasts via eth_sendRawTransaction. In a self-custodial wallet, the user controls their own funds, and the wallet provider does not hold the recovery phrase.
That protocol-level control creates the engineering surface your team inherits. There is no server-side recovery path, so that cryptographic information loss can result in permanent, irreversible loss of crypto-assets.
Non-custodial fits products that connect users directly to DeFi protocols or peer-to-peer transfers without taking custody. It also fits contexts where users are sophisticated enough to manage key material. If your product connects users to on-chain protocols and never holds their funds, self-custody is the honest architecture.
Non-custodial can shift compliance classification away from custody obligations when regulatory frameworks hinge on control over assets or access.
Under Article 3(1)(17) of the MiCA EU crypto-asset regulation, the regulatory body generally does not apply to hardware and software providers of non-custodial wallets because a publisher that cannot unilaterally trigger a transaction does not meet the custody definition.
However, there are various obligations, including smart contract audit responsibilities and front-end security, that fall entirely on you, since there is no default custodian to absorb failures. Self-custody can be a poor fit in consumer contexts, where handling seed phrases adds friction that product polish cannot fully eliminate.
The custodial-versus-non-custodial binary is often too blunt in production, and the consequences can be costly when regulators disagree with your marketing.
Some MPC wallet designs split key shares across the user and operator. In contrast, others use a 2-of-3 setup that adds a recovery or guardian service so that no single party can sign unilaterally. In a 2-of-3 design, the user, the operator, and an independent guardian each hold one share, and the full private key is never assembled.
This threshold design can change custody classification, but not always in the direction teams expect. The MiCA custody definition covers the safekeeping or control, on behalf of clients, of crypto-assets or of the means of access to those crypto-assets, including private cryptographic keys. Under MiCA, retaining an operator share that is part of the signing threshold can indicate authorization, as the regulation focuses on control over the means of access.
Account abstraction wallets governed by ERC-4337 take a different path. They are smart contract accounts that decouple signing authority from fund ownership. They allow social recovery and multi-signature policies, with gas sponsorship through paymasters without a traditional custodian relationship.
The validateUserOp function accepts arbitrary verification logic, allowing guardians to restore access and dApps to sponsor gas, while the smart account remains the primary account.
A platform running MPC may retain custody exposure if its key share gives it control over the means of access.
MiCA defines custody by control over crypto-assets or the means of accessing them. Still, the GENIUS Act separately restricts custodial and safekeeping services for payment stablecoins or their private keys. The treatment of threshold MPC shares will depend on the implementing rules. The term "Non-custodial" on your landing page does not exempt you if your architecture leaves the operator with practical control over signing.
The practical differences between custodial and non-custodial wallets are evident in private key control, settlement, account recovery, custody-regime treatment, DeFi access, operational complexity, and counterparty risk.
| Dimension | Custodial | Non-custodial |
|---|---|---|
| Private key control | Provider holds keys | User holds keys or seed phrase |
| Settlement | Off-chain internal ledger against omnibus | On-chain, direct to network |
| Account recovery | Server-side reset available | No recovery path if the seed is lost |
| Custody-regime treatment | crypto-asset service provider (CASP) authorization; custodial issuer obligations | Non-custodial software is generally outside the custody regime |
| DeFi access | Mediated by the provider | Direct protocol interaction |
| Operational complexity | HSMs, cold storage, 24/7 SecOps | Gas, smart contract audits, front-end security |
| Counterparty risk | Provider insolvency and control failures | User error is permanent and unrecoverable |
The right custody model depends on your users, markets, operational capacity, and future migration constraints.
Segment users by technical sophistication before you pick a model. A non-custodial model that requires a seed phrase recovery creates substantial friction in consumer onboarding.
The evidence base for precise abandonment rates is thin and often vendor-supplied. Still, the direction is clear enough for product planning: seed phrase creation, backup, and verification add cognitive load at exactly the point where new users are least confident.
For non-technical users, seed phrase friction is an architectural constraint that product polish cannot remove.
Custodial operation activates licensing events across every jurisdiction you serve.
In the EU, "custody and administration of crypto-assets on behalf of clients" requires CASP authorization from your home Member State regulator, with an EU passport across all members.
In the US, nearly every state regulates money transmitters and requires licenses or registration. Virtual currency transmission can require licensing under state money transmission laws.
In the UK, custodial wallet providers must register under the cryptoassets anti-money laundering and counter-terrorist financing regime. Firms issuing e-money in connection with cryptoasset services may also need separate authorization under the Electronic Money Regulations 2011.
Custodial operation imposes infrastructure requirements far beyond software. Plan for dedicated security engineering and ongoing compliance work, with hardware needs accounted for upfront. You also need threshold signing or HSM-based key management reviewed independently, plus 24/7 security monitoring.
Custodians may also need to account for insurance availability in operational planning. You need incident response plans for compromised signing keys that are tested under realistic conditions, because high-quality programs regularly perform tabletop exercises against compromised signing keys and fraudulent transactions.
A custody model chosen at launch compounds into a migration constraint. Moving from custodial to non-custodial requires initiating on-chain fund transfers for every user account, each to a new address whose private key only that user controls. You should treat a custodial provider with independent control over customer value as the money transmitter, rather than the user, which supports the control element of money transmission.
That creates destination-address screening and Travel Rule recordkeeping where applicable. It also creates gas fees for N transactions and irreversible broadcasts. An address or key mistake can cause permanent, irreversible loss and become a regulated money movement event. Decide as if the choice is permanent, because in practice it nearly is.
Your on-chain reality and internal records must agree, provably, on every posting. A properly built ledger earns its place by keeping those records aligned and treating custodial and non-custodial positions as the same accounting problem expressed through different account paths.
Teams create reconciliation problems when they treat the bank's omnibus account as a single internal account. Model the omnibus account as a view over many user-specific ledger paths.
Every deposit posts against the specific user, and the pooled total is derived by aggregation, so the pooled bank balance and the individual user balances never drift apart in your records.
Consider a 1.0 ETH deposit arriving from an external custodial provider. Use one multi-asset user wallet and a named custody-provider boundary account: @counterparties:custodyProviders:provider records the external provider, and @users:alice:wallet holds Alice's assets. The movement is 1.0 ETH from the provider boundary to Alice's wallet. The Numscript language expresses the deposit as a double-entry flow; the ledger commits atomically:
// CUSTODIAL_DEPOSIT
// Event: Alice receives 1.0 ETH from an external custodial provider
send [ETH/18 1000000000000000000] (
source = @counterparties:custodyProviders:provider allowing unbounded overdraft
destination = @users:alice:wallet
)
set_tx_meta("event_type", "custodial_deposit")
set_tx_meta("deposit_id", "dep001")
The transfer is expressed in Numscript as a source-to-destination flow between accounts, with the ledger handling the underlying balance updates and enforcing double-entry accounting. Balances are derived from postings, and omnibus reconciliation must be modeled explicitly in the ledger design.
If the two disagree, reconciliation can flag drift and help teams trace the discrepancy across internal postings and external records.
Non-custodial activity ingested from on-chain event posts is posted against user-specific accounts rather than an omnibus account, so the same ledger preserves chain-native traceability without a separate data model for each custody type.
A reconciliation layer compares internal postings against the correct external reality for each model.
For custodial positions, the connectivity tooling ingests and unifies external account and transaction data via prebuilt connectors, including digital-asset custody providers and exchanges, and normalizes each provider's format into a single data model. Reconciliation can then match internal ledger records against those external sources.
For non-custodial positions, teams can ingest on-chain data through supported digital-asset integrations or direct on-chain connectivity. A generic connector can cover other sources before reconciliation compares expected and actual balances. Teams building hybrid products, custodial for retail and non-custodial for institutional clients, can use the same reconciliation rather than maintaining two independent processes.
Formance Ledger's immutable, hash-chained transaction history can help support fund traceability and reporting workflows for teams addressing MiCA custody and GENIUS reserve reporting requirements.
Custody status can be preserved as a filterable attribute in the same ledger records you use for operations, so the data needed for client-position registers and periodic statements can be queried or exported from your system of record rather than a separate reporting stack assembled under exam pressure.
The custody decision compounds because it is written into your architecture and reconciliation model, with licensing tied to both. A ledger that treats both models as the same accounting problem, with custody type as a query dimension, is what lets you decide on the merits instead of on what your ledger can represent.