A crypto exchange account is a database record and permission structure that links user identity to order execution, custody, and settlement systems. Unlike a wallet, which holds keys and presents a direct onchain interface, an exchange account operates as an entry in a centralized ledger maintained by the exchange. Understanding how these accounts function internally, how balance reconciliation occurs, and where custody boundaries lie is essential for anyone executing nontrivial trade volume or managing operational risk.
This article examines account structure, balance mechanics, API access control, and the edge cases that separate a well configured account from one vulnerable to lockout, misallocation, or unintended liquidation.
Account Identity and Permission Layers
Most exchanges structure accounts around three identity components: a unique identifier (typically a UUID or sequential integer), an email or phone anchor for authentication, and a permission tier that determines API capabilities, withdrawal limits, and access to derivative products.
The permission tier is usually derived from a KYC verification level. A tier one account might allow deposits and spot trading but restrict withdrawals below a daily threshold. Tier two typically requires government ID and unlocks higher limits. Tier three adds proof of address and may enable margin or futures. Each tier maps to a different database role with distinct query permissions.
Subaccounts introduce a parent-child relationship. The parent account holds the primary KYC record, and each subaccount inherits the parent’s permission ceiling but can enforce stricter rules. Subaccounts maintain separate balances and isolated order books, useful for segregating strategies or managing client funds under a single entity. API keys issued to a subaccount cannot access sibling subaccounts unless explicitly granted.
Balance Representation and Reconciliation
Balances exist as rows in an internal ledger, not as onchain state. When you deposit 10,000 USDC to an exchange, the exchange credits your account and pools that capital in a hot or cold wallet shared with other users. Your balance is an accounting entry, not a custody claim on specific UTXOs or token IDs.
Exchanges reconcile balances at multiple intervals. Hot wallet balances are checked continuously (often every block or every few seconds). Cold wallet reconciliation happens less frequently, sometimes daily or weekly. Discrepancies trigger alerts. A mismatch between the sum of all user balances and the actual onchain holdings indicates either a software bug, a database corruption event, or a security incident.
Some exchanges publish Merkle tree proofs of reserves. These proofs commit to the total liabilities (user balances) and link them to verifiable onchain assets. The exchange generates a Merkle tree where each leaf represents a hashed account balance, publishes the root, and provides each user a path proving their balance was included in the snapshot. This does not prove solvency in real time, but it does demonstrate that the exchange held sufficient assets at the moment the tree was generated.
API Key Scopes and Execution Contexts
API keys grant programmatic access to an account. Each key has a scope: read-only keys return balance and order history, trade keys submit and cancel orders, and withdrawal keys authorize offchain transfers. Some exchanges allow IP whitelisting, tying a key to a specific address range.
Keys operate within an execution context. If you create a key scoped to a subaccount, that key sees only the subaccount’s balances and orders. Parent account keys can often read from all subaccounts but may not be able to trade on their behalf unless explicitly enabled.
Rate limits apply per key, per IP, or per account depending on the exchange’s architecture. Exceeding the limit returns an HTTP 429 response and may trigger a temporary ban. High frequency traders negotiate elevated limits or use websocket feeds with lower overhead than REST polling.
Custody Model and Withdrawal Pathways
Exchanges operate on a fractional custody model. User deposits flow into pooled wallets, and the exchange maintains a reserve ratio. A healthy exchange keeps the majority of funds in cold storage (offline wallets requiring multisig or hardware security modules) and a smaller hot wallet for instant withdrawals.
Withdrawal processing involves multiple checkpoints. The exchange verifies the API key permissions, checks the daily limit, runs AML screening against the destination address, and queues the transaction. Small withdrawals clear automatically. Large ones may trigger manual review or require additional 2FA challenges.
Some exchanges batch withdrawals to reduce gas costs. Instead of broadcasting one transaction per withdrawal, they aggregate multiple requests into a single onchain transaction. This introduces latency (batches execute every N minutes) but lowers the per-user fee.
Worked Example: Subaccount Liquidation Cascade
You operate a parent account with three subaccounts, each running a different futures strategy. Subaccount A is long BTC perpetuals at 5x leverage, subaccount B is short ETH futures, and subaccount C holds spot reserves. Subaccounts are isolated: a liquidation in A does not touch B or C.
BTC drops 15% in an hour. Subaccount A’s margin ratio falls below the maintenance threshold (typically around 2.5% to 5% depending on the exchange). The liquidation engine takes over, closing the position at market. The realized loss exceeds the subaccount’s collateral. Subaccount A is now zeroed, but B and C are unaffected.
Had you configured cross-margin mode on the parent account instead, the engine would have drawn from subaccounts B and C to cover A’s shortfall, potentially liquidating positions across all strategies. Isolated margin prevents contagion but requires active monitoring of each subaccount’s health.
Common Mistakes and Misconfigurations
- Using the same API key across multiple bots without rate limit coordination. Bots compete for the key’s quota, triggering 429 errors and missing fills.
- Enabling withdrawal permissions on keys deployed to cloud servers. If the instance is compromised, the attacker can drain the account.
- Failing to set subaccount leverage limits. A misconfigured bot can open overleveraged positions, triggering instant liquidation.
- Ignoring the exchange’s websocket heartbeat protocol. Silent disconnects leave your bot blind to order status and fills.
- Assuming balance updates are synchronous. Some exchanges delay balance changes by hundreds of milliseconds, causing double-spend logic errors in high frequency strategies.
- Not monitoring withdrawal address whitelists. If you whitelist an address and later lose access to that wallet, you’ve locked yourself out of your own funds.
What to Verify Before You Rely on This
- The current KYC tier requirements and withdrawal limits for your jurisdiction.
- Whether the exchange publishes proof of reserves and the frequency of snapshots.
- The specific margin calculation method (cross vs. isolated, initial vs. maintenance ratios).
- API rate limits for your account tier and whether websocket feeds are available.
- The withdrawal batching schedule and whether manual review applies above a certain threshold.
- The exchange’s policy on account recovery if 2FA is lost.
- Whether subaccounts inherit API keys or require separate provisioning.
- The exchange’s cold wallet to hot wallet ratio (if disclosed).
- The grace period before a liquidation becomes irreversible.
Next Steps
- Audit your API keys: revoke unused keys, scope active keys to the minimum required permissions, and enable IP whitelisting.
- Set up subaccounts for strategies that should not share margin, and test liquidation behavior in a paper trading environment.
- Implement balance reconciliation checks in your trading stack, comparing API reported balances against your internal ledger at regular intervals.
Category: Crypto Exchanges
