Verification topics
Define the claim topics used to classify identity evidence.
A verification topic names one category of identity evidence a participant can hold, such as a know-your-customer check or an accredited-investor status, and fixes the shape of the data a claim on it carries. This page decides which categories exist for your system, your organisation's platform deployment on one network, and shows the global categories every system inherits. The evidence itself lives on each participant's on-chain identity; the topics defined here are the vocabulary that evidence is written in.
Reach for this page when your compliance rules need a category of evidence that does not exist yet, when a topic's data shape must change, or when a topic no longer applies. You do not need it to review one participant's evidence; that sits on the participant's own identity record.
Everything downstream, meaning every trusted issuer, compliance rule, and data feed that reads a topic, consumes it through its identifier, and the identifier is derived from the topic name. Trusted issuers are authorised per topic, compliance rules require topics, and data feeds publish under feed topics, and each of those needs a topic defined here first. That makes this a setup-first screen: define the topic before you authorise an issuer for it, write a rule that requires it, or publish a feed under it.
Adding or removing a topic changes what an issuer can attest, what a rule can require, and what a feed can publish, everywhere that identifier is referenced. The name is permanent: the Console never renames a topic, because a new name would put a new identifier under every consumer that reads it.
Steps
Open Verification topics
Open "Compliance", then "Verification topics". The "System" tab lists every topic your system resolves, with a "Source" column separating the topics it owns from the ones it inherits; the "Global" tab shows the directory those inherited entries come from.
Screen equivalent: the page separates system and global topic registries and lists each topic's name and identifier.
Add a topic
Select "Add verification topic" in the System tab, name the topic, and pick its kind. Two kinds can be created here.
"Verification (claim)" is for identity evidence: you define each data field a claim must carry, giving every field a data type (text, number, a yes/no flag, or a wallet address) and an optional variable name. "Feed (SCALAR)" is for numeric data feeds and carries a fixed signature you cannot edit.
Choose a stable, descriptive name. The identifier every consumer stores is derived from it, and it cannot change later. The platform also refuses a name the registry already holds. For feed topics the Console suggests a "FEED:" name prefix so they stay recognisable next to verification topics.
Select "Create topic" and confirm with your identity verification; the registration is an on-chain transaction.
Decide who a rule may exclude with it
Set "Use in exclusions" while you add the topic, and review the holder's authority to remove the claim. The setting controls whether a compliance rule may exclude the holders of this claim. It matters because some claims sit on identities their holders manage: whoever can delete the claim from their own identity can pass the rule that was meant to catch them.
Choose "Allowed" when the claim sits on an identity the holder does not manage, so the holder cannot remove it to escape the rule; a rule may then exclude these holders with no extra step. "Allowed with acknowledgement" is the default. Use it when a holder could remove the claim to pass a rule. A rule author must explicitly acknowledge that risk before using the topic in an exclusion. Choose "Not allowed" when the party who would delete the claim to pass the rule is the party the control exists to stop; no rule in the system may then exclude the holders of this claim.
Choosing anything other than the default value here is a second write, made only after the topic itself is created on chain. If that second write fails, the Console still reports the topic created, but the topic is left at the default policy; check the "Use in exclusions" column on the new row to confirm the value you chose actually saved.
| Setting | What it permits |
|---|---|
| "Allowed" | A rule may exclude holders of this claim with no extra step. |
| "Allowed with acknowledgement" | A rule may exclude these holders, but whoever saves the rule accepts the risk by name. |
| "Not allowed" | No rule in this system may exclude the holders of this claim. |
Changing the setting later does not re-grade rules already saved; the new value applies from the next rule write. The change happens off chain, needs no transaction, and lands in the Audit trail together with the value it replaced.
Edit a topic's signature
Open the topic's row menu and select "Edit signature" to change the data fields a claim must carry. The topic keeps its name and its identifier, so every consumer stays pointed at it. Only signatures built from the field types the Console's builder supports can be edited here; a fixed feed signature, or one using other data types, appears read only, and the sheet points you to the claim topic endpoints instead. The same sheet carries "Use in exclusions", and a change there saves immediately, independent of any signature change you submit.
Delete a topic
Check the topic's consumers before you remove it: its assignments under "Trusted issuers", "Compliance providers", and "Data feeds", plus any compliance rule that requires it. The Console does not block deletion of a topic that is still assigned elsewhere, so this check is the required manual review; the confirmation dialog warns you in general terms but does not list what is still attached.
Then open the row menu, select "Delete topic", and confirm with your identity verification. Only topics your system owns can be deleted here; a row whose "Source" reads "Global" shows "Managed globally" in place of the menu, and removing that entry is a directory operation, not something this screen offers.
Creating, editing, or deleting a system topic is an operation the organisation's Audit trail records, with your name and the role you held at the time. The same operations exist as claim topic endpoints in the Platform API reference, covering create, replace the signature, and delete, for deployments that manage topics from code.
A compliance rule that requires a deleted topic fails every holder the same way it fails someone who was never verified. The check reads the topic registry at the moment the operation executes, so the deletion also reaches operations submitted earlier but executed after it, and the failure carries no message naming the deleted topic.
Deletion does not touch the claims themselves. They stay on participant identities and stop counting while no topic resolves for their identifier. Because the identifier is derived from the name, adding a topic under the same name restores the identifier. Existing claims can count again when their issuer remains trusted and the claims remain valid. Review the restored data signature against existing claim data before relying on those claims. A topic added under a different name has a different identifier, and every issuer authorisation, provider mapping, and rule must be repointed to it by hand.
Troubleshooting
The Global tab shows only a notice
Even with the directory administrator role, this tab stays a view: the Console offers no add or remove controls for global entries on this screen.
A topic's row has no actions menu
Check the row's "Source" first: inherited topics show "Managed globally" and cannot be edited or deleted from the System tab. On a system-owned row, a missing menu means your account lacks the permission to update topics.
A holder or operation starts failing compliance for no clear reason
Check for a recent topic deletion before assuming the holder's own evidence is the problem.
A deleted topic is still needed
Add a topic with the same name, then confirm the issuer authorisations and rules that used it still stand before relying on it again.
The exclusion policy will not save while you are acting as another user
The Console refuses this write from an impersonated session, because the audit record must name the person who decided, not the operator standing in for them. Ask the account holder to set "Use in exclusions" from their own session instead.
Frequently asked questions
What is the difference between a verification topic and a feed topic?
They carry different kinds of data for different consumers. A verification topic classifies identity evidence: a trusted issuer attests it and a compliance rule requires it, with data fields you define per topic. A feed topic carries published data instead, under a fixed numeric signature you cannot edit, and data feed configurations consume it. The "FEED:" naming prefix the Console suggests exists so the two stay distinguishable in every list that mixes them.
Can I rename a verification topic?
No. The topic identifier that every issuer authorisation, rule, and claim references is derived from the name, so a rename is impossible without abandoning the identifier. If the name is wrong, add a topic under the correct name, repoint each consumer to it, and delete the old one once nothing references it. Expect claims issued under the old topic to stay behind: they belong to the old identifier, and issuers must attest the new one afresh.
Why does a global topic show a "Shadowed" badge?
A registry below the global directory has registered the same topic identifier with a different signature. The systems that resolve the downstream entry decode claim data by the shadowing signature, not the directory's, so the same identifier can mean differently shaped data in different systems. Review the conflict before changing either entry; the badge marks the disagreement, it does not resolve it.
Why can I open this page but not add a topic?
Viewing and managing are gated separately. The sidebar shows the page to administrators, verification policy managers, feeds managers, and compliance managers, because topics feed all of those surfaces. Creating, editing, and deleting system topics needs the verification policy manager role, and the Console hides those controls when your account lacks it, instead of letting a request fail.
Do topics apply per token as well?
Yes. A token with an attached topic scheme registry can carry token-level topic schemes on top of the system and global topics it inherits, and those are managed from the token's own screens rather than here. Inherited entries stay read only at the token level, the same way global entries stay read only on this page. A token without an attached registry uses the inherited chain alone.