Compliance & security

Key terms

• ERC-3643 – Token standard embedding compliance checks in transfer execution
• OnchainID – Decentralized identity protocol for portable investor credentials
• HSM – Hardware Security Module providing tamper-resistant key storage
• Multi-signature – Wallet requiring multiple approvals for transactions

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

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.

For mint operations, the same control model separates the business instruction from the EVM transaction. Production integrations should send a stable Idempotency-Key for each approved mint instruction, keep the recipient, amount, asset, executor, and wallet route stable across retries, and reconcile the transaction status or indexed supply before issuing a replacement mint. See Replay protection and mint controls for the technical retry, nonce, custody-signing, and supply-control details.

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.

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.

Use templates to prepare the policy pattern. Use asset module parameters to make that policy active for an issued asset. That split matters during reviews: changing a reusable template prepares the next configuration, but it does not silently change policy on assets that already run on-chain.

Configurable compliance modules can enforce geographic restrictions, investor limits, transfer restrictions, holding periods, trading venue restrictions, and collateral requirements. Treat rule changes for live assets as governed operational changes: review the affected assets, explicitly re-apply or adjust the asset's module parameters, and verify the affected path before relying on the updated controls. For transfer controls, validate transfer behavior. For collateral and issuance controls, validate the mint or issuance path as well.

Audit evidence starts with the transaction record

DALP gives compliance and audit reviewers evidence from the transaction path, not a separate after-the-fact spreadsheet. Standard token transfers run identity and compliance checks before balances change. If a recipient identity check or configured compliance module rejects the movement, the EVM transaction reverts and token balances stay unchanged.

Use DALP evidence as the technical record for the platform action. Reviewers can look at the submitted transaction, receipt status, indexed token events, holder balances, configured compliance modules, trusted issuers, identity claims, and related operational history for the asset. The compliance transfer flow shows where the check happens. The signing flow shows how DALP records the network transaction hash and waits for the matching receipt before treating the operation as complete.

The institution still owns the examination file around that technical record. It decides which policy the rule implements, whether the attempted action was authorised under its programme, how long evidence is retained, and which identity-provider, SIEM, custody-provider, or case-management records complete the regulator-facing timeline. DALP supplies the platform evidence; the operating model turns that evidence into an audit response.

Identity verification and KYC/AML integration

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

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

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 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

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.

Sensitive operations should be routed through the approval policy configured for that deployment, such as maker-checker review, M-of-N approval, transaction limits, or custody-provider policy approval. The control objective is the same across minting, burning, large transfers, emergency pauses, and contract upgrades: one compromised account should not be able to inflate supply, destroy value, halt trading, or deploy unsafe contract logic on its own.

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.

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. DFNS approval callbacks are accepted on a webhook endpoint only after HMAC signature verification; invalid, malformed, or oversized callback payloads are acknowledged or rejected without being dispatched into the approval workflow.

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?"

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

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.

For reserve-backed, certificate-backed, or physical-asset-backed programmes, add asset-level document evidence to the review packet. Token document records can carry the file type, visibility, version group, upload timestamp, uploader, and file hash for documents such as reserve audits, attestation reports, certificates, storage receipts, and chain-of-custody files. DALP records those document references; the issuer, custodian, trustee, auditor, or warehouse operator still proves the off-chain reserve or asset record.

Use this split when preparing auditor or procurement evidence. Public DALP docs describe platform controls and document records. The deployment evidence pack discloses the actual incident history, investigation timeline, customer notifications, measured recovery results, and regulatory correspondence for the environment under review.

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. Bank and security reviewers should ask for measured evidence, not a universal product promise. A complete evidence pack identifies the selected pattern, PostgreSQL and cache recovery plan, object storage backup and restore path, RPC or node failover plan, alert ownership, last restore drill, achieved recovery runtime, and any accepted gap against the target RTO or RPO.

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. Use deployment topology, high availability, and backup and recovery to connect review questions to the right operating evidence.

When a bank reviewer asks for HA or DR proof, separate the design from the measured evidence:

For a review packet, start with Deployment topology to map failure domains, then use Backup and recovery to plan restore evidence. Do not treat a target RTO or RPO as proof until a restore drill has measured it in the environment being reviewed.

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

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

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

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

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

• DALP overview – Platform features and capabilities across the asset lifecycle
• Architecture – Technical details on system design and component interactions
• Glossary – Key terms and definitions for compliance and security concepts