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

# Fund and manage subaccounts

> Fund subaccounts with USD or in-kind digital assets, attribute deposits, and manage balances.

Once a subaccount is created, funding can begin. End clients may fund with digital assets in-kind or USD. The flow differs by funding method.

Topics covered:

* Fund with USD
* Fund in-kind with digital assets
* Attribute deposits
* Move funds between subaccounts
* Update billing fees and dates

***

## Fund with USD

Generate a USD wire memo per subaccount via API and share with the end client. Include the memo in the wire to Anchorage Digital to ensure proper attribution.

### USD funding considerations

* **ACH not supported** — ACH makes attribution unreliable.
* **Wires without memos are returned** — Any wire without a memo field is subject to return. Anchorage Digital will use best efforts to determine the recipient but requires written confirmation from the wealth manager before attributing.
* **Multiple subaccounts** — If the end client has multiple subaccounts, they can fund one and rebalance USD across subaccounts using the Subaccount transactions API.
* **Third-party wires not supported** — The originating bank account must be held in the end client's name. Payments from accounts not in the end client's name will be returned.

***

## Fund in-kind with digital assets

Steps must be completed in order — out-of-sequence execution risks funds being lost or returned.

<Steps>
  <Step title="Create a subaccount-specific deposit wallet">
    Create one wallet per subaccount per asset using **`POST /v2/vaults/{vaultId}/wallets`**, specifying `subaccountId`.

    Create wallets on demand (when the customer requests a deposit address) rather than pre-creating wallets for all supported assets.

    **Recommended naming convention:** `[PC name]_[Subaccount #]_Deposit Wallet`

    <Note>
      Wallet creation is limited to 10 wallets per asset per 30 minutes. This limit will increase in coming months.
    </Note>
  </Step>

  <Step title="Share with end client">
    Share the deposit address with the correct end client along with the blockchain details (e.g., Ethereum mainnet vs. Base), deposit attribution requirements, and any other relevant account information.

    <Tip>
      For the first few deposits, have the end client send a small test amount to confirm the address and network are correct before transferring the full balance. Ensure both parties are aligned on the exact asset symbol and supported network — deposits to the wrong network may result in lost funds.
    </Tip>
  </Step>

  <Step title="Monitor for deposits">
    Use [webhooks](/knowledge-base/platform/developers/webhooks/webhooks-overview) to get notified of deposit events, or poll pending deposit attributions via API.

    Deposit confirmations are not immediate — typically require 2 on-chain confirmations, which may take a few minutes.

    <Warning>
      Ensure end clients only deposit supported assets. Deposits of unsupported assets into a wallet will result in lost funds.
    </Warning>
  </Step>

  <Step title="Monitor for deposits">
    Use [webhooks](/knowledge-base/platform/developers/webhooks/webhooks-overview) to get notified of deposit events, or poll pending deposit attributions via API.

    Deposit confirmations are not immediate — typically require 2 on-chain confirmations, which may take a few minutes.

    <Warning>
      Ensure end clients only deposit supported assets. Deposits of unsupported assets into a wallet will result in lost funds.
    </Warning>
  </Step>

  <Step title="Attribute the deposit">
    See [Attribution steps](#integration-steps) below.
  </Step>
</Steps>

***

## Deposit attribution

### Status values

| `status`           | Details                                                                                                                  |
| :----------------- | :----------------------------------------------------------------------------------------------------------------------- |
| `PENDING`          | Deposit landed after Anchorage Digital auto-attribution attempt. Spam deposits marked by Anchorage will not appear here. |
| `INITIATED`        | Deposit detected; auto-attribution in progress. Moves to `PENDING` if auto-attribution fails.                            |
| `ATTRIBUTED`       | Terminal state — happy path.                                                                                             |
| `UNDER_REVIEW`     | Attributed but triggered a sanctions hit pending compliance clearance.                                                   |
| `BLOCKED`          | Confirmed true sanctions hit.                                                                                            |
| `NON_ATTRIBUTABLE` | Semi-terminal state for specific edge cases.                                                                             |

### Attribution type values

| `attributionType` | Details                                                        |
| :---------------- | :------------------------------------------------------------- |
| `MANUAL_STAFF`    | Attributed by Anchorage Digital staff.                         |
| `MANUAL_CLIENT`   | Attributed by wealth manager via web dashboard.                |
| `CLIENT_API`      | Attributed by wealth manager via API key.                      |
| `AUTOMATIC`       | Attributed via travel rule message from originating VASP.      |
| `SPAM`            | Attributed as spam by Anchorage Digital or the wealth manager. |
| `TRUSTED_SOURCES` | Attributed automatically using a designated trusted source.    |

### Trusted sources

Trusted sources auto-attribute recurring deposits from the same address. Create them in the Anchorage Digital web dashboard (API not available in production).

<Warning>
  Trusted sources should not be used if a single source address is shared by multiple end clients. Doing so may cause incorrect attribution and require the wealth manager to provide additional originator details to Anchorage Digital.
</Warning>

<Tip>
  In production, collect AML deposit attribution data from the end client before sharing the deposit address. This enables automatic attribution once the deposit is detected.
</Tip>

### Spam / unknown deposits

Attribute dust or spam deposits as `SPAM` using **`POST /v2/deposit-attributions/{depositTransactionId}/spam`**. This prevents unwanted balances from appearing on the end client's subaccount. Anchorage Digital will sweep these funds from on-chain wallets using the shared API key as needed.

### Automated attribution from VASPs

Crypto deposits from VASPs over \$2,100 (the travel rule threshold) are automatically attributed if Anchorage Digital receives a travel rule message from an active TRUST network VASP. This is not instant — use the attribution API for faster fund access.

***

## Integration steps

### Step 1: Get your `vaultId`

**`GET /v2/vaults`**

<CodeGroup>
  ```bash Request theme={null}
  curl --request GET \
       --url https://api.anchorage-staging.com/v2/vaults \
       --header 'Api-Access-Key: [API Key]' \
       --header 'accept: application/json'
  ```

  ```json Response theme={null}
  {
    "data": [
      {
        "accountName": "Wealth Manager - FBO Program Customers",
        "description": "",
        "name": "John Doe_Deposit wallet_Subaccount_123456789987654323456",
        "type": "VAULT",
        "vaultId": "7d04d1b820f1b5a903e47fd3019c58f3"
      }
    ]
  }
  ```
</CodeGroup>

### Step 2: Create a deposit wallet for the subaccount

**`POST /v2/vaults/{vaultId}/wallets`**

<CodeGroup>
  ```bash Request theme={null}
  curl --request POST \
       --url https://api.anchorage-staging.com/v2/vaults/7d04d1b820f1b5a903e47fd3019c58f3/wallets \
       --header 'Api-Access-Key: [API Key]' \
       --header 'accept: application/json' \
       --header 'content-type: application/json' \
       --data '{
    "networkId": "BTC",
    "walletName": "John Doe_ec761b5e-fd2c-497a-a9a0-f8738ac97bdf_Bitcoin Deposit Wallet_1",
    "subaccountId": "ec761b5e-fd2c-497a-a9a0-f8738ac97bdf"
  }'
  ```

  ```json Response theme={null}
  {
    "data": {
      "depositAddress": {
        "address": "3KEFt8iLAGSHhKvQsVUabmAHZdWar45PnW",
        "addressId": "2be7ad5e4dccbdf2d82b77113d908e5cb",
        "addressSignaturePayload": "7b225465787441646472657373223a22334b45467438694c41475348684b765173565561626d41485a645761723435506f57227d",
        "signature": "dcb09503a0dfd592749f6298a59ea46aac549aa56a1127fa51efb1ad34663eabb55bab24c9c87ff7c0e09e6d9154daeadc1805e5cf297abd8a8b404bb6b7910b"
      },
      "isArchived": false,
      "isDefault": false,
      "networkId": "BTC",
      "subaccountId": "ec761b5e-fd2c-497a-a9a0-f8738ac97bdf",
      "vaultId": "7d04d1b820f1b5a903e47fd3019c58f3",
      "vaultName": "Advisor 1, FBO Program Customers",
      "walletId": "6aabaa5127f3757de379e724f69d6fa10",
      "walletName": "John Doe_ec761b5e-fd2c-497a-a9a0-f8738ac97bdf_Bitcoin Deposit Wallet_1"
    }
  }
  ```
</CodeGroup>

<Note>
  **Sandbox testnet assets:** `BTC_T` (BTC testnet), `ETHHOL` (ETH Holesky), `USDANCHOL` (USDC Holesky)
</Note>

### Step 3: Identify a new deposit

**Option A:** Poll for pending attributions — **`GET /v2/deposit-attributions?status=PENDING`**

```json Response theme={null}
{
  "data": [
    {
      "assetType": "BTC",
      "depositTransactionId": "22a73be305a4131e2b3439ca5d0fbb7a",
      "status": "PENDING",
      "subaccountId": "cb80459c-a930-444e-8f17-69ba9d0e122f"
    }
  ]
}
```

**Option B:** Webhook notification — subscribe to `deposit.pending-attribution`:

```json Webhook payload theme={null}
{
  "payload": "eyJ0cmFuc2FjdGlvbklkIjoiNjE4Y2JkNTVlNzE2ZmFlMGVkODNjYTcyOWM4MDI2NmEifQ==",
  "timestamp": 1729112450,
  "message_id": "aa2dbc06-1665-44c0-bb8e-d2b0ad15a564",
  "event_type": "deposit.pending-attribution"
}
```

The `message_id` maps to the `depositTransactionId`.

### Step 4: Attribute the deposit

**`PATCH /v2/deposit-attributions/{depositTransactionId}`**

`sourceWalletType` values:

| Value         | Description                                                                                  |
| :------------ | :------------------------------------------------------------------------------------------- |
| `CUSTODIAL`   | Third party holds the private key (e.g., Binance, Coinbase, Kraken, BitGo).                  |
| `SELF_HOSTED` | Owner holds the private key (e.g., MetaMask, Trust Wallet, Ledger, Trezor, Exodus, Phantom). |

<Warning>
  For spam/dust deposits, use **`POST /v2/deposit-attributions/{depositTransactionId}/spam`** instead to prevent unwanted balances from appearing on the subaccount.
</Warning>

<CodeGroup>
  ```bash Request theme={null}
  curl --request PATCH \
       --url https://api.anchorage-staging.com/v2/deposit-attributions/aa2dbc06-1665-44c0-bb8e-d2b0ad15a564 \
       --header 'Api-Access-Key: [API Key]' \
       --header 'accept: application/json' \
       --header 'content-type: application/json' \
       --data '{
    "originatorName": "John Doe",
    "originatorCountry": "US",
    "sourceWalletType": "SELF_HOSTED",
    "notes": "US"
  }'
  ```

  ```json Response (attributed) theme={null}
  {
    "data": [
      {
        "assetType": "BTC",
        "attributedAt": "2024-04-09T19:31:02.046634Z",
        "attributionType": "CLIENT_API",
        "depositTransactionId": "aa2dbc06-1665-44c0-bb8e-d2b0ad15a564",
        "notes": "Example Attribution",
        "originatorCountry": "US",
        "originatorName": "John Doe",
        "sourceWalletType": "SELF_HOSTED",
        "status": "ATTRIBUTED",
        "subaccountId": "cb80459c-a930-444e-8f17-69ba9d0e122f"
      }
    ]
  }
  ```
</CodeGroup>

<Tip>
  After attributing in-kind deposits, update the missing cost basis via **`PATCH /v2/tax/transaction/{transactionId}`**. See [Tax data](/knowledge-base/platform/developers/wealth/wealth-management-tax#step-2-update-missing-cost-basis).
</Tip>

### Step 5: Generate a wire memo for USD funding

**`GET /v2/subaccounts/accounts/{subaccountId}/bank-info`**

<CodeGroup>
  ```bash Request theme={null}
  curl --request GET \
       --url https://api.anchorage-staging.com/v2/subaccounts/accounts/cb80459c-a930-444e-8f17-69ba9d0e122f/bank-info \
       --header 'Api-Access-Key: [API Key]' \
       --header 'accept: application/json'
  ```

  ```json Response theme={null}
  {
    "data": {
      "bank": "Customers Bank",
      "bankAccountNr": "1234567",
      "bankAddress": "123 Test",
      "bankRoutingNr": "123456789",
      "bankSwiftCode": "CUESUS33",
      "beneficiaryAddress": "123 Test",
      "beneficiaryName": "Anchorage Digital Bank NA",
      "memo": "515624204"
    }
  }
  ```
</CodeGroup>

<Note>
  Instruct clients to use the **Message to Beneficiary (OBI)** or **Message to Recipient (OBI)** field for the memo. If unavailable, use the **Memo** field. For international wires, share the `bankSwiftCode`.
</Note>

### Step 6: View subaccount balances

**`GET /v2/subaccounts/customers/{customerId}/accounts`**

<CodeGroup>
  ```bash Request theme={null}
  curl --request GET \
       --url https://api.anchorage-staging.com/v2/subaccounts/customers/{customerId}/accounts \
       --header 'Api-Access-Key: [API Key]' \
       --header 'accept: application/json'
  ```

  ```json Response theme={null}
  {
    "data": [
      {
        "subaccountId": "cb80459c-a930-444e-8f17-69ba9d0e122f",
        "name": "A1234_John Doe_Strat1",
        "customerId": "cf326d89b501d7ff2d1c7b7ffea4bd305a6561b54c9c6158160e17b5aca5cec2",
        "fees": [
          { "type": "MANAGEMENT", "rate": 0.01, "startDate": "2025-02-18", "isBillable": true },
          { "type": "CUSTODY", "rate": 0.01, "startDate": "2025-02-18", "isBillable": true }
        ],
        "balances": [
          { "assetType": "BTC", "totalBalance": "100", "availableForWithdrawal": "100", "availableForTrading": "100" },
          { "assetType": "USD", "totalBalance": "100000", "availableForWithdrawal": "100000", "availableForTrading": "100000" }
        ]
      }
    ]
  }
  ```
</CodeGroup>

### Step 7: Move funds between same-client subaccounts

**`POST /v2/subaccounts/transactions`**

Only settled funds can be moved. Use `availableForWithdrawal` for the settled balance. Cannot move funds between different end clients.

<CodeGroup>
  ```bash Request theme={null}
  curl --request POST \
       --url https://api.anchorage-staging.com/v2/subaccounts/transactions \
       --header 'Api-Access-Key: [API Key]' \
       --header 'accept: application/json' \
       --header 'content-type: application/json' \
       --data '{
    "transactions": [
      {
        "sourceSubaccountId": "cb80459c-a930-444e-8f17-69ba9d0e122f",
        "destinationSubaccountId": "3eeaf765-0df2-49c9-9e1f-db9cf3e796dd",
        "assetType": "USD",
        "amount": "1000.00",
        "transactionMemo": "USD re-balance",
        "idempotentId": "12838927347"
      }
    ]
  }'
  ```

  ```json Response theme={null}
  {
    "data": {
      "transactionIds": [
        { "transactionId": "c4c4652f-0c07-472c-a7f8-955fbe07775d", "idempotentId": "12838927347" }
      ]
    }
  }
  ```
</CodeGroup>

<Tip>
  Use `idempotentId` on bulk subaccount transactions to prevent duplicate submissions.
</Tip>

### Step 8: Update subaccount billing fees or dates

**`PATCH /v2/subaccounts/accounts/{subaccountId}`**

* Updates trigger email notifications to end clients and the wealth manager (including sandbox).
* Updated rates apply from the `startDate` specified.
* Mid-cycle updates retroactively apply to the current billing period.
* End-of-month billing uses the latest rate set for that month.

<CodeGroup>
  ```bash Request theme={null}
  curl --request PATCH \
       --url https://api.anchorage-staging.com/v2/subaccounts/accounts/cb80459c-a930-444e-8f17-69ba9d0e122f \
       --header 'Api-Access-Key: [API Key]' \
       --header 'accept: application/json' \
       --header 'content-type: application/json' \
       --data '{
    "fees": [
      { "type": "ADVISORY", "rate": 0.01, "startDate": "2025-02-20" }
    ]
  }'
  ```

  ```json Response theme={null}
  {
    "data": {
      "subaccountId": "cb80459c-a930-444e-8f17-69ba9d0e122f"
    }
  }
  ```
</CodeGroup>