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 claims manually through a configured trusted issuer. You can also let a compliance-provider integration issue and revoke claims through its own trusted-issuer identity.
Choose the path before you configure the claim topic. Compliance modules evaluate the resulting claim, 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 can make reviews harder and should be deliberate. If manual and provider-driven 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 then issues the claim.
This path fits when:
- the review happens inside your organisation
- your claim issuer is a staff-controlled or service-controlled issuer
- the KYC data is submitted and reviewed through DALP user/KYC flows
- provider evidence exists, but the final claim decision is made by your own compliance process
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.
This path fits when:
- a provider such as Sumsub, Jumio, Middesk, Onfido, Persona, Trulioo, or Veriff creates and reviews applicants, inquiries, or businesses
- approved provider verdicts should issue the configured claim topic
- rejected provider verdicts should revoke the configured claim topic
- 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.
This path fits when:
- Sumsub AML, Sumsub KYT, ComplyAdvantage, or Elliptic should supply monitoring events
- the subject is a mapped provider applicant, monitored entity, transaction, or wallet address
- provider alerts should be normalised to DALP severity scores
- severe alerts should revoke the configured claim topic when they meet the integration's revocation threshold
- the provider's claim-issuer identity should be the on-chain issuer of record
Monitoring integrations still 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 claim issuance or revocation through the provider's trusted-issuer identity. Compliance modules then evaluate the resulting claim like any other trusted claim 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 is already issued manually, confirm:
- which issuer should be authoritative for the topic
- whether manual claims become overrides, fallbacks, or legacy evidence
- how rejected provider verdicts or high-severity alerts should affect existing claims
- which team owns provider dashboard configuration and webhook replay requests
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.