automation
Connecting a bot, a dashboard or a copy service to an exchange account means issuing an API key. The permissions attached to that key are the entire security model, and the defaults are usually more generous than they need to be.
The permission ladder
| Permission | What it allows | Grant it? |
|---|---|---|
| Read | Balances, positions, trade history | Yes, for dashboards and reporting |
| Trade | Place and cancel orders | Only for a service that must trade |
| Margin or futures | Leveraged positions | Only if that is the explicit purpose |
| Withdraw | Move assets off the venue | No. There is no legitimate third-party use |
| Internal transfer | Move between sub-accounts | Rarely. Treat as close to withdrawal |
Six settings that do most of the work
- 01Bind every key to a fixed IP address. A stolen key is useless from elsewhere.
- 02One key per service. Revoking one then costs nothing.
- 03Set an expiry and rotate on a schedule you actually keep.
- 04Use a sub-account with a capped balance for anything automated.
- 05Turn on withdrawal address allowlisting at the account level, independent of keys.
- 06Store secrets outside the code. Keys in a repository are the most common single failure.
Operational habits
Log every order your automation sends, separately from the venue record, so the two can be reconciled. Alert on unexpected order volume rather than on price. And rehearse the kill switch: know exactly how to revoke a key and flatten positions manually, before the day you need to do it quickly.
A key with trade permission can lose you money. A key with withdrawal permission can end the account.
Written by Aram Latifi. Ex-quant developer, now writing about the plumbing of retail trading. No affiliate links on this site.
