Fund and manage subaccounts - Anchorage Digital

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.

Create a subaccount-specific deposit wallet

Create one wallet per subaccount per asset using the Create Wallet endpoint, 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

Wallet creation is limited to 10 wallets per asset per 30 minutes. This limit will increase in coming months.

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.

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.

Monitor for deposits

Use webhooks 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.

Ensure end clients only deposit supported assets. Deposits of unsupported assets into a wallet will result in lost funds.

Attribute the deposit

See Attribution steps below.

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 dashboard (API not available in production).

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.

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.

Spam / unknown deposits

Attribute dust or spam deposits as SPAM using the spam attribution API. 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 — Reference

curl --request GET \
     --url https://api.anchorage-staging.com/v2/vaults \
     --header 'Api-Access-Key: [API Key]' \
     --header 'accept: application/json'

Step 2: Create a deposit wallet for the subaccount

POST /v2/vaults/{vaultId}/wallets — Reference

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"
}'

Sandbox testnet assets: BTC_T (BTC testnet), ETHHOL (ETH Holesky), USDANCHOL (USDC Holesky)

Step 3: Identify a new deposit

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

Response

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

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

Webhook payload

{
  "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} — Reference 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).

For spam/dust deposits, use the spam attribution endpoint instead to prevent unwanted balances from appearing on the subaccount.

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"
}'

After attributing in-kind deposits, update the missing cost basis via the tax transaction endpoint.

Step 5: Generate a wire memo for USD funding

GET /v2/subaccounts/accounts/{subaccountId}/bank-info — Reference

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'

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.

Step 6: View subaccount balances

GET /v2/subaccounts/customers/{customerId}/accounts — Reference

curl --request GET \
     --url https://api.anchorage-staging.com/v2/subaccounts/customers/{customerId}/accounts \
     --header 'Api-Access-Key: [API Key]' \
     --header 'accept: application/json'

Step 7: Move funds between same-client subaccounts

POST /v2/subaccounts/transactions — Reference Only settled funds can be moved. Use availableForWithdrawal for the settled balance. Cannot move funds between different end clients.

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"
    }
  ]
}'

Use idempotentId on bulk subaccount transactions to prevent duplicate submissions.

Step 8: Update subaccount billing fees or dates

PATCH /v2/subaccounts/accounts/{subaccountId} — Reference

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.

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" }
  ]
}'

​Fund with USD

​USD funding considerations

​Fund in-kind with digital assets

​Deposit attribution

​Status values

​Attribution type values

​Trusted sources

​Spam / unknown deposits

​Automated attribution from VASPs

​Integration steps

​Step 1: Get your vaultId

​Step 2: Create a deposit wallet for the subaccount

​Step 3: Identify a new deposit

​Step 4: Attribute the deposit

​Step 5: Generate a wire memo for USD funding

​Step 6: View subaccount balances

​Step 7: Move funds between same-client subaccounts

​Step 8: Update subaccount billing fees or dates

Fund with USD

USD funding considerations

Fund in-kind with digital assets

Deposit attribution

Status values

Attribution type values

Trusted sources

Spam / unknown deposits

Automated attribution from VASPs

Integration steps

Step 1: Get your `vaultId`

Step 2: Create a deposit wallet for the subaccount

Step 3: Identify a new deposit

Step 4: Attribute the deposit

Step 5: Generate a wire memo for USD funding

Step 6: View subaccount balances

Step 7: Move funds between same-client subaccounts

Step 8: Update subaccount billing fees or dates