Global controls
Configure compliance controls that apply across every bound token.
A global control is one compliance module, such as an address block list or an issuance cap, installed on the platform's 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. The token's own compliance tab lists the control as inherited from global, says it "can only be changed in Platform Settings," and offers no way to loosen it there. That pointer means this page: the Console groups it under "Compliance" in the sidebar, not a section literally named Platform Settings. See 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 for how the global layer and the token layer fit together.
Use this screen when a rule must hold everywhere regardless of product decisions. A sanctions list, for example, must bind every token an issuer runs, whatever product line issued it. The token issuer cannot remove that inherited binding. A rule that belongs to one product line goes into a policy template instead, because other product lines legitimately differ. A rule for a single instrument goes onto that token's compliance tab instead, because only that instrument needs a stricter rule than its siblings. Those two surfaces add rules on top of global controls and never replace them. Review the rule's scope, recipient bypass list, and privileged recovery paths to establish where the global layer applies.
Installing, reconfiguring, or removing a control changes the outcome of later compliance checks for every token in the rule's scope at once, not only the one you were investigating when you arrived. The same modules are configurable from three surfaces, so confirm first that the rule belongs at this one.
| 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. | It must be non-negotiable everywhere. |
| Policy template | 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. |
Steps
Open Global controls
In the sidebar, open "Compliance", then "Global controls". With the "Compliance manager" role, the page shows two lists: "Active controls" holds what is already enforced, and "Available controls" holds what you can still install, with a category filter to narrow it. An administrator without that role sees "Active controls" only; "Available controls" does not render at all, so its absence is not a broken page. Only current-generation module variants appear in "Available controls", so it is shorter than the full module catalog.
Screen equivalent: the page lists installed global controls with their scope and parameters. It also shows compatible controls you can install.
Pick a control and add a rule
Select a control tile, then choose "Add rule" in the sheet that opens, or select an existing rule to change it. The sheet opens on "Active rules", so an active control shows every rule it carries before you add another. 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 "Claim topics" and "Countries". "Only transfers matching these criteria are checked by this rule," the include hint on each card reads, and 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 claim 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 scoping by token depends on the topics already assigned to it, not on picking the token by name.
The checkbox "Track transfers outside this scope" controls whether the rule's hooks track movements its checks exclude. "Outside-scope transfers won't be checked by this rule, but they will still be tracked for reporting," the hint reads. Review this setting for stateful modules that count supply, holders, or other activity outside their enforcement scope. It does not configure a general reporting export.
Save and confirm
Choose "Save changes", then enter your verification code 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. It does not mean the rule behaves as you intended; that proof comes from the verification below.
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. After a broad change, simulate representative transfers against a bound token, including one that should pass and one that should fail. Validate issuance rules in a test environment before relying on them in production. When a module refuses shows what a refusal looks like and which reason code names your rule. The system compliance module endpoints support installation, reconfiguration, scope changes, and removal. The install-or-reconfigure endpoint creates an instance when its address is omitted. Supplying an instance address updates that binding. Separate endpoints can apply parameters and scope together in one transaction. A sixth endpoint registers module implementations in the system's registry before any of the five can target them, but it needs the system manager role, not compliance manager, so it sits outside what this page's role reaches.
Troubleshooting
The page is read only and shows a not-authorized banner
Your account lacks the "Compliance manager" role for this organisation. Administrator and system manager roles do not qualify: the backend refuses their writes, so the Console disables the controls up front. The banner names "the system manager role", but that is not what unlocks this page; ask an administrator to grant "Compliance manager" in user management instead, then reload.
A control I expect is not under Available controls
Two causes. The control is already active, in which case it sits under "Active controls" and you add another rule from its sheet instead of installing it again. Or you are looking for a legacy variant: this screen offers only current-generation modules, even where an older generation still runs elsewhere on the platform.
A rule row says its scope is unavailable and saving is blocked
The Console could not read the rule's on-chain scope, usually a transient RPC failure, and it 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. Mind the editor's own advisory: "Changing scope on an active rule may trigger re-validation of existing holders."
A capital raise limit rule will 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.