Using sub-accounts for automation
Figures on this page are as of 2026-09. Fees, limits and margin tiers change — check the venue's own docs before acting on a number.
A sub-account with bounded funds is the only control that limits damage from software behaving exactly as designed. Every permission flag protects against the software doing something it should not; a funding boundary protects against it doing what it was told, badly.
That distinction matters more as you hand more to automation, and it matters most for third-party code you did not write.
What permissions cannot bound
A trade-only API key cannot withdraw. Good, and it covers exfiltration.
It does not cover:
- A sizing bug that opens a position ten times too large.
- A model producing a plausible order with a decimal in the wrong place.
- A retry loop that doubles a position.
- A strategy that is simply wrong and loses steadily.
- An MCP server whose tool list changed in an update.
None of those require a permission the key lacks. They are authorised actions with unintended consequences, and no scope setting addresses them.
A sub-account does, because it bounds the pool the mistake can reach.
The model
Move a defined amount into a sub-account. Create keys scoped to it. Point the automation there.
The main account holds the rest, and there is no path from the automation’s credentials to it.
Blast radius becomes a number you chose rather than a property of your code being correct. That is a qualitatively different kind of assurance — the same distinction as read-only by construction versus read-only by configuration.
Venue mechanics
Binance supports sub-accounts with their own API keys. Two things to know:
The permission rules apply identically — a sub-account key with no IP whitelist still has its spot trading permission switched off after 90 days, and withdrawals still require IP restriction. Sub-accounts are not a different rule set, only a different balance. See Binance API key permissions.
And enableInternalTransfer covers master-to-sub transfers. An automation key
on a sub-account should not have it, or the boundary you just built has a door
in it.
Bybit supports sub-accounts with scoped keys. Note that sub-account activity
counts toward the same UID for session limits, which is relevant to 10003 on
classic accounts — see
Bybit API error 10003.
Hyperliquid has sub-accounts, and its agent wallet model interacts with them: a master account can approve API wallets to sign for the master or any of its sub-accounts. Combined with the fact that fund-moving actions cannot be expressed by an agent signature, this gives an unusually clean separation.
What you give up
Capital efficiency. Funds in a sub-account are not available elsewhere. For a margin-constrained setup this is a real cost.
Operational friction. Topping up and withdrawing are manual steps — which is also the point. A boundary you can cross without thinking is not a boundary.
Split reporting. Positions live in two places, and any tooling that assumes one account needs to know.
No cross-margin across the boundary. Correct, and worth stating: a sub-account cannot draw on the main account’s collateral, which is exactly the property you wanted.
Sizing the sub-account
The useful question is not “how much does the strategy need” but:
What is the most I am willing to lose to this software being wrong?
Fund that. Not more, because the funded amount is the maximum loss, and not so little that ordinary operation is constrained by minimum order sizes — see symbol filters and minimum order sizes.
Then top up on a schedule rather than on demand. Topping up because the automation ran out is a decision made under the influence of whatever just happened, which is the wrong time to be making it.
When it is most worth it
Third-party MCP servers. Most exchange MCP servers are community code — see where an MCP server keeps your API keys. A sub-account converts “I hope this code is correct” into “this code can cost me at most X”.
Anything unattended. Without a human in the loop, the funding boundary is the only limit that does not depend on your own software’s correctness.
A new strategy. During the period when you cannot yet evaluate it, the blast radius is the thing you control.
Multiple strategies. Separate sub-accounts give clean attribution and stop one strategy’s drawdown from consuming another’s margin.
What it does not replace
A sub-account is the outermost boundary, not the only one. Inside it you still want a daily loss limit, position caps, and read-only keys where trading is not needed. The sub-account bounds the worst case; those controls prevent reaching it.
FAQ
Why use a sub-account for trading automation?
Because it bounds damage from software working as designed but wrong — an oversized position, a retry that duplicates an order, a strategy that simply loses. Permission flags prevent unauthorised actions; they do nothing about authorised actions with bad consequences. A funded boundary is the only control that caps that.
Does a sub-account have different API key rules?
No. On Binance the permission rules apply identically to sub-accounts, including the 90-day expiry of spot trading permission on keys without an IP whitelist and the requirement that withdrawals need IP restriction. What differs is the balance at stake, not the rules.
How much should I put in a sub-account?
The most you are willing to lose to the software being wrong — since the funded amount is the maximum loss — but enough that minimum order sizes do not constrain normal operation. Top up on a schedule rather than when it runs out, so the decision is not made in reaction to what just happened.
Can the automation move funds out of the sub-account?
Only if you give it permission to. On Binance, enableInternalTransfer covers
master-to-sub transfers and should be off for an automation key — otherwise the
boundary has a door in it. Check the transfer flags alongside enableWithdrawals
rather than only the obvious one.