Sub-Accounts and API Key Isolation: Limiting What One Key Can Do

One key should not be able to do everything

The useful question about an API key is not “is it secret” but “what can it do if it stops being secret.” A key that can place orders and a key that can withdraw are different instruments. One risks the trading balance; the other moves the balance out of the venue entirely.

Sub-accounts and permission scopes exist to separate those powers. They are not a substitute for keeping the key out of reach, and they do not make a compromised host safe. They decide how far the damage travels after the first mistake. The custody explainer covers why an exchange balance is a claim on an intermediary rather than an asset you hold directly; the same intermediary relationship is what makes an over-scoped key expensive.

What a sub-account changes at Binance

Binance describes sub-accounts as multiple accounts used to divide responsibilities and manage transactions. They are available to users who complete identity verification and enable two-factor authentication. Regular users are limited to five sub-accounts; VIP users get a limit that scales with their VIP level.

The details that matter for automation are less obvious:

• A sub-account can be created with a regular email, a virtual email, or through a third-party custodian. A virtual-email sub-account can only be operated by the master account through the API; the virtual email cannot be used to log in.
• Each sub-account can hold up to 30 API keys.
• The API order limits for each sub-account are the same as the master account’s: 100 spot orders per 10 seconds and 200,000 per 24 hours, with futures limits documented separately in the same FAQ.
• Sub-accounts cannot withdraw. The FAQ states that only the master account can manage asset transfers, and that transfers between sub-accounts and third-party accounts are not supported.

That last point is the structural one. On Binance, a sub-account is a trading container whose exit door is controlled by the master. A stolen sub-account key can trade the balance badly, but it cannot send the balance to an external address.

Permission scopes on a Binance key

Binance’s Spot API does not treat an API key as one all-or-nothing credential. Each endpoint has a security type, and the documentation lists TRADE, USER_DATA and USER_STREAM alongside NONE for public market data. The docs also state that an API key can be configured to allow access only to certain types of secure endpoints, and that by default a key cannot trade; trading has to be enabled in API Management.

The FAQ adds the part that catches people during setup. An unrestricted-IP HMAC key will not have any permission other than reading, and enabling other permissions requires one of: an IPv4 IP restriction, a self-generated Ed25519 or RSA key, or disabling the default security controls. Withdrawal permission is stricter still: adding an IPv4 IP restriction is mandatory before it can be enabled. Futures permission has its own edge case — a key created before the futures account was enabled, or while portfolio margin is active, cannot enable futures permission.

This is a useful default rather than an inconvenience. The path of least resistance produces a read-only key, and every step up in power requires a deliberate configuration change.

Why a trading bot should never hold withdrawal rights

A trading key and a withdrawal key fail differently.

If a trading key leaks, the attacker can place orders, cancel orders, and move the balance into bad positions. That is expensive and recoverable: the venue’s risk controls, the account owner’s monitoring and the fact that the coins remain on the exchange all limit the outcome. If a withdrawal key leaks, the coins leave. A withdrawal is final in a way that a trade is not, and it does not need the strategy to be wrong.

The practical rule is that the machine running the bot should hold no key with withdrawal permission, and preferably no key that can change security settings. Withdrawals are an operational action performed by a person, from a separate credential, ideally from a separate device. That is the same logic as clear signing versus blind signing: the authority to move value should not be bundled into the routine path that runs unattended.

On Binance the sub-account rule enforces part of this for you. On OKX a sub-account key is limited to read and trade as well, but the master key can carry withdrawal, so the separation depends on which credential the bot is allowed to hold.

OKX: a separate UID and a narrower key

OKX documents three API key permissions: read, trade and withdraw. Read covers account information such as bills and order history. Trade covers placing and canceling orders, funding transfers, and settings that require write access. Withdraw covers withdrawals. One or more permissions can be assigned to a key.

OKX also recommends binding keys to IP addresses, and documents that each key can bind up to 20 IPv4 or IPv6 addresses, including network segments. A key that is not bound to an IP and carries trade or withdraw permission expires after 14 days of inactivity. The same section states that only authenticated calls count as use, and that a WebSocket login counts while later actions on the connection do not.

The sub-account API is narrower than the master API. The endpoint for creating a sub-account API key documents perm values of read_only and trade only — withdrawal is not among them. It also requires the master account’s API key to be linked to IP addresses before it can create the key at all. Sub-accounts have individual User IDs, which is why OKX’s rate limits treat them as separate buckets.

A layout that limits the blast radius

A workable setup follows the shape of the permissions rather than the shape of the codebase:

• Keep the master key off automated hosts. On Binance the master controls transfers; on OKX it can carry withdrawal. Neither belongs on the server that runs a strategy.
• Give each strategy its own sub-account. This separates balances, key lists and, at OKX, rate-limit identity. It also makes revocation a single action rather than an audit.
• Use a read-only key for monitoring. Balances, positions, order status and fills do not need trade permission. A dashboard that can only read is a dashboard that cannot be turned into an attack tool.
• Scope trade keys to the IP addresses that actually run the bot. An allowlist does not survive a leaked key on an allowed host, but it defeats reuse from anywhere else.
• Rotate and inventory. A key that no one can identify is a key that no one will revoke. Record which strategy owns each key and when it was created.
• Watch the account, not only the bot. Binance documents login history for sub-accounts; OKX documents API key usage records in its Security Center. An unexpected login or a key used from a new address is the signal that the permission design is about to matter.

What isolation does not do

A sub-account is not a firewall around market risk. A trade key with a bad strategy can still lose the balance inside its scope, and a compromised trade key can cancel hedges, open positions and leave the account in a state that costs more to unwind than the original loss. Isolation limits where the damage stops, not whether it starts.

It also does not fix a shared secret. If the master key and the bot key sit in the same environment file, the permission split is decoration. The controls only work when the credential that can move assets is somewhere the bot cannot read.

Risk note. The permission names, limits and sub-account rules in this article come from Binance’s FAQ pages and Spot API documentation and OKX’s API documentation as read on 2026-10-25. Venue rules and default security controls change; verify the current settings in the venue’s API management page before relying on them. Nothing here is investment advice.