Permissions: trading yes, withdrawals never
Exchange API keys carry granular permissions, and the only ones automated trading needs are: read account data, place and cancel orders. Withdrawal permission is never required — a service that asks for it is either built carelessly or built maliciously, and in both cases the correct response is to leave.
A trade-only key bounds your worst case: even if it leaked publicly, an attacker could not move funds off the exchange. The remaining abuse (manipulative trading against your account) is real but far smaller, and the next section closes most of it too.
API key permissions
Set this on the exchange before connecting
-
Read market dataOn
-
Place orders / TradeOn
-
Withdraw fundsNever enableOff
IP whitelisting: the strongest lock most people skip
Every major exchange lets you bind an API key to specific IP addresses: requests from anywhere else are rejected before the signature is even checked. A whitelisted key that leaks is close to useless — the attacker would need to control the exact server behind your IP as well.
The catch: whitelisting requires a STABLE address, which shared-infrastructure services cannot honestly offer. Arbitron gives every user a dedicated server with its own static IP precisely so whitelisting works — your keys are pinned to one machine that runs only your trading. Whatever service you use, ask what address its requests come from and whether it is yours alone.
Storage: questions any service must answer
The 2022 breach of a major bot platform leaked ~100,000 API keys and drained roughly $20M from user accounts — the failure mode is not hypothetical. Before connecting keys anywhere, get answers to three questions: how are keys encrypted at rest, is there one master key that decrypts every user at once, and do keys ever appear in logs or backups in plain text.
Arbitron's answers, verifiable on our security page: AES-256-GCM encryption, an individual data-encryption key per user wrapped by AWS KMS (no master password that opens everyone), decryption only at the moment of use, and never in logs or analytics. Any serious service should publish equivalents.
Key hygiene: cheap habits that close the rest
One key per service
Create a SEPARATE key for every service — never reuse one key across tools, or a breach in any of them burns all of them. Label keys by service on the exchange so revoking is one click, and delete keys for services you stopped using the same day you stop.
Two-factor on both sides
Finally, protect the account that owns the keys: two-factor authentication on the exchange AND on the trading service, because a takeover of either bypasses every other control. Five minutes of setup covers the attack paths that actually occur in practice.