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 operations, how settlement is coordinated, and what evidence exists when an auditor asks what happened.

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

Key terms

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: asset setup, holder onboarding, transfer checks, privileged administration, and settlement. Servicing and incident review extend that same chain after launch, as does ongoing reporting.

The diagram shows the operating chain from asset policy to evidence. Each stage needs a clear owner, and each step must produce evidence for operations and incident review.

The practical test is whether each step reads from the same shared state. That state covers asset records and identity records, plus assigned roles and the full transaction history. When a different system owns each step with its own copy, your institution inherits reconciliation work, ownership becomes unclear, and audit evidence weakens.

DALP is designed as one control plane for these lifecycle stages on EVM-compatible networks. The DALP overview explains the platform model in full. The architecture overview shows how the console, APIs, workflow engine, and smart contracts fit together as a single surface you can operate against. No separate system integration required for each stage.

Compliance must run before balances move

Regulated assets need eligibility checks before a transfer changes balances. A post-hoc review may still be useful for surveillance, but it cannot undo 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 platform blocks the movement before the ledger updates. 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 your team falls 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 operations need role assignment, approval policy, and custody-provider routing where configured, plus a record of who initiated each step. Without clear role separation, a single compromised key or process failure can bypass all platform controls.

DALP separates platform requests from signing and execution. The signing flow routes through configured signer infrastructure. See the DALP overview and signing flow for details, including provider-native signing with Fireblocks or DFNS where the deployment uses those integrations.

Your institution still owns custody policy, provider setup, approval quorum, key recovery procedures, and any custodian-side controls its governance model requires. DALP enforces platform roles, prepares transactions, and routes signing through the configured path. The two sides are complementary: DALP handles the platform control layer, while your custody setup handles the key management and approval quorum.

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 carries counterparty risk, timing gaps, and reconciliation exposure.

A stronger model coordinates the asset and payment-side steps 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.

Test settlement requirements with concrete flows: primary issuance, secondary transfer, redemption, partial failure, and cancellation. Include expiry and evidence retrieval in that set. If your 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, record updates, and investor communications. Each task should read from the same state that the rest of the platform uses: token records, holder eligibility, and the event log that records what changed. That shared foundation keeps the programme operating as one system rather than several.

DALP exposes lifecycle and addon pages for these operating tasks. Start with Asset creation and System addons, then check the API docs to see which operations run through the console, the API, the SDK, or workflow surfaces.

A feature checklist alone is not enough to evaluate servicing. Ask which actor can run each operation, 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 need their digital asset platform to fit existing identity controls, network architecture, and change-management processes, as well as their monitoring stack. 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 asset tokenization overview and DALP overview. Your institution still has to decide the hosting environment, network access model, backup policy, data residency stance, incident process, and downstream monitoring for the chosen deployment.

When you evaluate a platform, separate three questions:

Evaluation checklist

Use this checklist when you review a platform:

Where to next

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