# Policy templates

Source: https://docs.settlemint.com/docs/operators/compliance/templates
Create, publish, delete, and reuse policy templates that group DALP compliance modules for asset creation.



A policy template packages a set of compliance modules with predefined configurations. Keep it in draft while you configure it, publish it when ready, and select it in the Asset Designer to apply the same controls across multiple issuances.

Use this guide when you need to turn a repeatable policy pattern into something asset creators can apply without rebuilding the same country, identity, transfer, supply, or collateral controls for every issuance.

## What are policy templates? [#what-are-policy-templates]

A policy template is a collection of compliance modules with predefined configurations. The Platform API exposes this surface through compliance-template endpoints, but the operator workspace labels the page Policy templates. When you apply a template to an asset, DALP copies its modules into the asset's compliance configuration.

### How template types fit together [#how-template-types-fit-together]

DALP separates reusable asset setup into three template areas:

| Template type     | Defines                                                                                                                              | Usage                                                                                       |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- |
| Policy template   | Compliance modules, jurisdictions, required controls, and draft or published status.                                                 | Selected in the Asset Designer compliance step when an asset should reuse a policy pattern. |
| Token template    | Token-level behaviors the issued asset should include, such as maturity, fees, yield, conversion, or permit support.                 | Managed through instrument templates as required token features and feature configuration.  |
| Metadata template | Asset data fields the Asset Designer should collect, including field key, label, type, required status, mutability, and constraints. | Managed through instrument templates and completed during asset creation.                   |

These template types compose with each other. An [instrument template](/docs/operators/asset-creation/instrument-templates) can require token behaviors and metadata fields, while a policy template supplies the policy controls selected during the compliance step.

### Why use templates? [#why-use-templates]

Apply the same module pattern to multiple assets rather than rebuilding controls per issuance. Assets in the same category share the same configured rules. Configure once, reuse across your portfolio. DALP also ships library templates for common compliance patterns so you have a starting point.

## Template detail page [#template-detail-page]

When you open a policy template, the detail page shows all key information at a glance.

### Inline metadata bar [#inline-metadata-bar]

The top of the detail page shows an inline metadata bar. It displays status (published or draft), jurisdiction (the regulatory scope the template targets, or "Global" for multi-jurisdictional use), version number, and the date of the last modification. Use these fields to pick the right template without opening each one.

### Template content [#template-content]

Below the metadata bar, the page lists all compliance modules in the template by category. Categories include eligibility (who can hold the asset, via verification, allow lists, and block lists), geographic and address restrictions, transfer controls, supply limits, time-based holding rules, and settlement or collateral requirements.

## Module classification tags [#module-classification-tags]

Each compliance module in a template carries classification tags. Expand a module's details to see the exact rules it enforces before you enable it.

| Tag          | Meaning                                                                |
| ------------ | ---------------------------------------------------------------------- |
| Eligibility  | Controls who can hold or receive assets based on identity verification |
| Identity     | Validates investor identity through verified credentials               |
| Restrictions | Limits asset ownership based on geography or specific addresses        |
| Security     | Enforces security measures like transfer approvals                     |
| Limits       | Caps the number of holders or total supply                             |
| Transfer     | Controls how and when transfers can occur                              |

## Filtering templates [#filtering-templates]

The templates index page gives you four ways to narrow the list. Search by name or description. The jurisdiction filter picks a specific country or "Global" for templates that span jurisdictions. The source filter shows DALP library templates (pre-built for common patterns) or templates your organisation created. The status filter shows only published templates, which are ready to apply, or drafts, which are still being configured.

## Creating a new template [#creating-a-new-template]

To create a new policy template:

1. Navigate to **Organisation settings** → **Compliance & verification** → **Policy templates**.
2. Use the page-level **Version** filter to choose the generation you want to work with. **Current** lists current-generation templates, **Legacy** lists legacy templates, and **All** lists both. Legacy templates carry the earlier compliance-module generation and exist so tokens deployed on that generation keep working. Use current-generation templates for new tokens.
3. Click **Create template** and select:
   * **From scratch** to build a new policy with no starting configuration.
   * **From existing** to copy an existing template.
4. When you create from an existing template, choose a **Source Template**. The source list follows the page-level Version filter. In **All** mode, legacy source rows are marked so you can tell same-named templates apart.
5. Choose the module generation for the template. From-scratch templates start on the current generation by default. Templates copied from an existing template start with the source template's generation, but you can still change the generation before saving. If copied modules or required controls are not available in the generation you select, DALP asks you to confirm and removes the incompatible items from the new template.
6. Configure the compliance modules and required controls you need.
7. Set the template status to **Published** when ready.

### Required controls [#required-controls]

Required controls define which compliance controls must be present when the template is applied to an asset. Use them when a template should make a policy control mandatory but the final parameters still need to be completed during asset creation or later governance.

Required controls are saved as compliance control IDs and must match the template's module generation. Do not mix legacy and current-generation controls in the same template. If a control is not compatible with the selected generation, DALP rejects the create, update, or publish request rather than saving a template that asset creators cannot apply safely.

The selector shows a generation marker next to each control name. Use it to distinguish similar-named controls and confirm the generation matches. The marker is display guidance only: the saved record stores raw control IDs.

Required controls are not the same as configured modules. A configured module carries the values the template will copy into the asset. A required control tells the asset creator that this control family must exist. The asset-specific values can still be supplied during asset creation or later governance. For example, a template can require identity verification without deciding every trusted issuer, claim topic, or issuer-topic permission in the template itself.

