Compliance by design means the product can make, explain, and evidence required decisions without relying on manual workarounds after launch. For a decentralized virtual-asset service, that requires more than an onboarding vendor and an address-screening API. The architecture must know which entity and rule set apply, which user or counterparty is involved, what the transaction will do, which controls are available at that point, how exceptions are handled, and what evidence is retained. It must also remain secure and resilient under rapid product change.
The stack described here is modular so that legal rules, risk appetite, and technical services can evolve independently. It is not a claim that every product needs every module or that software can resolve legal judgment. Human governance remains essential. The objective is to create explicit control points and reliable records while preserving accurate boundaries between the protocol, interface, operator, customer, and third-party providers.
Layer one: service and jurisdiction registry
Create a source of truth for legal entities, products, services, assets, client types, countries, and launch conditions. Each permitted combination should have an owner, legal basis, approval date, restrictions, and control dependencies. Product configuration should consume this registry so an unsupported asset or geography cannot be enabled only through a front-end flag. Record assumptions, such as no custody or no fiat handling, that would require reassessment if changed.
The registry should link to transaction-flow diagrams, control maps, and responsible teams. Version it and expose a clear change process. A new chain can alter sanctions coverage, monitoring, Travel Rule capability, security, and asset classification. A new institutional API can create a different service relationship from the retail interface. Treat these as governed launch events, not ordinary content updates.
Layer two: identity, account, and wallet context
Build a canonical party record that separates verified identity, account, roles, legal entity, beneficial ownership, jurisdiction, risk factors, and consent or privacy metadata. Link wallets and addresses with provenance and confidence rather than declaring permanent ownership. Track whether an address was customer-declared, signature-verified, attributed to a service, observed through transaction history, or supplied by a counterparty. Keep historical associations because wallet use changes.
Access to identity data should be purpose-limited. Product services may need a decision token rather than full personal data. Investigators may require deeper access under logged roles. Avoid copying identity and wallet links into analytics, support, and logging systems without controls. Data-quality checks, duplicate resolution, and correction workflows are compliance functions as well as engineering hygiene. A wrong party link can produce both missed risk and unfair restriction.
Layer three: transaction intent and simulation
Capture what the user intends before execution: asset, amount, source, destination, chain, route, contract calls, counterparty, and purpose where needed. Simulate the transaction to reveal approvals, transfers, nested calls, routers, bridges, and fees. A wallet address alone may not show that the transaction grants unlimited approval or routes through an unexpected contract. Use normalized transaction objects so policy services can evaluate different chains consistently while retaining chain-specific details.
Simulation results need integrity and freshness. Detect changes between simulation and signing, stale quotes, replaced routes, and manipulated front-end data. For APIs, authenticate the client and bind the decision to the exact instruction. Define which changes require rescreening. Store enough information to reproduce the decision without retaining unnecessary secrets. This layer connects the user experience to the actual on-chain effect.
Layer four: policy decision service
Centralize governed decision logic for eligibility, limits, sanctions, AML/CFT risk, Travel Rule status, asset policy, counterparty status, and required approvals. The service should receive normalized facts and return a decision with reason codes, rule version, required actions, and expiry. Keep legal or risk rules out of scattered interface code. Support jurisdiction-specific logic while preserving global safeguards and a controlled hierarchy when rules conflict.
Explainability is essential. Reviewers should see the inputs and rule that produced a hold, denial, or escalation. Customers should receive appropriate messages without disclosure of sensitive detection logic. Overrides require named authority, reason, duration, and follow-up. Test rules with scenario libraries before release and monitor outcomes afterward. A policy engine is only as trustworthy as its data, governance, and failure behavior.
Layer five: execution gates and control adapters
Connect policy decisions to the controls the product can actually exercise. A custodial platform can hold or reject a transfer. An interface can deny a managed route, remove an asset from its list, or stop a hosted relayer. A smart contract may support pausing, allowlists, or limits, subject to governance and technical constraints. Each adapter should report whether the action succeeded. Do not mark a transaction blocked when a UI request failed but the relayer still submitted it.
Design safe failure modes. Decide whether a screening outage causes a hold, restricted functionality, or a documented fallback for each product. Protect against bypass through alternate endpoints, cached configuration, or direct API calls. Separate control credentials, use least privilege, and monitor administrative action. Where direct protocol interaction remains possible, state that limitation and use monitoring or future-access decisions where appropriate.
Layer six: monitoring, cases, and reporting
Stream relevant events into monitoring with consistent identifiers for customer, account, wallet, transfer, transaction hash, counterparty, rule, and case. Detection should cover on-chain behavior, account activity, product misuse, and control anomalies. Alerts need context and a defined disposition. Case management should preserve evidence, review steps, approvals, related activity, and reporting decisions. Avoid analyst workflows that require copying sensitive data into ungoverned notes.
Feedback loops improve the stack. Confirmed cases can inform typologies and rules; false positives can reveal poor data or thresholds; repeated exceptions can expose product design problems. Reporting workflows should use validated data and controlled approval. Metrics should show coverage, backlogs, conversion, investigation time, unresolved exposure, and remediation, not merely the number of alerts generated.
Layer seven: evidence, security, and resilience
Every material decision needs durable, tamper-evident evidence: input facts, source timestamps, list and model versions, rule results, reviewer actions, execution outcome, and later reconciliation. Define retention, legal holds, privacy controls, and access logging. Ensure backups and disaster recovery preserve integrity. Evidence should allow an independent reviewer to reproduce a historical decision even after vendors or models change.
Secure the stack through governance, asset inventory, identity and access management, vulnerability management, logging, incident response, recovery, vendor oversight, and tested continuity. Compliance services are high-value targets because they combine identity, wallet links, decision authority, and sensitive investigations. NIST CSF 2.0 offers a broadly applicable taxonomy for governing and managing cybersecurity risk that can anchor this layer:
Layer eight: controlled product change
Embed compliance review in the product lifecycle. A change request should identify affected entities, countries, assets, transaction paths, permissions, data, vendors, and controls. Risk-based triage can route minor copy changes quickly while requiring architecture, legal, security, and operations approval for material features. Define launch conditions and evidence before release, not after. Feature flags should respect the service registry and should not permit an unauthorized combination to be enabled by a single administrator.
After launch, compare actual behavior with assumptions. Monitor route selection, user geography, alert volume, failure rates, support cases, and unexpected contract calls. Schedule a post-launch review for high-risk changes and roll back when control dependencies fail. Preserve the decision record, tests, approvals, and production configuration. This closes the gap between a compliant design document and the product users actually receive.
Conclusion
A compliance-by-design stack turns obligations and risk decisions into explicit, testable services. The strongest architecture knows which rule applies, understands the intended transaction, produces an explainable decision, enforces it through a real control point, and preserves evidence of the result.
Modularity does not remove accountability. Legal, compliance, product, engineering, security, and operations teams must govern data, rules, releases, exceptions, and incidents together. When those responsibilities are defined, the stack can evolve with new chains and products without rebuilding compliance from scratch.