Exchange Sub-Account and API Key Permissions: Safe Setup Guide

The safe rule for exchange API keys is simple: give each key the smallest set of permissions it needs, keep withdrawal permission off unless you have a specific reason, and restrict the key to known IP addresses where the platform allows it. Sub-accounts are useful for separating strategies or team activity, but they sit under the main account’s identity verification. They do not create a second identity, and they are not a way around verification, regional or tax rules.

What sub-accounts are for

Many exchanges let a verified main account create sub-accounts. Typical legitimate uses are:

• Separating a trading bot’s funds from your long-term holdings
• Giving each strategy its own balance and history, which makes reporting easier
• Letting team members work within limits set by the account owner

What sub-accounts do not do: they are not a separate identity. They are created from, and controlled by, the verified main account, and activity in them is still linked to the main account holder. On Binance, for example, sub-accounts are available to users who have completed identity verification and enabled 2FA, regular users can create up to five (more at higher VIP levels), only the master account manages asset transfers, and transfers to third-party accounts are not supported. Do not give a sub-account to someone else to use as “their” account, and do not sell or rent sub-accounts. Availability and rules differ by platform and account type, so check the official help pages before setting them up.

API permission types in plain terms

Names vary, but most exchanges offer something like:

• Read / view: see balances, orders and history. Cannot move anything.
• Trade: place and cancel orders. Cannot send funds out.
• Transfer: move funds between your own accounts or sub-accounts, depending on the platform.
• Withdraw: send funds to external addresses. This is the dangerous one.

Platforms tie some of these to IP restrictions. On Binance, a system-generated (HMAC) key without an IP restriction can only read, and withdrawal permission requires an IPv4 restriction. On OKX, keys with trade or withdraw permission that are not bound to an IP are deleted after 14 days of inactivity, and one key can list up to 20 IP addresses.

Which permissions each tool really needs

Tool	Permissions it normally needs
Tax or portfolio tracker	Read only
Trading bot you run yourself	Read and trade, no withdrawal
Third-party trading service	Read and trade, with an IP restriction to the service’s published addresses
Moving funds between your own accounts	Transfer, only if the tool really needs it

If a service asks for withdrawal permission and you cannot explain exactly why, do not grant it. Legitimate tracking and trading tools generally do not need it.

Setup checklist for each key

1. Create a separate key for each tool, never one shared key for everything.
2. Give it a clear label, such as the tool’s name and the date.
3. Turn on only the permissions from the table above.
4. Add an IP restriction if the tool runs from fixed addresses. On Binance, a system-generated key without one is limited to reading, and withdrawal permission always requires one.
5. Store the secret key in a password manager or the tool’s secure settings. Never in chat, email or a document shared with others.
6. Record the key in a simple list: label, purpose, permissions, IP restriction, creation date, and when you will review it.

Review your keys regularly

Every few months, or whenever you stop using a tool, open the API management page and delete keys you do not need. When a team member leaves or a server is replaced, delete the old keys before creating new ones.

If a key may have leaked

Treat a key as exposed if it was pasted into a chat, committed to a code repository, saved on a shared or unknown server, or entered on a site you no longer trust.

1. Delete the key immediately on the exchange.
2. Check recent orders, transfers and withdrawals for anything you did not do.
3. Check your withdrawal address list for addresses you did not add. A withdrawal address whitelist helps here.
4. Change your password and check that your 2FA is still yours.
5. Contact official support if you find unauthorised activity.

API key mistakes to avoid

• Do not give withdrawal-enabled keys to “signal groups”, copy-trading strangers or “fund managers” you met online.
• Do not share your main account login with a team member when a sub-account or limited key would do.
• Do not use sub-accounts to let other people trade under your verification.

For keeping records that come out of your API-connected tools, see exporting transaction history for tax or a bank review.

Frequently asked questions

Does a tax app need withdrawal permission on my API key? No. Tax and portfolio tools only need to read your history and balances. A read-only key is enough.

Do sub-accounts need their own KYC? They are created under a main account that has already completed verification, and they remain linked to that account holder. Binance, for example, requires identity verification and 2FA on the main account before sub-accounts can be used. Check your exchange’s rules for your account type.

Is an IP restriction really necessary? It is one of the most effective protections. If a key leaks, it cannot be used from an address outside the list. On Binance it is also required: without it, a system-generated key is limited to reading.

How do I know if my API key was used by someone else? Look for orders, transfers or withdrawals you did not make, and new withdrawal addresses. If you see any, delete the key and contact official support.