Tokenized Deposit Application

6 Tokenized Deposit Application

The tokenized deposit application scenario supports issuance and distribution of funds with minimal governance overhead.

Overview

A tokenized deposit is a digital representation of a commercial bank deposit on programmable infrastructure, such as a distributed ledger or blockchain network. Unlike a stablecoin, which is generally issued against a pool of reserve assets, or central bank digital currency (CBDC), which represents a central bank liability, a tokenized deposit remains a liability of the issuing commercial bank. In economic terms, a tokenized deposit represents commercial bank money that can interact with smart contracts, digital assets, and programmable financial workflows.

Tokenized deposits don't fundamentally change the relationship between a bank and its customers. A customer who holds a conventional deposit has a claim on the commercial bank. Similarly, a customer who holds a tokenized deposit has a claim on the issuing bank. The primary difference is how the bank represents, transfers, programs, integrates, and settles the deposit.

Tokenized Deposits in Financial Services

Tokenized deposits can bring commercial bank money into programmable digital financial ecosystems. Banks and their customers can use existing deposit value for institutional and corporate payments, treasury transfers, settlement of tokenized assets, and other programmable financial transactions. Tokenized deposits can support payments subject to defined controls for participant eligibility, transaction purposes, and account limits. These controls can also include know your customer (KYC) and anti-money laundering (AML) controls, risk controls, and configurable approval policies. Tokenized deposits can also maintain transaction history and support auditing. In an environment with multiple financial institutions, tokenized deposits can support transfers of value among permitted participants across participating financial institutions. When combined with transaction orchestration, tokenized deposits can serve as the cash leg for tokenized securities and other digital asset transactions, including delivery versus payment (DvP) scenarios. Tokenized deposits enable banks to extend trusted commercial bank money into tokenized markets while retaining the governance, compliance, and operational controls required for regulated financial services.

Oracle Implementation Advantages

The Oracle Blockchain Platform tokenized deposit solution provides a ready-to-use enterprise application that extends beyond standard fungible token functionality. It supports the deposit token life cycle and includes organization and wallet management, role-based personas, account controls, configurable daily limits, account suspension, and transaction purposes.

The solution also provides know your customer (KYC) and anti-money laundering (AML) restriction controls, amount-based and sequential approval policies, and transaction holds. Audit capabilities, rich history, analytics, wrapper APIs, identity integration, and a role-specific web application support operational oversight and integration.

The underlying smart contract architecture separates account functionality from token functionality. Account functionality includes registration, status, limits, and roles. The token contract supports balances, issuance, transfers, holds, and retirement. These capabilities provide banks with a governed digital money application without requiring them to develop the smart contracts, enterprise APIs, wallet integration, history services, approval workflows, and user experience independently.

Oracle Blockchain Platform also simplifies deployment and integration of the application stack. One-click deployment provisions and connects the Besu tokenized deposit smart contract, wrapper API, rich history database components, Oracle REST Data Services (ORDS), and web application. It also prepopulates the relevant service, contract, wallet, identity, and history configuration.

The resulting extensible foundation can be adapted to a financial institution's tokenized deposit operating model. The application retains enterprise controls that govern who can hold and move value, the applicable limits and policies, and the required approvals. It also provides an auditable record of the resulting transactions.

Participants in a Tokenized Deposit Ecosystem

The issuing commercial bank is the primary participant in a tokenized deposit ecosystem. Its responsibilities include creating and issuing tokenized deposits, establishing participant eligibility requirements, controlling issuance and redemption, and maintaining responsibility for the underlying deposit liability. The bank also establishes governance rules for holding and transferring tokens.

Corporate and institutional customers can hold and use tokenized deposits for approved activities, including payments, treasury operations, securities transactions, and other financial activities. Depending on the regulatory framework, individuals might also be eligible to use tokenized deposits for retail payments.

Business Workflow and Application Capabilities

The Oracle Blockchain Platform tokenized deposit application supports the end-to-end life cycle of tokenized commercial bank money. The life cycle includes token initialization, participant onboarding, creation, issuance, transfers, return of value, and retirement.

The application separates responsibilities among administrative and operational roles (personas), including administrators, creators, issuers, managers, approvers, officers, users, retirers, and auditors. Each operational user is associated with an eligible wallet and tokenized deposit account. Application groups determine the user's workspace, while ledger roles determine which smart contract operations the user can complete. These controls establish segregation of duties and institutional governance throughout the tokenized deposit life cycle.

