B2B2X accounts

​

ADx vs. wealth

​

Key concepts

• FBO account — a “for benefit of” arrangement where you hold the account relationship, and the funds within it belong to your end clients. You are the account holder of record.
• End client — the client of our client. The party you serve in a B2B2X relationship.
• Vault — the top-level container in the org model. Carries its own permission set and governance (quorum, approvers).
• Wallet — sits inside a vault and holds a single asset. Every wallet maintains a true balance and transaction history. The mapping of a given wallet to a given end client is maintained at the Anchorage Digital Bank (ADB) level.

​

Fiat: deposit information is client-specific identity

• Sub-account — a wallet whose deposit instructions resolve to your legal name as the account holder of record. This is what Anchorage Digital supports today. Fiat wallets are sub-accounts with real balances, not pass-through virtual accounts.
• Named account — a sub-account whose deposit instructions bear the end client’s name rather than yours, so the end client can receive wires addressed to them directly. In development.
• True virtual account — a pure pass-through set of deposit instructions in the end client’s name, where Anchorage Digital doesn’t track the end client’s balance. Not available.

​

Crypto: the wallet address carries no identity

• There’s no client-specific deposit instruction to name. The address can stay obscured to the end client without losing anything, because it conforms to crypto standards rather than carrying identity.
• There’s no crypto FBO or named-account concept, because there’s nothing on the address to name. Segregation is handled entirely by which wallet maps to which end client at the ADB level.

​

Structures available today

​

Segregated vaults and wallets per end client

• You submit a KYC package for the end client to Anchorage Digital’s compliance team.
• Once compliance approves, you create a vault in that end client’s name with a dedicated wallet, used exclusively for that client.
• The wallet holds a real balance. The end-client-to-vault association is tracked at the ADB level.
• Deposit instructions on the wallet resolve to your legal name as the account holder of record.

1. In the web dashboard, create vaults in advance as empty shells: unfunded, unnamed, and not exposed to the end client.
2. Pre-assign each vault the permission set you want to govern it (quorum, approvers).
3. Upon KYC approval, name the vault to the end client and put it into use. The USD wallet already exists from vault creation; add any crypto wallets with POST /v2/vaults/{vaultId}/wallets.

​

Step 1: Confirm or create the wallet

• USD — the vault already has its USD wallet (vault creation provisions it). You don’t create one. Fetch it with GET /v2/wallets/{walletId} to read its wire instructions.
• Crypto — create a wallet per asset in the end client’s vault. Use POST /v2/vaults/{vaultId}/wallets with the assetTypeID set to the asset ticker (for example BTC, ETH), then fetch it to read its deposit address.

{
  "assetTypeID": "BTC",
  "name": "End Client A BTC"
}

​

Step 2: Fund the wallet

"fiatDetails": {
  "accountNumber": "123456789",
  "bankId": "987654321",
  "bankName": "Anchorage Digital Bank",
  "fedWire": "WIRE12345",
  "memo": "Q1 Payout",
  "name": "Jane Doe"
}

​

Step 3: Withdraw

{
  "assetTypeID": "USD_R",
  "source": {
    "type": "WALLET",
    "id": "24bd12752fcbaec0100d20fa6c3b1a06"
  },
  "destination": {
    "type": "STANDING_INSTRUCTION",
    "id": "9f1c2b7a-2f7e-4a3f-9a5d-0c1a2b3d4e5f"
  },
  "amount": {
    "amount": "250000.00",
    "currency": "USD"
  },
  "clientReferenceId": "withdrawal-2025-10-31-0001",
  "note": "Treasury rebalance"
}

• assetTypeID — USD_R in staging and USD in production for fiat, or the asset ticker for crypto.
• source — the end client’s wallet (type: WALLET, id: the wallet ID).
• destination — the approved Trusted Destination. Fiat withdrawals use a standing instruction (STANDING_INSTRUCTION); both fiat and crypto can target a TRUSTED_DESTINATION.
• clientReferenceId — your idempotency and reconciliation key.

​

Omnibus plus your own sub-ledger (reliance)

1. Reliance approval. Anchorage Digital’s compliance team must approve a reliance arrangement with you, relying on your KYC program for your end clients rather than KYC’ing each one directly. This is granted case by case and isn’t available to every client.
2. You maintain the sub-ledger. Anchorage Digital tracks the pooled balance. Per-end-client balances are yours to maintain. Building and operating that sub-ledger is non-trivial work that sits on your side.

​

What’s coming

• Named accounts — sub-accounts that carry the end client’s own name and deposit instructions, so end clients receive wires addressed directly to them while funds still settle within your account. In active build.
• True virtual accounts (native pass-through) — pass-through deposit instructions in the end client’s name where Anchorage Digital doesn’t maintain the end client’s balance, with native sub-ledgering on Anchorage Digital’s side. A known future need, not currently being built. Clients who require native sub-ledgering at retail scale today typically use a third-party ledger provider.

​

Choosing your structure

• You want Anchorage Digital to segregate and KYC each end client, with real per-client balances: segregated vaults and wallets. Recommended for most clients.
• You’re a large, sophisticated platform that wants one account and will run your own sub-ledger, and you can qualify for reliance: omnibus plus reliance.
• You need end clients to receive wires in their own name: named accounts, once available. Use segregated vaults and wallets in the meantime.
• You’re a retail-scale wealth platform onboarding end clients under reliance: see the Wealth management overview.