Skip to main content

Global controls

Configure compliance controls that apply to every token bound to your organisation's compliance engine, whatever product line issued it.
Open it fromComplianceGlobal controlsRoles:Permission managerSystem managerCompliance managerConsole address: /compliance/global-controls

A global control is one compliance module, such as an address block list or an issuance cap, installed on your organisation's system compliance engine rather than on a single token. Each control carries one or more rules, and each rule pairs the module's parameters with a scope that decides which transfers it checks. Every bound token inherits the result. A token is bound when its factory deployed it against this system's compliance engine, and an older token joins only after a factory migration binds it. A global control reaches your organisation's tokens on the active network only. See compliance policy for how the global layer and the token layer fit together.

Use this screen only when a rule must hold on every token, whatever product line issued it. Issue asset offers no way to remove an inherited global control. Policy templates and a token's own compliance tab add rules on top of it and never replace it.

Where the rule lives
What it reaches
Choose it when
Global control
Every bound token, including ones issued after the rule lands, minus the rule's own carve-outs.
Every token must follow it.
Tokens issued from a template that carries the policy.
It defines one product line, not every one.
The token's compliance tab
One token, on top of everything it inherits.
Only that instrument needs it.

With no rule installed, the “Global controls” page shows “No global rules yet” and an “Add control” button.

The card reads “No global rules yet”, explains that a global control is a rule that applies to every asset your organisation issues, on top of each asset's own rules, and carries Add control. Once rules are installed, the page lists them, and each row names the control, summarises its parameters and scope, and carries an on or off switch, “Edit” and “Remove”.

Steps

Open Global controls

In the sidebar, open “Compliance”, then Global controls. The page holds one list of the rules already installed. Each row names the control, summarises its parameters and scope, and carries an on or off switch, “Edit”, and “Remove”. An organisation with no global rule shows “No global rules yet” instead, with “Add control” for a compliance manager.

Select Add control. The sheet of the same name lists the controls you can install, grouped by category, with a search box and a filter for each category. A control you already installed is marked “Added”, and picking it again adds a second rule of the same kind. The sheet lists only controls registered in the system's module registry, and of those only the current-generation variants and the issuance volume limit, so it is shorter than the full module catalogue. Compliance modules explains the generations. Without the Compliance manager role, the rows offer “View” instead of “Edit”, and there is no switch, “Remove”, or “Add control” to use.

The “Add control” sheet lists the controls, grouped by category, starting with “Eligibility”, “Restrictions” and “Transfer controls”.

The category filters above the list each show a count, and All shows the total. Each row names the control and says in one line what it does, such as “Block investors from specific countries” for “Country block list”.

Pick a control and add a rule

Select a control in the Add control sheet. Its editor opens with the module's parameters under “Configuration” and the scope under “Applies to”. A control you have not installed yet is marked “Not enabled”. To change a rule that is already installed, select “Edit” on its row instead. Parameters differ per module. The compliance module reference states what each one permits or refuses, with units. Check that reference before committing, because some parameters lock. The issuance volume limit locks its period length and window mode when enabled. The capital raise limit locks its parameters at installation, while its scope stays editable. Changing a locked value requires a new instance and resets that instance's tracking.

Decide the rule's scope

Under “Applies to”, keep “All transfers” or choose Selected transfers and build the filter. Choosing “Selected transfers” reveals three independent dimensions, “Sender”, “Receiver”, and “Token”, each with its own filters.

“Sender” and “Receiver” each take an Include card and an “Exclude” card, filtered by “Verification topics” and “Countries”. The include hint on each card reads “Only transfers matching these criteria are checked by this rule.” An empty include card matches everyone, so a rule with only excludes checks everything except the carve-outs.

Token takes the same pair of cards, but filtered by verification topics only, which is how you keep a global rule off tokens it should not touch. A token that carries no distinguishing claim topic cannot be singled out this way, so you scope by the topics a token carries. The filter cannot pick a token by name.