When an asset creator applies the policy template in the [Asset Designer](/docs/operators/asset-creation/create-asset), DALP checks the final asset configuration against the template's required controls. If the template requires a control family, the asset must include that control before deployment. Use the [compliance module index](/docs/compliance-security/compliance) to confirm whether the required control checks holders, transfers, minting, lifecycle accounting, or trusted-issuer claims.

### Which controls can a template require? [#which-controls-can-a-template-require]

A policy template can require the same control families that DALP can attach to an asset.

Use this table to decide whether the policy should be fixed on the template or left for the asset creator to complete.

| Control family             | Example controls                                                               | What the template can standardise                                                                                                      |
| -------------------------- | ------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------- |
| Geographic restrictions    | Country allow list, country block list                                         | The allowed or blocked jurisdictions for a product family.                                                                             |
| Identity and address lists | Identity allow list, identity block list, address block list                   | The identities or addresses that must be allowed or blocked before the asset starts operating.                                         |
| Verification requirements  | Identity verification                                                          | The claim topics holders must satisfy, such as KYC or accreditation. Claim-policy managers still configure trusted issuers and topics. |
| Holder and supply limits   | Investor count, token supply limit, capital raise limit, issuance volume limit | Caps and thresholds that must be present for the asset.                                                                                |
| Transfer controls          | Time lock, transfer approval                                                   | Holding-period rules or approval requirements that should apply before transfers execute.                                              |
| Collateral controls        | Collateral requirement                                                         | The backing-evidence rule that must be present before minting assets that depend on collateral verification.                           |

Required controls describe token-compliance rules that the asset must carry after the template is applied. They can require the rule family, but they do not replace claim-policy management: a claim-policy manager still owns trusted issuer setup, claim topics, and issuer-topic permissions for verification-based controls.

Current-generation templates use the current control set by default. Legacy-only controls stay available for legacy templates, but DALP does not let a current-generation template require a legacy-only control.

### Decide what stays configurable [#decide-what-stays-configurable]

Each module can either carry fixed values from the template or leave selected values configurable in the Asset Designer. Use this split deliberately:

| Policy decision                         | Keep fixed on the template when                                                                     | Leave configurable during asset creation when                                                   |
| --------------------------------------- | --------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| Jurisdiction or country list            | Every asset created from the template must use the same allowed or blocked jurisdictions.           | The asset's market, investor base, or distribution region changes per issuance.                 |
| Identity and address controls           | The same allow list, block list, or identity-verification policy applies to the whole asset family. | The policy is mandatory, but the exact list or verification setup is chosen for each asset.     |
| Transfer approval                       | The same approval model and authority set applies to every asset created from the template.         | The asset needs transfer approval, but the authority list or approval window is asset-specific. |
| Holder, supply, or capital-raise limits | The limit is part of the product policy and should not vary between assets.                         | The limit depends on the individual offering, issuance size, or governance decision.            |
| Collateral controls                     | The same collateral rule applies to the whole product family.                                       | Collateral terms are set per asset or per issuance program.                                     |

Before publishing, review each required control and module setting from the point of view of the asset creator. If the asset creator must provide the value to complete issuance, keep that value configurable. If changing the value would break the intended policy pattern, keep it fixed in the template.

## Applying templates to assets [#applying-templates-to-assets]

When creating a new asset using the Asset Designer, select a policy template on the compliance step. DALP copies the template's modules into the asset's compliance configuration.

Review the [compliance module index](/docs/compliance-security/compliance) before publishing or applying a template. The index shows which controls apply to transfers, minting, burns, pre-checks, and lifecycle accounting hooks. Use it to confirm that the template matches the asset's policy before holders depend on it.

You can also reassign the policy template on an existing asset if you hold the governance role. Review the impact on current holders before making that change.

## Managing templates [#managing-templates]

### Editing templates [#editing-templates]

Open a template and click Edit to modify its configuration. Changes to the template do not automatically affect assets that already use it. Each asset maintains its own copy of the compliance configuration.

### Publishing and drafts [#publishing-and-drafts]

Templates are either draft or published. Draft templates are hidden from the selector during asset creation. Published templates are available to apply to new assets. This lets you prepare templates in advance and publish only when they are ready.

### Deleting templates [#deleting-templates]

When an organisation template is no longer needed, you can remove it from the policy templates workspace.

1. Open the template from the policy templates list to reach its detail page. **Template actions** is available there, not on the list itself.
2. Open **Template actions** and select **Delete**.
3. Confirm in the **Delete template?** dialog. DALP permanently deletes the template and its compliance module configuration, then returns you to the policy templates list.

Deleting a template requires the same manage permission as editing it. If you do not have that permission, the **Delete** action stays visible but disabled.

A few rules keep deletion safe:

* **DALP library templates cannot be deleted.** The **Delete** action does not appear for templates from the DALP library, since other organisations rely on them. You can delete only your own organisation's templates.
* **Existing assets are not affected.** Each asset keeps its own copy of the compliance configuration it was created with. Deleting a template never changes the controls already enforced on assets that used it.
* **Deletion is permanent.** There is no undo. If you might need the policy pattern again, duplicate the template before deleting, or keep it in **Draft** instead.

## Related [#related]

* [Compliance user guides](/docs/operators/compliance/overview)
* [Compliance module index](/docs/compliance-security/compliance)
* [Configure trusted issuers](/docs/operators/compliance/configure-trusted-issuers)