# Deposit certificates Source: https://docs.settlemint.com/docs/business/use-cases/deposits Model tokenized bank deposits and certificate-of-deposit style products on DALP with controlled issuance, holder eligibility, maturity terms, deposit detail claims, price feeds, and auditable token records. External banking systems remain responsible for legal classification, deposit insurance, cash movement, core-ledger posting, statements, and regulatory reporting. Tokenized deposit certificates are cash-like instruments whose token record represents a bank-led product such as a tokenized deposit, term deposit, or certificate of deposit. DALP provides the EVM lifecycle layer: token configuration, role-controlled issuance, holder eligibility, term and rate metadata, token price records, supply actions, and indexed operational evidence. DALP does not decide whether a product is a regulated deposit or an insured instrument. DALP also does not move cash in the bank core. The issuing institution remains responsible for product terms, customer disclosures, deposit-insurance treatment, reserve evidence, bank-ledger posting, payment rails, statements, and supervisory reporting. ## Quick answer [#quick-answer] Use the DALP deposit pattern when the institution wants a controlled EVM record for a deposit-like position while the bank core remains the source of truth for money movement and the customer deposit relationship. The useful starting point is simple: define the product terms, create a `deposit` token with the relevant term and rate fields, apply holder controls, then reconcile every token action against bank-ledger and payment records. ## What this page helps you decide [#what-this-page-helps-you-decide] Use this page when you need to evaluate whether a deposit-like product can be operated on DALP and which parts must stay in the bank's surrounding systems. | Reader | Decision this page supports | | ------------------- | --------------------------------------------------------------------------------------------------------- | | Product owner | Whether a term deposit, tokenized bank deposit, or certificate-like product fits the DALP deposit pattern | | Solution architect | Which fields and lifecycle controls DALP records, and which banking systems must remain integrated | | Operations lead | Which mint, transfer, redemption, reconciliation, and exception processes need an owner | | Compliance reviewer | Where DALP holder controls end and product, insurance, disclosure, and reporting obligations begin | ## The operating model [#the-operating-model] A deposit programme starts with bank-approved product terms. DALP turns those terms into an EVM token lifecycle that operators can administer and reconcile. The split is deliberate. DALP gives the institution a controlled token record for the deposit position. The institution still owns the product terms, customer relationship, cash movement, and bank-book record. ## What DALP records for deposit tokens [#what-dalp-records-for-deposit-tokens] Deposit creation uses the `deposit` asset type. The creation schema requires the shared token fields and deposit valuation fields, then accepts optional deposit-specific terms. | Field or control | How it is used | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | `type: "deposit"` | Selects the deposit token creation path and deposit factory | | `name`, `symbol`, `decimals` | Define the public token identity and accounting precision | | `countryCode` | Records the numeric jurisdiction code used during token creation | | `priceCurrency` and `basePrice` | Record the fiat valuation input used for token pricing and liability views | | `termLengthDays` | Optional term length stored in deposit-detail claims when provided | | `interestRateBps` | Optional annual rate, in basis points, stored in deposit-detail claims when provided | | `earlyWithdrawalPenaltyBps` | Optional early withdrawal penalty, in basis points, stored in deposit-detail claims when provided | | `initialModulePairs` | Compliance module configuration applied during token creation | | `initialPermissions` | Optional token-role assignments made during creation | | `unpauseOnCreation` | Optional creation-time unpause path; otherwise the token can be unpaused later by an account with the required role | When deposit term, rate, or penalty fields are provided, DALP writes a `depositDetails` claim. The claim contains `termLengthDays`, `interestRateBps`, and `earlyWithdrawalPenaltyBps`. These fields make the product terms visible to DALP surfaces and downstream API consumers. They do not replace customer terms, bank statements, or disclosures. ## Lifecycle controls [#lifecycle-controls] A deposit token follows the same regulated-token lifecycle as other DALP asset classes, with deposit-specific detail fields layered on top. | Stage | DALP control | Institution-owned control | | ------------------ | ----------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | Product setup | Configure the deposit token and optional deposit details | Approve product terms, disclosures, eligibility, insurance position, and operating policy | | Issuance | Mint certificates only through accounts with supply-management authority | Confirm the corresponding deposit liability, customer account, payment, or funding event in the bank core | | Holder eligibility | Use identity registration, trusted issuer configuration, and compliance modules to restrict holders and transfers | Own onboarding policy, KYC or AML interpretation, exceptions, and customer communication | | Servicing | Use token records, price feeds, holder lists, events, and optional yield or maturity features where configured | Calculate customer entitlements, interest posting, statements, tax, notices, and regulatory reporting | | Redemption or exit | Burn or redeem token positions through the configured operating process | Move cash on payment rails, post the bank ledger, and close or update the customer product | | Reconciliation | Compare token supply, holder balances, transaction status, and indexed events | Reconcile against bank-core balances, reserve accounts, customer records, and audit evidence | The most important implementation habit is to keep token supply and bank liability in lockstep. A mint without a matching deposit record creates reconciliation risk. A bank-ledger redemption without the corresponding token action leaves a stale token record. ## Pricing, maturity, and yield context [#pricing-maturity-and-yield-context] DALP separates three concepts that are often bundled together in banking language: 1. **Valuation** - `priceCurrency` and `basePrice` describe the fiat value per token and feed pricing views. 2. **Deposit details** - `termLengthDays`, `interestRateBps`, and `earlyWithdrawalPenaltyBps` describe the deposit terms captured with the token. 3. **Cash servicing** - interest posting, withholding, statements, payment instructions, and bank-ledger updates remain operating responsibilities unless the institution has integrated the relevant external systems. The split lets a deposit token show term and rate context without turning DALP into the bank's core deposit system. DALP supplies the token lifecycle and evidence record. The institution supplies the banking book and customer administration. ## Compliance and insurance boundary [#compliance-and-insurance-boundary] DALP can support a compliant operating process, but it does not make a product insured or compliant by itself. | Topic | DALP can support | Still owned by the institution | | ------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Holder controls | Identity, trusted issuers, compliance modules, role-based token administration | KYC policy, eligibility interpretation, sanction screening policy, exception handling | | Deposit insurance | Token, holder, supply, and transaction records that can be reconciled with programme evidence | Whether the product qualifies, the insured capacity, customer disclosures, aggregation rules, and supervisory reporting | | Auditability | Indexed events, transaction status, token metadata, holder records, and API reads | Legal register treatment, statements, bank-core extracts, reserve reports, attestations, and regulator evidence packs | | Redemption controls | Token burn or redemption records and status tracking | Cash settlement, ACH or wire execution, account posting, settlement timing, and customer notice | Treat DALP records as evidence for the token-side lifecycle, not as proof of insurance status, reserve sufficiency, or supervisory approval. ## Evidence files and document handoff [#evidence-files-and-document-handoff] Deposit programmes usually need an evidence packet that combines DALP records with bank-owned records. Keep those two evidence types separate. DALP can attach approved files to the token record through the token document upload flow. For deposit tokens, the documented file types include `term_sheet`, `legal_opinion`, `regulatory_filing`, `compliance_report`, `financial_statement`, `interest_schedule`, `certificate`, and `other`. Use those records for files that belong with the token lifecycle, such as product terms, compliance reports, statements, certificates, or reviewed operating evidence. Do not treat an uploaded token document as DALP proof that the bank ledger, reserve account, or insured balance exists. The uploaded file is an asset document with metadata, versioning, visibility, download controls, and a file hash. The institution still owns the source evidence, approval process, retention basis, and reconciliation against bank-core, treasury, and supervisory records. A clean handoff uses this split: | Evidence question | DALP record | Bank-owned evidence | | -------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | What token action happened? | Token address, holder address, amount, status, transaction hash, indexed event, and document metadata | Operations approval, bank-ledger posting, payment reference, and customer notice | | Which approved document supports the token record? | Token document type, title, version, visibility, uploader metadata, and `fileHash` | Source document, sign-off, retention policy, and access approval | | Does the deposit liability match the token state? | Total supply, holder balances, mint or burn history, and related token documents | Core-banking balance, reserve or treasury record, statement, attestation, and audit file | For the upload flow, file hash, document types, and visibility controls, see [Token document uploads](/docs/developers/api-integration/token-documents). ## What a production design needs around DALP [#what-a-production-design-needs-around-dalp] A production deposit programme normally needs these connected capabilities around the DALP token lifecycle: * bank-core integration for account opening, liability posting, interest posting, and maturity processing; * payment-rail integration for subscription funding, redemption, and exception handling; * customer identity and disclosure processes outside the token contract; * reconciliation between token supply, holder balances, bank-ledger balances, reserve evidence, and statements; * operating controls for pause, role grants, mint approval, redemption approval, and incident response; * reporting packs for finance, risk, compliance, audit, and supervisors. DALP is useful because it makes the token-side lifecycle explicit and queryable. It is not a substitute for those surrounding controls. ## Implementation path [#implementation-path] 1. **Classify the product.** Confirm whether the instrument is a tokenized deposit, certificate of deposit, stablecoin-like product, note, fund unit, or another asset type. 2. **Define the token terms.** Choose the token name, symbol, decimals, jurisdiction, price currency, base price, term, rate, and any penalty field you want recorded. 3. **Design holder controls.** Decide which identities, trusted issuers, claims, and compliance modules are required before holders can receive or transfer certificates. 4. **Map bank-system integration.** Decide how mint, burn, redemption, interest posting, statements, and payment events synchronize with the bank core. 5. **Create and operate the token.** Use the deposit creation and minting runbook for the SDK path, then reconcile the resulting token records against the bank record. ## Limits to make explicit [#limits-to-make-explicit] * DALP deposit tokens are EVM assets. Non-EVM networks, bridges, payment systems, and bank rails are external integration surfaces. * DALP records deposit detail fields when provided. It does not calculate the legal deposit balance, insurance cap, customer statement, or tax treatment by itself. * Early-withdrawal penalties can be recorded as a deposit term. Applying the penalty to a customer cash flow requires the institution's servicing process or an integrated workflow. * Token price records support valuation and reporting views. They are not proof that reserves, cash, or insured balances exist outside DALP. * Redemption timing depends on the institution's payment rails, settlement policy, and core-banking integration. ## Related docs [#related-docs] * [Deploy and mint deposits with the TypeScript SDK](/docs/developers/runbooks/create-mint-deposits) shows the API flow for creating a deposit token and minting certificates. * [Use cases and instrument template routing](/docs/business/use-cases) explains how deposit certificates fit the wider asset-class map. * [Stablecoins](/docs/business/use-cases/stablecoins) covers cash-like tokens where reserve and redemption controls are the main concern. * [Identity and compliance](/docs/compliance-security/security/identity-compliance) explains holder eligibility controls. * [Market data infrastructure](/docs/business/market-data-infrastructure) explains token price feeds and valuation records. * [Operational integration patterns](/docs/developers/api-integration/operational-integration-patterns) explains how external systems consume DALP records.