# Compliance & security
Source: https://docs.settlemint.com/docs/executive-overview/compliance-security
DALP embeds regulatory controls into transaction execution so regulated asset programmes can enforce eligibility, identity, and transfer rules before state changes settle.
## Key terms [#key-terms]
* **[ERC-3643](/docs/executive-overview/glossary#erc-3643)** – Token standard
embedding compliance checks in transfer execution
* **[OnchainID](/docs/executive-overview/glossary#onchainid)** – Decentralized
identity protocol for portable investor credentials
* **[HSM](/docs/executive-overview/glossary#hsm)** – Hardware Security Module
providing tamper-resistant key storage
* **[Multi-signature](/docs/executive-overview/glossary#multi-signature-wallet)**
– Wallet requiring multiple approvals for transactions
## Why institutions need compliance-first architecture [#why-institutions-need-compliance-first-architecture]
Compliance must be foundational, not an afterthought. Traditional securities
have compliance processes that evolved over decades through painful, costly
failures.
Transfer agents verify eligibility before updating ownership records because
regulators mandated it after investors lost money. Custodians enforce security
controls before releasing assets because someone once walked away with millions.
Risk committees approve platforms that demonstrate control, auditability, and
regulatory alignment from day one, not platforms promising to "add compliance
later."
DALP was architected with this reality as the foundational requirement.
Blockchain technology improves traditional processes only when the platform
implements enforceable controls. For regulated assets, the important questions
are practical: can the operator trace decisions, verify identity checks, and
show that transfer rules were evaluated before settlement? DALP treats those
controls as embedded infrastructure rather than optional application logic.
## Regulatory compliance by design [#regulatory-compliance-by-design]
### Compliance happens in the transfer path, not after it [#compliance-happens-in-the-transfer-path-not-after-it]
Every token transfer in DALP executes through compliance checks before any state
changes occur. This isn't a best practice recommendation you can skip under
deadline pressure. It is how the ERC-3643 standard works at the protocol level.
When Alice tries to transfer bond tokens to Bob, the transaction either
completes fully or reverts completely. There's no partial transfer, no "pending
compliance review," no cleanup operation to reverse an improper transaction.
The smart contract verifies whether Alice's wallet links to a verified identity,
whether Bob's wallet links to a verified identity, and whether Bob meets the
specific eligibility requirements for this asset: accreditation status,
jurisdiction restrictions, or institutional qualifications. The system checks
whether the transfer violates holding limits, lockup periods, or concentration
rules that prevent a single investor from dominating ownership. Finally, the
contract confirms no asset-wide restrictions are currently in force, such as
trading halts or emergency freezes imposed by compliance officers.
If any check fails, the transfer reverts immediately. The blockchain state
doesn't change, so there is no "undo" process for the failed transfer, and the
transaction emits a reason code explaining which rule prevented execution. This
ex-ante control gives operators an auditable record of the rule evaluation
before settlement.
### Identity registry and portable credentials eliminate repetitive verification [#identity-registry-and-portable-credentials-eliminate-repetitive-verification]
Investors verify identity once. DALP implements reusable digital identity that
works across all assets an investor is eligible to hold. When an
investor completes KYC/AML verification for one bond offering, that verification
credential carries forward automatically to other investments on the platform.
Investors don't waste time repeating identity checks; their digital identity
accumulates verified credentials from trusted verifiers that travel with them.
Identity credentials are attestations about investor status signed by trusted
verifiers like KYC providers, legal counsel, or regulatory custodians. These
credentials might prove someone completed KYC verification to Level 2 standards
on a specific date, confirm an entity qualifies as an accredited investor under
Regulation D, attest an individual resides in a permitted jurisdiction, or
verify an institution meets qualified institutional buyer thresholds.
Credentials are revocable if circumstances change, such as sanctions list
additions, and have expiration dates requiring periodic renewal, like annual
accreditation refresh requirements.
The Identity Registry maintains the authoritative list of verified investors.
Only registered, verified identities can hold compliant assets; unknown wallet
addresses are rejected before a transfer can succeed. This architecture keeps
identity checks in the transfer path without publishing investor identity files
on-chain. Claims and proofs needed for token eligibility are available to the
contracts, while detailed personally identifiable information remains with the
trusted verifier or the deployment's off-chain systems.
DALP uses the OnchainID protocol for decentralized identity credentials. See [Identity & Compliance
Architecture](/docs/architecture/security/identity-compliance) for technical implementation details on claim
structures, verification flows, and privacy-preserving designs.
### Jurisdictional rule templates standardize rule configuration [#jurisdictional-rule-templates-standardize-rule-configuration]
Different jurisdictions have fundamentally different rules that you can't
ignore. US Regulation D requires accredited investors for private placements
with specific income and net worth thresholds. EU MiFID II has its own investor
classification schemes that don't map cleanly to US definitions. Singapore MAS
imposes fit-and-proper requirements under distinct regulatory frameworks. When
regulations change, platforms need a controlled way to update the policies they
apply to tokenized assets.
DALP's Compliance Engine represents jurisdictional requirements as configurable
rule modules that compliance officers activate for specific assets. The Rule
Library provides jurisdictional templates as reusable starting points for common
controls, while the editable live unit is the per-token or per-asset module
parameters applied to an asset.
Configurable compliance modules can enforce geographic restrictions through
country whitelists or blacklists, investor limits capping the maximum number of
holders or concentration per holder, transfer restrictions implementing lock-up
periods and vesting schedules, holding requirements preventing transfers before
minimum holding periods expire, and trading venue restrictions limiting
transfers to approved exchanges. Treat rule changes for live assets as governed
operational changes: updating a template does not mutate existing asset policy
state, so teams review affected assets, explicitly re-apply or adjust the
asset's module parameters, and verify the resulting transfer behavior before
relying on the updated controls.
### Audit trails provide regulatory examination evidence [#audit-trails-provide-regulatory-examination-evidence]
DALP generates the evidence trail that regulators require during examination.
The platform creates immutable audit records for every
compliance decision with the information regulators actually request during
investigations. Each record captures the transaction ID identifying which
transfer or operation was evaluated, the precise timestamp with block number
showing exactly when the check occurred, the parties involved identifying who
initiated the transaction and who the counterparty was, and which OnchainID
claims were evaluated to verify identity and eligibility.
The system records which compliance modules were checked and their results,
whether the outcome allowed or denied the transaction with specific reason
codes, and any administrator actions if manual overrides occurred, documenting
who approved the override and their documented justification. Regulators
reviewing your compliance program can query these records programmatically and
export machine-readable reports showing every transaction attempt, every
eligibility check, and every compliance decision over any requested time period.
This isn't compliance theater where you produce documents after regulators ask
uncomfortable questions. This is the evidence base that survives regulatory
examination because it's cryptographically tamper-proof, automatically generated
without human intervention, and complete from day one of operations. Your
observability dashboards provide real-time visibility into compliance
metrics such as transaction approval rates, common rejection reasons, and identity
verification throughput so you spot patterns before they become regulatory
problems.
## Identity verification and KYC/AML integration [#identity-verification-and-kycaml-integration]
### How investor onboarding works [#how-investor-onboarding-works]
DALP integrates with professional KYC/AML providers who specialize in identity
verification, sanctions screening, politically exposed person (PEP) checks, and
adverse media monitoring. You're not building verification infrastructure from
scratch or trusting unverified self-attestations that regulators reject. The
platform routes verification to specialists with established regulatory
relationships and proven track records.
Investors visit your white-labeled onboarding portal branded to your
organization and provide personal information along with required documentation
like passports and proof of address. The platform routes verification requests
to integrated KYC providers who perform identity verification, sanctions checks,
and PEP screening with results returning to your platform including risk scoring
and attestations. Your compliance officer reviews results and either approves or
rejects the application based on your risk policies. Approved investors receive
identity claims added to their OnchainID and their wallet address gets
registered in the Identity Registry, granting them access to interact with
compliant assets.
### Wallet binding prevents post-onboarding address substitution [#wallet-binding-prevents-post-onboarding-address-substitution]
That registration is the wallet-binding control. A verified investor cannot
receive or transfer compliant tokens by substituting an unverified wallet address
in an application field after onboarding. Token transfers check the Identity
Registry and the active compliance modules before balances move, so an unknown
or unregistered address fails the transfer path instead of becoming a new holder.
If an investor loses access to a registered wallet, an identity manager uses the
identity recovery flow rather than editing the registered address in place. The
flow is scoped to the operator's active organization, verifies that the target
wallet belongs to the participant being recovered, and requires the recovery
permission before execution. User-session execution also requires administrator
wallet verification; API-key execution authenticates through the API key session
instead. The workflow creates replacement wallets and a new OnchainID, marks the
previous wallet as lost, and attempts token recovery for recoverable affected
wallet balances. KYC claims do not migrate automatically to the new identity.
Trusted issuers or configured compliance providers must issue fresh claims before
the replacement wallet can satisfy the same eligibility rules.
DALP does not treat wallet replacement as a silent self-service address change.
Any deployment that requires dual authorization, a cooling-off period, or fresh
sanctions and AML screening before a replacement takes effect should enforce
those steps in its operational approval and issuer/provider workflow before
running recovery or reissuing claims.
For institutional investors, the process extends to corporate KYC/KYB
verification including beneficial ownership verification, entity structure
documentation, authorized signer verification, and institutional due diligence
questionnaires. The framework handles both individual and institutional
onboarding through the same architectural pattern with different verification
requirements.
### Ongoing monitoring maintains claim accuracy [#ongoing-monitoring-maintains-claim-accuracy]
Identity verification isn't one-and-done because investor circumstances change
over time. DALP supports periodic reverification requirements, continuous
monitoring for adverse events like sanctions list additions, and claim
expiration requiring renewal to ensure credentials remain current. If a KYC
provider flags an investor due to sanctions list addition or criminal
proceedings, their claims get revoked automatically and immediately.
Revoked claims don't confiscate tokens or seize assets. Investors retain
ownership of their holdings. However, they cannot transfer tokens until the
compliance issue is resolved and their identity is re-verified. This is exactly
how regulated securities should behave when investor eligibility changes.
Accreditation claims have expiration dates because a verified accredited
investor from 2022 might not qualify in 2025 due to changed financial
circumstances. The platform enforces claim freshness requirements and prompts
reverification when credentials near expiration, preventing expired credentials
from enabling improper transfers.
### Privacy and data protection balance transparency with protection [#privacy-and-data-protection-balance-transparency-with-protection]
Privacy regulations constrain how identity information is handled, while
regulated assets still need identity and eligibility checks. DALP separates
on-chain eligibility claims from off-chain identity documents so token contracts
can verify required claims without exposing the underlying personal data on a
public ledger. Detailed identity documents stay in the deployment's identity or
verification systems, protected by the access controls and retention policies
that the operator configures.
On-chain transaction history remains part of the ledger. Off-chain personal data
can be managed through the deployment's data-retention, access-control, and
data-residency processes. Legal teams should map those controls to the privacy
obligations that apply to the asset programme and jurisdiction.
## Security architecture and threat mitigation [#security-architecture-and-threat-mitigation]
### Multi-signature governance eliminates single points of failure [#multi-signature-governance-eliminates-single-points-of-failure]
DALP assumes individual credentials will eventually be compromised through
phishing, social engineering, device theft, or insider threats. Security is
layered so that no single person can cause catastrophic loss even if their
credentials are fully compromised. Multi-signature treasury controls require
M-of-N approval for sensitive operations, ensuring multiple independent parties
must coordinate for any high-risk action.
Token minting or burning requires 2-of-3 administrator approval so no single
admin can inflate supply or destroy value unilaterally. Large transfers require
3-of-5 treasury approval with thresholds set based on your risk tolerance.
Emergency freeze operations require 2-of-2 executive approval ensuring both
operational and compliance leadership agree before halting trading. Smart
contract upgrades require 3-of-5 governance approval preventing a single
compromised account from deploying malicious contract logic.
Role-based access control separates platform access, system roles, asset roles,
and system module permissions. The model lets operators give each team only the
rights it needs: administrators manage organisation access, identity managers
maintain identity records and recovery, compliance managers configure policy
controls, token managers deploy assets, and auditors inspect operational and
security-sensitive surfaces without operator rights. For the full role model,
see [Authorization](/docs/architecture/security/authorization).
### Institutional custody controls protect high-value keys [#institutional-custody-controls-protect-high-value-keys]
Private keys controlling substantial value require protection meeting the same
standards banks apply to cryptographic material. DALP supports custody-aware
signing routes that delegate transaction signing and broadcasting to configured
providers instead of concentrating control in a single application hot wallet.
Fireblocks and DFNS integrations can handle provider-native signing,
broadcasting, nonce management, and approval polling. When a provider policy
requires approval, DALP keeps the transaction in its tracked workflow while the
provider-side approval completes or is rejected.
Custody integrations help address the primary digital asset risk, private key
theft or loss, by keeping signing inside provider-managed controls and approval
policies. This addresses the single biggest objection risk committees raise when
evaluating blockchain platforms: "How do we protect the keys?"
See [Security Architecture](/docs/architecture/security) for the broader security model, authentication controls, and
compliance architecture.
### Network security and monitoring detect attacks before damage occurs [#network-security-and-monitoring-detect-attacks-before-damage-occurs]
Production security hardening includes TLS encryption for all API communications
using modern cipher suites that prevent man-in-the-middle attacks. Default API
authentication uses session and scoped API-key controls; deployments that install
OAuth 2.0/OIDC plugins can add enterprise identity federation, but those plugins
are not active by default. Rate limiting prevents abuse and denial-of-service
attacks by throttling suspicious traffic patterns. IP allowlisting restricts
administrative operations to known networks, preventing remote attacks even with
stolen credentials. DDoS protection through Cloudflare or equivalent edge
networks absorbs attack traffic before it reaches your infrastructure. Web
application firewalls protect against common vulnerabilities like SQL injection
and cross-site scripting. Secrets management via HashiCorp Vault or cloud
provider secret stores prevents credentials from appearing in code or
configuration files.
DALP gives operators product evidence for incident investigation. Global
administrator routes emit structured audit events for successful and denied
administrator calls, including the user ID, route, timestamp, outcome, and
denial reason. Session-security routes let an authorised security operator
delete one browser session or all sessions for a user. Asset pause controls let
an operator with the asset Emergency role submit a wallet-verified pause
transaction that pauses token transfers for that asset.
Deployment monitoring, SIEM routing, on-call coverage, tabletop exercises, and
formal incident-history disclosures are operator controls. They depend on the
hosting model, contracted SLA, monitoring stack, and the operator's own incident
register. DALP can supply the platform control points and event evidence for an
investigation, but it does not turn the public product documentation into a
universal incident register for every deployment.
### Cybersecurity incident evidence boundaries [#cybersecurity-incident-evidence-boundaries]
Security questionnaires often ask whether the tokenization platform has had
unauthorised smart-contract interactions, erroneous minting or burning, signing
key compromise, registry tampering, long platform outages, or regulatory
notifications. Answer those questions from the deployment evidence pack, not from
a generic product claim.
| Incident question | DALP evidence to review | Product boundary |
| -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| Unauthorised administrator access | Global administrator audit events for allowed and denied calls, plus account-session records | Audit events show platform route outcomes. The deployment's SIEM and identity provider show the full security timeline. |
| Compromised browser session | Remaining DALP session state after revocation, affected-user account records, and identity-provider or access logs | DALP deletes the targeted browser session rows. External identity-provider sessions and forensic logs remain under the operator's identity stack. |
| Erroneous or fraudulent minting, burning, or transfer activity | Token event history, transaction queue records, asset role assignments, and pause-state changes | DALP records the requested and indexed asset activity. The operator must classify whether the activity was authorised under its policy. |
| Signing key or claim-signer compromise | Custody-provider logs, DALP signer configuration, claim-signer key-rotation evidence, and issuer identity state | DALP supports rotation paths and custody-aware signing routes. Custody compromise analysis depends on the selected signer backend. |
| Registry tampering or identity abuse | Trusted issuer, claim, identity, and role-change records for the affected asset or participant | DALP exposes the identity and claim state needed for review. Legal impact and notification duties stay with the operator. |
| Availability incident over the disclosure threshold | Deployment monitoring, uptime records, transaction queue depth, and recovery logs | Availability and incident-response commitments follow the selected deployment architecture and SLA. |
Use this boundary when preparing auditor or procurement evidence. Public DALP
docs describe platform controls. The deployment evidence pack discloses the
actual incident history, investigation timeline, customer notifications, and
regulatory correspondence for the environment under review.
### Operational security and recovery procedures handle inevitable failures [#operational-security-and-recovery-procedures-handle-inevitable-failures]
Production incidents need product controls and operator procedures. DALP covers
the product-side controls: session revocation, role-gated asset pauses,
custody-aware signing routes, claim-signer key rotation, global administrator
audit events, and high-availability deployment patterns. The operator owns the
incident commander, notification process, regulatory disclosure decision, and
evidence retention policy for the environment.
For key compromise, contain the affected signing path before resuming normal
activity. Depending on the key type, that can mean pausing affected assets,
revoking user sessions, rotating a provider claim signer, or changing custody
policy with the selected signer backend. Keep the incident timeline tied to the
available audit events, transaction records, custody logs, and identity-provider
logs used to make each decision.
System failure recovery depends on the deployment architecture selected for the
environment. For production deployments, review the high-availability design,
backup coverage, restore drills, recovery time objectives (RTO), recovery point
objectives (RPO), and queue-recovery evidence that apply to that environment.
DALP's self-hosting architecture guidance gives operators patterns for
availability and recovery, but the actual outage record and recovery evidence
come from the deployed platform.
Smart contract upgrade procedures should be reviewed from the deployed contract
architecture, governance policy, signer policy, test evidence, and change log.
For upgradeable deployments, evidence should show who approved the change, which
contract version was deployed, what pre-production validation ran, and how the
operator would contain or roll back an unsafe change.
## Standards, certifications, and regulatory alignment [#standards-certifications-and-regulatory-alignment]
### Industry standards provide interoperability and best practices [#industry-standards-provide-interoperability-and-best-practices]
DALP implements standards that enable interoperability with existing financial
infrastructure and demonstrate alignment with industry best practices. The
platform implements ERC-3643 for permissioned token transfers with embedded
compliance and uses FIDO2/WebAuthn as an active strong-authentication standard
that eliminates password vulnerabilities. OpenID Connect identity federation
and OAuth 2.0 authorization for secure API access are available through
installable authentication plugins and are not active by default in every
deployment.
These aren't checkbox features. They are architectural choices that determine how
the platform integrates with broader financial infrastructure and whether
institutions can adopt it within existing operational frameworks.
### Regulatory framework alignment supports global deployment [#regulatory-framework-alignment-supports-global-deployment]
DALP provides configurable controls that regulated asset programmes can map to
their jurisdiction-specific obligations. Compliance teams can configure identity
requirements, transfer restrictions, investor limits, holding rules, and audit
records for each asset programme. The same architecture can support different
regulatory contexts, but the legal interpretation and final control design stay
with the operator and its counsel.
DALP does not make a deployment automatically compliant. It gives operators the
technical control points and evidence trails they need to implement, test, and
review their compliance model for the relevant jurisdiction.
### Security certifications demonstrate operational maturity [#security-certifications-demonstrate-operational-maturity]
Organizations deploying DALP typically pursue certifications that demonstrate
operational maturity to regulators, auditors, and institutional customers. SOC 2
Type II attestation covers service organization controls for security,
availability, and confidentiality through independent audit. ISO 27001
information security management system certification demonstrates systematic
security practices. Smart contract audits provide third-party security review of
contract code by specialized blockchain security firms. Penetration testing
through regular external security assessments identifies vulnerabilities before
attackers exploit them. Regulatory examinations through cooperation with
securities regulators reviewing operations validate that compliance claims match
operational reality.
These aren't automatic with the platform. They are organizational certifications
your deployment pursues with DALP's architecture supporting the requirements
rather than fighting against them.
## What this means for adoption [#what-this-means-for-adoption]
Risk committees approve platforms that demonstrate control through evidence, not
promises. DALP provides audit trails for eligibility checks, identity
verification, and rule evaluation. Security controls with multi-signature
operations and custody-aware signing routes reduce single-key risk. Configurable
rule modules help teams align asset controls with their legal and operating
model. Privacy-aware identity design keeps personal data off-chain while still
letting token contracts verify required claims.
When you present DALP to your risk committee, you're presenting a platform
built for regulated financial instruments with institutional control points, not
a developer experiment retrofitted with compliance features after launch. Use
DALP's audit trails, transaction records, health surfaces, and deployment
evidence pack to show what the platform enforced, who acted, and how the
environment was operated.
Compliance controls are part of transaction execution. Security is built into
the operating model. Privacy starts with clear separation between on-chain claims
and off-chain identity records.
## Where to next [#where-to-next]
* **[DALP overview](/docs/executive-overview/dalp-overview)** – Platform features
and capabilities across the asset lifecycle
* **[Architecture](/docs/architecture/overview)** – Technical details
on system design and component interactions
* **[Glossary](/docs/executive-overview/glossary)** – Key terms and definitions
for compliance and security concepts