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. On this screen you decide which categories exist for your system, which is your organisation's deployment on one network. The screen also shows the global categories every system inherits. The evidence itself lives on each participant's on-chain identity.
Come here first: trusted issuers, compliance rules and data feeds all reference a topic by an identifier derived from its name. A topic must exist before any of them can use it, and its name can never change. Come back when a topic's data shape must change or a topic no longer applies. You do not need this screen to review one participant's evidence, which sits on the participant's own identity record.
The page separates system and global topic registries and lists each topic's name and identifier.
Steps
Open Verification topics
Open “Compliance”, then Verification topics. The “This system” tab lists every topic your system resolves, with a “Source” column separating the topics it owns from the ones it inherits. The “Global directory” tab shows the directory those inherited entries come from.
Add a topic
Select Add verification topic in the “This system” tab, name the topic, and pick its kind. Two kinds can be created here.
The “Add verification topic” sheet, where you name the topic and pick its kind, “Verification (claim)” or “Feed (SCALAR)”.
“Verification (claim)” is for identity evidence. Under “Verification fields”, select Add field for each value a claim must carry. Give each field a “Data type”: text, a number, a yes or no value, or a wallet address. A variable name is optional.
The registry stores this layout on chain but does not check issued claims against it, so a claim counts towards the topic whatever data it carries. The layout tells consumers how to read the data. Claim values are public on the network, so define no field that holds personal data. Does a holder's personal data end up on a blockchain? explains what reaches the ledger.
“Feed (SCALAR)” is for numeric data feeds and carries a fixed signature you cannot edit.
Set the topic's Subject, what the topic describes: “Person”, “Asset”, “Issuer” or “Any subject”, the default. The subject groups topic choices in pickers and filters the table. “Add verification” on a user or entity offers only “Person” and “Any subject” topics, and on an asset it leaves out “Person” topics. The subject never stops a claim or a compliance rule from using the topic.
Choose a stable, descriptive name. The identifier every consumer stores is derived from it, and it cannot change later. Topic names are unique within a system, ignoring case and surrounding spaces. The Topic name field refuses a name an existing topic already uses, including the name a built-in topic is shown under, such as “KYC (Know Your Customer)”, and “Review” stays unavailable until you choose another. The Platform API refuses a name that differs from an existing topic's name only by case or surrounding spaces. For feed topics the Console suggests a FEED: name prefix so they stay recognisable next to verification topics.
If two topics still show the same name, for example two added through the API before this check, the topic pickers and the “Delete topic” dialog add each topic's subject and source in brackets, such as “KYC (Know Your Customer) (Person · Global)”.
Select “Review”, then Create topic, and confirm with your wallet 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. The setting controls whether a compliance rule may refuse the holders of this claim, such as a rule that blocks anyone holding a sanctions-hit claim. That only works while the holder cannot delete the claim: whoever can remove it from their own identity passes the rule meant to stop them. The platform stores the setting off-chain before it registers the topic, and does not create the topic when the setting cannot be stored.
A topic you add starts at “Allowed with acknowledgement”. The built-in know-your-customer, anti-money-laundering, know-your-transaction, Regulation S, sanctions screening and residence topics start at “Not allowed”. The chain does not read this setting, so it does not stop a module write signed outside DALP. Under “Not allowed”, use an identity block list, a country block list, or a positive claim the participant must hold instead.
The value you choose is saved with the topic in the same request, before the registration goes on chain, so the new row shows it as soon as the topic appears. If the value cannot be saved, the sheet reports the create as failed and nothing is registered.
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. The “Edit topic” sheet changes the data fields a claim must carry, the subject and “Use in exclusions” together, and “Update topic” asks for one wallet verification for all of them. The topic keeps its name and its identifier, so every consumer stays pointed at it. A signature that uses data types the sheet cannot build appears read only, with “This topic's signature uses data types that aren't editable here. Update it through the API.” Use the claim topic endpoints for those.
If the signature or subject change lands but the exclusion setting does not, the sheet reports that the topic was updated but its exclusion policy was not, and offers Save exclusion policy without a second PIN. If the signature or subject change is still processing, the sheet does not save “Use in exclusions” and tells you so. Set it again once the change completes.
Delete a topic
- Check the topic's consumers: its assignments under “Trusted issuers”, “Compliance providers” and “Data feeds”, plus any compliance rule that requires it on “Global controls”, a policy template or a token's “Rules” table. The Console does not block deleting a topic that is still assigned, and the confirmation dialog does not list what is still attached, so you must check them yourself.
- Open the row menu and select Delete topic. The dialog “Delete this verification topic?” warns that the deletion cannot be undone and that verifications using the topic may stop counting.
- Confirm the dialog, then confirm with your wallet verification.
Only topics your system owns can be deleted here. A row whose “Source” reads “Global” shows Managed globally in place of the menu. Only a directory administrator can remove a global entry, and not from this screen.
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.
What a change records
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.
Troubleshooting
The Global directory tab shows only a notice
The tab shows the directory's topics to a directory administrator only. Everyone else sees You are viewing the global verification topics in read-only mode. Contact a directory administrator to make changes. A directory administrator sees the table, and the Console offers no add or remove controls for global entries to anyone.
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 “This 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 new topic takes the Use in exclusions value you choose while you add it, not the value the deleted topic had.
The exclusion policy does not save from an impersonated session
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. This includes adding a topic with any value other than the default. 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?
A verification topic classifies identity evidence, and a feed topic carries published numeric data. A verification topic is attested by a trusted issuer and required by a compliance rule, with data fields you define per topic. A feed topic has 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 topic again.
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 and changes neither entry.
Why can I open this page but not add a topic?
Viewing and managing are gated separately. The sidebar shows the page to the Permission manager, System manager, Verification policy manager, Feeds manager and Compliance manager roles, 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.
API routes
The claim topic endpoints in the Platform API reference cover create, replace the signature, set the exclusion policy, and delete, for deployments that manage topics from code.