A compliance provider connects one account at an identity or screening vendor, such as Sumsub, Onfido or Elliptic, to your organisation, so the vendor's verdicts become verifications on participants' on-chain identities without anyone issuing them by hand. An approved verdict issues the verification, a rejection or a severe screening alert revokes it, and every transfer check afterwards reads the result. A revoke removes only this provider's verification: a participant who also holds a valid verification on the same topic from another trusted issuer still passes, so review who else is trusted for the topic. The provider verifies only participants your integration registers as subjects at the vendor through the Platform API, a step with no Console screen.
A verification, also called a claim, is a signed record on a participant's on-chain identity that says the participant passed one category of check, such as KYC. Each category is a verification topic. A token's compliance rules require topics, and they accept a verification only from a trusted issuer, an identity the system trusts to sign verifications for that topic. When no vendor is connected, a person with the “Verification issuer” role adds verifications by hand on Verify a participant.
The “Compliance providers” list with an “Add compliance provider” button and one row per provider, showing its name, its topics as active out of total, its status badge and its last activity.
A failed or pending row offers “Retry provisioning”, an active row offers “Pause”, and a paused row offers “Resume”.
Steps
Open Compliance providers
Open “Compliance”, then Compliance providers. The list has the columns “Provider”, “Topics”, “Status”, “Last activity” and “Actions”, and shows up to 200 providers, 25 to a page. The “Actions” cell offers “Retry provisioning” on a failed or pending provider, “Resume” on a paused one and “Pause” on an active one. Providers whose own status is failed or paused sort first, then the rest by most recent change.
The status badge sums up the provider's topics: “Failed” when any topic failed, “Pending” when any topic is still being set up, the shared status when every topic agrees, and “Mixed” when they differ. Last activity shows the latest verdict state over “Last verdict at” and its date, or “Verdict recorded” when the state is not known. For an alert it shows the severity over “Last alert on” and the date. For a refused event it shows the outcome over “Last webhook on” and the date. A provider with none of these reads “No activity yet”.
Choose the vendor
Select Add compliance provider. The wizard “Add a compliance provider” has three chapters: “Provider”, “Connect” and “Review and sign”. On “Provider”, pick the vendor. “Filter by what you need verified” narrows the list to vendors that attest one topic, and each vendor card lists “Verifications it can issue” and “What you need from your account”.
The “Provider” chapter of the “Add a compliance provider” wizard asks “Which provider checks your investors?”.
A filter narrows the cards by what you need verified, such as KYC or AML. Each card names a provider and the verifications it can issue, and a side panel lists what you need from your account with that provider, for Sumsub an app token, a secret key, a KYC level name and a webhook signing secret.
The wizard keeps your choices in this browser for 7 days, for the signed-in user and organisation, so you can leave and come back. It keeps the level name, the region and the webhook IP addresses, but never a token, key or secret: you enter those again when you return.
Set the topic, threshold and claim validity
On “Connect”, the Topic and threshold section sets three values for the first topic.
- Verification topic: one of the topics the vendor attests. A vendor with one topic shows it without a choice. You add more topics on the provider page later.
- Severity threshold: the alert severity, on a scale of 0 to 100, at or above which an alert revokes the verification. An alert below it is recorded and changes nothing. The threshold has no effect for a vendor that sends no monitoring alerts. The choices are “Low (25/100)”, “Medium (50/100)”, “High (80/100)” and “Critical (95/100)”. “High (80/100)” is the default.
- Claim validity: how long a verification issued from an approved verdict stays valid. Enter a whole number and pick “Days”, “Months” or “Years”, or keep “Never expires”, the default. A month counts as 30 days and a year as 365 days, and the total can be at most 68 years, 828 months or 24,855 days. The validity runs from the time the vendor reports for the verdict.
The platform writes the valid-until date into the verification. An asset refuses a lapsed verification only when it runs the Claim expiry compliance module, and on such an asset the participant must be verified again.
The “Connect” chapter for Sumsub shows the verification topic, severity threshold and claim validity.
The “Topic and threshold” section shows “KYC (Know Your Customer)” under “Verification topic”, the “Severity threshold” picker on “High (80/100)” and the “Claim validity” field on “Never expires”. Continue to Review and sign stays unavailable until the credential fields in the next section are filled.
Enter and test the credentials
In “Credentials”, fill in every field the vendor asks for, then select Test connection. The platform sends the credentials to the vendor and shows the answer: “Sumsub accepted these credentials.” or “Sumsub rejected these credentials.”, with the vendor's own message when it gives one. For Sumsub, the test also checks that the level name exists. “Test connection” stays disabled until every required field is filled in, and changing a credential after a passing test means you test again.
Review and sign
On “Review and sign”, read What signing does: signing registers the vendor as a trusted issuer for the topic, and after that its verifications count when investors are checked. The chapter lists checks that must pass before you can sign. It blocks signing when the credentials are not tested or were rejected, when the claim validity is not valid, when your signing wallet lacks the roles, or with “KYC (Know Your Customer) is not registered on this platform” when the topic does not exist yet. Create a missing topic on “Verification topics” and come back.
Select Sign and connect with the vendor's name and confirm with your wallet verification. Setting up the provider's identity on chain can take longer than one request, for example while the network is busy. The Console then keeps waiting on the same step until the setup finishes, for up to three minutes. The outcome reads one of these:
- Sumsub is connected: the provider is active and registered as a trusted issuer.
- Sumsub is waiting for approval: your organisation's transaction policy holds the registration until its approvers approve it.
- Sumsub could not be connected: the provider stays on the list as “Failed”, with “Retry provisioning”.
Point the vendor at each topic's webhook URL
Select Open provider. The “Verification topics” table on the provider page has one row per topic, with the columns “Topic”, “URL”, “Status”, “Severity threshold”, “Claim validity” and “Last activity”. The Console masks the end of each URL.
Select Reveal to see it, or copy it, then paste it into the webhook settings at the vendor, together with the same signing secret you entered in the wizard. Treat the URL like a credential: it identifies this provider to the platform.
The provider page shows the “Provider actions” menu and the “Verification topics” table.
The header holds “Test connection”, “Replace credentials” and “Provider actions”. The “Verification topics” table has one row per topic with its masked URL and a “Reveal” button, its status, severity threshold, claim validity and last activity, and an “Add topic” button in the table toolbar.
Change a connected provider
Add a topic
Select Add topic in the “Verification topics” toolbar. The dialog “Add a verification topic” offers only topics the vendor attests that this provider does not hold yet, and asks for the topic's “Severity threshold”, “Claim validity” and “Webhook signing secret”. Confirm with your wallet verification. The provider keeps its identity and credentials, and the platform registers it as a trusted issuer for the new topic. “Add topic” is disabled with “Topics can be added once the provider is active.” while the provider is pending, and with “Every available topic is already added.” when nothing is left.
Change a topic's threshold or claim validity
In the topic row's menu, select Edit topic. The panel changes the severity threshold and the claim validity, and asks for your wallet verification. You can edit an active or paused topic. The new values apply to events that arrive afterwards. Verifications already issued keep the valid-until date they were issued with.
Replace the credentials
Select Replace credentials in the page header, or in “Provider actions” on a phone. Enter the full set again, because credentials are write-only, then confirm with your wallet verification. The new credentials must be for the same vendor product, and the vendor must accept them before anything is saved. If the vendor refuses them, the old credentials stay in place. Webhook signing secrets are not part of this sheet: you rotate them per topic.
Rotate a webhook signing secret
- In the first topic's row menu, select Rotate secret.
- Enter the New signing secret and choose a “Grace window” of “15 min”, “1 hour”, “6 hours” or “24 hours”.
- Select “Stage rotation” and confirm with your wallet verification.
- Update the vendor's dashboard inside the window.
- Promote the rotation through the Platform API before the window ends.
During the window the platform accepts events signed with either the current or the new secret. Only one rotation per topic can be pending. Once the window has passed without promotion, the platform accepts only the current secret again and refuses a late promotion. The expired rotation stays pending and blocks a new one until you cancel it through the API.
Pause, revoke and reactivate
A pause has no on-chain effect. A revoke removes the provider's trusted-issuer registration, which changes every transfer check that runs afterwards. A provider revoke cannot be undone.
An event that the platform had already accepted when you paused can still be processed afterwards. It is then recorded as Rejected: provider paused and changes no verification.
Revoke topic is disabled on the provider's last topic that is active or paused, with “This is the last active topic on the provider. Revoke the whole compliance provider instead.” To stop that topic, revoke the provider.
The revoke dialog, titled with the vendor's name such as “Revoke compliance provider Sumsub?”, names every topic it removes. Connecting the same vendor again creates a new provider with a new on-chain identity, and the platform never registers the revoked identity again, so each participant needs a new verification from the new provider.
Read what the vendor sent
For a vendor that sends alerts, Monitoring history in “Provider actions” lists each recorded monitoring alert with its “Subject”, “Topic”, “Severity”, “Outcome” and “Created” time in UTC. Open a row to see and copy its “Event reference”. You can filter by topic and search. Verdicts do not appear in this list. The outcomes are:
- Applied: the alert revoked the verification, or was below the threshold and was recorded.
- Duplicate delivery: the vendor sent an alert the platform had already processed.
- Pending: the alert is still being processed.
- Rejected: out of order: a newer event for the same subject and topic was already processed.
- Rejected: unknown subject: the platform could not map the event, or its subject was never registered with this provider.
- Rejected: topic mismatch: the alert's topic is not the topic row's, or the provider is no longer a trusted issuer for the topic on chain.
- Rejected: provider paused: the provider or topic was paused when the alert was processed.
- Rejected: over the cap: the provider reached its limit of fee-paid verifications. The limit is shared by all the provider's topics. The default is 10,000 verifications in a rolling 24 hours, and the limit and window are configurable per organisation. The cap counts issued verifications only. A revocation is never refused for the cap.
- Rejected: cannot be sponsored: the provider's issuing account is not set up to sign for the provider's identity, so the platform refuses to pay for a transaction that would fail.
- Failed: processing failed.
The title names the provider, “Sumsub monitoring history”, and an “All topics” filter sits above the list.
Until an alert is accepted, the page reads “Monitoring is active, no alerts yet” and “Provider alerts will appear here after signed provider webhooks are accepted.” Once alerts arrive, the table lists “Subject”, “Topic”, “Severity”, “Outcome” and “Created”.
How a provider verifies a participant
- The topic exists. The topic the vendor attests, such as “KYC (Know Your Customer)”, is registered on Verification topics.
- You connect the provider. The platform creates an on-chain identity for the provider and registers it as a trusted issuer for that topic. Each topic gets its own webhook URL, the address where the vendor sends its results.
- The participant becomes a subject at the vendor. A subject is the vendor's record for one participant, wallet or transaction, linked to the participant's identity. Your integration registers subjects through the Platform API. The API creates the applicant at the vendor, links a wallet, or registers a transaction for screening. The Console has no screen for this step. A result for a participant who was never registered as a subject changes nothing. With Sumsub, an investor can also complete the vendor's check inside the investor portal.
- The vendor sends a signed result. The platform checks the signature with the topic's webhook signing secret, or, for Jumio, checks Basic-Auth credentials and the sender's IP address. It refuses an event whose timestamp is more than 5 minutes away from the time it arrives.
- The platform changes the verification. An approved verdict issues the topic's verification on the subject's identity, signed by the provider's identity, and the platform pays the network fee. A rejected verdict revokes it. A monitoring alert at or above the topic's severity threshold revokes it, and an alert below the threshold is recorded and changes nothing. A revoke removes only this provider's verification.
- Every later check reads it. A transfer counts the verification only while the provider stays a trusted issuer for the topic. An asset that runs the Claim expiry compliance module also refuses a verification past its valid-until date.
The vendor never writes to the chain, and a check counts the verifications built from its results only while the provider is a trusted issuer for the topic.
Supported vendors
KYC checks a person's identity, KYB checks a business, AML screens against sanctions and watch lists, and KYT screens wallets and transactions. The vendor list is fixed. Each vendor product is its own provider with its own on-chain identity, so Sumsub, Sumsub AML and Sumsub KYT are three providers. The wizard asks for different credentials per vendor. Every credential is write-only: the platform stores it in its secret store and never shows it again.
A Sumsub level name must match a level that already exists in that Sumsub account. Jumio's region is amer-1, eu-1 or sg-1, and Onfido's is EU, US or CA. For Jumio, the webhook IP field takes one IP address or address range in CIDR notation, such as 34.107.16.0/24, per line, and the platform refuses webhooks from any other address. A vendor that sends monitoring alerts gets a “Monitoring history” page. The others return one verdict per subject.
The investor portal shows Sumsub's own verification screen. DALP passes it English as the language and the portal's light or dark theme. The rest of its look comes from the WebSDK 2.0 customisation on the level in your Sumsub account, which Sumsub documents in Customise WebSDK.
Troubleshooting
Test connection says the vendor rejected the credentials
The message under the result is the vendor's own. Until you reload the page, the header badge and the health line also read “Credentials rejected”, with the time of the test. Nothing is stored, so a reload shows the stored status again. Correct the field it names, then test again. For Sumsub, check that the level name matches a level in that Sumsub account exactly.
Last activity reads Rejected instead of a severity
The latest webhook from the vendor was refused or failed. “Last activity” shows its outcome, such as “Rejected: unknown subject”, with “Last webhook on” and the date. For a vendor that sends alerts, “Monitoring history” lists each one.
Review and sign says the topic is not registered on this platform
The topic the vendor attests is missing from your system. Create it on Verification topics, then return to the wizard. Your choices are still there, but enter the credentials again.
The provider stays Pending
The status explanation reads “Provisioning is in progress.” The registration is either still running or held by your organisation's approval step in the transaction queue, where a transaction waits until it is approved, for example under your custodian's approval policy. Ask whoever approves your organisation's transactions to approve it. If it does not complete, select Retry provisioning.
The provider shows Failed
The status explanation reads “Setup did not finish. Retry provisioning to continue.” Select Retry provisioning in “Provider actions” or on the list row.
Review and sign says another provider of this vendor is still being created
An organisation holds one live provider per vendor on a system, and an earlier connection of the same vendor is still being set up, for example from another browser tab or by another administrator. The platform refuses the second one before it writes anything on chain. Open the providers list and wait for the earlier provider to turn Active, Pending or Failed, then continue with that one. If no earlier provider appears and the refusal persists, connecting again succeeds 15 minutes after the earlier attempt started.
The provider is Active but nothing happens
Check that the vendor's webhook settings use the topic row's full URL and the same signing secret you entered, and, for Jumio, that the vendor's IP addresses are among the accepted webhook IP addresses. For a vendor that sends alerts, check Monitoring history for “Rejected: unknown subject”: the participant was never registered as a subject with this provider.
The health line says some stored credentials could not be found
A credential or signing secret the provider needs is missing from the secret store. Replace the credentials with Replace credentials. For a missing signing secret on the provider's first topic, stage a rotation and promote it through the Platform API, or cancel a stale pending rotation through the API. On a later topic the Console and API offer no way to replace the secret, and the last resort is to revoke the provider and connect the vendor again, which ends every verification the provider issued.
Frequently asked questions
Can two providers serve the same topic?
Yes. Each provider is its own trusted issuer, so a second provider can register for a topic another provider already serves. To move to a new vendor, connect it on the topic, let it issue new verifications, then revoke the old provider once no participant depends on its verifications.
Can I read the credentials back?
No. Credentials and signing secrets are write-only and never appear in the Console or in an API response. Keep the source values in your own secret store.
Does pausing a provider take verifications away?
No. Pausing changes nothing on chain, and verifications the provider already issued keep counting until a revoke, or until their valid-until date on an asset that runs the Claim expiry compliance module. But a rejection or alert the vendor sends during the pause is refused and revokes nothing unless the vendor sends it again after you resume.
API routes
Every action on this screen has an endpoint in the Platform API reference. Subject registration, which has no Console screen, uses the compliance subject endpoints under /.
Creating a provider (POST /api/) answers 202 with { request, and the setup continues on chain. Read statusUrl (GET /api/) until it answers 200 with the provider, or the refusal the setup ended with. Send Prefer: wait=N, with N from 5 to 99 seconds, to wait for the setup in the same request: the answer is 200 with the provider when it finishes in time, and 202 otherwise.