Compliance Policy
A Compliance Policy lets a compliance team write eligibility and holding rules once, while a platform floor reaches every current-factory token.
A Policy Template is copied into the token's own policy at creation, then every movement checks that policy live against the deployment's Global Controls before it settles.
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 platform owner set a rule once and reach every token the current System Factory creates, without editing each token by hand.
A movement must pass both layers before it settles, unless the recipient sits on the deployment's compliance bypass list. 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 is what lets that team approve the rule set once and hand it to an asset team as something to select, not something to reconstruct.
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 template set at issuance rather than a rule set improvised afterward.
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 already-approved shape reused across the programme. The result of using a template is controlled reuse: asset teams do not rebuild eligibility, jurisdiction, holding, or approval rules for each issuance, and every token still starts from something a compliance team already reviewed.
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 no single asset team can configure their way around a deployment-wide requirement. Global Controls answer that. The System Factory is the platform component that deploys a new token's contracts and wires them to the deployment-wide Compliance Engine. A platform owner installs a rule once in that engine, and it reaches every token the System Factory creates from then on, 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, a task that grows with the number of tokens rather than with the number of rules.
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 movement a token makes, mint, transfer, or burn, for as long as the deployment runs. A Compliance Policy is the pair of them together: a reviewed template an asset team selects, plus a platform-wide floor neither that team nor the template can turn off.
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 deployment-wide engine directly on every transfer, so a change to a Global Control reaches every bound token at once.
Due diligence needs this boundary: the rules chosen for one asset stay separate from the controls mandated for the whole deployment. Both are enforced inside the transfer pathTransfer-Path Compliance enforces a regulated token's rules inside the on-chain transfer itself, so a movement that fails any rule reverts and never settles.Read the concept before settlement. Each layer 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, adds controls and scopes, then publishes it for asset teams. Choose the current generation unless the template needs a control that only exists in the legacy set, such as a volume-based issuance limit or a flat token supply cap. A handful of newer controls, such as a capital-raise limit or a minimum-holding requirement, exist only in the current 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 asset team selects the published template during creation instead of reconstructing its controls.
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 platform administrator manages Global Controls separately. A global module can restrict every token created by the current System Factory or use token scope to narrow where it applies. Installing or changing it affects the deployment-wide Compliance Engine, not the Policy Template catalog. Operators therefore review two views when they need the effective policy: the token's own module bindings and the inherited Global Controls.
Where a rule lives decides who it reaches and who can change it.
| Put the rule in | When it is right | What it costs |
|---|---|---|
| A Policy Template | The rule belongs to an asset programme and should shape future tokens. | Existing tokens keep their current policy; the edit only reaches new ones. |
| One token's own bindings | A single live token needs a rule its programme does not share. | The change stays on that token; repeating it by hand brings back the drift templates exist to remove. |
| A Global Control | The rule must reach every token the current System Factory creates. | A deployment-wide change by a platform administrator. Tokens deployed before the current factory path stay outside 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, so the operator reads both the token's own bindings and the inherited Global Controls to find the failing rule, then fixes the underlying eligibility, scope, limit, or approval condition. They do not override the policy by completing the transfer elsewhere.
Where reuse ends and inheritance begins
A Compliance Policy composes two on-chain compliance engines. Each token created by the current System Factory has its own engine with address-keyed module bindings, and the deployment also has one shared Compliance Engine. During a token movement, the token evaluates active, in-scope local modules and then delegates to the deployment-wide engine, as shown in the two-engine flow.
The token engine evaluates its own modules first, then delegates to the deployment-wide engine for the inherited Global Controls; either layer can revert the movement, and its error does not say which one.
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 a snapshot of what was applied, so the template is provenance rather than a live dependency.
Global Controls live on-chain in the deployment-wide Compliance Engine. Module types must first exist in the System Factory's shared module registry. Registration only makes a type available. A separate install creates a configured binding on the deployment-wide engine. Tokens created by the current System Factory bind to that engine and inherit its active controls. Tokens deployed before the current factory path remain outside this inheritance path.
Scope preserves the difference between universal and targeted rules. Both engines evaluate scope the same way: by sender or receiver identity or country, and by token. Scoping by token does no useful work on a token's own engine, since that engine is already bound to a single token. On the deployment-wide Compliance Engine, scoping by token is what lets one installed control cover a selected group instead of the whole deployment.
One policy, two API surfaces
Policy Templates are settings resources: create, update, publish, list, and read operations. Token bindings and inherited Global Controls are separate read surfaces, because they describe separate on-chain engines rather than the template catalog.
A template targets one module-set version. Legacy and current-generation module types cannot be mixed in one template, and the version cannot change after the template is saved. The API validates each module's values and scope against its type. A published template can then be selected during asset creation, where its configuration is expanded into token module writes.
Global installation targets the deployment-wide Compliance Engine, not the System Factory's shared module registry. Registering a module type is only a prerequisite. Install, reconfigure, enable, disable, scope, and uninstall operations address the configured binding on the deployment-wide 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 gives reviewers two clear control domains. Policy Templates hold the approved pattern for an asset programme. Global Controls hold the deployment-wide rules that tokens created by the current System Factory cannot avoid. Both domains use the same registered module types, but approval of one does not authorize changes to the other.
The evidence for a token starts with its applied template snapshot and current local bindings. The snapshot records the template and version used at creation. Current bindings show what the token enforces now, including active state and scope. The inherited-control read adds a third source: the deployment-wide Compliance Engine bindings that also reach that token.
This evidence prevents a common false conclusion. 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.
Enforcement is fail-closed for an ordinary transfer or mint: every active, in-scope module gets a decision, and a rejected module reverts the full movement before balances change. Two paths sit outside that guarantee. A bypassed recipient, held on the deployment's compliance bypass list, skips both layers entirely. A forced transfer or wallet recovery skips both layers' module checks by design, gated instead by the custodian role and identity verification. Reviewing a token's effective policy means checking the bypass list and the custodian role alongside the bindings, not just the modules. Tokens deployed before the current System Factory path need separate review because they remain outside its shared floor.
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 is not pre-checked: both engines are notified after the supply change, which keeps modules that track balances accurate. 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 holds the compliance bypass list, and how does an address end up on it?
The platform's compliance-manager role holds it, not the token or its administrator. An address is added automatically when the current System Factory or an addon factory deploys a contract; nothing on the token itself can add to or override that list. A bypassed address short-circuits both the token's own modules and the Global Controls, so an effective-policy review reads the bypass list alongside the bindings: it is the one address set neither layer evaluates.
On-Chain Identity
An On-Chain Identity lets a subject's verification serve every asset that accepts it, so a screened wallet skips re-onboarding for the next regulated asset.
Transfer-Path Compliance
Transfer-Path Compliance enforces a regulated token's rules inside the on-chain transfer itself, so a movement that fails any rule reverts and never settles.