Policy templates
Assemble reusable compliance rules for instrument templates and asset issuance.
A policy template bundles compliance controls into one named rule set, scoped to the jurisdictions it covers. A control is one enforceable rule, such as an investor eligibility check or a country restriction, that decides whether a regulated operation like a transfer or a subscription can proceed. Instrument templatesAn Instrument Template lets an issuer configure a new instrument from an approved shape, instead of re-deciding what it records, does, and permits each time.Read the concept (the reusable product definitions selected during asset issuance) each link one published policy. This page decides which rule sets exist for your organisation, what each one enforces, and which values an asset designer may still adjust per asset.
Reach for this page when a jurisdiction, product type, or regulatory change needs its own rule set, or when the values in an existing one must move. You do not need it to issue an asset; the instrument template chosen there already carries its policy.
The "Policy templates" entry appears under "Compliance" only for the admin and compliance manager roles, and the platform accepts template writes from those two roles only.
Publishing a policy adds it to the choices an instrument template can link, and changes nothing until one does. The rules land on an asset at issuance and stay with that asset, so editing a policy later changes what the next issuance installs, never an asset that already exists. Every write on this page, from a first draft to a delete, lands in the organisation's audit trail with your name and role at the time.
Rules travel one way: publishing makes the policy selectable, an instrument template links it, and issuance installs a copy on the asset. Edits after publishing change only what later issuance installs.
Steps
Open Policy templates
Open "Compliance", then "Policy templates". The catalog is a table that shows your organisation's templates next to the platform-provided DALP library set, one row per template. Its columns are "Name", "Jurisdictions", "Source", "Status", "Module set version", and "Updated". Search, or filter by "Jurisdictions", "Source", and "Status", to check whether a usable rule set already exists before you create a near-duplicate. Sort by a column heading and page through the table at the bottom.
The "Jurisdictions" column lists each jurisdiction a template covers and reads "Global" for a template with none. "Status" reads "Draft" or "Published". "Module set version" identifies the generation: 1 is the earlier, legacy generation. On a deployment that still runs legacy asset types, the table opens filtered to the current generation, and removing that filter lists legacy templates too. Compliance modules explains how the generations differ.
Select the arrow at the start of a row to expand it. The expanded row shows the template's description, the controls it configures, and the controls it requires. Selecting the row itself opens the template's detail page.
Screen equivalent: the catalog is a table. Each row shows the policy's name, its jurisdictions or "Global", its source, whether it is a draft or published, its module set version, and its last update. A row expands to show the description and the configured and required controls. Use the jurisdictions filter to narrow the catalog by scope.
Choose a starting point
Select "Create template", then pick one of the three cards on the Start step.
| Start from | What you get | Choose it when |
|---|---|---|
| "Start from DALP library" | A draft copied from a platform-maintained regulatory framework | A recognised framework covers your product and you only tune its values |
| "Clone one of yours" | A draft copied from one of your organisation's templates | A close rule set exists and needs a variant for another jurisdiction or share class |
| "Blank" | An empty draft with no inherited controls | Nothing existing is close, or every control must be chosen deliberately |
The DALP library includes frameworks such as the Markets in Crypto-Assets Regulation (MiCA) and the SEC Regulation D Rule 506(b) exemption for private placements. A copy does not stay connected to its source, so a later change to the library or to the source template never reaches your draft. On deployments that still run legacy asset types, the "Blank" card also asks for the module-set generation. That choice is fixed the moment the template is created, and instrument templates offer current-generation policies only, so take the legacy generation only for a product line that genuinely still needs it.
Set the scope and the controls
Name the template on the Basics step, choose jurisdictions on the Scope step, then enable and configure controls on the "Controls & Rules" step. Template names are unique within an organisation. Leaving the jurisdiction list empty applies the template globally; a scoped list records where the rule set is meant to apply and feeds the catalog's jurisdiction filter.
In the controls catalog, selecting a control marks it active, but the wizard blocks the next step until you open each selected control, set its rule values, and save. Two toggles govern the value at issuance. "Make configurable in Asset designer" starts on, allowing the issuer to change it. "Required" starts off, allowing issuance without a value. Turn "Make configurable in Asset designer" off and turn "Required" on when a regulator, not a product team, owns the number. The catalog lists only controls compatible with the template's module-set generation; what each control enforces is described on Compliance modules.
Review and publish
Check the readiness list on the Review step, then either "Save as draft" or publish. The list names each required control that is missing or incompatible, together with its fix; "Publish template" stays unavailable until the list is empty, and the platform runs the same check again when you publish. "Save as draft" keeps the template out of instrument templates' choices while it stays editable. Publishing asks for confirmation because it cannot be undone: there is no unpublish, and the policy stays selectable until you delete it. Both paths end on the template's detail page.
Do this without opening the Console
Creating a draft and publishing it are separate calls. After creation, configure the draft's controls and review its readiness before publishing. Replace the example template identifier with the identifier returned by creation.
curl -X POST "https://your-instance.example.com/api/v2/settings/compliance-templates" \
-H "X-Api-Key: sm_dalp_..." \
-H "Content-Type: application/json" \
-d '{"name": "EU transfer restrictions", "description": "Transfer restrictions for Northwind Coffee securities issued in the EU", "jurisdictions": ["EU"]}'
curl -X POST "https://your-instance.example.com/api/v2/settings/compliance-templates/ct_northwind_eu_transfer/publish" \
-H "X-Api-Key: sm_dalp_..."Both calls need the admin or compliance manager role behind the credential, the same requirement the Console enforces. Publishing still cannot be undone through either path.
Changes after publishing reach only later issuance
A published organisation template stays editable in place. Its detail page changes the basics, the scope, or the controls directly, and the version rises by one on each save. The platform refuses an edit that would leave a published template unable to pass the readiness check. An edit changes what the next issuance installs; an asset already issued keeps the rules it was created with, and a live asset's rules are managed on the asset itself, not here. A DALP library template never changes: duplicate it into an organisation draft when you need a variation.
Deleting removes the policy and its module configuration. The confirmation dialog names the template and deletes its compliance module configuration with it. An instrument template that linked the deleted policy loses the link but keeps working. The missing link does not itself block publishing or issuance, so later assets start without the deleted template's rules. Inherited global and identity controls still apply. Link a replacement policy on every affected instrument template before the next issuance. A platform-managed template cannot be deleted, and no deletion touches an asset already issued.
Troubleshooting
Publishing is unavailable
The template has readiness gaps, or you lack the role. The Review step and the detail page list every gap: configure the named required control on "Controls & Rules", or remove it from the required controls when it is incompatible with the template's generation. When the list is empty and publishing is still refused, check that you hold the admin or compliance manager role.
A template refuses edits
DALP library templates cannot be edited or deleted; duplicate one into an organisation draft and adjust the copy. When one of your organisation's templates refuses a change, check your role: the platform accepts template writes from admin and compliance manager only.
Creating or renaming fails on the name
Template names are unique within an organisation, and the refusal says a template with this name already exists. Pick a distinct name, or delete the earlier template when it is obsolete.
A control is missing from the catalog
A control introduced for the current generation never appears in a legacy template, because the catalog only offers controls compatible with this template's generation. The generation cannot be changed after creation; rebuild the rule set as a current-generation template instead.
The policy is missing from an instrument template's choices
Only published, current-generation policies are offered when linking. Check the status badge on the policy's detail page: a draft must be published first, and a legacy-generation policy never appears in the instrument template wizard. The wizard's compliance step also opens filtered to the instrument template's jurisdiction. Select the "Applies to" chip there to turn the filter off and list policies for every jurisdiction.
An instrument template lost its policy
Deleting a policy clears the link on every instrument template that used it rather than deleting those templates. Open each affected template and link a replacement before the next issuance; without a link, newly issued assets start without the deleted policy's rules.
Frequently asked questions
Can I unpublish a policy template?
No. Publishing a policy template is permanent, and the confirmation dialog says so before you commit. Only instrument templates can be unpublished. To retire a rule set, point the instrument templates that link it at a successor policy first, then delete it; deletion removes it from the choices without touching any asset already issued. An unlinked published policy enforces nothing on its own, but remains selectable for future instrument templates.
How is a policy template different from global controls?
Scope. A policy template's rules reach only assets built from instrument templates that link it. Global controls apply to bound tokens, including existing ones, within each rule's scope. An issuer cannot remove inherited global rules during asset creation. Review recipient bypasses and privileged recovery paths separately. Together the two layers form the asset's compliance policyA Compliance Policy lets a compliance team write eligibility and holding rules once, while a platform floor reaches every current-factory token.Read the concept, the full rule set a transfer or subscription is checked against. Use global controls for a floor every asset must meet, and policy templates for the rules a specific product type or jurisdiction adds on top.
Can another organisation see or use my policy templates?
No. The catalog is scoped to your organisation: you see your own templates plus the platform's DALP library set, and other organisations see theirs. A DALP library template is shared platform-wide but read-only; copying it with "Start from DALP library" creates an organisation-owned draft that only your organisation can see, edit, or eventually publish.
Is there an API for policy templates?
Yes. Create and publish above are the two calls this page's steps map to; list, read, update, and delete follow the same shape through the Platform API, under the same role requirements this screen enforces. The generated reference documents every request field and status code; no guide restates those schemas.