Compliance providers
Connect an external verification service to claim topics and control what pausing, revoking, and reactivating each connection changes.
Compliance providers connect an external verification service, such as a KYC, AML, or business-verification integration, to the claim topics your compliance policies check. Adding one provisions a dedicated on-chain issuer identity for that service and registers it as a trusted issuerA Compliance Policy lets a compliance team write eligibility and holding rules once, while a platform floor reaches every current-factory token.Read the concept for each topic you attach. From then on the service's results arrive as signed webhook events: an approval becomes an on-chain claim on the participant's 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, a rejection revokes the claim it issued earlier.
Reach for this page when you integrate a new verification service, widen or narrow the topics it serves, rotate its webhook signing secret, or stop it. You will not need it to check one participant's status; that lives on the participant's own identity record, which reads whichever provider serves the topic it needs.
What you change here reaches further than the screen suggests. A compliance check reads the trusted-issuer registration at the moment it runs, not at the moment a claim was issued. Pausing keeps issuer registrations and stops new claim changes from that provider. Existing claims can still count, subject to expiry and the asset's other rules. Revoking removes the provider's issuer registration. Its claims stop counting in later checks; a holder can still qualify through another trusted issuer or another branch of the policy. The organisation's Audit trail records each change you make here with your name and the role you held at the time.
The service never touches the chain itself. Its results become claims from the provider's issuer identity, and a check honours those claims only while the topic registration stands.
Steps
Open Compliance providers
Open "Compliance", then "Compliance providers". The list shows each provider's topics and status, plus when it last had activity. Providers whose own status is failed or paused sort to the top because those rows need you first; that ordering follows the provider's own status, not the status badge next to it. The badge reads from the topics instead: one failed topic is enough for the row to show "Failed", and topics that disagree with each other show "Mixed", either way regardless of where the row sits in the sort.
Screen equivalent: the list shows configured verification integrations, their topics, and their current provisioning state.
Pick the service and its first topic
Select "New provider", choose the service, then confirm the first claim topic on the next step. The wizard offers only topics the chosen service supports, and it selects the topic for you when the service supports exactly one. Services come in two families, and the split decides what you will see later. Identity and business verification services return one terminal verdict per subject. Monitoring services keep sending alerts after the first result and get a "Monitoring history" page the verdict services never show. ComplyAdvantage and Elliptic belong to this second family, along with every Sumsub variant.
For the severity threshold on the same step, the tier you pick is the point at which an incoming alert revokes the subject's claim automatically. An alert below the tier is recorded without touching the claim.
| Tier in the picker | A claim is revoked when | Choose it when |
|---|---|---|
| "Low (25/100)" | Almost any alert arrives; only the weakest signals are recorded without claim removal. | Your policy requires automatic revocation at severity 25 or above. |
| "Medium (50/100)" | A moderate signal arrives. | Your policy requires automatic revocation at severity 50 or above. |
| "High (80/100)" | A severe alert arrives. The Console proposes this tier by default. | Your policy requires automatic revocation at severity 80 or above. |
| "Critical (95/100)" | Only the strongest alerts arrive. | Your policy requires automatic revocation at severity 95 or above. |
Connect credentials and provision
Enter the credentials the wizard asks for, which differ by service (see Before you start), review the provisioning summary, then select "Verify and provision" and confirm with your PIN. The wizard checks the credentials against the live service first, so a wrong key fails here with the service's own message before on-chain provisioning starts. Correct it and submit again. After validation the platform provisions the issuer identity and registers it on-chain, with three possible endings. "Provider active" means the registration stands. "Provisioning failed" leaves the provider on the list with a "Retry provisioning" control. "Awaiting transaction approval" means the registration is queued behind your organisation's transaction approval policy, and the provider activates once that clears.
Point the service at each topic's webhook
Open the new provider's detail page and find the "Webhooks" table, which carries one row per topic with its own delivery URL and status. Reveal or copy each row's URL into the service's own dashboard so it delivers signed events there. Treat the URL like a credential: its trailing segments identify this provider to the platform. That is why the Console masks them by default, and copying always emits the full address.
Once the service starts delivering, the detail page tells you whether the loop is closing. Verdict services stamp each topic row's last activity with the latest result; monitoring services fill "Monitoring history", which you can filter by topic and search. The "Health" card shows the latest health check, which confirms the stored credential references are present. Its "Test connection" button sends the stored credentials to the service and shows whether the service accepts them, with the service's own message when it refuses; for Sumsub it also confirms the configured level exists. The test changes nothing and needs no PIN. To change the credentials themselves, open "Edit" in the page header and enter the full new set: credentials are write-only, the service checks them before anything is saved, and the replacement asks for your PIN. Webhook signing secrets are rotated per topic under "Webhooks", not in "Edit". The header's status explanation summarises the current state in one line; for a failure, it only names that provisioning failed, so read the "Health" card for the reason.
Growing and stopping the integration
Attach another topic from the detail page with "Add webhook". The provider's existing identity and credentials are reused; the platform only widens its trusted-issuer registration, and the new row gets its own delivery URL, signing secret, and severity threshold. The topic picker hides topics the service does not support and topics already attached.
Stopping happens at two levels, one webhook row or the whole provider, and these four stops differ in how far they reach and how you undo them.
| You choose | What stops | What keeps working | The way back |
|---|---|---|---|
| "Pause" on one webhook row | Deliveries for that topic keep arriving and get recorded, but no new claim activity happens for it. | The provider's other topics, and the row's registration, URL, and signing secret. | "Resume" on the same row. Nothing needs reconfiguring. |
| "Revoke" on one webhook row | That topic's registration. This provider's claims stop counting for the topic. | The provider's other topics, and the row's URL and signing secret. | "Reactivate" on the same row re-registers the topic with the URL and secret intact. |
| "Pause" on the provider | Every topic's deliveries keep arriving and get recorded, but the platform issues no new claims from any of them. | Every trusted-issuer registration. Existing claims can still count subject to expiry and other rules. | "Resume". Nothing needs reconfiguring. |
| "Revoke" on the provider | Every registration at once, and the delivery URLs stop accepting events. Claims from this provider stop counting everywhere. | Nothing operational. The record stays on the list for your audit trail. | None. Provision a new provider with fresh credentials and reattach every topic it served. |
The Console refuses to revoke the last active webhook row and tells you to revoke the whole provider instead, so a provider is never left active with nothing it can do. Two grants split the controls here. The Compliance manager grant covers pausing and resuming at either level, along with secret rotation. The Verification policy manager grant covers the registry, from revoking and reactivating a webhook row to attaching a new topic. A colleague who sees "Pause" but not "Revoke" is missing the second grant, not looking at a broken page.
To rotate a webhook's signing secret, pick "Rotate secret" on its row, enter the replacement, and choose a grace window of 15 min, 1 hour, 6 hours, or 24 hours. During the window the platform accepts deliveries signed with either secret, so you can update the service's dashboard without dropping events in between.
Automation note: everything this page does is also exposed through the Platform API. The compliance provider endpoints are not written up separately; browse and call them from the v2 API explorer, which reads the generated contract, to script provisioning across environments.
Troubleshooting
The wizard fails at the last step with an unregistered-topic error
In the wizard's first step, the picker limits itself to topics the chosen service supports; it does not check whether the topic has actually been created on "Verification topics". Pick one that has not, and the wizard still lets you enter credentials and your PIN, then fails at "Verify and provision" with an error naming the topic as not registered on-chain, and nothing is created. Create the topic on "Verification topics" first, then run the wizard again. On an existing provider's detail page, "Add webhook" also hides topics already attached to this provider, since there the point is adding one it does not yet serve.
Provisioning does not complete
A credential the service rejects stops the wizard before anything is created; the message shown is the service's own, so fix the key and resubmit in place. A failure after validation leaves the provider on the list as "Failed"; its status explanation only says provisioning failed, so open the detail page and read the "Health" card for the reason. Select "Retry provisioning" to run the on-chain steps again.
The provider stays Pending
A "Pending" provider is either queued behind your organisation's transaction approval policy or still running its on-chain provisioning steps; Check the approval and workflow status to distinguish an expected wait from a failure. The wizard shows "Awaiting transaction approval" while you are still in it, but once you leave, the list and detail page report "Provisioning is in progress." for both causes alike, with nothing to tell them apart. It activates when an approver clears the queue or provisioning finishes. "Retry provisioning" also appears in this state if the queue entry itself failed.
A provider that was Active now shows Failed
One failed topic makes the list show the whole provider as "Failed". Open the detail page, read the "Health" card, since the status explanation itself carries no detail, and check which topic row turned. Correct what the error names, then use "Retry provisioning".
The last webhook cannot be revoked
That refusal is deliberate: the Console rejects revoking a provider's last active topic row so an empty-but-trusted provider cannot linger. If the provider should stop serving its final topic, revoke the provider itself.
Frequently asked questions
Can two providers serve the same topic?
Yes: "Add webhook" only hides topics already attached to the provider you are editing, so a second provider can register for a topic the first one covers already. That is how you migrate: provision the new provider on the topic, let it issue fresh claims, then revoke the old one once nothing depends on it.
Can I read the credentials back after setup?
No. Credentials are write-only: the platform encrypts stored credentials and does not return their values through the Console. Keep the source values in your own secret store. The one secret you can see again is each webhook row's delivery URL, which reveal and copy controls expose on the detail page.
What happens if a delivery URL leaks?
An event that cannot prove it came from the service is refused before any claim changes. Most rows check a valid signature from the row's signing secret. Jumio's rows also check Basic-Auth credentials against a source-IP allowlist, which you must set during setup since the wizard will not let you finish with an empty one. If the secret leaked too, stage a "Rotate secret" with a short grace window.
Do I have to finish the wizard in one sitting?
Yes. The wizard holds your selections and credentials only in the open session, and leaving it discards them; the Console warns you before you go. Nothing is created before you select "Verify and provision", so an abandoned wizard leaves no half-provisioned provider behind.