> ## Documentation Index
> Fetch the complete documentation index at: https://apidocs.finrock.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Sub-Accounts: Hierarchical Digital Asset Management

> Use Finrock sub-accounts to separate funds across entities, departments, or client portfolios — each with its own wallets, policies, and permissions.

Finrock sub-accounts give you a structured way to separate funds, policies, and permissions within a single Finrock workspace — without creating entirely new accounts or legal entities. Each sub-account operates as a self-contained unit with its own wallets, gas tanks, transaction policies, and access controls, while remaining nested under your primary account hierarchy.

## What Is a Sub-Account?

A sub-account is a secondary account nested within a primary (parent) account. It shares the parent's workspace login and legal structure, but maintains independent operational boundaries — its own wallets, gas tanks, policies, and user permissions are fully separate from the parent account and from sibling sub-accounts.

Think of sub-accounts as departments within a company: they share the same roof, but each has its own budget, team, and processes.

**Common use cases:**

<CardGroup cols={3}>
  <Card title="Multiple Departments" icon="building">
    Give each business unit (trading, treasury, operations) its own segregated wallet environment with independent policies.
  </Card>

  <Card title="Client Portfolios" icon="briefcase">
    Assign each customer or client a dedicated sub-account with isolated funds — ideal for exchanges, brokers, and OTC desks.
  </Card>

  <Card title="Regulatory Segregation" icon="scale-balanced">
    Separate customer funds from company funds within the same workspace to meet internal compliance requirements.
  </Card>
</CardGroup>

## HD Wallet Derivation

Finrock uses **Hierarchical Deterministic (HD) wallets** for sub-accounts. A single entropy source (your client seed) generates all sub-account wallets via unique BIP-32 derivation paths. Each sub-account receives a distinct path in the form:

```
m/44'/0'/0'/0/X
```

Where `X` is the sub-account index. All sub-accounts derive from the same root seed, but their keys are mathematically independent — no sub-account's key can be used to derive another's.

### Backup Simplicity

Because all sub-accounts share a single root seed, you only need to back up one thing:

<Steps>
  <Step title="Record Your Seed Phrase">
    Store your single 12-word seed phrase in a secure location. This one phrase is the root of your entire sub-account hierarchy.
  </Step>

  <Step title="Recover All Sub-Accounts at Once">
    If you ever need to restore, import the 12-word phrase into a compatible wallet. All sub-accounts at their respective BIP-32 paths (`m/44'/0'/0'/0/X`) appear automatically.
  </Step>

  <Step title="No Per-Sub-Account Backup Required">
    You do not need to track or store separate seeds, keys, or phrases for individual sub-accounts. One phrase recovers everything.
  </Step>
</Steps>

<Note>
  This backup model is a significant operational advantage — but it also means all sub-accounts share cryptographic lineage. If the root seed is compromised, all sub-accounts are affected. For full key isolation between entities, see [Multiple Workspaces](#when-to-use-multiple-workspaces) below.
</Note>

## Limitations of Sub-Accounts

Sub-accounts are powerful for organizational separation, but they do not provide full cryptographic isolation. Because all sub-accounts derive from the same root entropy, a compromise of the root seed exposes all sub-accounts simultaneously.

If you need true key-level segregation between entities — for example, keeping client funds and company treasury on entirely separate cryptographic roots — you need separate Finrock workspace accounts, each with its own seed.

## When to Use Multiple Workspaces

<Accordion title="Regulatory Compliance (MiCA / FCA)">
  Regulations such as MiCA and FCA-equivalent standards often require provable segregation between client assets and company assets. A single seed shared across sub-accounts creates an auditable link between those funds. Separate workspaces with independent seeds provide the clean boundary that regulators and auditors expect — and simplify proof-of-reserves reporting.
</Accordion>

<Accordion title="Security Isolation: Hot vs Cold">
  If one workspace is used for active hot-wallet operations (high transaction frequency, API access), a compromise of that environment should not be able to reach your cold treasury. Separate workspaces ensure that a breach of the hot-wallet seed does not expose company treasury keys.
</Accordion>

<Accordion title="Proof-of-Reserves">
  Demonstrating to external auditors or customers that specific funds are held in segregated custody is cleaner with separate workspaces. Each workspace's seed is independent, making it straightforward to produce cryptographic proofs that one pool of funds has no connection to another.
</Accordion>

<Note>
  **Sub-accounts vs. separate workspaces:** Use sub-accounts when you need organizational structure, independent policies, and operational separation within a trusted entity. Use separate Finrock workspace accounts when you need full cryptographic segregation — for example, between customer funds and company treasury, or between hot and cold storage environments.
</Note>

## Sub-Account Capabilities

Each sub-account you create includes full access to the following independent resources:

| Resource             | Sub-Account Scope                                                |
| -------------------- | ---------------------------------------------------------------- |
| Wallets              | Each sub-account has its own wallet(s) with derived addresses    |
| Gas Tanks            | Independent gas tank balances per sub-account                    |
| Transaction Policies | Per-sub-account approval rules, limits, and whitelists           |
| User Permissions     | Granular access control — different team members per sub-account |
| AML Settings         | Separate AML policy configuration                                |