Choose a KYC issuance path
Decision guide for choosing manual DALP KYC claim issuance or provider-driven ClaimSource intake through a compliance-provider integration.
DALP turns KYC, KYB, AML, and wallet-monitoring outcomes into on-chain compliance claims. You can issue them manually through a configured trusted issuer, or let a compliance-provider integration issue and revoke them through its own trusted-issuer identity.
Choose the path before you configure the claim topic. Compliance modules evaluate the resulting on-chain record, not the operational process that produced it.
| Decision point | Manual claim issuance | Provider-driven intake |
|---|---|---|
| Who reviews the evidence | Your compliance staff or internal back-office process | The selected compliance provider |
| Who writes the claim | A staff-controlled or service-controlled trusted issuer | The provider's claim-issuer identity |
| Best fit | Internal KYC review, exceptions, and controlled manual attestations | Provider verdicts, KYB checks, AML alerts, and wallet-monitoring events |
| Main operating risk | Manual claims can drift from later provider results | Provider rejections or severe alerts can revoke claims when configured to do so |
Issuing duplicate claims for the same subject and topic complicates reviews. If both paths coexist, define which issuer is authoritative and which path is an exception or fallback.
Use manual KYC claim issuance
Use Verify KYC via API when compliance staff or an internal back-office system reviews KYC evidence and issues the claim directly.
Choose this path when the review happens inside your organisation, your claim issuer is staff- or service-controlled, and any provider evidence feeds an internal decision rather than driving the claim automatically.
The issuer must be configured as a trusted issuer for the relevant claim topic. The API caller needs the claim-issuer role and wallet verification for the claim transaction.
Use provider-driven identity or business intake
Use Onboard a compliance provider and Map compliance-provider subjects when a provider should produce identity or business verdicts for DALP identities.
Choose this path when the provider (such as Sumsub, Jumio, Middesk, Onfido, Persona, Trulioo, or Veriff) creates and reviews applicants or businesses. Approved verdicts should issue the claim, rejected verdicts should revoke it, and the provider's claim-issuer identity should be the on-chain issuer of record.
Each provider topic must be supported by the selected provider kind. Some provider kinds support one topic, while Onfido and Persona can support both KYC and KYB topics.
Check provider topic support
Provider-driven intake is not a generic claim writer. Each provider kind can attest only the claim topics it supports:
| Provider kind | Supported topics |
|---|---|
sumsub, jumio, trulioo, veriff | knowYourCustomer |
middesk | knowYourBusiness |
onfido, persona | knowYourCustomer, knowYourBusiness |
sumsub-aml, complyadvantage, elliptic | antiMoneyLaundering |
sumsub-kyt | knowYourTransaction |
DALP rejects an unsupported provider and topic pair before provisioning provider state. For example, a Sumsub KYC integration cannot be created for the accreditedInvestor topic; the API returns the supported topics for the selected provider kind.
Use provider-driven AML or wallet-monitoring intake
Use provider intake when monitoring alerts should affect AML claim state or monitoring history for DALP identities.
Choose this path when Sumsub AML, Sumsub KYT, ComplyAdvantage, or Elliptic supplies monitoring events, and the subject is a mapped provider applicant, monitored entity, transaction, or wallet address. The platform normalises alerts to DALP severity scores. Severe alerts revoke the claim topic when they meet the configured revocation threshold, and the provider's claim-issuer identity is the on-chain issuer of record.
Monitoring integrations require subject mapping before a provider event can affect a claim. Unmapped provider events are retained for audit but do not create an on-chain claim effect.
How provider events become enforceable claims
Provider-driven intake does not bypass compliance-module rules. ClaimSource resolves the provider event to a mapped DALP identity, checks the active provider topic, and dispatches issuance or revocation through the provider's trusted-issuer identity. Compliance modules then evaluate the resulting claim like any other trusted attestation for that topic.
Keep the paths distinct
Manual KYC issuance and provider-driven intake can coexist in one DALP environment, but they should not compete silently for the same claim topic.
Before enabling provider intake for a topic that already has manual issuance, confirm which issuer is authoritative and whether manual claims become overrides or legacy evidence. Also confirm how rejected verdicts or high-severity alerts should affect existing claims, and which team owns provider dashboard configuration and webhook replay.
See also
- Verify KYC via API for developer-led manual claim issuance.
- Onboard a compliance provider and Map compliance-provider subjects for provider integration setup.
- Verify KYC and Configure trusted issuers for operator tasks in the dashboard.
- Claims and identity for the conceptual model behind claim topics, trusted issuers, and compliance expressions.
- Compliance provider API reference for provider kinds, subject-mapping endpoints, webhook fields, integration statuses, and monitoring payloads.
- How compliance provider intake works for the provider-driven ClaimSource architecture.
Register user
Register a user's wallet and OnchainID in the identity registry via API for compliance tracking and token eligibility.
Configure trusted issuers
Add, scope, and remove trusted issuer entries in system and token registries so on-chain claim verification resolves the correct identity addresses.