A participant can receive a regulated token in an ordinary transfer or mint only when its identity is registered in the identity registry, the system's list of identities that tokens recognise, and carries the verifications the token's rules require. On the participant's Verifications tab you add a verification by hand, then check the intended transfer on the token's “Transfer pre-check” tab before you submit it. A custodian forced transfer or a token recovery checks only that the recipient is registered.
A verification, also called a claim, is a signed record on the participant's on-chain identity that says the participant passed one category of check, such as KYC.
Each category is a verification topic, defined on Verification topics, and a token counts a verification only when it comes from a trusted issuer for that topic, set on Trusted issuers.
When your organisation connects a compliance provider, the platform issues and revokes these verifications from the vendor's verdicts. You issue one by hand when no provider covers the topic or when your own team makes the decision.
Issuing a verification moves no balance. Transfer-path compliance, the check a token runs on every transfer, reads the verification when a transfer executes, so a verification issued while an earlier transfer still waits to execute counts for that transfer too.
The “Verifications” tab of the participant's detail page.
An “On-chain identity” card names the identity, its registration, its wallet and its country. Below it, the “Verifications” table lists every verification on this identity with its name and issuer address, its “Status”, and its “Verification data”, such as the claim value and how long it stays valid, with “Add verification” above it. A participant with no on-chain identity shows “No verifications yet” with the reason instead of the list.
Steps
Confirm the identity is registered
Open “Organisation participants”, then “Users” or “Entities”, and open the participant. On a user, the header reads Identity registration: registered when the registry marks the identity active and not lost, or “Identity registration: pending” when it does not. The “On-chain identity” card on the “Verifications” tab says “Registered” or “Pending registration”. The platform refuses to issue a verification to an identity that is not registered, so register it first from the same detail page.
On the “Identity and verifications” tile, select Manage verifications to open the participant's “Verifications” tab. The tab opens with the “On-chain identity” card above the “Verifications” table.
Open Add verification
Select Add verification in the toolbar of the “Verifications” table. When the button is disabled, point at it to read why. Troubleshooting lists the reasons.
An identity with no verifications yet shows “No verifications yet” and “This identity has no associated verifications.” in the table, with the button above it. A participant with no on-chain identity has no table and no button: the tab shows “No verifications yet” with the reason, such as “This participant has no on-chain identity yet. Verifications can be issued after the identity is registered.”
Select the topic
The sheet “Issue verification” has two steps: “Details” and “Review”. On “Details”, first choose the topic the token requires under Verification topic. The list shows your system's topics whose subject is “Person” or “Any subject”, in alphabetical order. It is not the token's required set, so you choose the right one yourself. Topics whose subject is “Asset” or “Issuer”, such as “Collateral” or “Issuer licensed”, are not offered on a participant. Issue them on an asset's identity. The list also leaves out “Instrument structure”, which the platform issues when a structured instrument's final class deploys.
The list still shows “Residence”, but the platform refuses it, because it issues Residence itself from an approved KYC profile. A topic you are not a trusted issuer for shows “You are not a trusted issuer for this topic” and cannot be chosen. When your identity is trusted for no topic, the “Verifications” tab says “You cannot issue verifications because your acting identity is not a trusted issuer for any topic.” A verification policy manager gets a link to “Trusted issuers”, and everyone else is asked to contact one.
Issuer event determination is issued on an asset's identity, not a participant's. Record an issuer event determination covers it.
Enter the details
Once you choose a topic, its fields appear below it on Details.
- KYC, AML and the other investor topics. The Console fills the value in for you: “This value is calculated automatically for this verification type. No manual entry is needed.” For KYC the value comes from the participant's approved profile. When the profile is not approved, including while a newer version waits for review, the step shows “No approved KYC profile” and “Review” stays disabled. The optional “Expiry date” sets the day after which the verification no longer counts. Leave it empty for a verification that never expires.
- Issuer and asset topics. Typed fields, such as a jurisdiction, licence details, a document hash or coordinates.
- Custom topics. One field for each value in the topic's signature, the list of values the topic defines.
Select Review, then check the summary against your evidence before you sign.
Sign and issue
Select Issue verification and confirm with your transaction PIN or transaction code. Wait for “Verification issued successfully”. The verification list reloads, and the new row shows “Active”, the topic you chose and your issuer identity.
Selecting a row opens its “Verification history”: each event, added, changed, revoked or removed, with its transaction, block, sender and event data.
Check the intended transfer
Open the asset under “Assets”, select its Transfer pre-check tab, enter the intended “Sender”, “Recipient” and “Amount”, and select “Run check”. The check simulates the transfer without signing anything and lists the blockers it can establish. Resolve each one before you submit the real transfer. A passing check describes the state now. The token checks every configured rule again when the transfer executes, not only this verification.
Revoke a verification
The row menu offers Revoke verification on an active verification when your account holds the “Verification issuer” role and your identity is either the participant's own identity or the verification's issuer. A revoke cannot be undone: to restore the participant's standing, issue a new verification. Confirm the dialog, then enter your transaction PIN or transaction code.
The same control takes one of two paths. When you revoke as the issuer, the platform revokes the verification through your issuer identity, and the record stays on the identity marked revoked. The dialog names both outcomes. When you revoke as the participant's own identity, the platform removes the verification from that identity instead, which needs the signing wallet to hold the on-chain authority to remove verifications from it. The identity no longer holds the record, and its history shows Verification removed. If more than one verification matches, the platform refuses instead of choosing one.
Record an issuer event determination
This task applies to an asset's own identity, not to a participant. An issuer event determination records that an event of a named kind occurred on an instrument, with a reference to the notice that records it. You issue it on the asset's own identity from the asset's “Verifications” tab, with Add verification and the topic “Issuer event determination”. The topic has two fields: “Determination kind”, such as “Early redemption approved” in the Console's example, and “Document reference”. Holders and counterparties rely on the signed record as the issuer's official determination, so check both fields before you sign.
A distribution request can name a determination kind that has a priority row in the distribution waterfall, the ranked list that decides who a coordinated distribution pays first. The waterfall uses that row only when, at the moment the distribution is funded, the asset's identity holds a determination whose Determination kind matches the row's kind exactly. The issuer must be trusted for the topic and must report the determination as valid. An absent, untrusted or invalid determination leaves the distribution on its ordinary ranking.
From registration to the transfer pre-check
The token's pre-check runs once the identity is registered and the verification issued, and it checks every rule against current state.
The pre-check evaluates the intended operation against current state, and a confirmed transfer records the outcome under the rules applied at execution.
Troubleshooting
Add verification is disabled
Point at the button to read the reason. “You are not authorized to issue verifications.” means your account lacks the “Verification issuer” role. A line that names a wallet means the role sits on that wallet, so switch to it. “This identity can't receive verifications yet.” means the identity has no account on this network yet. When the participant has no on-chain identity at all, the tab shows “No verifications yet” with the reason instead of the button.
A topic is disabled in the picker
Your identity is not a trusted issuer for that topic. Ask a verification policy manager to add the topic to your identity on Trusted issuers, or ask an issuer who is trusted for it to issue the verification.
The issue is refused because the KYC profile is not approved
The topic is an investor topic, and the participant's latest KYC profile is not approved. Ask the participant to complete their KYC profile and select Submit for review. Issue the verification once an identity manager or verification issuer approves the profile.
The issue is refused because the identity was not found in the registry
The participant's identity exists but is not registered. Register it from the participant's detail page, then issue the verification again.
The verification is active but the transfer still fails
Run the Transfer pre-check and read the blocker it names. The token can require another topic, accept only issuers your identity is not among, or enforce a rule unrelated to verifications, such as a country restriction or a holder cap. Fix the blocker the check names and run it again.
The participant held the token before but now fails
Run the Transfer pre-check against current state. A revoked or expired verification, a changed token rule or an issuer that is no longer trusted each changes the result on its own. On the “Verifications” tab, a verification whose issuer lost trust for its topic shows “Issuer not trusted for this topic”: issue it again from an issuer that is trusted for the topic, or restore the topic on Trusted issuers.
Frequently asked questions
Does a verification issued here work for every token?
It works for every token that requires the same topic and trusts the issuer. The verification sits on the participant's on-chain identity, not on a token, so any token whose rules ask for that topic reads the same record.
If a verification is revoked, does the participant lose the tokens they already hold?
No. The balance stays where it is. A revoked verification blocks the next transfer that depends on it and leaves settled transfers untouched. Moving or freezing an existing balance is a separate action on the token.
What happens if I issue a verification for a topic that already has one?
A verification is keyed by its issuer and its topic together, so issuing the same topic again from the same issuer identity replaces that issuer's earlier verification. An issuer with a different identity adds a second verification for the same topic. Check the issuer on the existing row before you submit.
Which holders would fail an asset's identity rule?
When your organisation has the Console assistant on, ask it on the asset's page what the identity rule means or which holders it would block. Search explains how to ask. The answer states the asset's identity rule in words and shows a block with the holders who fail it. The check covers the 50 largest holders and says so.
It asks each one the same eligibility question a transfer asks, and counts a holder as failing the rule when the reason is a missing verification, a revoked verification or an identity the token does not accept. A holder refused for another reason is counted separately. The block names at most five failing holders, largest first, with the reason for each.
The check stops after four seconds and reports how many holders it did not check, so a partial result never reads as complete.