Learn how to create and configure client subaccounts

In this section, we will review the following topics regarding subaccounts:

• What is a subaccount?
• The types of subaccounts and how balances and transactions work.
• How to think through your billing and fee configurations, which impact the way you configure your subaccounts.
• How to create and configure a subaccount.
• Additional subaccount FAQs and important considerations.
• Integration steps.

What is a subaccount?

A subaccount is an end client account, tied to one or more end client beneficial owners (e.g., institutional taxable account, joint account, Roth IRA) and represents one account on the ledger. Each wealth manager onboarded to Anchorage Digital Bank, has their own instance of the ledger, which will track crypto and USD positions and sits across their client's on-chain wallets and USD wallet balances.

The ledger has two types of subaccounts:

1. End client funds : Accounting of end client positions and transactions.
2. Anchorage Digital operational funds: Accounting for unassigned deposits, trades, settlement and withdrawals to ensure the ledger is balanced at all times. These are funds still owned by the end client but are automatically managed by the platform to ensure all balances tie out and reconcile at the end of each day.
   1. Network transaction fees for org : Funds deposited by Anchorage Digital for the purposes of covering all on-chain fees. These funds will not impact the ledger balances of the end client but will be seen when looking at wallets on-chain.
   2. FBO customer fees for org : Funds accrued for the purposes of paying subaccount and custody fees. This subaccount will only be impacted during the billing cycle.
   3. Payables and receivables for org : Funds held for the purposes of settling trades with liquidity providers.
   4. Unassigned funds for org: Funds that have not yet been assigned to a subaccount (e.g. in-kind Deposits with missing attribution information).

Each end client may have one or many subaccounts assigned to their customerId.

These subaccounts have asset position balances and transaction types, which correspond to the on-chain and off-chain activity. Funds within these subaccounts can be re-balanced within the end client's subaccounts, assuming they're settled.

Balances

These subaccounts have asset position balances and transaction types, which correspond to the on-chain and off-chain activity tied to the funds involved. Funds within these subaccounts can be re-balanced within an end client's subaccounts, assuming they're settled.

• availableForTrading: Balance you can trade with—may include funds that have not settled.
• availableForWithdrawal: Balance of settled funds available to withdraw, less any unsettled trades.
• totalBalance: Balance after each settlement is completed.

Subaccount transaction types

Each transaction type will impact the various subaccount balances and will have an associated status:

Subaccounts (Anchorage Digital operational + wealth manager operational)

• Naming conventions: Typically recommend a standard naming convention or UID for all end client subaccounts (e.g., A123_Robinson).
• Structure: You can leverage multiple subaccounts for each PC too facilitate various workflows and fee mitigation. We've seen some partners leverage.
  • Deposit subaccounts
  • Investment (1+)
  • Hold subaccounts
  • Withdrawal subaccounts
• External ID:externalSubaccountId is the unique client identifier created by the wealth manager for internal client management.

How does billing and fee configuration work

Billing

End clients, via their acceptance of Anchorage Digital Bank's terms & conditions, consent to debiting management and custody fees from their fiat balances in accordance with the agreed-upon fee schedule.

Anchorage Digital calculates the subaccount fees configured as isBillable = true and custody fees, then debits these from the USD balances on the 10th business day of the month. If these fees and amounts are communicated at the end of the month using 'manual billing' via API, Anchorage Digital will not be able to track these throughout the month but will still debit these fees and custody fees from the USD balance.

Net management fees are then remitted to the wealth manager. Transparency into the fee amounts and calculations are available to the wealth manager via API. Each wealth manager is responsible for managing end client USD balances to ensure there are sufficient amounts to debit fees each month.

Any subsequent changes to fee rates, are communicated by ADB to the end client directly via email notifications at the email address collected during onboarding due diligence.

Rates used for the purposes of calculating custody fees are those agreed to in the umbrella services agreement, signed by the wealth manager and Anchorage Digital Bank. Fee rates are based upon the assets under custody (AUC) aggregated at the wealth manager-level.

Custody statements are provided monthly to end clients and clearly identify management and custody fees debited from their subaccounts, as well as the rate used to calculate the management fee determined by the wealth manager.

Billing and fee management configuration

When getting started with your integration, it is important to think through the various billing configurations and how you would plan to manage fees and billing cycles.

There are a few important concepts we will dive into:

