# Compliance and custody split Source: https://docs.settlemint.com/docs/compliance-security/security/compliance-custody-boundary Understand how DALP separates identity and compliance decisions from custody approvals and signing policies when token operations are executed. DALP separates eligibility checks from signature release before a token operation reaches an EVM network. Compliance controls decide whether an address, claim, or transfer is allowed under the asset's rules. Custody controls decide whether the wallet, MPC provider, HSM partition, or signer backend may release a signature for the prepared transaction. During architecture review, ask: "Does DALP enforce this on-chain, or does the custody, signing, or operating policy enforce it somewhere else?" Start by identifying the requested token operation. Then check the compliance layer, platform authorization layer, and signing layer separately. ## System context [#system-context] ## Why the split matters [#why-the-split-matters] Issuers and operators often connect both compliance services and custody services to the same asset workflow. They serve different purposes: | Control area | Primary question | Enforced by | | ---------------------- | ------------------------------------------------------------ | ----------------------------------------------------------------- | | Platform authorization | Is this user or API key allowed to request the action? | DALP authentication, organization membership, and role checks | | Wallet verification | Has the user-session operator confirmed the write operation? | DALP wallet verification before browser-session blockchain writes | | Compliance eligibility | Is the identity, claim, or transfer allowed? | On-chain identity claims and token compliance modules | | Custody signing policy | Can this wallet or signing service sign this transaction? | Configured signer backend or custody service | Passing one layer does not bypass the others. A compliant investor address still needs an authorized platform action and a valid signature path. A custody approval does not create KYC claims or override on-chain transfer rules. Read the boundary this way: compliance answers whether the asset rules allow the state change. Custody answers whether the configured key-control system may sign it. Provider case files, screening alerts, custody policies, and platform roles can all be evidence for an operating programme. Those records only become on-chain enforcement when the asset is configured to use the corresponding identity claims, trusted issuers, compliance modules, token roles, or signing route. ## Boundary rules [#boundary-rules] Use these rules when reviewing a regulated asset workflow: | Verified fact | It means | It does not mean | | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------- | | A compliance provider reports an approved verdict | DALP can map the verdict to a configured identity claim or audit event when the provider, subject, and topic match | The custody provider must sign the next transaction | | A wallet has the required identity claim and passes the asset's selected modules | The on-chain eligibility gate can allow the mint or transfer to continue | The caller has platform permission, wallet verification, or custody approval | | A custody provider, MPC policy, HSM partition, or local signer releases a signature | The prepared transaction can be submitted through the active signing path | The signer has changed KYC status, issuer trust, country rules, supply caps, freezes, or transfer approvals | | A custodian-role token function freezes or forced-transfers balances | The token contract state changes on-chain and later hooks enforce that state | DALP has made a legal custody determination or replaced the operator's off-chain governance process | | An emergency-role token function pauses or unpauses an asset | The token operation path stops or resumes through the token's pausable state | The custody provider has changed key policy or investor eligibility | This distinction keeps public architecture claims narrow. The token controls in this page apply to DALP's configured EVM asset operations. Non-EVM networks are outside this boundary. DALP can enforce configured token controls on EVM assets and route signing through configured key-management infrastructure. External provider policy, legal review, reserve operations, and custody governance do not automatically become token rules. A provider or operating decision affects on-chain execution only when the asset configuration represents that decision as a claim, module, token role, or signing policy. ## Compliance controls [#compliance-controls] Compliance integrations normalize external verification outcomes into DALP compliance events. Those events update identity claims, monitoring status, or audit records without exposing vendor-specific API payloads to every downstream consumer. On-chain compliance remains the transfer gate. Token hooks and compliance modules evaluate the asset rules that apply to each operation before state changes land on the EVM network. The active asset type and configured modules determine which rules run. | Operation or rule area | On-chain control point | | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Minting and issuance | Supply-management roles call mint functions; token hooks apply identity, compliance, freeze, collateral, and supply-limit checks configured for the asset. | | Transfers and holding eligibility | Transfer hooks apply frozen-address, partial-freeze, identity, country, investor-count, allowlist, blocklist, time-lock, approval, and similar compliance modules when those modules are configured. | | Burning and redemption | Supply-management roles call burn functions; burn hooks apply custodian freeze checks before balances change. | | Collateral and reserve coverage | Stablecoin assets can require valid collateral claims or ratios before minting or transfer activity proceeds. | | Freezing and partial freezing | Custodian-role functions update frozen-address and frozen-balance state on-chain. Transfer and burn hooks enforce those states. | | Pausing | Emergency-role pause functions stop token operations through the token's pausable update path until the asset is unpaused. | | Forced transfers and wallet recovery | Custodian-role forced-transfer and recovery functions execute through the token contract and emit on-chain balance changes. | External verification verdicts can supply claim evidence, but a compliance-service verdict is not custody approval and does not replace these token rules. Use the compliance documentation when you need to understand: * how identity claims support KYC, KYB, AML, or jurisdiction checks * how token compliance modules evaluate transfer eligibility * how verification verdicts and monitoring alerts become normalized compliance events * how trusted issuers and claim topics affect on-chain identity state ## Custody controls [#custody-controls] Custody integrations protect private keys and transaction signing. DALP hands a prepared transaction to the configured signing infrastructure, which applies its own policy engine and approval flow before releasing or rejecting the signature. Custody services do not decide whether an investor has the required compliance claim. The custody service evaluates signing policy for a prepared transaction, such as approval thresholds, wallet policy rules, or custody-side transaction authorization. Use the custody documentation when you need to understand: * which signing path is used for a wallet or asset operation * whether a transaction requires a custody-side approval flow * how browser-wallet verification differs from institutional custody signing * which key-management service owns final signature release ## End-to-end control sequence [#end-to-end-control-sequence] A typical token operation crosses the split in this order: 1. DALP authenticates the user or API client and checks platform permissions. 2. DALP validates the requested operation and prepares the blockchain write. 3. DALP requires wallet verification for sensitive browser-session write operations. API-key flows use API-key authorization instead of wallet verification. 4. The token's on-chain identity and compliance modules determine whether the action is allowed. 5. The configured key service or custody service evaluates signing policy and releases or rejects the signature. 6. The signed transaction is submitted to the EVM network. This sequence is defense in depth. Compliance handles eligibility. Custody handles key protection and signature release. Platform authorization and wallet verification run first. ## Audit evidence split [#audit-evidence-split] Reviewers often need to know which system proves which decision. Use this split when you prepare operating evidence for an asset programme: | Evidence question | DALP evidence | External evidence | | ---------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | Who requested the operation? | Authenticated user, participant, API key, organization, and wallet selection on the platform request | Identity-provider or enterprise-access logs, if the operator exports them | | Did the platform require an operator confirmation? | Wallet-verification result for browser-session writes, or API-key authorization for API flows | None for DALP-managed wallet verification | | Why was the address or transfer eligible? | Identity claims, trusted issuers, claim topics, and configured token compliance modules | Compliance-provider case files, screening reports, or monitoring alerts | | Why was the transaction signed, rejected, or left pending? | DALP transaction state and signer status returned by the configured signing path | Custody, MPC, or HSM policy approvals, quorum evidence, and provider audit trails | | Which network received the signed transaction? | Transaction hash and configured EVM network | Chain explorer or node-provider records | DALP keeps the platform request, transaction state, and on-chain result connected. External providers remain the system of record for their own policy approvals, user approvals, screening case files, and hardware or MPC audit trails. ## See also [#see-also] * [Identity and compliance](/docs/compliance-security/security/identity-compliance) for identity claims, KYC and AML status, and verification lifecycle * [Compliance modules](/docs/compliance-security/security/compliance) for token-level transfer rules and restrictions * [Compliance integrations](/docs/architects/architecture/integrations/compliance-providers) for normalized verification intake and monitoring events * [Custody integrations](/docs/architects/architecture/integrations/custody-providers) for signer backend and custody responsibilities * [Authorization](/docs/compliance-security/security/authorization) for platform roles and resource-level permissions * [Wallet verification](/docs/compliance-security/security/wallet-verification) for PIN, TOTP, and backup-code checks before blockchain writes