Skip to content
Executive summary

A domain is an organizational boundary that groups accounts, users, policies, and other entities under a single governance structure.

  • Domains form a hierarchy that mirrors your business structure.
  • Data is isolated by domain.
  • Users operate in their own domain and, where permitted, descendant domains.
  • Policies can apply to one domain, descendant domains, or both.
  • Governing strategies control whether parent-domain policies are considered with or override child-domain policies.
Why this matters

Domains are the main tool for segregating assets, users, and governance rules. Domain design affects client asset segregation, regional controls, treasury operations, compliance review, reporting, and emergency response. Poorly designed hierarchies can cause unintended access paths, duplicated policies, or parent policies applying more broadly than intended.

What domains contain

A domain is a logical container for domain-owned records:

EntityWhy domain ownership matters
UsersDetermines where users can submit and approve intents.
Accounts and vaultsKeeps assets and signing material aligned to an operational boundary.
PoliciesDefines the approval rules that apply in the domain.
EndpointsScopes trusted addresses and external destinations.
Requests and eventsProvides domain-level audit and operational visibility.

Domain hierarchy

Every environment has a root domain. Subdomains sit beneath it in a tree.

Root domain

APAC region

EMEA region

Japan

Singapore

London

Root domain

APAC region

EMEA region

Japan

Singapore

London

RuleDescription
Single rootEvery environment has one root domain.
One parentEach subdomain has one parent domain.
No upward accessUsers cannot submit intents to parent domains.
Descendant operationUsers can target their own domain and, where permitted by policy, descendant domains.
InheritanceParent-domain policies can affect child-domain intents, depending on policy scope and governing strategy.

Governing strategies

A domain's governing strategy determines how its policies interact with subdomain policies.

ConsiderDescendants

Parent-domain policies are considered alongside child-domain policies. This is useful when the parent sets baseline oversight and child domains add local rules.

Parent policy: all transfers need one approval

Child policy: high-value transfers need CFO approval

Both policies can be considered for child-domain intents

Parent policy: all transfers need one approval

Child policy: high-value transfers need CFO approval

Both policies can be considered for child-domain intents

CoerceDescendants

Matching parent-domain policies override child-domain policies. This is useful when the parent must enforce controls that child domains cannot weaken, such as emergency, compliance, or group-wide risk controls.

ignored when coerced

Parent policy: emergency freeze requires senior approval

Child policy: routine transfer approval

Parent policy overrides matching child policy

ignored when coerced

Parent policy: emergency freeze requires senior approval

Child policy: routine transfer approval

Parent policy overrides matching child policy

Use CoerceDescendants only when the override is intentional and understood by operators.

Policy scope and inheritance

Policy scope defines where a policy applies relative to the domain where the policy is created.

ScopeApplies to
SelfIntents targeting the policy's own domain.
DescendantsIntents targeting child domains.
SelfAndDescendantsIntents targeting the policy's own domain and child domains.

The combination of domain governing strategy and policy scope determines policy inheritance.

Compliance domains

A compliance domain is a specialized domain used to manage transaction screening, Travel Rule, quarantine release, and exception review. A compliance domain can sit above operational domains so compliance policies and reviewers can apply across those descendants.

Design considerations:

  • Compliance roles need read access to accounts, transactions, requests, events, and relevant policies.
  • Quarantine release policies should live where compliance reviewers can approve them.
  • Domain injection can add a compliance layer after launch if the original hierarchy needs to change.

Multi-tenancy

Use domains for multi-tenancy when a boundary affects data access, approval policy, reporting, or operational ownership.

PatternDomain model
Client segregationOne subdomain per client or client group.
Business unit segregationOne subdomain per business unit.
Regional controlOne subdomain per region or legal entity.
Treasury isolationSeparate domains for asset classes, desks, or treasury teams.
Compliance oversightCompliance domain above operational domains.

Avoid deep hierarchies unless policy inheritance is clear. A flatter hierarchy is often easier to operate and audit.

Domain lifecycle

StateDescription
CreatedDomain exists and can operate when unlocked.
LockedDomain activity is suspended.
UnlockedDomain activity is enabled.

Locking a domain is useful for investigations, temporary suspension, incident response, or decommissioning.

Domain injection

Domain injection inserts a new domain between an existing parent and its child domains. Use it to add a governance layer without rebuilding the entire hierarchy.

Common uses:

  • Add compliance oversight above existing operational domains.
  • Group existing domains under a new regional parent.
  • Apply shared policies to a subset of existing child domains.
  • Retrofit a governance layer after launch.

For operations, see Manage domains and Inject a domain. For fields and valid values, see Domain reference.