• Billing methods
• Fee model
• Fee visibility & tracking
• Fee types
• Fee accruals
• Fee calculation methodology
• Billing life-cycle
• Logistics and timing

Billing methods

There are various billing methods we enable you to choose from, depending on how the wealth manger would like to manage fees and billing:

Fee model

Fee types

Fee visibility and tracking

If you choose to leverage the automated fee model, and apply at least one of the three fees configured over API for the subaccounts, you will need to decide if you want to make these fees billable or not.

This enables you to more easily track and manage fees internally without exposing all fee granularity to your end clients. Depending on how you want to expose these fees will determine which fee bucket you fall into (Bundled or Unbundled/Fully disclosed)

Fee accruals

Within each subaccount, there will be an accruedFees section. This is meant to convey the estimated fees accrued on the account based on the average AUC, not the actual point-in-time fees on the account to-date.

Note: The termaccruedValue can be confusing and does not necessarily represent the actual fees to be charged based on the prior day's fee accruals. This value represents the average fee that has accrued based on the number of days and average AUC in the account. We do not recommended using this to display any sort of mid-month "performance net of fees" estimation, as this will not reflect the actual balance of fees for the number of days past but rather the average.

There are a few critical fields to note here:

Example subaccount with fee accruals

{  
			"createdAt": "2025-02-1T19:11:06.390Z",
      "customerId": "9bcbbb3136356ff85670085f64cfb4f53419a94277261be0094c4d97de71a4yb",
      "externalSubaccountId": "1A-13579-Doe",
      "fees": [
        {
          "isBillable": true,
          "rate": 0,
          "startDate": "2024-08-02",
          "type": "ADVISORY"
        },
        {
          "isBillable": false,
          "rate": 0.0025,
          "startDate": "2024-11-20",
          "type": "CUSTODY"
        },
        {
          "isBillable": true,
          "rate": 0,
          "startDate": "2024-08-02",
          "type": "MANAGEMENT"
        },
        {
          "isBillable": true,
          "rate": 0,
          "startDate": "2024-08-02",
          "type": "MODEL"
        }
      ],
      "name": "1A-13579-Doe",
      "subaccountId": "99fc9d84-4843-4a2c-95cc-1d90385c7955"
    },
    {
      "accruedFees": [
        {
          "accruedValue": "2982.05",
          "endPeriod": "2025-01-31",
          "rate": 0.351,
          "startPeriod": "2025-01-01",
          "state": "DONE",
          "totalBalanceInUSD": "100032.1",
          "type": "CUSTODY"
        },
        {
          "accruedValue": "1731.5",
          "endPeriod": "2025-02-18",
          "rate": 0.351,
          "startPeriod": "2025-02-01",
          "state": "ONGOING",
          "totalBalanceInUSD": "100031.22",
          "type": "ADVISORY"
        }
      ],
      "balances": [
        {
          "assetType": "BTC",
          "availableForTrading": "0.00018915",
          "availableForWithdrawal": "0.00018915",
          "totalBalance": "0.00032102"
        },
        {
          "assetType": "ETH",
          "availableForTrading": "0.19400093",
          "availableForWithdrawal": "0",
          "totalBalance": "0"
        },
        {
          "assetType": "USD",
          "availableForTrading": "87676.46",
          "availableForWithdrawal": "87676.46",
          "totalBalance": "100000"
        }

Fee calculation and methodology

Starting on the 2nd day of month 1, each subaccount will begin accruing fees based on the rolling average AUC in the account divided by the number of days held in the subaccount over that month. The "accrual" is not a net addition each day to the total fees listed as accrued, but rather a daily calculation using the rolling average logic.

This should not used to calculate performance-net-of-fees, but rather a rough estimate at how much you'll pay at the end of the month based on the current AUC.

🚧

Fee calculation

accruedValue = (AvgAUC x feeRate) x ( numberOfDays / 365)

Note: Avg AUC is calculated based on the totalBalance

Billing life-cycle

The following lifecycle applies to subaccount fees which are labeled as isBillable = true. For those listed as false, these will just revert to:

1. (January - day 1): Billing period starts and acrruedFee begins calculating at the end of the day. The state= ONGOING.
2. (January - day 2 - 30): Billing period reflects acrruedFeestarting on the 2nd.
3. (January - day 31st (or end of month): Billing period closes and the state= DONE.
4. (February- day 1): Fee transaction will show on the ledger at 8:00 am ET (1:00:00 pm UTC) as PENDING and the acrruedFee fee object will reflect DONE.
5. (Month 2 - day 2 - 9th business day): Billing dispute period. For any questions, please reach out to your account point of contact to raise any questions.
6. (Month 2 - day 10th business day): Billing transactions are finalized and the subaccount transaction will update to POSTED. Fees are then withdrawn from the subaccounts and remittance process back to wealth managers begins. Fee transactions will update on the ledger at 8:00 am ET (1:00:00 pm UTC).

Note: For subaccounts with mid-month billing period, the fees will be pro-rated to only consider the days with an active subaccount.

Additional billing considerations

1. Manual billing method: This needs to be submitted by partner via manual billing API end-point prior to the 10th business day to ensure Anchorage can process this in time to pay out on the 10th business day.
2. Cash management for billing: Keep 3 months of USD in the subaccout for billing, rather than requiring liquidation events, which trigger taxable events for the end client.
3. 0-rate subaccount fees: If the rate is “0”, nothing is accrued or posted as a transaction.
4. Negative USD balances: If the current USD balance is insufficient mid-month, the ledger reflects a negative USD balance. This needs to be offset before the 10th business day to ensure sufficient funds are available to withdrawal the correct amount the subaccount.
5. Rate changes: Anchorage Digital will send an email notification to the end client to notify them when rates are created or changed, only for fees that are Billed (isBillable = true).
6. Fees to be set in percentage terms: When configuring the fee, configure the fee to be set in percentage terms.
   1. 1% fee = 0.01 rate value

Integration steps: Subaccount creation

Subaccount applications can be created tied to one or two end clients. The following account types are supported, with the number of linked end client and client types shown:

Note: For each end client subaccount, we require a signer who can serve as an authorized individual to represent the client. The signer can be the actual client or someone else.

Step 1: Create an end client subaccount application

POST /v2/onboarding/subaccounts

• applicationType: RIA_PC_ACCOUNT
• externalId: unique identifier used by the wealth platform to identify this subaccount
• submit - optional boolean flag to indicate if it should submit the request right away or if there will be more changes on the application and will be submitted later.
• entries - refer the table below to check all the possibilities for the entries object. Also check all examples below for all the accounts possibilities and requirements.

The endpoint accepts the following entries data:

A unique subaccountId is returned, which will be used in all future calls to identify this wealth platform customer at Anchorage Digital.

Sample

Request:

{
    "name": "{{name}}",
    "externalId": "{{externalId}}",
    "submit": true,
    "entries": [
        { "key": "legalEntityName", "value": "SubAccount IRA ROLLOVER" },
        { "key": "accountType", "value": "IRA" },
        { "key": "accountSubtype", "value": "ROLLOVER" },
        { "key": "documentPreferenceAddressDefaultEmail", "value": "[email protected]" },
        { "key": "programSignerGroup", "value": [
                {
                    "programSignerFirstName": "Kevin",
                    "programSignerLastName": "Flynn_5",
                    "programSignerEmail": "[email protected]"
                },
                {
                    "programSignerFirstName": "Kevin",
                    "programSignerLastName": "Flynn_6",
                    "programSignerEmail": "[email protected]"
                }
            ]
        },
        { "key": "programCustomers", "value": [
                {
                    "programCustomerId": "{{customerId1}}",
                    "programCustomerRole": "PRIMARY"
                }
            ]
        },
        { "key": "beneficiaryGroup", "value": [
                {
                    "beneficiaryType": "SPOUSE",
                    "beneficiaryName": "Test beneficiary",
                    "beneficiaryAllocation": "50"
                },
                {
                    "beneficiaryType": "CHARITY",
                    "beneficiaryName": "Test beneficiary 2",
                    "beneficiaryAllocation": "50"
                }
            ]
        },
        { "key": "contingencyBeneficiaryGroup", "value": [
                {
                    "beneficiaryType": "FAMILY_OR_FRIEND",
                    "beneficiaryName": "Test beneficiary 3",
                    "beneficiaryAllocation": "25"
                },
                {
                    "beneficiaryType": "TRUST",
                    "beneficiaryName": "Test beneficiary 4",
                    "beneficiaryAllocation": "75"
                }
            ]
        },
        { "key": "fees", "value": [
                {
                    "feeType": "ADVISORY",
                    "feeRate": "0.1"
                },
                {
                    "feeType": "MANAGEMENT",
                    "feeRate": "0.25",
                    "feeIsBillable": true
                }
            ]
        }
    ]
}

Step 2: Check the status of the end client subaccount application

GET /v2/onboarding/subaccounts/{{subaccountId}}

Any errors or missing documents will be listed in the errors section of the returned JSON.

Sample

Response:

{
  "data": {
    "entries": [
      {
        "key": "programSignerGroup",
        "value": [
          {
              "programSignerFirstName": "Kevin",
              "programSignerLastName": "Flynn_5",
              "programSignerEmail": "[email protected]"
          },
          {
              "programSignerFirstName": "Kevin",
              "programSignerLastName": "Flynn_6",
              "programSignerEmail": "[email protected]"
          }
        ]
      },
      {
        "key": "documentPreferenceAddressDefaultEmail",
        "value": "[email protected]"
      },
      {
        "key": "accountType",
        "value": "IRA"
      },
      {
        "key": "accountSubtype",
        "value": "ROLLOVER"
      },      
      {
        "key": "programCustomers",
        "value": [
          {
            "programCustomerId": "43a37de2dcc326579fe9ab3a187c48b786007bd759802dfa04ef1aa35383a273",
            "programCustomerRole": "PRIMARY"
          }
        ]
      }
    ],
    "errors": [],
    "externalId": "37c4abc1-b94b-48d7-a41b-c4e4becc865a",
    "name": "SubAccount IRA ROLLOVER 20250407-2",
    "status": "IN_PROGRESS",
    "subaccountId": "4305271f-7c1c-4b72-bb80-82b2e144d19d"
  }
}

Step 3: Submit the application (if submit = false)

POST /v2/onboarding/subaccounts/{{subaccountId}}/submit

Step 4: Check the subaccount approval status

GET /v2/subaccounts/customers/accounts?subaccountIds={{subaccountId}}

This will return details of the subaccount, and its approval and creation status. When received but pending approval, the status will be PENDING. When approved and created, the status will be OPEN.

Alternatively you can register for a webhook asynchronous response for an event when the subaccount is opened. Information on registering for webhooks is available here.

Sample

{
   "data": {
       "applicationId": "6ba46417-66dc-424e-8e68-4fbd2597d993",
       "entries": [
           {
               "key": "programSignerGroup",
               "value": [
				          {
				              "programSignerFirstName": "Kevin",
				              "programSignerLastName": "Flynn_5",
				              "programSignerEmail": "[email protected]"
				          },
				          {
				              "programSignerFirstName": "Kevin",
				              "programSignerLastName": "Flynn_6",
				              "programSignerEmail": "[email protected]"
				          }
               ]
           },
           {
               "key": "programCustomers",
               "value": [
                   {
                       "programCustomerId": "43a37de2dcc326579fe9ab3a187c48b786007bd759802dfa04ef1aa35383a273",
                       "programCustomerRole": "PRIMARY"
                   }
               ]
           },
           {
               "key": "accountSubtype",
               "value": "ROLLOVER"
           },
           {
               "key": "accountType",
               "value": "IRA"
           },
           {
               "key": "beneficiaryGroup",
               "value": [
                   {
                       "beneficiaryAllocation": "50",
                       "beneficiaryName": "Test beneficiary",
                       "beneficiaryRelation": "Primary",
                       "beneficiaryType": "Spouse"
                   },
                   {
                       "beneficiaryAllocation": "50",
                       "beneficiaryName": "Test beneficiary 2",
                       "beneficiaryRelation": "Contigency",
                       "beneficiaryType": "Charity"
                   }
               ]
           },
           {
               "key": "fees",
               "value": [
                   {
                       "feeRate": "0.1",
                       "feeType": "Advisory"
                   },
                   {
                       "feeIsBillable": "Yes",
                       "feeRate": "0.25",
                       "feeType": "Management"
                   }
               ]
           },
           {
               "key": "documentPreferenceAddressDefaultEmail",
               "value": "[email protected]"
           },
           {
               "key": "legalEntityName",
               "value": "SubAccount IRA ROLLOVER"
           }
       ],
       "errors": [],
       "status": "COMPLETE"
   }
}

Changelog