Sub-Accounts: Separating Risk

An exchange sub-account is a separate trading balance that sits under one master account but keeps its own positions, margin and, usually, its own API keys. It is the cheapest risk control available on a centralized venue, and most traders never turn it on.

The point of an exchange sub-account is containment. If one strategy blows up, the loss stays inside the container instead of reaching the balance that funds everything else. The mechanics are simple, but the details vary by venue, and the differences matter more than the marketing suggests.

• Sub-accounts separate margin and positions, but not always the custody risk of the venue itself.
• Most venues let you scope API keys per sub-account, which limits the blast radius of a leak.
• Transfers between sub-accounts are usually internal and free, unlike withdrawals to an external chain.
• Segmentation fails if the master account keeps withdrawal rights or shared collateral enabled.

What an exchange sub-account actually isolates

It isolates margin, positions, order history and permissions. It does not isolate counterparty risk. Funds on the same venue share the same custodian, the same operational failures and the same withdrawal queue.

That distinction should drive how you use them. Sub-accounts are excellent at stopping one strategy from liquidating another. They are useless against the venue itself freezing withdrawals, and they do not protect you if the entity holding the assets fails. For that risk you need a different venue, not a different sub-account.

The four things that are separated

Balance, margin, positions and API credentials are what typically move into a sub-account. Each one has its own consequences.

• Balance — the collateral available to that container only. A loss elsewhere cannot touch it, and vice versa.
• Margin — leverage is calculated per account, so a heavily used strategy does not consume the borrowing capacity of a conservative one.
• Positions — netting happens within the container. Two opposing positions in different sub-accounts stay open instead of offsetting.
• API credentials — keys issued to a sub-account normally cannot read or trade the master account, which is the single most useful property.

What stays shared

KYC identity, fee tier treatment, deposit addresses, and the legal relationship with the venue usually remain at master level. Some venues aggregate volume across sub-accounts for fee tiers; others do not. Some allow internal transfers instantly; others batch them.

Check three settings before you rely on the structure: whether the master can withdraw from sub-accounts without approval, whether negative balances in one sub-account can be covered from another, and whether margin is shared by default. Any of these enabled quietly defeats the purpose.

Why separating risk with an exchange sub-account pays off

Because the most common account failure is not theft — it is one strategy consuming the collateral that another strategy needed.

Consider a funding-rate position that is correctly hedged but temporarily underwater, running in the same account as a directional position with a tight stop. The hedge needs margin to stay open. The directional trade’s losses reduce available margin. The venue liquidates whichever position is closest to the line, which may be the hedge you intended to keep. Two sub-accounts make that interaction impossible.

Operational separation beats mental separation

Keeping strategies apart “in a spreadsheet” is not separation. If they share one balance, one liquidation engine treats them as one portfolio. The engine does not care about your labels.

This is also why sub-accounts matter for automation. A bot with a key that can only touch its own container cannot drain the rest of your account through a bug, a bad config, or a compromised API secret. That is a real limit, not a theoretical one.

How sub-account models compare

Models differ in where the boundary sits, and the differences change what you can safely automate.

Segmentation is only real when the failure of one container cannot reach the collateral of another. Everything else is bookkeeping.

Setting one up without creating new failure modes

Setup takes minutes, and the ordering matters more than the clicks.

1. Decide the boundary first: one sub-account per strategy, per client, or per risk budget. Mixed boundaries produce containers nobody can reconcile.
2. Create the sub-account and fund it with only the collateral that strategy needs, not a round-share of your total.
3. Disable master-level withdrawal rights over the sub-account if the venue allows it, or remove withdrawal permission from every key.
4. Issue a fresh API key scoped to that sub-account, with IP allowlisting where available and no withdrawal permission.
5. Set a notional cap in your own code as well, because venue-side limits are the second line of defence, not the first.
6. Record which key belongs to which container in one place, and test the separation with a small deliberate transfer.
7. Review monthly: dormant sub-accounts accumulate balance and become an unmonitored attack surface.

A simple allocation example

Suppose 10,000 units of quote currency are split three ways: 5,000 for a spot core position, 3,000 for a hedged basis trade, 2,000 for a high-turnover experimental strategy. If the experimental container loses its entire 2,000, the other two are untouched, because the liquidation engine never saw them. In a single account, that same loss would have reduced shared margin by 20 percent and could have forced a partial unwind of the hedge at the worst moment.

The arithmetic is the argument. Containment converts an unbounded portfolio event into a bounded, pre-agreed loss.

Mistakes that quietly undo the separation

Most failures come from configuration drift rather than from the model itself.

• Shared collateral switched on for convenience, which links every container again.
• One master key reused across bots, so a single leak reaches everything.
• Sub-accounts used as a filing cabinet, with balances left idle in containers nobody watches.
• Withdrawal permission granted to a trading key “just in case”, which turns a trading bug into a full loss.

Each of these is reversible, and each is worth checking before the next deposit rather than after the next incident.

Reconciliation is the other quiet failure. Once balances live in several containers, your total exposure is no longer visible on one screen, and a position you believe is hedged may be hedged in a container that no longer holds enough collateral. Export balances on a fixed schedule and add them up yourself.