Digital Asset Business Models

How issuers, custodians, platforms and banks create value while keeping the customer's claim clear

Start with the claim

A digital token can represent a claim on an issuer, a right recorded in another register, or an asset whose value depends on a network. Those are different products even when the customer sees the same wallet icon. A bank assessing a digital-asset proposition should first identify what the holder owns, who owes any obligation, which record establishes the right, and how the holder can exit. A network balance alone may not answer those questions.

Tokenisation records a representation of money or another asset on a programmable platform. The BIS and CPMI explain that this can change how financial activities are organised across an asset's life cycle, but sound governance and risk management are still necessary. This chapter focuses on the business roles and operating economics. The neighbouring chapters cover stablecoin reserves and redemption, CBDC distribution, tokenised deposits and custody controls in depth.

Four business roles

These roles can sit in one group or be split among firms. A bank may issue a tokenised deposit, use another firm's platform, keep custody itself and distribute through its own app. An exchange may combine trading, custody and distribution. A diagram showing one logo is therefore inadequate: the customer contract, safeguarding arrangement, technology contract and operating runbook must identify the actual legal entities.

Where the business earns and spends

The attractive part of a proposal is usually faster distribution, programmable processing or longer service hours. The bank's business case must measure the whole arrangement. Revenue may come from account or custody fees, issuance and redemption fees, transaction processing, market-making spread or partner distribution. None of these should be assumed to be available in every jurisdiction or to every licensed entity.

Cost is broader than the platform invoice. It includes legal analysis of the instrument and participant roles; customer disclosure and support; onboarding, financial-crime controls and transaction monitoring; integration to the bank's books; security and key operations; reconciliation; liquidity and funding; incident response; and exit from a failed partner. A model is profitable only after those costs, expected losses and capital or liquidity effects relevant to the entity have been considered.

A useful unit-economics view follows one transaction from customer instruction to final book entry. It records fee income, network and partner charges, treasury or inventory cost, exception-handling cost and any unresolved balance. A low processing fee is not a benefit if a high share of transactions needs manual repair.

Example: a bank distributes a tokenised fund interest

Assume a bank offers eligible customers access to a fund interest represented by a token. The fund or its authorised agent defines the investor's rights. A register, which may involve an on-platform record and an off-platform legal record, establishes who is entitled to those rights. A custodian controls the relevant assets or keys. The bank's app presents the holding and handles customer support. This is a training example, not a statement that every tokenised fund uses the same legal structure.

Before launch the bank should trace one purchase and one redemption end to end: customer eligibility, disclosure version, order acceptance, money movement, token or register update, custody confirmation, bank book entry and customer statement. It should also trace a failed purchase and a disputed balance. The customer must be told which event changes their legal position and when a pending instruction becomes a completed holding. The finality and ownership answers come from the actual instrument terms, market rules and applicable law, not from a generic blockchain confirmation count.

The bank should test a partner outage as well. If the platform is unavailable, can it identify each customer's entitlement from independently retained records? Can it stop new orders, communicate the pending state, reconcile after recovery and process an orderly exit? An arrangement whose only reliable record lives behind the partner's login leaves the bank unable to service a claim when customers most need it.

Controls that make the model credible

Rights and disclosures. Record the instrument's obligor, holder rights, redemption or sale route, fees, restrictions and loss allocation. Separate the token transfer rule from the legal transfer of the underlying right. Review customer language against the actual contract.

Custody and access. Identify who can create, move, freeze or recover assets and who approves those actions. Segregation, key ceremonies, backup and recovery must fit the custody model. Do not promise that a lost key can always be restored or that a transfer can always be reversed.

Books and reconciliation. Join customer instruction, platform reference, ownership record and bank posting with durable identifiers. Reconcile outstanding positions and cash movements at a frequency suited to the exposure. Assign and age breaks. A visible token balance does not by itself prove that the bank's accounting or the customer's legal entitlement is correct.

Partner and concentration risk. Map dependencies on the platform, custodian, issuer, liquidity provider and any cloud or oracle service. Set an exit path, data rights and incident responsibilities before scale. Combining issuance, trading, custody and distribution within one group can create conflicts that need explicit governance.

Financial crime and conduct. Apply the controls required for the particular activity, entity and jurisdiction. Screening, monitoring, market integrity, customer appropriateness and complaints cannot be inferred from the technology label. The Financial Stability Board's recommendations provide a high-level framework for crypto-asset activities and emphasise governance, risk management, data and conflicts; they are not a substitute for binding local rules.

A decision record before launch

The product owner should be able to answer these questions on one page, with links to evidence:

1. What exact claim or asset does the customer acquire, and which legal entity owes performance?
2. Which register is authoritative for ownership, and how is it reconciled with the app and bank books?
3. Who controls issuance, transfer, custody, redemption and suspension?
4. Which event makes the customer's transaction complete under the applicable terms?
5. What does the customer pay, what does each partner earn, and who pays when a transaction fails?
6. Which permissions, disclosures, financial-crime controls and prudential treatments apply to the actual entities and locations?
7. Can the bank service customers and unwind the arrangement if a provider fails?

If any answer relies only on a vendor slide or a screen balance, the business model is still a proposal. The release gate is a tested claim, a reconciled book and an executable customer-service path.

Takeaway

Digital assets do not create one business model. They rearrange issuance, custody, distribution, transfer and servicing. Map the customer's claim and every operating role before projecting revenue or promising speed. The value of the model depends on whether those roles remain accountable when the network, partner or book disagrees.

Sources and review scope

This chapter uses international publications to explain concepts and risk themes. Product permissions, investor protections, accounting and prudential treatment must be checked against the current rules and contracts for the relevant entity before launch.

• BIS/CPMI, Tokenisation in the context of money and other assets (2024) — token arrangements, platform roles, governance and risk.
• FSB, High-level recommendations for crypto-asset activities and markets (2023) — activity-based oversight, governance, data, risk and combined functions.
• FSB, Global regulatory framework for crypto-asset activities (2023) — scope and distinction between crypto-asset recommendations and CBDCs.