What institutions require

Institutional digital asset programmes fail when token issuance is treated as the whole platform. Once an asset is live, the operating question changes. The institution has to control who may hold it, who may move it, who approves privileged actions, how settlement is coordinated, and what evidence exists when an auditor asks what happened.

Use this page to test the main operating requirements before selecting or implementing digital asset infrastructure. Each section links to DALP pages that explain the relevant platform behaviour.

Key terms

• Integration point: a connection between separate systems that needs design, testing, monitoring, and ownership.
• Ex-ante control: a check that runs before a transaction changes state.
• Ex-post control: a check that runs after execution and may require correction or reversal.
• DvP: Delivery versus Payment, where asset delivery and payment are coordinated so neither leg is treated in isolation.
• XvP settlement: Exchange versus Payment settlement for coordinating token exchanges in one workflow.

See the Glossary for more definitions.

The lifecycle is the requirement

A regulated asset platform has to cover more than token creation. The institution needs a controlled lifecycle from asset setup through holder onboarding, transfer checks, privileged administration, settlement, servicing, reporting, and incident review.

The diagram shows the operating chain that starts with asset policy and ends with evidence. Asset setup, identity, signing, compliance, settlement, and servicing each need a clear owner. Each stage also needs enough evidence for operations, audit, and incident review.

The practical test is whether each stage reads from the same asset, identity, role, and transaction state. If each stage is owned by a different system with its own copy of the truth, the institution inherits reconciliation work, unclear ownership, and weaker audit evidence.

DALP is designed as one control plane for these lifecycle stages on EVM-compatible networks. The DALP overview explains the platform model. The architecture overview shows how the UI, APIs, workflows, contracts, indexer, and integrations fit together.

Compliance must run before balances move

Regulated assets need eligibility checks before a transfer changes balances. A later review may still be useful for surveillance. It does not prevent the original ledger state change.

DALP supports pre-transfer enforcement through identity records, trusted issuers, claim topics, token compliance modules, and transfer validation. If a configured check fails, the transfer path blocks the movement before balances change. The compliance transfer flow explains the validation order and failure outcomes.

This requirement matters because policy usually differs by asset. One token may require KYC and jurisdiction restrictions. Another may require accreditation claims, holding limits, lock-ups, or transfer approval.

The platform has to let those rules follow the asset. Otherwise teams fall back to manual checks in a separate spreadsheet or support queue.

Custody and signing need explicit operating control

Institutional signing cannot depend on one application hot wallet or one operator's local key. Privileged actions need role assignment, approval policy, custody-provider routing where configured, and evidence of who initiated and approved the action.

DALP separates application requests from signing and execution. The signing flow can route through configured signer infrastructure, including custody-provider integrations described in the DALP overview and the signing flow. Provider-native signing with Fireblocks or DFNS is covered where the deployment uses those integrations.

The operating split is important. DALP can enforce platform roles, prepare and track transactions, and route signing through the configured signing path. The institution still owns custody policy, provider configuration, approval quorum, key recovery procedures, and any custodian-side controls required by its governance model.

Settlement has to define both legs

On-chain token movement is not the same as complete settlement. If the token leg moves now and the cash leg settles later on banking rails, the operating model still has counterparty, timing, and reconciliation risk.

A stronger model coordinates the asset and payment-side actions so the approved exchange completes together or does not complete. DALP documents this pattern as DvP and XvP settlement.

See the XvP settlement overview and the architecture flow overview for the current settlement pages.

The institution should test settlement requirements with concrete flows: primary issuance, secondary transfer, redemption, partial failure, cancellation, expiry, and evidence retrieval. If a deployment uses an external payment rail, the split between DALP state and the payment system must be explicit.

Servicing must stay attached to the asset model

After launch, the programme still needs supply administration, distributions or yield flows where enabled, redemptions, holder reporting, document updates, and investor communications. These operations should be tied to the token, holder, role, and event state used by the rest of the platform.

DALP exposes lifecycle and addon pages for these operating tasks. Start with Asset creation, System addons, and API integration to see which actions are handled through the console, API, SDK, and workflow surfaces.

Do not evaluate servicing from a feature checklist alone. Ask which actor can run the action, what state changes, what evidence is emitted, how retries or failures are handled, and which external system remains responsible for off-platform cash movement, notices, legal records, or investor communications.

Enterprise deployment is part of the product decision

Banks and asset managers usually need their digital asset platform to fit existing identity, network, monitoring, backup, and change-management controls. The deployment model is not a hosting footnote.

DALP supports managed, customer-hosted, and dedicated deployment patterns on EVM-compatible networks, as described in the Introduction and DALP overview. The institution still has to decide the hosting environment, network access model, backup policy, data residency position, incident process, and downstream monitoring integration for its target deployment.

For evaluation, separate three questions:

Evaluation checklist

Use this checklist during platform review:

Where to next

• DALP solution explains how DALP addresses these requirements as a unified lifecycle platform.
• DALP overview describes the platform surfaces and deployment model.
• Architecture overview explains the control-plane architecture and integration split.
• Glossary defines the terms used across the executive overview.