Compliance Providers
Explanation of DALP compliance-provider intake, including ClaimSource, provider issuer EOAs, webhook verification, and the boundary between persistent claims and per-transaction decisions.
Purpose
DALP compliance providers turn events from external KYC, KYB, and wallet-monitoring systems, including Sumsub and Elliptic, into standard on-chain claims. The provider-specific API calls and webhook formats stay behind an intake layer, while the claim that affects compliance remains a normal DALP claim issued by a trusted issuer.
For setup steps, see onboard a compliance provider. For exact endpoints and fields, see compliance provider API reference.
Current coverage boundary
Current DALP compliance-provider adapters cover provider events that can be reduced to durable identity, business, or wallet claims through ClaimSource:
- Identity and KYB verdicts from configured KYC/KYB providers
- Monitoring alerts from applicant, entity, and wallet-monitoring providers
- Wallet-monitoring alerts from Elliptic
For the current default DALP integration surface, Notabene Travel Rule transfer gating is a separate per-transfer decision surface rather than a compliance-provider adapter. Chainalysis KYT is also not a current DALP compliance-provider adapter.
Provider intake model
Compliance integrations split by what the provider produces and how long the subject lives:
| Surface | Provider shape | DALP behaviour |
|---|---|---|
| A | Identity verdicts | Sumsub, Jumio, Middesk, Onfido, Persona, Trulioo, and Veriff terminal verdicts issue or remove on-chain claims for one topic |
| B | Monitoring alerts | Sumsub AML watchlist events, Sumsub applicant-on-hold events, ComplyAdvantage entity monitoring, and Elliptic wallet alerts are normalised to severity scores for claim revocation |
| C | Per-transaction Travel Rule | Outside the current dapp compliance-provider flow |
ClaimSource covers identity or wallet subjects that persist beyond one transaction. Sumsub applicant-review events produce identity verdicts, Sumsub AML watchlist events, Sumsub applicant-on-hold events, and ComplyAdvantage monitored-search events produce monitoring alerts, and Elliptic produces wallet-monitoring alerts. TransferGate is reserved for Travel Rule and similar per-transaction decisions, where the subject is one transfer rather than a durable identity or wallet.
Provider issuer trust model
Each integration provisions one tenant-scoped, DALP-custodied EOA for one provider and one claim topic. DALP registers that EOA as a trusted issuer in the tenant's trusted issuer registry for that topic.
The integration then uses the EOA to sign claims emitted by provider intake.
The on-chain attestor of a compliance-issued claim is the provider integration EOA, not DALP itself and not the tenant compliance officer. An audit can identify which integration asserted the claim, retrieve the original provider payload, and verify the trusted-issuer registration history from on-chain events.
This design keeps provider-driven claims inside DALP's existing trusted-claim primitive. There is no separate compliance-provider trust store.
Webhook intake boundary
Each integration receives one webhook URL that the tenant pastes into the provider dashboard:
/api/webhooks/compliance/<provider>/<integrationId>/<urlToken>The integration identifier scopes the URL to one tenant integration. The URL token is a non-guessable UUID generated when the tenant creates the integration. HMAC remains the primary authentication mechanism; the token limits accidental cross-integration delivery and adds a defence-in-depth layer against URL leaks.
DALP verifies each provider's webhook authentication material before processing the event. HMAC providers sign the raw request body; Jumio uses callback Basic Auth plus a configured IP allowlist. DALP records raw provider payloads for audit and extracts decision-driving fields such as subject, topic, severity, applied timestamp, and outcome for query and claim processing.
| Provider | Webhook authentication | Header or network source |
|---|---|---|
| Sumsub | HMAC over raw body | x-payload-digest, x-payload-digest-alg |
| Sumsub AML | HMAC over raw body | x-payload-digest, x-payload-digest-alg |
| ComplyAdvantage | HMAC-SHA256 digest | x-complyadvantage-signature |
| Elliptic | HMAC-SHA256 digest | x-elliptic-signature |
| Jumio | Basic Auth + IP allowlist | Authorization: Basic … and callback source IP |
| Middesk | HMAC-SHA256 over raw body | X-Middesk-Signature-256 |
| Onfido | HMAC-SHA256 over raw body | X-SHA2-Signature |
| Persona | HMAC-SHA256 over ${timestamp}.${rawBody} | Persona-Signature timestamp and hexadecimal signature values (space-separated sets accepted during key rotation) |
| Trulioo | HMAC-SHA256 over raw body | x-trulioo-signature |
| Veriff | HMAC-SHA256 over raw body | X-HMAC-SIGNATURE |
Subject mapping
Provider webhooks can only affect a DALP subject after that subject has been mapped to the integration.
- Sumsub, Jumio, Onfido, Persona, Trulioo, and Veriff applicant intake, plus Middesk business intake, map the provider subject to a DALP identity address.
- ComplyAdvantage search intake maps a monitored person or company search to its DALP identity.
- Elliptic wallet intake maps the monitored wallet to its DALP identity.
If a webhook arrives for an unmapped subject, DALP records the event for audit but does not produce an on-chain claim effect. Map the subject before provider delivery; the same delivered provider event is not replayed automatically after mapping.
Why the two intake models stay separate
ClaimSource works with durable subjects: identities and wallets. It receives background provider events and emits standard on-chain claim issue or revoke transactions.
TransferGate would work with one transfer at transfer-initiation time. That is a different subject, timing model, and output. Combining both models would make the persistent-claim path harder to reason about and would expose per-transaction decisions inside an event-driven claim model.
This boundary keeps the model clear. Current DALP compliance-provider integrations support these event families through ClaimSource:
- Sumsub identity verdicts
- Sumsub AML watchlist monitoring alerts for existing applicants
- Sumsub applicant-on-hold monitoring alerts
- ComplyAdvantage entity monitoring alerts
- Elliptic wallet monitoring
- Jumio identity verdicts
- Middesk KYB verdicts, attested to
knowYourCustomeras DALP's current KYB umbrella topic - Onfido Workflow Studio and classic API identity verdicts, attested to
knowYourCustomer - Persona inquiry verdicts, attested to
knowYourCustomer - Trulioo DataVerify identity and business verdicts, attested to
knowYourCustomer - Veriff hosted identity-verification verdicts, attested to
knowYourCustomer
For the current default DALP integration surface, Notabene Travel Rule transfer gating remains a separate per-transfer surface rather than a compliance-provider adapter.
A deployment that needs Travel Rule gating should integrate a per-transfer adapter instead of folding that decision into ClaimSource. Chainalysis KYT is also not a current DALP compliance-provider adapter.
See also
Custody Providers
Architecture overview of DALP's custody provider integrations covering browser-wallet verification boundaries, DFNS and Fireblocks MPC signing, Luna HSM partition signing, policy engines, configuration requirements, and the unified signer boundary that keeps DALP signing workflows consistent while provider-specific approval and wallet behavior stays behind the adapter.
Supported Networks
Reference for blockchain networks supported by the DALP platform, covering EVM-compatible Layer 1 mainnets, Layer 2 rollups, testnets, and private consortium networks with their configuration differences.