When a bank decides to offer digital assets to its retail clients, one of the first architectural decisions is how wallets are structured. The question looks technical, but it shapes accounting, reconciliation, regulatory compliance, operating cost and the way the institution responds to an incident.
There is no correct model in the abstract. There is the model that fits each institution’s licence, processes and client base. This article describes the two main options, their implications and the criteria that usually decide the choice.
What individual and omnibus wallets are
In an individual wallet model, each client has at least one address of their own on the network. Their assets are recorded on-chain at that address, and every movement is publicly reflected on the blockchain separately from other clients. The bank still holds the keys, but each client’s position can be verified directly on the network.
In an omnibus model, the assets of many clients are pooled in a small number of addresses controlled by the bank. The attribution of each position to each client is not on the network but in an internal record: a ledger that allocates balances, movements and ownership. The blockchain shows the aggregate balance; the bank knows which part belongs to whom.
Both models are common in the custody of traditional assets and of digital assets. The difference lies in where the truth about each client’s position resides: on the network, in the bank’s internal record, or in a combination of both.
Segregation, traceability and custody obligations
The MiCA Regulation (Regulation (EU) 2023/1114) requires those who hold crypto-assets on behalf of clients to keep them separate from their own assets and to maintain a record of each client’s positions. Credit institutions operating in the European Union can provide crypto-asset services by notifying their competent authority under Article 60, but the safeguarding obligations still apply.
An individual model makes that segregation easier to demonstrate, because each position is visible and separable on the network. An omnibus model can also meet it, provided that client addresses are kept apart from the bank’s own addresses and that the internal record is complete, auditable and continuously reconciled with on-chain balances.
Per-client traceability follows similar logic. With individual wallets, each client’s history can be reconstructed from the network itself. In an omnibus structure, it depends on the quality of the internal record and on how it is linked to each on-chain transaction.
Reconciliation, network fees and scalability
Reconciliation is where the differences become most tangible in day-to-day operations.
- Individual wallets: reconciliation is carried out address by address. It is conceptually simple, but the number of addresses grows with the number of clients, and so does the monitoring workload.
- Omnibus: reconciliation compares the aggregate on-chain balance with the sum of positions in the internal ledger. There are fewer addresses to monitor, but any break requires analysing the internal record to locate its source.
Network fees also differ. In an individual model, each client operation usually translates into an on-chain transaction with its corresponding fee, and it is sometimes necessary to fund many addresses to cover those fees. In an omnibus model, much of the investment activity can be settled internally and reflected on the network in aggregate, which reduces the number of transactions and the associated cost.
For a large retail base with frequent, low-value operations, this factor tends to carry significant weight. For clients with few operations, large amounts or a need for direct traceability, it matters less.
Travel rule, external transfers and incidents
Since 30 December 2024, the Transfer of Funds Regulation (Regulation (EU) 2023/1113) has applied the travel rule to crypto-asset transfers: originator and beneficiary information must accompany the transfer. In an individual model, the source or destination address is linked to a specific client, which simplifies the association of data. In an omnibus model, the institution must ensure that its internal record accurately identifies which client originates or receives each movement entering or leaving the shared address.
Deposits from external wallets raise the same issue. With individual addresses, a deposit is automatically attributed to the client who owns the address. With an omnibus structure, an additional identification mechanism is needed, such as dedicated deposit addresses that are later consolidated, or references associated with each operation.
Incident isolation is another relevant criterion. A problem with an individual address affects, in principle, a single client. A problem with an omnibus address can affect many at once, so signing policies, limits and the distribution of balances across several addresses become more important.
In both cases, keys should be generated and held in the bank’s own HSMs, with signing performed inside the module. The wallet model changes how addresses are organised; it does not change who controls the keys.
Hybrid models
In practice, many institutions do not choose an extreme. Some common combinations:
- Omnibus for investment, individual for external transfers: buying and selling is settled internally, and each client has their own addresses for deposits and withdrawals.
- By client segment: omnibus for the general retail base and individual for private banking or clients with specific traceability requirements.
- By asset type: tokenised stocks or regulated stablecoins in one model, native crypto-assets in another, depending on the requirements of each network and each issuer.
A hybrid model adds complexity to the internal record, which must accurately reflect the movement of assets between shared and individual addresses. In return, it allows cost, traceability and client experience to be tuned to each case.
Questions to settle before choosing
The decision usually depends more on the bank’s regulatory and operating model than on the technology. These questions help to pin it down:
- What does the supervisor expect in terms of demonstrating segregation and recording per-client positions?
- How many clients are expected to be onboarded, and with what frequency and average operation size?
- Will deposits and withdrawals to external wallets be allowed from the outset?
- How will the position record be integrated with core banking and accounting?
- What capacity does the operations team have to reconcile daily and resolve breaks?
- How will the travel rule be handled for each type of transfer?
- What is the maximum acceptable impact if an address is affected by an incident?
- Which networks and assets will be offered, and how do their fees vary?
The answers are rarely final on day one. That is why it helps to validate the chosen model in a proof of concept, with real onboarding, investment, deposit, withdrawal and reconciliation flows, before extending it to the entire client base.
At Finhattan we work inside each bank to deploy the infrastructure in the wallet model the institution needs, whether individual, omnibus or hybrid, with keys in its own HSMs and a complete history of operations and positions reconciled with the network. The details of that approach are set out in how we work and security and control.
If your institution is weighing this decision, we would be glad to review it together through our contact page.