The checkbox Track transfers outside this scope decides whether the rule still counts transfers it does not check. The hint reads “Transfers outside this scope are not checked, but they still update this rule's counts and quotas.” Review this setting for stateful modules that count supply, holders, or other activity outside their enforcement scope: with the box cleared, such a module shows a warning that its counts, quotas and approvals drift and that missed transfers are not replayed.

Save and confirm

Choose Save & enable for a control you have not installed yet, or “Save” otherwise, then enter your wallet verification in the “Confirm compliance change” dialog. A success toast, “Compliance control enabled” or “Compliance control updated”, means the transaction landed and the rule is already live for every bound token in scope. The toast does not prove the rule behaves as you intended, and the checks under You should see do.

Turn a rule off or remove it

To pause a rule and keep its settings, turn its switch off. Turn it on again to resume checking.

Select Remove on the rule's row, read the dialog, and confirm with your wallet verification.

When a change takes effect

Installing, reconfiguring or removing a control changes later compliance checks for every token in the rule's scope at once. A compliance check runs at the moment an operation executes on chain, not when someone submits it. A transfer that completed under the old rule keeps its outcome and is never revisited. One still pending is checked against whatever rule set is live when it executes. When a module refuses shows what a refusal looks like and which reason code names your rule.

Troubleshooting

A token's compliance tab says Set in Compliance › Global controls

The token's compliance tab lists a global control with the status Global and the setting “Set in Compliance › Global controls”, and offers no action on it there. Change the rule on this screen, which the sidebar lists under “Compliance”.

The page is read only

The notice “Only a Compliance manager can change global controls.” means your account lacks that role for this organisation. The Permission manager and System manager roles cannot write rules from this screen: the platform refuses their writes, so the Console disables the controls. Ask someone with the Permission manager role to grant Compliance manager on Roles and permissions, then reload.

A control I expect is not in the Add control sheet

This screen offers only controls registered in the system's module registry, and of those only the current-generation variants and the issuance volume limit, even where an older generation still runs elsewhere on the platform. A control whose type the registry does not hold needs a system manager to register it through the Platform API first. A control you already installed stays in the sheet, marked Added.

A rule row says its scope is unavailable and saving is blocked

The row reads “Its settings could not be read.” when the Console could not read the rule's on-chain scope. The editor then blocks saving rather than let an edit overwrite filters it cannot see: “Cannot save: rule scope failed to load. Refresh the page and try again.” Refresh and reopen the rule. The block clears once the scope loads.

A change reached the wrong transfers or tokens

Open the rule, adjust its scope or parameters, and save again. The correction applies to every future check the moment it lands. Operations that already completed under the earlier configuration are not revisited.

A capital raise limit rule does not accept new parameters

That module's configuration is immutable once applied, so only its scope can change in place. To change the limit itself, remove the rule and add a new one, and account for the reset: the new instance starts its tracking window with nothing counted.

Mints stop after adding a global capital raise limit

The limit converts each mint to fiat through the system's price resolver and refuses the mint when the price is missing, zero, negative or stale. A global rule applies to every token, so a token with no valid price cannot mint while the rule covers it. Give the token a price feed, or scope the rule away from it under Applies to.

Frequently asked questions

What skips a global control?

Three paths skip some or all of the checks. A recipient on the system's compliance bypass list skips the checks that judge whether it may hold the token. A Custodian's forced transfer and a wallet recovery move tokens without any compliance module, global or token-level. Compliance policy lists exactly what each path skips. DALP manages the bypass list: token and add-on factories add the contracts they deploy, such as settlements, escrows and token sales. 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 contract.

API routes

The system compliance module endpoints cover installing, reconfiguring, scoping, switching off and on, and removing a control, and each one needs the Compliance manager role. The install-or-reconfigure endpoint creates an instance when its address is omitted, and refuses when the system already has a global control of that type. Supplying an instance address updates that binding. The scoped install endpoint creates an instance and sets its scope in one transaction, and a companion endpoint replaces an existing instance's parameters and scope together. The Console adds every rule through the scoped install, so it can add a second rule of the same kind. One more endpoint registers a control's implementation in the system's module registry, which a control needs before any rule can use it. That endpoint needs the System manager role. A system manager finds it in a control's sheet as Use a custom contract for this control.

Was this page helpful?