Verify a participant
Confirm a participant has a registered identity, add the issuer-signed verification, and check the target token's eligibility requirements.
A participantA participant lets every role grant, claim, audit row, and delegated action point at one stable subject, so a person's history never splits.Read the concept needs the identity registration and verifications required by the target token. This workflow checks the registration, adds an issuer-signed verification, and checks the intended operation. Create the participant first through Users or Entities.
Two separate on-chain records sit between "this participant exists" and "this participant can hold the token," and mixing them up is the single most common mistake on this page. An On-Chain IdentityAn On-Chain Identity lets a subject's verification serve every asset that accepts it, so a screened wallet skips re-onboarding for the next regulated asset.Read the concept is a contract that either exists or does not; deploying it is a separate event from registering it. A registered identity can later flip back to pending if it is marked lost, even though the contract itself still exists. Registering it makes the participant addressable to every token's rule check, but proves nothing about what that participant is allowed to hold. A verification is a distinct, issuer-signed claim attached to that identity, naming a specific topic, such as accreditation or a jurisdiction check, that a trusted issuer attests to. A registered identity with no verifications can still fail every eligibility check a token runs; registration is the prerequisite, not the proof.
Transfer-Path ComplianceTransfer-Path Compliance enforces a regulated token's rules inside the on-chain transfer itself, so a movement that fails any rule reverts and never settles.Read the concept owns the actual decision, and it is the token, not this page, that makes it. Issuing a verification here does not itself move any balance or force any token to accept the participant; it only adds a record the token's compliance engine can read the next time someone attempts a transfer. Use the token's Pre-check tab to inspect eligibility before submitting the intended transfer. A confirmed transfer proves that the operation passed the rules at execution time. The token reads that record at the moment a transfer executes, not when it was submitted, so a verification issued while an earlier transfer is still pending is already visible to it, provided that transfer has not yet executed.
Issuing or revoking a verification touches only the participant it is attached to; no counterparty is named or notified. The participant's own detail page keeps an activity view of on-chain events tied to its account, where both an issued and a revoked claim appear with the acting identity. That view is the audit trail for who issued or revoked which verification and when. Entities describes this same activity view for that roster's own registration events.
Registration and verifications are inputs to eligibility. Pre-check evaluates the intended operation against current state; a confirmed transfer records the outcome under the rules applied at execution.
Steps
Confirm the identity is registered
Open "Organisation participants", then "Users" or "Entities". Find the participant and open its detail page. Check the registration-status badge: "Registered" means the registry marks this identity active and not lost; "Pending registration" means it does not, whether because no identity contract has been deployed yet, registration has not completed, or a previously registered identity was later marked lost. A pending identity does not block the steps that follow; you can still open its verifications and add one. It just cannot pass a token's rule check until registration completes, so register it from this same detail page as soon as you can. The detail page's "Identity and verifications" tile carries a "Manage verifications" button; select it to open the dedicated verifications view for this identity.
Screen equivalent: reached from the participant's detail page by selecting "Manage verifications" on its "Identity and verifications" tile. This is its own screen, not a variant of the page you opened in the first step; the breadcrumb trail names it "Verifications". It lists every verification record currently attached to this identity, each row showing its topic, its issuer, whether that issuer is trusted, and whether the record is active or revoked. An "Add verification" button appears above the list when your account may issue one for this identity. The "Manage verifications" button itself never renders for a participant with no identity contract yet, so this view has no path in from the detail page; reached directly, it shows "No identity found" instead of an empty list. A deployed identity that is still pending registration opens the same list and button; existence, not registration status, decides whether this view has anything to render.
Open the Add verification form
On the verifications view, select "Add verification". The control appears only when your account holds the verification-create permission and the identity has an account record for the claim to attach to; it disappears entirely, rather than showing disabled, when either condition is not met. An identity that meets both and has no verifications yet shows an empty list with the same button, not an error.
Select the required topic
The picker lists the organisation's verification topics, not the target token's required set. You must know which topic that token's policy requires and choose it yourself; nothing on this screen looks that requirement up for you. A topic you are not a trusted issuer for is disabled and labelled as such, because issuing against a topic you are not trusted for would create a verification the token can never actually honour. Enter the values from the approved evidence, review the summary, and correct any mismatch before submission.
Sign and issue
Submit the verification. The Console opens a wallet-verification prompt titled "Issue verification" and asks for your "PIN code" or "Authenticator code", whichever method your account signs with. Wait for "Verification issued successfully". The participant's verification list reloads its records on its own, and the new row appears with an active status, the topic you chose, and your issuing identity.
Check the intended operation
Confirm that the new row is active and names the expected topic and issuer. For a transfer, enter the intended sender, recipient, and amount in the token's Pre-check tab. Resolve reported restrictions before submitting the intended operation. Review the amount and recipient again, then wait for on-chain confirmation. The token checks every configured rule, including but not limited to this verification, before balances change.
Troubleshooting
Add verification is not shown
Confirm that your account can create verifications and that the identity has an account record for a claim to attach to. The control disappears entirely rather than showing disabled when either condition is not met; resolve the identity from the participant's own detail page, then return here.
A topic is disabled in the picker
You are not a trusted issuer for that topic, and the picker marks it so rather than letting you submit a verification the token will never honour. Ask an authorised issuer for that topic to complete the issue, or ask an administrator to grant your issuer identity trust for it if that is the correct long-term arrangement.
The verification is active but eligibility still fails
Read the transfer failure. It names the specific rule that blocked the movement. The token can require other topics you have not issued, a different trusted issuer than the one who signed, or enforce another configured rule entirely unrelated to verifications, such as a jurisdiction restriction or a holder cap. Fix only the rule the current result names; a verification that looks correct is not itself the blocker in that case.
The participant held the token before but now fails
Run Pre-check against current state before retrying the intended transfer. A revoked or expired verification, a changed token policy, or another current rule can each change the result independently of the others, and the transfer failure names which one applies now.
A verification was issued in error and needs to be undone
The Console shows its revoke control only for the signed-in account's own identity. The server also requires the Claim Issuer role and a management key on the target identity. The control never appears here, or on the participant's own detail page, while you are viewing it as the issuer or operator who added the record. A "Revoked" status can still appear against a record here, but that status alone does not identify who submitted the revocation. If a verification you issued needs to come down, and the participant cannot or will not revoke it themselves, escalate the incorrect claim for correction through an authorized identity-management path. Escalate to whoever administers your organisation's compliance tooling, since neither surface gives you a way to revoke a claim on someone else's identity. In the meantime, do not rely on the mistaken verification; the target token still evaluates its full rule set on every transfer attempt, and an incorrect verification can still affect which operations pass.
A failed transfer reports no clear reason
Submit the same sender, recipient, and amount to the token's "Pre-check" tab before retrying the real transfer. It calls the same transfer-simulate endpoint the transfer itself would run, without signing anything, and reports the checks it can evaluate, including named blockers. Each rule is grouped by who can resolve it: resolvable by you, requiring an operator to intervene, or, for the hardest group, one the Console states plainly cannot be resolved under any standard workflow. Retrying an unchanged transfer against that hardest group returns the same result, since a rejection here is a policy decision, not a transient fault.
Frequently asked questions
Does a verification issued here work for every token, or only the one I tested it with?
Every token that requires the same topic from an issuer it trusts, not only the one you tested. Issuing a verification from a participant's own detail page attaches the record to that participant's on-chain identity in the shared identity registry, never to any single token. Any token whose rules ask for that topic can read the same record the next time it checks a transfer.
If a verification is revoked, does the participant lose the tokens they already hold?
No. The held balance stays exactly where it is; a revoked verification only blocks the participant's next transfer that would depend on it, and leaves any transfer that already settled untouched. Moving or freezing an existing balance is a separate, deliberate decision on the token itself, not a side effect of revoking a verification. The Platform API's claim-removal route requires the target identity's management key and the Claim Issuer role, so this holds regardless of who initiates the revocation.
What happens if I issue a verification for a topic that already has one?
It depends on who issues it. Resubmitting the same topic from the same issuer identity overrides that issuer's own earlier record, so that issuer never ends up with two active verifications for the same topic. A colleague issuing the same topic from a different issuer identity adds a second active verification for that topic instead, because the underlying record is keyed to the issuer and the topic together, not to the topic alone. Check the issuer named on the existing row before you submit; only a resubmission from that same issuer replaces it.
Why does a participant's Identity tab sometimes show a disabled "Issue verification" button instead of hiding it?
The Identity tab embeds the same verification component in a compact layout that labels the button "Issue verification" and never hides it: when your account cannot use it, the button stays visible but disabled, with a tooltip naming the reason. The dedicated verification view this page documents renders the same component in its full layout, labelled "Add verification", and hides the button outright instead of disabling it. Both surfaces gate on the same two facts: your account holds the permission to issue, and the identity has a linked account record for the new claim to attach to.
Insights
Read identity and verification counts for the selected organisation and network, and know when to stop trusting the aggregate and open the participant record.
Asset design
Build the reusable product shapes and compliance rules an issuer selects when creating an asset, plus the identity-evidence chain every compliance check reads.