# Domains

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:

| Entity | Why domain ownership matters |
|  --- | --- |
| Users | Determines where users can submit and approve intents. |
| Accounts and vaults | Keeps assets and signing material aligned to an operational boundary. |
| Policies | Defines the approval rules that apply in the domain. |
| Endpoints | Scopes trusted addresses and external destinations. |
| Requests and events | Provides domain-level audit and operational visibility. |


## Domain hierarchy

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


```mermaid
flowchart TB
    Root["Root domain"]
    APAC["APAC region"]
    EMEA["EMEA region"]
    Japan["Japan"]
    Singapore["Singapore"]
    London["London"]

    Root --> APAC
    Root --> EMEA
    APAC --> Japan
    APAC --> Singapore
    EMEA --> London
```

| Rule | Description |
|  --- | --- |
| Single root | Every environment has one root domain. |
| One parent | Each subdomain has one parent domain. |
| No upward access | Users cannot submit intents to parent domains. |
| Descendant operation | Users can target their own domain and, where permitted by policy, descendant domains. |
| Inheritance | Parent-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.


```mermaid
flowchart TB
    Parent["Parent policy: all transfers need one approval"]
    Child["Child policy: high-value transfers need CFO approval"]
    Result["Both policies can be considered for child-domain intents"]
    Parent --> Result
    Child --> Result
```

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


```mermaid
flowchart TB
    Parent["Parent policy: emergency freeze requires senior approval"]
    Child["Child policy: routine transfer approval"]
    Result["Parent policy overrides matching child policy"]
    Parent --> Result
    Child -. ignored when coerced .-> Result
```

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.

| Scope | Applies to |
|  --- | --- |
| `Self` | Intents targeting the policy's own domain. |
| `Descendants` | Intents targeting child domains. |
| `SelfAndDescendants` | Intents 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.

| Pattern | Domain model |
|  --- | --- |
| Client segregation | One subdomain per client or client group. |
| Business unit segregation | One subdomain per business unit. |
| Regional control | One subdomain per region or legal entity. |
| Treasury isolation | Separate domains for asset classes, desks, or treasury teams. |
| Compliance oversight | Compliance domain above operational domains. |


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

## Domain lifecycle

| State | Description |
|  --- | --- |
| Created | Domain exists and can operate when unlocked. |
| Locked | Domain activity is suspended. |
| Unlocked | Domain 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](/products/custody/v1.36/governance/domains/manage-domains) and [Inject a domain](/products/custody/v1.36/governance/domains/inject-a-domain). For fields and valid values, see [Domain reference](/products/custody/v1.36/governance/domains/reference).