A Policy Template is copied into the token's own policy at creation, and every movement then checks that policy and the system's Global Controls live.
A Policy Template lets a compliance team approve eligibility, jurisdiction, holding, and approval rules once, then hand asset teams something ready to select at creation. A later edit to the template never rewrites a token already issued.
Global Controls let a Compliance manager set a rule once and reach every token bound to the organisation's system Compliance Engine on that network, without editing each token by hand. Each token factory binds the tokens it deploys, and a factory migration binds older tokens.
A movement must pass both layers before it settles. On a second-generation engine, a recipient on the compliance bypass list skips only the checks that judge whether it may hold the token. DALP manages that list. Who manages the compliance bypass list says who can still change it. One failing rule in either layer reverts the movement in full before balances change.
Why an asset team starts from an approved template
An asset programme rarely stops at one token. A compliance team that approves eligibility, jurisdiction, holding, and approval rules for a corporate bond does not want to rewrite the same rules for the next issuance under that programme. A Policy Template lets that team approve the rule set once and hand it to an asset team to select.
Asset Lifecycle names where that choice attaches. An Instrument Template binds four design inputs together at deployment: the asset's business class, the facts it records, the features it carries, and the compliance choice that governs it. A Policy Template is what a compliance team hands to that fourth input. Once the asset is live, the same choice surfaces again in its own workspace as a compliance configuration tab, so a reviewer reads the rules the token enforces and compares them with the approved template.
Without a reviewed template, each new issuance starts blank. A compliance team writes the same kind of rule from scratch for every asset, or an asset team improvises its own version. A due-diligence reviewer then checks each token's policy on its own, instead of pointing to one approved shape reused across the programme. With a template, every token can start from something a compliance team already reviewed. The platform does not record which template an asset used, so a reviewer matches its bindings to the template.
Why the platform still enforces its own floor
A platform owner needs a different guarantee: one rule that reaches every token regardless of which template it started from, so a token's own rules cannot switch off an organisation-wide requirement. Global Controls answer that. Every token factory binds the tokens it deploys to the system Compliance Engine, the shared engine of the organisation's system on that network. A Compliance manager installs a rule once in that engine, and it reaches every bound token, including tokens created later, whether or not the token's own template ever named the rule. Without Global Controls, a platform owner would edit each live token by hand whenever a new floor is required. That work grows with the number of tokens.
The two layers do not answer to the same clock. A Policy Template ties to one point in an asset's working life, the Design and Service stages Asset Lifecycle already names. Global Controls sit outside any one stage: they check every mint and transfer a token makes, and receive every burn for their counts, for as long as the deployment runs. A Compliance Policy is the pair of them together: a reviewed template an asset team selects, plus an organisation-wide floor that the template and the token's own rules cannot switch off. Only a Compliance manager changes that floor. A holder of the token's Governance role can still replace the token's compliance contract with a direct contract call, so review who holds Governance.
What each layer holds
A template is a starting configuration, not a promise that every existing token changes when the template changes. The platform copies the chosen modules, each one a configured rule with its own values and scope, into the new token's on-chain compliance engine. This gives each issued token a stable, inspectable policy. Global Controls hold no such copy: each token consults the system engine directly on every transfer, so a change to a Global Control reaches every bound token at once. Both layers are enforced inside the transfer path before settlement, and each has its own owner, scope and change path.
How teams use the two policy layers
Day to day, a Compliance Policy divides work between programme policy and platform policy. A compliance team drafts a Policy Template, chooses its module generation, first or second as Compliance modules defines them, when the deployment allows first-generation templates, adds controls and scopes, then publishes it for asset teams. Policy templates and Global controls show the Console steps. Choose the second generation unless the template needs a control that only exists in the first, such as the issuance volume limit or the token supply limit. A handful of newer controls, such as a capital-raise limit or a minimum-holding requirement, exist only in the second generation. The choice is permanent: a template cannot mix generations. A required control incompatible with the saved generation can never be configured on that template, so the only fixes are dropping the control from the required list, or requiring a compatible one instead. An instrument template links the published template, and an asset team issuing from it starts from those controls instead of reconstructing them.
The template can carry two kinds of content: required controls and configured modules. Required controls name the rule types the template must include before it can publish. A readiness check blocks publishing a template that is missing one. Configured modules carry the values and scope that are installed on the token. Drafts remain editable. Published templates are available for selection. Platform library templates are read-only, while an organisation can copy one and maintain its own version.
A Compliance manager manages Global Controls separately. A global module can restrict every token bound to the system Compliance Engine or use token scope to narrow where it applies. Installing or changing it affects the system Compliance Engine, not the Policy Template catalogue. Operators therefore review two views when they need the effective policy: the token's own module bindings and the inherited Global Controls.
Choose where to put a rule by who it must reach and who may change it.
When a transfer fails, the failed module blocks the movement before balances change, and the caller receives DALP-1096 for a transfer or DALP-1110 for a mint. Neither error names which layer rejected the movement. To find the failing rule, the operator reads both the token's own bindings and the inherited Global Controls, or runs the same transfer on the token's “Transfer pre-check” tab, which names the failing rule. The operator then fixes the underlying eligibility, scope, limit, or approval condition.
Where reuse ends and inheritance begins
A Compliance Policy composes two on-chain compliance engines. Each second-generation token has its own engine with address-keyed module bindings, and the organisation's system also has one shared Compliance Engine on each network. A first-generation token has no engine of its own: it calls the shared engine directly, which runs that token's modules and then the Global Controls. During a token movement, the token evaluates active, in-scope local modules and then delegates to the system engine, as shown in the two-engine flow.
The token engine evaluates its own modules first, then delegates to the system engine for the Global Controls, and either layer can revert the movement.
Policy Templates live off-chain as versioned settings records. A template stores its module-set version, jurisdictions, module configurations, scopes, and required control types. Applying one expands that record and installs the resulting bindings on the token. The token keeps only those bindings, so a later template edit never reaches it.
Global Controls live on-chain in the system Compliance Engine. Module types must first be registered in the system's compliance module registry. Registration only makes a type available. A separate install creates a configured binding on the system engine. Each token factory binds the tokens it deploys to that engine, and a factory migration binds the older tokens that factory deployed, so every bound token inherits the engine's active controls.
Scope preserves the difference between universal and targeted rules. Both engines evaluate sender and receiver scope the same way: by identity claims or by country. Only the system engine takes a token dimension. A token's own engine refuses one, since it is already bound to a single token. On the system engine, scoping by token lets one installed control cover a selected group of tokens instead of all of them.
One policy, two API surfaces
Policy Templates are settings resources: create, update, publish, list, read, and delete operations. Reading one template also lists the instrument templates that link it, and deleting the template clears that link on each of them. Token bindings and inherited Global Controls are separate read surfaces, because they describe separate on-chain engines rather than the template catalogue.
A template targets one module-set version. First- and second-generation module types cannot be mixed in one template, and the version cannot change after the template is saved. The API refuses a module or required control of the other generation. It also checks every value of a supply cap, a first-generation investor count or a token supply limit, and the approval expiry of a transfer approval. Other values, such as approval authorities, can stay open until issuance. A published, second-generation template can then be linked to an instrument template. When an asset is issued from it, its configuration is expanded into token module writes.
Global installation targets the system Compliance Engine, not the system's compliance module registry. Registering a module type is only a prerequisite. Install, reconfigure, enable, disable, scope, and uninstall operations address the configured binding on the system engine. Reads of inherited controls resolve those bindings for a selected token, including whether each control is active and in scope.
Integrations should read both layers when they present the effective policy. A token-module list alone omits the mandatory floor. A global-control list alone omits the asset-specific policy. Transfer prechecks and on-chain execution remain the final authority because scope and identity state can change.
Control ownership and audit evidence
A Compliance Policy splits control into two domains. Policy Templates hold the approved pattern for an asset programme. Global Controls hold the organisation-wide rules that a bound token's own rules cannot switch off. Both domains use the same registered module types, but approval of one does not authorise changes to the other.
The evidence for a token starts with its current local bindings, which show what the token enforces now, including active state and scope. The platform does not record which template or template version an asset was issued from, so match the bindings against the approved template rather than assuming they track it. The inherited-control read adds a third source: the system Compliance Engine bindings that also reach that token.
Two conclusions do not follow from this evidence. A published template proves what was approved for reuse. It does not prove that every existing token tracks later template edits. An inherited Global Control proves a live system-level rule reaches the token. It does not prove that the token has no additional local restrictions.
For an ordinary transfer or mint, every active, in-scope module must pass or the movement reverts before balances change. Three paths sit outside that guarantee. On a second-generation engine, a recipient on the compliance bypass list skips, in both layers, the checks that judge whether it may hold the token: country and identity lists, identity verification, claim expiry, holder counts and transfer approval. Sender-side and supply checks still run. A first-generation engine skips every module for a bypassed recipient. A forced transfer skips both layers' module checks, the pause and the sender's freeze, gated by the token's Custodian role. It still refuses a recipient whose address is frozen on the token and runs the recipient's identity check in the identity registry, as Transfer-Path Compliance describes. A wallet recovery skips the same checks and can deliver into a frozen replacement wallet, gated by the Identity manager who records the lost wallet and names its replacement. Reviewing a token's effective policy means checking the bypass list and who holds Custodian, Governance, Identity manager, System manager, Compliance manager and Escrow manager alongside the bindings. A token is inside the shared floor only once it is bound to the system engine, so an older token needs review until a factory migration binds it.
Frequently asked questions
How do policy and instrument templates differ?
They shape different layers of a new token. An Instrument Template defines a product: the facts an instrument records, the behaviours it carries, and the compliance rules it follows. A Policy Template packages only compliance controls, with its own review, publication, and versioning path, so one reviewed rule set can serve products whose facts and features differ.
Does a module that is out of scope for a movement still do anything?
An out-of-scope module can still update its accounting. Scope decides whether a module's validation runs for that movement, but a module can be configured to keep running its accounting regardless. A module set to skip everything when it is out of scope skips both the check and its own bookkeeping. A module set to only skip validation keeps updating its state on every movement, even when out of scope. That is why a module that tracks running balances, such as a holding limit, still reads accurately after a movement it did not validate.
Do compliance checks cover minting and burning as well as transfers?
Minting runs the same two-layer check as a transfer, with the sender side empty, so an issuance that fails a rule reverts before any supply exists. Burning runs no eligibility check, and the token's Supply management role can burn from any holder's wallet. Both engines are notified after the burn, which keeps modules that track balances accurate, and a notification that reverts also reverts the burn. For a forced transfer or wallet recovery, the recipient still has to clear identity verification: a current On-Chain Identity registry checks the recipient's claims, and an older registry falls back to confirming the recipient is registered at all.
Who manages the compliance bypass list, and how does an address end up on it?
DALP manages it. The system Compliance Engine holds the list, not the token or its administrator, and nothing on the token can add an address to it. A token factory adds each token it deploys, and an add-on factory adds each add-on it deploys. That includes every escrow an Escrow manager creates, for whatever controller the creator names, so the Escrow manager role puts each new escrow on the list. No Console screen or Platform API route edits the list directly. A System manager can change the list by registering a custom token factory or add-on, or by pointing a registered one at new code, because every registered factory and add-on can add and remove addresses. A Compliance manager can change it with a direct call to the system Compliance Engine. The chain records every change to the list with the account that called the Compliance Engine: the factory for an address it adds or removes, the calling account for a direct call. Control ownership and audit evidence gives the effect of a bypass.