Why a Trading Bot Should Never Have Withdrawal Permission
Connecting a bot or trading platform to your exchange account means creating an API key — a credential that lets software act on your account. The single most important security decision in that process takes one click: leaving withdrawal permission off.
This article explains what API permissions actually control, why trading automation never needs withdrawal access, and what a safe setup looks like.
API keys are permission bundles
When an exchange account owner creates an API key, the exchange asks which permissions the key should carry. The standard set:
| Permission | What it allows |
|---|---|
| Read | View balances, positions, and history |
| Trade | Place and cancel orders |
| Withdraw | Send funds out of the exchange |
These are independent switches. A key can trade without being able to withdraw — and this separation exists precisely so account owners can give software the minimum access it needs.
Trading never requires withdrawal access
Everything a trading bot does — reading the market, opening positions, closing them, checking margin — is covered by read and trade permissions. There is no step in any trading strategy that requires moving funds off the exchange. A platform that asks for withdrawal permission is asking for access it does not need for its stated function.
The practical consequence of a withdrawal-disabled key: even in the worst case — the platform is compromised, or the key leaks — the funds cannot leave your exchange account. An attacker holding a trade-only key could at most place bad trades, which is damaging but bounded; they cannot drain the account to an external wallet.
The checklist for a safe connection
- Create the key yourself, in your own exchange account. You should be the only person who ever sees the secret.
- Enable read and trade only. Withdrawal stays off. On most exchanges this is the default — leave it that way.
- Prefer platforms that enforce this. The strongest signal is a platform that rejects keys with withdrawal permission enabled, making the safe configuration mandatory rather than optional.
- Fund with a defined budget. If the key belongs to a sub-account, the sub-account's balance is the most the strategy can ever put at market risk — a structural cap on exposure (see Why Each Trading Strategy Should Run in Its Own Sub-Account).
- Revoke unused keys. Keys for services you no longer use should be deleted in the exchange's API management page.
Non-custodial automation: the broader principle
The withdrawal-permission rule is one piece of a larger design called non-custodial automation: your funds never move to the platform — they stay in your own exchange account, and the platform operates through the limited API key you issued. Contrast this with custodial arrangements, where you deposit funds into a service's wallet and depend entirely on that service's solvency and honesty.
The difference matters most when something goes wrong. In a non-custodial setup, disconnecting is always available: delete the API key at the exchange and the platform's access ends immediately, with funds untouched in your account.
ONYX follows this model as a matter of policy: it only accepts withdrawal-disabled API keys — keys with withdrawal permission enabled are rejected at registration — and user funds remain on the user's own exchange (Toobit or BingX) at all times. How this fits the rest of the platform's security design is described on the ONYX home page.
Summary
- API permissions are separable; trading software needs read + trade, never withdraw.
- A withdrawal-disabled key bounds the worst case: funds cannot leave your exchange.
- The safest platforms make this configuration mandatory.
- Combined with sub-account budgeting, the total exposure of any single strategy is capped in advance.
This article is for general information only and is not financial advice. Futures trading carries risk of principal loss and liquidation. Past results do not guarantee future performance.