Compliance pre-check console
Simulate a token transfer in the Console before anyone submits it, read the will-clear or will-revert verdict, and act on each blocker by who can resolve it.
The compliance pre-check console answers one question before a transfer is ever signed: will this transfer clear, or will it revert? When it would revert, the console lists every compliance rule that blocks it and sorts those rules by who can resolve them. This turns an opaque on-chain rejection into a worklist an operator can act on.
Use this console when a holder reports that a transfer keeps failing, when you prepare a large or sensitive movement, or when you need to confirm that an investor is ready to receive an asset. The check is read-only. It runs a transfer against the live compliance engine and changes nothing on-chain.
Who can open it
The pre-check console is gated to operators who can inspect and remediate compliance state for the asset. You can open it when either condition holds:
- You hold the asset's Custodian role, the same role that performs balance freeze and forced transfer.
- You hold a system compliance role: system manager, identity manager, claim issuer, or compliance manager.
If you have neither, the tab stays hidden and the Console routes you back to the asset. This split lets a separated-duty organisation give compliance staff access to the blocker detail without granting them custodian authority over balances.
What the verdict means
The console form takes a sender, a recipient, and an amount, then runs that exact transfer against the asset's compliance engine. The result is one of two verdicts.
| Verdict | Meaning |
|---|---|
will-clear | The compliance engine accepts the transfer as entered, right now. |
will-revert | At least one active compliance rule blocks the transfer. The console lists each one. |
The verdict is authoritative for the moment it runs. It comes from the same
on-chain check the contract enforces at execution, so a will-clear result
means the transfer would pass if submitted immediately. The verdict is still a
pre-flight signal, not a guarantee: eligibility state can change between the
check and a signed transaction. Always treat an on-chain revert as possible even
after a clear result, and run the check again if conditions may have moved.
If the compliance engine cannot be reached, the console reports an error instead
of a verdict. It never shows will-clear when it could not run the check. Treat
the error as temporary and run the check again.
Read the blocker list
When the verdict is will-revert, the console groups the blockers by
remediation class, so you can see at a glance who needs to act. Each blocker
names the failing compliance rule, the party it applies to (sender or
recipient), and the reason.
| Group | What it means | Who resolves it |
|---|---|---|
| Self-serve | A required identity claim is missing or expired for the holder. | The holder completes verification. |
| Operator | An identity is unregistered, frozen, or on a blocklist for the asset. | An operator runs the administrative step. |
| Structural | A rule blocks the transfer with no standard remediation path. | A configuration or design change, not a quick fix. |
The reason on each blocker tells you the failure class:
identity-not-verifiedmeans the party has an identity but a required claim, such as a KYC claim, is missing or expired. A holder fixes this without an operator: they obtain the claim and the transfer clears.identity-not-registeredmeans the party has no identity entry for the asset. An operator registers the identity.module-blockedmeans an active module bars the address, such as a freeze, a blocklist entry, or a country restriction. The remediation depends on the module: an operator can unfreeze or remove a blocklist entry, while a country or allow-list rule is structural.
A revert always lists at least one blocker. If the contract rejects the transfer but no specific rule can be attributed, the console shows a single unrecognised rule rather than an empty list, so a failed transfer is never left unexplained.
A common case makes this concrete. A holder tries to receive an asset and the
transfer keeps failing. The pre-check returns will-revert with one self-serve
blocker on the recipient: identity-not-verified, naming a KYC claim. The
holder completes that verification, the operator runs the check again, and the
verdict turns to will-clear. No custodian step was needed, and the operator
never had to read an on-chain revert reason.
Pre-check a transfer
Open the compliance pre-check console
Go to Asset Management, select the asset, then open the Compliance pre-check tab. The tab appears only for operators who meet the access conditions above.
Enter the transfer to check
Fill in the three fields:
- From: the sender address.
- To: the recipient address.
- Amount: the token amount to simulate.
Both address fields offer a search picker that suggests holder accounts for the asset, or manual entry for an address that is not yet a participant. Run check stays disabled until all three fields are valid.
Run the check and read the verdict
Select Run check. The console runs the transfer against the live compliance
engine and shows the verdict badge. A will-clear result confirms the transfer
would pass as entered. A will-revert result opens the grouped blocker list.
Each run reflects current compliance state. If you freeze an address, register an identity, or a holder completes a claim, run the check again to confirm the change cleared the blocker.
Act on each blocker
Work the blocker list by group:
- For a self-serve blocker, the console names the claim topics the holder must satisfy. Route the holder to complete the missing verification.
- For an operator blocker, the console offers a shortcut that takes you to the asset's management tab, where you run the matching step such as an unfreeze, a blocklist removal, or an identity registration.
- For a structural blocker, there is no quick fix. Resolving it needs a configuration or eligibility change, so escalate it rather than treating it as a one-step fix.
Re-check before you proceed
After a remediation, run the check again with the same sender, recipient, and
amount. A will-clear verdict confirms the transfer is ready. Only then move to
the actual transfer, whether a holder initiates it or you run a custodian
operation.
What the console does not do
The pre-check console explains a transfer; it does not perform one. Keep these boundaries in mind.
- It never moves tokens. Running a check signs nothing and queues nothing.
- It does not override compliance. Use it to understand and clear a revert, not to bypass it. To move an asset against the normal rules in a governed exception case, use a forced transfer instead.
- The operator shortcut it offers is a link to the right management surface, not the remediation itself. You still run and authenticate the freeze, blocklist, or registration step there.
Troubleshooting
| Issue | What to check |
|---|---|
| Tab not visible | Confirm you hold the Custodian role or a system compliance role for the asset. |
| Check returns an error | The compliance engine could not be reached. The console does not guess a verdict; wait and run the check again. |
| Verdict reverts with no detail | A revert with no attributable rule shows a single unrecognised rule. Review the asset's configured compliance modules. |
| Blocker stays after a fix | Re-run the check. The verdict reflects state at run time, so confirm the remediation applied before you proceed. |
| Self-serve blocker won't clear | Confirm the holder completed every named claim topic, and that the claim has not expired. |
Related operations
- Transfer simulation API runs the same check from an integration, with the full verdict and blocker schema.
- Freeze and unfreeze balances and forced transfer are the custodian operations an operator blocker often points to.
- Verify KYC and identity verification cover how a party becomes a registered, verified holder.
- Compliance templates explain the rules the pre-check evaluates against.
How to run a custodian forced transfer
A custodian-authorised on-chain transaction that debits one holder and credits another, bypassing normal approval and freeze controls for governed exception cases.
How to force convert holder principal
Run a custodian-initiated conversion that bypasses the holder consent path, used for mandatory convertible instruments and institution-approved exception cases.