# Global controls

Source: https://docs.settlemint.com/docs/console/compliance/global-controls
Configure compliance controls that apply to every token bound to your organisation's compliance engine, whatever product line issued it.

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. |
| [Policy template](https://docs.settlemint.com/docs/console/compliance/policy-templates) | 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. |

![Global controls before any rule is installed, with No global rules yet and the Add control button](https://docs.settlemint.com/docs/screenshots/console-global-controls-rules.light.en.webp)

[Screenshot] 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".

## Before you start [#before-you-start]

- **The Compliance manager role.** You need it to change anything here. Any other role that can open the page sees it read only, under the notice "Only a Compliance manager can change global controls." The Permission manager role opens the page read only. The System manager role cannot add or edit a rule here either, but it can register a control's contract and replace the contract an installed control type runs, which changes how every rule of that type behaves, so review who holds it.
- **A second approver, when your organisation requires one.** When the "Compliance configuration" group is protected under [Approvals](https://docs.settlemint.com/docs/console/organisation-settings/general#approvals), each change on this screen waits on [Actions](https://docs.settlemint.com/docs/console/essentials/actions#decide-an-administrative-change) until another person approves it, and nothing changes until then.
- **The active organisation.** The controls you manage belong to the active organisation. If you belong to more than one, switch from the "Organisation" submenu of the account menu at the top right first.
- **The network.** On a deployment with more than one network, the page reads and writes the active network's controls.
- **Your wallet verification.** The Console confirms each change with your wallet verification and submits it as a signed transaction from your wallet. Installing a rule, switching it and removing it each add an entry to the organisation's [audit trail](https://docs.settlemint.com/docs/console/reporting/audit-trail). The screen shows current state only.

## Steps [#steps]

### Open Global controls [#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](https://docs.settlemint.com/docs/concepts/compliance-and-identity/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 open over Global controls, listing eligibility, restriction and transfer controls with a search box and category filters](https://docs.settlemint.com/docs/screenshots/console-global-controls.light.en.webp)

[Screenshot] 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 [#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](https://docs.settlemint.com/docs/concepts/compliance-and-identity/compliance-modules) 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 [#decide-the-rules-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 [#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](#you-should-see) do.

## Turn a rule off or remove it [#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.

Note (Removing a rule is permanent, and a replacement starts from zero): The removal dialog warns that the control "stops checking transfers on every asset and its counts are deleted." Operations the rule already allowed or blocked keep their outcomes, and adding the same kind of control again later creates a fresh instance with fresh tracking. A capacity rule that had counted issuance against its window starts that window over at zero. When you add the control again, nothing on its row shows the earlier tally.

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

## When a change takes effect [#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](https://docs.settlemint.com/docs/concepts/compliance-and-identity/compliance-modules#when-a-module-refuses) shows what a refusal looks like and which reason code names your rule.

## You should see [#you-should-see]

- Refresh the page and confirm the rule's row shows the parameters and scope you intended, with its switch on.
- For the full proof, open one bound token's compliance tab and confirm the control appears as a **Global** row in its "Rules" table.
- Open the token's "Transfer pre-check" tab and run one sender, recipient and amount that should pass and one that should fail, as [Verify a participant](https://docs.settlemint.com/docs/console/participants/verify-a-participant) describes.
- Confirm the results match the intended policy.

## Troubleshooting [#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](https://docs.settlemint.com/docs/console/organisation-settings/admins-and-roles), 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 [#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](https://docs.settlemint.com/docs/concepts/compliance-and-identity/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 [#api-routes]

The [system compliance module endpoints](https://docs.settlemint.com/docs/api-reference/v2) 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**.