# Compliance overview
Source: https://docs.settlemint.com/docs/operators/compliance/overview
Understand how DALP enforces tokenized asset compliance controls across identity,
eligibility, transfer approvals, supply limits, capital raise limits, issuance volume,
collateral checks, and trusted verification issuers.
DALP turns a regulated asset policy into enforceable controls by combining asset-level compliance modules, reusable policy templates, trusted verification issuers, and on-chain claims. Asset issuers configure the controls an asset must enforce. Identity Managers review participant evidence. Trusted issuers add on-chain verification claims. Transfers, minting, and holder eligibility pass only when the configured controls approve the action.
Start here when you need to decide which compliance control to use, who operates it, and which task guide to open next. The fastest path is policy need → template or module → trusted issuer and claim setup → asset operation → audit record.
## What are tokenized asset compliance controls? [#what-are-tokenized-asset-compliance-controls]
Tokenized asset compliance controls sit between participant onboarding and asset activity. DALP enforces policy conditions that the platform can verify on-chain or through configured verification claims. Your organisation still owns the legal policy, KYC provider, custody provider, approval process, and off-chain evidence process.
## Quickstart [#quickstart]
Use this sequence when you prepare a regulated asset:
1. Decide the policy requirement for the asset, such as KYC eligibility, country restrictions, transfer approval, holder caps, token-supply caps, capital-raise limits, issuance-volume quotas, or collateral backing.
2. Match that requirement to the [compliance module index](/docs/compliance-security/compliance) so you know whether the control runs at holder, transfer, minting, or lifecycle-accounting time.
3. Select a [policy template](/docs/operators/compliance/templates) or configure individual modules during [asset creation](/docs/operators/asset-creation/create-asset).
4. Configure the trusted issuers that can issue the verification topics your controls require.
5. Review participant or asset evidence off-chain where required, then issue the matching on-chain verification claim.
6. Operate the asset. DALP checks every configured module for the relevant action.
## Who owns what [#who-owns-what]
| Area | Owner in DALP | What DALP enforces | What stays with your organisation |
| -------------------- | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| Compliance policy | Asset issuer or governance role | The selected modules, thresholds, lists, approval authority, and template copied into the asset configuration. | The legal policy, regulatory interpretation, approval procedure, and decision to change controls. |
| Participant evidence | Identity Manager | KYC submission status, review actions, and the path to issuing an on-chain verification after approval. | Evidence collection standards, document validation, data protection duties, and escalation process. |
| Verification trust | Verification Policy Manager or platform administrator | Which issuer identities are trusted for each verification topic at system or inherited registry level. | Issuer selection, independence checks, and periodic review of issuer authority. |
| Verification claims | Trusted issuer | On-chain claims for topics such as KYC, accreditation, AML, or collateral when the issuer is trusted for that topic. | Source evidence, renewal cadence, revocation decisions, and external provider monitoring. |
| Asset activity | Compliance modules | Whether a mint, transfer, or holder eligibility check passes all configured controls. | Business decisions after a blocked action, customer communication, and off-chain remediation. |
| Signing and custody | Configured signer path | The platform prepares and tracks the controlled action before it is signed through the configured route. | Custody-provider policy, quorum design, key recovery, and custodian-side evidence. |
## Choose a compliance control [#choose-a-compliance-control]
Start from the rule you need to enforce, then choose the DALP control that matches that rule. Use a compliance template when the same policy pattern should be reused across assets. Use individual modules when one asset needs a specific control.
| Policy need | DALP control | Where to configure it | Read next |
| ---------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| Require holders to pass KYC, accreditation, or another OnchainID claim | [Identity verification](/docs/operators/compliance/identity-verification) | Add the module directly or include it in a [compliance template](/docs/operators/compliance/templates). | [Identity verification architecture](/docs/compliance-security/compliance/identity-verification) |
| Allow or block specific identities or addresses | [Identity lists](/docs/compliance-security/compliance/identity-lists) or [address block list](/docs/compliance-security/compliance/address-block-list) | Configure the list during asset creation or update it later with the asset governance role. | [Compliance module index](/docs/compliance-security/compliance) |
| Restrict holders by country | [Country restrictions](/docs/operators/compliance/country) | Select allowed or blocked countries in the compliance step. | [Country restrictions architecture](/docs/compliance-security/compliance/country) |
| Limit lifetime or periodic token supply | [Supply and investor limits](/docs/compliance-security/compliance/supply-investor-limits) | Configure the numeric supply limit before the asset is used by holders. | [Create asset](/docs/operators/asset-creation/create-asset) |
| Limit the number of holders | [Investor count](/docs/operators/compliance/investor-count) | Configure the holder cap before distribution starts. | [Supply and investor limits architecture](/docs/compliance-security/compliance/supply-investor-limits) |
| Cap gross fiat value raised through minting | [Capital raise limit](/docs/operators/compliance/capital-raise-limit) | Configure the fiat-denominated cap and price-resolution path before minting. | [Capital Raise Limit architecture](/docs/compliance-security/compliance/capital-raise-limit) |
| Cap token units issued during a fixed or rolling period | [Issuance volume limit](/docs/operators/compliance/issuance-volume-limit) | Configure the token-unit issuance quota and window before the asset starts issuing. | [Issuance volume limit](/docs/operators/compliance/issuance-volume-limit) |
| Enforce a holding period before transfers | [Time lock](/docs/operators/compliance/timelock) | Configure the hold period and any identity-based exemptions for the asset. | [Time lock architecture](/docs/compliance-security/compliance/timelock) |
| Require transfer review before execution | [Transfer approval](/docs/compliance-security/compliance/transfer-approval) | Configure the approval authority and approval conditions for the asset. | [Transfer approval architecture](/docs/compliance-security/compliance/transfer-approval) |
| Require collateral evidence before minting | [Supply cap and collateral](/docs/compliance-security/compliance/supply-cap-collateral) or [collateral requirement](/docs/operators/compliance/collateral) | Configure collateral controls for assets that need backing evidence. | [Collateral requirement](/docs/operators/compliance/collateral) |
If your workflow depends on a third-party KYC, KYB, AML, sanctions, or travel-rule provider, use provider-issued claims alongside these controls. The on-chain compliance module enforces the claim or policy condition. The provider integration supplies the external screening or monitoring signal. See [compliance provider integrations](/docs/architects/integrations/compliance-providers).
## Connect KYC and AML decisions to claims [#connect-kyc-and-aml-decisions-to-claims]
DALP can accept KYC, KYB, AML, and wallet-monitoring decisions through two issuance paths. Both paths end in the same enforcement model: a trusted issuer adds or revokes an on-chain claim for a topic that an asset compliance module requires.
| Issuance path | When to use it | Who or what issues the claim | Read next |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| Provider-driven | Use this for supported providers that send webhook verdicts or monitoring alerts for mapped people, organisations, or wallets. Supported provider topics are listed in the compliance-provider architecture page; a provider can only issue the topics its adapter publishes. | The provider's DALP claim-issuer identity issues or revokes the claim after DALP verifies the signed provider event. | [Compliance provider integrations](/docs/architects/integrations/compliance-providers) |
| Manual trusted-issuer | Use this when your compliance team, outsourced reviewer, or custom provider workflow has completed review outside the supported provider webhook flow and an authorised issuer needs to attest the result in DALP. | A user or organisation identity that is trusted for the selected topic issues the claim through DALP. | [Verify KYC](/docs/operators/compliance/verify-kyc) |
Use the provider-driven path for provider-backed KYC, KYB, AML, and wallet-monitoring workflows:
1. Choose a supported provider product and one of the verification topics it can attest, such as `knowYourCustomer`, `knowYourBusiness`, or `antiMoneyLaundering`.
2. [Onboard the compliance provider](/docs/developers/compliance/onboarding-a-provider) so DALP provisions the provider as a trusted claim-issuer identity for the selected topic.
3. Map the provider subject to the DALP identity before webhooks arrive. Hosted applicant checks, entity monitoring, wallet monitoring, and KYT transactions use different subject-mapping paths.
4. Let the provider send signed webhook events. Approved verdicts issue claims. Rejected verdicts or high-severity monitoring alerts can revoke claims for the configured topic.
5. Configure the asset compliance module to require that topic. A mint, transfer, or holder check passes only when the identity has a current claim from an issuer trusted for the required topic.
Use the manual path when the decision comes from your own review process or from a custom provider flow that DALP does not receive as a supported webhook event. The issuer still needs to be trusted for the topic before its claim can satisfy compliance. Keep the source review and evidence in your compliance system, then issue or revoke the matching claim in DALP.
| Signal or record | Where it stays | What DALP uses for enforcement |
| ------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| Identity documents, screening reports, reviewer rationale, provider raw evidence, and retention records | Off-chain in your provider, case-management, or compliance evidence process. | Not used directly by the compliance module. Keep these records available for audit, remediation, and provider escalation. |
| Provider verdicts, monitoring status, subject mapping, claim topic, issuer identity, and claim state | DALP claim and audit workflow. | DALP records the result against the mapped identity or wallet and issues or revokes the configured topic claim. |
| Topic, issuer identity, signature, claim data, and claim state | On-chain claim and trusted-issuer checks. | Asset compliance modules check whether the identity has a current claim from an issuer trusted for the required topic. |
| Provider signal | Typical DALP topic | Enforcement effect |
| -------------------------------- | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| KYC applicant approval | `knowYourCustomer` | The identity can satisfy KYC-based holder or transfer checks when the provider issuer is trusted for that topic. |
| KYB business approval | `knowYourBusiness` | The organisation identity can satisfy business-verification controls that require KYB evidence. |
| AML or sanctions monitoring | `antiMoneyLaundering` | The identity or wallet can satisfy AML checks until a rejected verdict or configured severity threshold revokes the claim. |
| Transaction or wallet monitoring | `knowYourTransaction` or `antiMoneyLaundering` | DALP records the provider signal against the mapped identity or wallet and applies the configured topic policy. |
Keep sensitive provider evidence and documents off-chain. DALP uses the result, topic, issuer identity, claim state, and audit trail to enforce configured controls. Your organisation remains responsible for provider selection, custom connector operation, legal interpretation, evidence retention, escalation, and remediation after a provider flags risk.
## How modules work together [#how-modules-work-together]
When multiple compliance modules are enabled, every enabled module must pass for the action to proceed. A transfer that satisfies KYC but fails a country restriction is blocked. A mint that satisfies role checks but lacks enough collateral evidence is blocked. A transfer approval requirement stays separate from KYC or collateral claims, so the asset can require both prior approval and verified holder eligibility.
Compliance modules can validate different parts of the lifecycle. Burns are role-gated asset operations; compliance modules may update accounting after a burn, but they are not the approval path that blocks the burn.
| Control family | Typical check point | Example result |
| ----------------------------- | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Identity and country controls | Holder eligibility and transfers | Recipient must have a trusted KYC claim and an allowed country claim. |
| Lists and address controls | Sender or recipient checks | A blocked address or identity cannot participate while the control applies. |
| Supply caps | Minting | A mint stops when the configured token-supply cap would be exceeded. |
| Capital raise limits | Minting | A mint stops when the configured fiat-denominated gross capital-raise window would be exceeded. |
| Issuance volume limits | Minting and lifecycle accounting | A mint stops when the configured token-unit issuance quota would be exceeded for the fixed or rolling window; burns can release capacity according to the module rules. |
| Investor-count controls | Holder-count checks | A transfer to a new holder stops when it would exceed the configured investor-count limit. |
| Transfer approval | Transfer execution | The transfer must have the required approval before it executes. |
| Collateral controls | Minting | The asset identity must have a valid collateral verification with enough backing for the post-mint supply. |
## Verification system [#verification-system]
Verifications are on-chain attestations that confirm facts about investors, issuers, assets, or contracts. A verification only satisfies compliance when the issuer is trusted for the relevant topic.
Each verification contains:
* **Topic:** what is being verified, such as KYC, accreditation, AML, or collateral.
* **Scheme:** the signature scheme used for the claim.
* **Issuer:** the identity that issued the verification.
* **Signature:** the cryptographic signature for the verification.
* **Data:** verification details, often represented in a privacy-preserving form.
* **URI:** an optional reference to supporting data.
Verifications do not have expiration dates by default. If a topic needs renewal, revocation, or expiry handling, define that in your operating process and issue or revoke claims accordingly. Collateral verifications are an example of a workflow where expiry matters because minting depends on current backing evidence.
## Trusted issuers [#trusted-issuers]
Any identity with an on-chain presence can technically issue a verification. DALP compliance controls only count the verification when the issuer is trusted for the required topic.
Trust is organisation-specific and topic-specific:
* One issuer can be trusted for KYC but not for collateral.
* One organisation can trust an issuer that another organisation does not trust.
* System-level trust entries can inherit from a parent global registry when configured.
* Removing a system-managed trusted issuer stops that system trust entry from satisfying checks, while inherited global trust can still apply until changed in the parent registry.
Use [Configure trusted issuers](/docs/operators/compliance/configure-trusted-issuers) to manage the issuers and topics your assets rely on.
## Verification topics [#verification-topics]
Common topics include investor eligibility, asset evidence, issuer status, and contract identity. The exact topics your organisation uses should match the policy controls configured on each asset.
| Topic area | Examples | Used for |
| --------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------- |
| Investor-level topics | KYC, AML, accredited investor, professional investor, Regulation S | Holder eligibility and transfer checks. |
| Asset-level topics | Collateral, classification, unique identifier, issuer, location | Asset evidence, backing checks, and reporting controls. |
| Price feed topic | `price` feed topic through the active PriceResolver | Price-sensitive mint controls and token-price reads. |
| Issuer-level topics | Prospectus filed, prospectus exempt, licensed, reporting compliant, jurisdiction | Issuer qualification and review evidence. |
| Contract topics | Contract identity | Contract-level identity verification. |
Treat asset evidence topics and price feeds as separate setup work. Collateral or classification evidence is issued as a verification claim by a trusted issuer. Use an asset-level base-price claim only for controls that explicitly require that claim path. PriceResolver-backed controls read current valuation data from feeds published under the standard `price` topic. Configure those feeds through the data-feeds flow, and trust the publishing issuer for the feed topic before publishing updates. Put currency or pair context in the feed description rather than creating a separate verification topic for each price label.
When none of the built-in topics describe a claim your policy needs, [add a custom verification topic](/docs/operators/compliance/verification-topics) before you assign trusted issuers to that topic.
## Production checklist [#production-checklist]
Before holders use the asset, confirm that:
* The asset uses the policy template or individual modules that match the policy.
* Governance roles can update lists, thresholds, approval authorities, and module settings when policy changes.
* Trusted issuers are configured for every verification topic the asset requires.
* Identity Managers know which evidence to review before a trusted issuer adds a claim.
* Provider-issued screening or monitoring signals map to the verification topics your controls enforce.
* Collateral-backed assets have a renewal, revocation, and evidence review process for collateral verifications.
* Assets with price-sensitive mint controls have the PriceResolver addon installed and an active `price` feed that satisfies the resolver freshness policy.
* Your operations team knows how to respond when a configured module blocks a mint, transfer, or holder check.
## Where to go from here [#where-to-go-from-here]
Use the compliance docs in three layers:
| Need | Start here | Why it matters |
| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| Design the asset policy and enforcement model | [Compliance module index](/docs/compliance-security/compliance) and [asset policy concept](/docs/architecture/concepts/asset-policy) | These architecture pages explain what each control checks and how claim, issuer, module, and token policy state fit together. |
| Create a new asset with the selected controls | [Create an asset with the Asset Designer](/docs/operators/asset-creation/create-asset) | The Asset Designer is where operators select a policy template, add individual compliance modules, and review required controls before deployment. |
| Configure or operate one control after the policy is chosen | The operator task guides below | These guides show the steps and checks for country rules, identity verification, caps, approvals, collateral, and other modules. |
## Operator task guides for module configuration [#operator-task-guides-for-module-configuration]
Use these task guides when the policy decision is already made and an operator needs to configure the module on an asset. The architecture pages explain the control model; the Asset Designer guide shows where controls are selected during asset creation; these pages show the operating steps and checks.
| Policy control | Operator guide | Use it when |
| ------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| Country eligibility | [Country restrictions](/docs/operators/compliance/country) | The asset needs a country allow-list, block-list, or both. |
| Holder verification | [Identity verification](/docs/operators/compliance/identity-verification) | The asset requires a trusted verification claim before holders can transact. |
| Holder cap | [Investor count](/docs/operators/compliance/investor-count) | The asset must limit how many identities can hold the token. |
| Holding period | [Time lock](/docs/operators/compliance/timelock) | Transfers must wait until the configured holding period has elapsed. |
| Address block list | [Address block list](/docs/operators/compliance/address-block-list) | A specific wallet address must be blocked from participating in asset actions. |
| Transfer approval | [Transfer approval](/docs/operators/compliance/transfer-approval) | A transfer must be approved before it can execute. |
| Token supply limit | [Token supply limit](/docs/operators/compliance/token-supply-limit) | Minting must stop once total supply reaches a fixed cap. |
| Capital raise limit | [Capital raise limit](/docs/operators/compliance/capital-raise-limit) | Minting must stay within a fiat-denominated gross fundraising cap. |
| Issuance volume limit | [Issuance volume limit](/docs/operators/compliance/issuance-volume-limit) | Minting must stay within a fixed or rolling issuance window. |
| Collateral-backed minting | [Collateral requirement](/docs/operators/compliance/collateral) | Minting depends on current backing evidence from a trusted issuer. |
## Related guides [#related-guides]
* [Policy templates](/docs/operators/compliance/templates) explains how to group modules into reusable policy patterns.
* [Add a verification topic](/docs/operators/compliance/verification-topics) explains how to define a custom topic when no built-in topic matches the claim you need.
* [Configure trusted issuers](/docs/operators/compliance/configure-trusted-issuers) explains how to trust issuer identities for specific verification topics.
* [Manage KYC data](/docs/operators/compliance/manage-kyc-data) explains how Identity Managers review participant submissions before verification.
* [Verify KYC](/docs/operators/compliance/verify-kyc) explains how a trusted issuer adds a KYC verification.
* [Map compliance-provider subjects](/docs/developers/compliance/compliance-provider-subjects) explains how provider applicants, searches, wallets, and transactions attach to DALP identities before provider events affect claims.
* [Collateral requirement](/docs/operators/compliance/collateral) explains how collateral verification blocks or allows minting.
* [Events catalogue](/docs/api-reference/tokens/token-events) lists the public event pages used to inspect lifecycle outcomes and audit-relevant state changes.
* [Signing flow](/docs/architects/flows/signing-flow) explains how DALP separates platform requests from signing and execution responsibilities.
* [Compliance module index](/docs/compliance-security/compliance) lists the available module-level architecture pages.