In regulated digital asset programs, compliance policy belongs inside the operating model of the asset. Eligibility, jurisdictional reach, investor limits, approval requirements and evidence obligations are defined before an asset can move through issuance, transfer, servicing or redemption.
As digital asset programs expand across asset classes, instruments, and jurisdictions, the policy layer needs the same discipline as the asset model itself. The institution needs one approved standard that can be reused across the program, enforced at the point of transfer, and inspected by the teams responsible for control, audit, and reporting.
DALP 3.0 introduces compliance templates for that purpose. A compliance team can define the policy once, including who can hold the asset, which jurisdictions apply, which limits are in force and which approvals are required. Asset teams then apply the published template when they create an asset or instrument.
The result is a governed policy layer that travels with the asset. DALP applies the full module configuration to the on-chain compliance policy, and every mint, transfer and burn is checked against that policy before settlement.
Compliance templates make policy reusable
A compliance template is a versioned policy package for a regulated digital asset program. It groups the controls that belong together in a regulatory context: trusted identity issuers, required claims, jurisdiction rules, supply caps, investor limits, approval gates and collateral requirements.
The ownership boundary is deliberate. Compliance teams configure, review and publish the template. Asset teams select a published template during asset creation. That separation keeps policy design with the team accountable for it, while allowing new assets and instruments to start from approved controls rather than a reconstructed rule set.
The workflow is described in the DALP 3.0 compliance templates documentation.
On-chain enforcement through ERC-3643
DALP compliance templates are built on ERC-3643, the open Ethereum standard for permissioned tokens and regulated security tokens. ERC-3643 places compliance checks inside the token's transfer logic, so the asset consults the active policy before an operation settles on-chain.
That gives an institution a direct enforcement point for transfer eligibility. When a holder requires a verified identity claim, a jurisdiction rule applies, an investor limit has been reached or an approval is still pending, the token logic evaluates the condition at execution time.
DALP extends this model through modular compliance. Each module governs one dimension of policy, and the template packages those modules into a named, versioned composition. The documentation section on ERC-3643 in DALP 3.0 explains the model in more detail.
Identity, jurisdiction, limits and approvals in one policy layer
The template surface maps to the controls a regulated institution already manages. Identity and eligibility rules define which trusted issuers are accepted and which claim topics a holder must carry, such as KYC, AML, accreditation, suitability or a custom eligibility claim.
Jurisdiction rules allow or restrict participation based on residency. Supply and investor limits define the maximum size and composition of the asset or instrument. Approval and collateral modules add maker-checker review or evidence requirements before the operation proceeds.
These controls can sit at program level or asset level. A global rule can apply across every token in a system, while a local rule can remain specific to one asset. That structure lets an institution separate baseline policy from instrument-specific obligations without rebuilding the same control set each time.
Built-in frameworks for regulated programs
DALP 3.0 includes built-in library templates for nine regulatory frameworks. Institutions can clone the closest framework and adapt it to their own footprint, including trusted issuers, jurisdiction rules, caps and approval requirements.
The documentation references frameworks such as MiCA, MAS, UK FCA, Japan FSA, UAE regimes, Reg D and Reg CF patterns. The library templates are read-only, so an institution can use them as a starting point while maintaining its own organization-owned policy templates.
The available framework pattern is covered in the documentation section on frameworks for nine jurisdictions.
Typed rejection reasons for operations and audit
When an operation is blocked, DALP returns the reason. The platform can distinguish between an unregistered holder, a missing or expired claim, and a specific compliance module preventing the operation.
For operations teams, that creates a clear remediation path. For integration teams, it allows systems to branch on the typed reason and route the next action correctly. For compliance and audit teams, it produces a more precise record of how the policy was applied at the moment of execution.
The product behavior is documented in the section on rejection reasons.
Active policy available through the API
Once a template is applied to an asset, integration teams can read the active controls through the DALP v2 API. The API exposes the template, modules, jurisdictions, required controls, publication status and module-set version through a single endpoint.
The same policy surface is available through the CLI and MCP tooling. Compliance remains owned by the people qualified to define it, while platform teams can inspect the active rule set and build the right operational flows around it.
The API details are available in the compliance templates API documentation.
Reusable compliance as part of the digital asset lifecycle
Composability in DALP 3.0 applies to the policy layer as well as the asset design layer. An institution can configure approved building blocks once and use them across issuance, compliance, custody, settlement and servicing.
For compliance teams, the practical value is consistency. The same policy standard can be applied across asset classes and instruments, enforced on-chain and inspected through the platform surface. The asset carries the rules that govern it, and the institution retains a single operating model for defining, applying and reviewing those rules.
To see how compliance templates fit into the wider release, visit the DALP platform overview or read the DALP 3.0 compliance templates documentation.
Frequently asked questions
Compliance templates are reusable, versioned policy packages for regulated digital assets. They can include identity requirements, jurisdiction rules, supply and investor limits, approval gates and collateral requirements.
DALP uses ERC-3643-based on-chain compliance checks. The token checks the active policy before a mint, transfer or burn settles, and the operation proceeds only when the configured rules are satisfied.
The compliance team configures, reviews and publishes the template. The asset team selects a published template during asset creation, keeping policy ownership with the right team while allowing assets to be launched from approved controls.
A template can include trusted identity issuers, required identity claims, jurisdiction allowlists or blocklists, supply caps, investor limits, transfer approvals and collateral requirements.
Yes. The DALP v2 API exposes the applied template, modules, jurisdictions, controls, status and version. The same policy surface can also be accessed through the CLI and MCP tooling.
Want to discuss how reusable compliance policy fits your digital asset program?
Book a call with our team ↗
About SettleMint
SettleMint, headquartered in Leuven, Belgium, with offices in UAE, Singapore and Japan is the company behind DALP, the Digital Asset Lifecycle Platform. DALP enables financial institutions, market infrastructure operators, and governments to build, deploy, and manage digital assets and blockchain applications at scale.
