INSTITUTIONAL CONTROLSACROSS THE INFRASTRUCTURE.

Designed to support verified participation, so that a counterparty is a known institution rather than an address.

Intended to connect eligibility rules to the workflow itself, including jurisdiction, investor class and product requirements.

Role and entitlement controls intended to determine what an account may see, hold, transfer and approve.

Transaction monitoring and risk signals designed to operate in the transaction path rather than beside it.

Transport, key management, least-privilege administration and audit logging designed in as architecture, not added after.

Designed so that each controlled action is attributable and each stage leaves a record that can be reviewed.

IDENTITY & ACCESS

Designed to support verified participation and controlled access across institutional digital financial workflows.

Access is intended to be established against an identified institution and its authorized representatives, so that permissions belong to a known counterparty rather than to a shared credential.

Verification and screening capabilities may be provided through integrated providers.

KYC & KYB

KYC and KYB capabilities may be integrated into applicable onboarding and transaction workflows through appropriate infrastructure and providers.

Digital Assets Capital does not itself approve every customer globally. Where verification is required, it is performed under the requirements that apply to the regulated entity and market in question.

Identity verification providers, integrated.

AML & TRANSACTION CONTROLS

Infrastructure may support compliance workflows, transaction monitoring and risk controls where applicable.

The intended design places these controls inside the transaction path, so that a workflow which cannot be supported by an applicable permission cannot complete.

Automated controls support a compliance function; they do not replace the judgment, or the obligations, of the regulated entity responsible for them.

ELIGIBILITY & PERMISSIONS

Eligibility rules — jurisdiction, investor classification, product and counterparty requirements — are intended to be expressed as permissions rather than as policy documents.

A permission is designed to travel with the asset and the account, so the same rule applies wherever the asset moves rather than only where it was first issued.

PROGRAMMABLE TRANSFER CONTROLS

Transfer conditions are intended to be enforced by the infrastructure at the moment of transfer, subject to the requirements applicable to the asset and the market.

This is a design intention for the infrastructure being built. It is not a representation that every asset issued or connected through the ecosystem carries its conditions on-chain today.

ASSET VERIFICATION & DUE DILIGENCE

Asset workflows are designed to accommodate verification, valuation and due diligence steps, carried out by qualified providers appropriate to the asset class.

No asset is described on this website as independently verified. Verification, where it occurs, is specific to an asset, a provider and a date, and will be stated when it has actually happened.

Valuation, assay and audit providers, per asset class.

SECURITY BY DESIGN

The intended architecture combines transport encryption, edge protection, least-privilege access control, secret management and continuous monitoring, with administrative actions attributable to a named account.

No security programme eliminates risk, and no certification is claimed. A production security statement and an independent assessment will be published when the platform reaches that stage.

TRANSPARENCY & AUDITABILITY

Designed so that controlled actions leave a reviewable record: what happened, under which permission, and on whose authority.

Transparency is a design objective rather than a description of current reporting. Where reserve, custody or performance information is published in future, it will be stated with its source, its scope and its date.