Token Creation, Issuance, and Retirement: The application governs the creation, issuance, and retirement of tokenized deposits through controlled processes rather than unrestricted mint and burn operations. It uses an inventory-based model in which tokenized deposits are created in advance through an authorized process. The application then distributes the tokens from the available inventory instead of minting them on demand for each customer transaction.; An authorized creator submits a request to create new tokenized deposit supply. The request remains pending until the designated manager approves it. After approval, the created tokenized deposits are transferred to the issuer. The issuer maintains the available inventory and distributes tokens to eligible participants as required.; The inventory-based model provides greater operational control over token creation, clearer segregation of duties, and predictable token availability. It also reduces the need for a minting workflow for every issuance transaction. This approach is suitable for financial institutions that want to control minting and burning through approval processes while supporting efficient day-to-day distribution.; At the end of the life cycle, tokenized deposits are returned and subsequently submitted for retirement by an authorized retirer. The application burns the tokens only after the required approval.; Financial institutions that prefer an on-demand model can customize the smart contract and associated application workflow. In this model, tokenized deposits are minted and burned dynamically in response to individual issuance and redemption requests rather than managed through an inventory that is already created.
Transfers and Approval Policies: For day-to-day transactions, entity officers and users can transfer tokenized deposits to other participants. The application evaluates the active amount-based approval policy for each transfer. Depending on the configured policy, a transaction can settle immediately, require approval from a designated approver, or require sequential approval from multiple approvers before settlement. Rejection stops the transaction without settlement.; Transfers can also include a configurable business purpose that records the reason for the movement of funds. Before processing a transaction, the application validates account status, recipient eligibility, available balance, daily amount limits, daily transaction count limits, and the required approval context.; The application also provides governance and compliance controls for tokenized deposit transactions. Administrators can maintain users' know your customer (KYC), anti-money laundering (AML), and restriction states. They can also define approval policies based on transaction value ranges.; Approval policies can specify the relevant approver organization, individual approvers, and the sequence in which approvals must occur. The application retains policy history for review. At the account level, administrators can define maximum daily transaction amounts and transaction counts. They can also suspend or reactivate accounts as required.
Institutional Controls and Auditing: The tokenized deposit application extends standard ERC-20 fungible-token functionality with institutional controls. It provides registered organizations and accounts, wallet associations, and role-based segregation of duties. The application also supports controlled creation and retirement, transaction holds, and amount-based and sequential approvals. Additional capabilities include KYC and AML restriction controls, account suspension, daily transaction limits, configurable transaction purposes, and dedicated auditor roles.; The implementation separates account-related functionality from token-related functionality. Account-related functionality includes registration, status, limits, and roles. Token-related functionality includes balances, issuance, transfers, holds, and retirement.; The application provides operational visibility, transaction traceability, and auditability throughout the tokenized deposit life cycle. Transaction history can capture the initiator, counterparty, amount, business purpose or memo, balance, transaction type, and transaction identifier. Dedicated auditor workspaces provide read-only access for oversight and transaction investigation.

Customization and Extension Options

The tokenized deposit application can be customized and extended to align with a bank's operating model, governance framework, customer requirements, and integration architecture. The packaged application provides configuration options for organizations, accounts, roles, transaction limits, approval policies, wallets, and application presentation.

For requirements beyond these configuration options, customers can extend the smart contracts, wallet and account policies, web application, and APIs. These extensions can adapt the packaged application to a bank-specific tokenized deposit offering.

Smart-Contract Customization: Customers can extend the smart contracts to implement additional business rules and tokenized deposit behaviors. The packaged solution separates the account contract, which supports account registration, status, limits, roles, and related operations, from the token contract, which supports balances, issuance, transfers, holds, retirement, and related token operations.; Customers can extend this architecture to meet bank-specific requirements, such as additional transaction controls, different approval conditions, participant restrictions, or additional lifecycle operations.; For example, the packaged application uses an inventory-based issuance model. Customers could customize the smart contracts and application workflow to support an on-demand model in which tokenized deposits are minted and burned dynamically in response to individual issuance and redemption requests. These extensions are customer-specific and aren't described as packaged capabilities in the documentation.
Wallet and Account-Policy Customization: Banks can configure which users and accounts can interact with tokenized deposits and under what conditions. The packaged application associates users with wallets, organizations, application groups, smart contract roles, account status, and transaction limits. It validates these attributes when establishing a user's application session.; Customers can use these controls to establish different operating profiles for administrators, managers, officers, corporate users, and auditors. For additional requirements, customers can extend the model with wallet eligibility rules, transaction authorization requirements, and participant-specific limits. These additional wallet policy controls require customer-specific implementation.
Governance and Approval Customization: The application supports approval-driven transactions. Depending on the applicable policy and transaction amount, a transfer can complete directly or remain pending while the application routes it to the configured approver or approval sequence. A rejected transaction doesn't settle.; Banks can extend this framework to reflect their internal governance models. Potential extensions include different approval thresholds, additional approval stages, institution-specific authorization hierarchies, and separate policies for different categories of customers and transactions.; These controls can support the maker-checker environment required for governed transactions in regulated banking systems.
Web Application Customization: Customers can customize the application's user experience to reflect their branding and terminology. The packaged deployment supports optional changes to display names, logos, currency presentation, languages, organization information, and role labels.; For additional requirements, customers can extend the web application with customer-specific screens, dashboards, data fields, approval journeys, reporting views, and transaction workflows.
API and Enterprise Integration Extensions: The wrapper API provides the application interface for account, token, organization, and transaction operations. Through this interface, the web application and other enterprise applications can interact with the underlying tokenized deposit services.; Customers can extend this integration layer to connect the tokenized deposit application with their core banking system, deposit accounts, general ledger, treasury and liquidity management systems, and payment infrastructure. Other potential integrations include know your customer (KYC), anti-money laundering (AML), and sanctions services, regulatory reporting, and enterprise resource planning (ERP) applications.; These external integrations are potential customer extensions, not the prebuilt integrations described in the documentation.