sprock's definitive exchange onboarding checklist for institutional-grade security and access

When a fund or trading desk begins onboarding to a new exchange, security often gets pushed to the back of the line. The rush to start trading, the complexity of API key management, and the assumption that 'the exchange handles it' lead to configurations that look fine on paper but leak risk in practice. This guide, built from patterns observed across many institutional onboarding projects, gives you a concrete checklist to lock down access from day one. We focus on the decisions that matter most: key hierarchy, IP whitelisting, withdrawal policies, and audit logging.

Field context: where this checklist lives in real projects

Exchange onboarding for institutions is not a one-time form-filling exercise. It is a multi-phase process that touches legal, compliance, treasury, and engineering teams. The security and access portion typically begins after KYC approval but before the first API trade. Yet many teams treat it as a simple step: generate keys, paste them into the trading system, and move on. That approach works until a breach, an insider threat, or a misconfiguration locks funds.

In a typical project, the security lead receives a spreadsheet of exchange accounts and a deadline. The pressure to go live means decisions about key permissions, IP restrictions, and approval workflows get made in a single meeting. The checklist we present here is designed to be reviewed in sequence, with each step building on the previous one. It assumes your firm has at least two environments (test and production) and that you can enforce policies via the exchange's admin panel or API.

Why exchanges are high-value targets

Exchanges hold hot wallets and trading balances. Even with cold storage, the APIs that connect your systems to the exchange are a vector. Attackers target API keys with withdrawal permissions, or they social-engineer support teams to reset 2FA. The checklist addresses these threats by ensuring that no single key can drain funds and that all sensitive actions require multi-party approval.

Who should own this checklist

We recommend that a senior security engineer or a compliance officer with technical knowledge owns the process. The treasury team provides requirements (which assets, which trading pairs), and the operations team implements the API connections. The checklist should be signed off by both security and finance before any live funds are moved.

Foundations readers confuse: key concepts that matter

Two concepts trip up most teams during onboarding: the difference between account-level and sub-account keys, and the distinction between read-only and trading permissions. Many exchanges offer multiple key types, and selecting the wrong one can either expose your main account or prevent your bots from executing trades.

Account-level vs. sub-account keys

An account-level key can access all sub-accounts under that main account. If your firm uses sub-accounts to segregate strategies or client funds, an account-level key with full permissions becomes a single point of failure. The safer pattern is to generate separate API keys for each sub-account, with only the permissions needed for that sub-account's activity. This limits blast radius: a compromised sub-account key cannot affect other sub-accounts or the main account's withdrawal settings.

Permission granularity: read, trade, withdraw

Most exchanges offer at least three permission levels: read (balances, orders), trade (place and cancel orders), and withdraw (move funds off the exchange). The common mistake is to grant 'trade' permissions to a key that only needs to read market data, or to grant 'withdraw' to a key used by a trading bot. The rule of thumb: any key that does not need to move funds off the exchange should have withdrawal disabled. For keys that need to trade, consider setting a withdrawal whitelist (addresses that can receive funds) and a daily withdrawal limit.

IP whitelisting vs. IP restriction

IP whitelisting allows only requests from approved IP addresses. IP restriction is a broader term that may include geo-blocking or ASN filters. For institutional setups, IP whitelisting is the stronger control because it reduces the attack surface to a known set of servers. However, it creates operational friction: if your trading servers have dynamic IPs, you need a process to update the whitelist. Some exchanges support API-based IP management, which can be automated.

Patterns that usually work: the core checklist

After reviewing dozens of onboarding configurations, we have identified a set of patterns that consistently reduce risk without blocking trading. These are not theoretical—they are used by firms managing millions in daily volume.

Pattern 1: tiered key hierarchy

Create three tiers of API keys: admin keys (for account settings and withdrawal whitelist management), trading keys (for order placement, no withdrawal), and monitoring keys (read-only). Admin keys should be stored offline and used only for configuration changes. Trading keys are on your trading servers. Monitoring keys are used by risk dashboards or alerting systems. This hierarchy ensures that a breach of a trading server does not expose withdrawal capabilities.

Pattern 2: withdrawal whitelist with time locks

Configure the exchange's withdrawal whitelist to include only addresses you control. Many exchanges allow you to set a time delay (e.g., 24 hours) before a new address can receive funds. This gives the security team time to detect and cancel an unauthorized withdrawal. Combine this with a multi-signature approval process: one person initiates, another approves.

Pattern 3: automated key rotation

API keys should be rotated on a regular schedule—quarterly is common. Automate the rotation using a script that generates new keys, updates the trading system, and revokes the old keys. Manual rotation is prone to being skipped. Document the rotation process in your runbook and test it in a staging environment first.

Pattern 4: comprehensive audit logging

Enable all available audit logs from the exchange. These logs should be sent to your SIEM or log aggregation platform. Monitor for unusual patterns: login from new IPs, key creation outside of rotation windows, failed withdrawal attempts. Set up alerts for any action that creates or modifies API keys.

Anti-patterns and why teams revert

Even with a solid checklist, teams often slip into bad habits. Understanding these anti-patterns helps you catch them before they become the norm.

Anti-pattern 1: the 'one key to rule them all'

A single API key with all permissions and no IP restriction is the most common onboarding mistake. It is easy to set up, and it works until the key is leaked. The reason teams revert: convenience. When a new sub-account is created, it is faster to reuse the existing key than to generate a new one. Combat this by making key generation part of the sub-account creation process, with automated scripts that enforce the tiered hierarchy.

Anti-pattern 2: ignoring withdrawal limits

Some exchanges allow you to set daily withdrawal limits per key or per account. Teams often leave these at the default (which may be very high) or disable them entirely. The revert happens when a legitimate large withdrawal is blocked by a limit, and the operations team, under time pressure, raises the limit globally rather than approving the specific transaction. Solution: set limits based on typical trading volume and have a documented process for temporary limit increases with two-person approval.

Anti-pattern 3: static IP whitelist in a dynamic environment

If your trading infrastructure uses cloud services with elastic IPs, a static whitelist will break connectivity. Teams respond by disabling IP whitelisting entirely, which is worse. The better approach is to use a VPN or a bastion host with a fixed IP, so that all exchange API traffic appears to come from a single, whitelisted address. Alternatively, use the exchange's API to programmatically update the whitelist when your IP changes.

Anti-pattern 4: no key revocation process

When an employee leaves or a trading bot is decommissioned, the associated API keys often remain active. Over time, the number of active keys grows, and no one knows which ones are still in use. The revert is simply neglect. Prevention: maintain a key inventory with ownership, purpose, and expiration date. Automate revocation when the owner is offboarded from the identity provider.

Maintenance, drift, and long-term costs

Security is not a one-time setup. Over months and years, configurations drift. Keys accumulate, permissions widen, and whitelists become outdated. The cost of maintaining the security posture is often underestimated.

Drift example: permission creep

A trading key originally created with read and trade permissions might be granted withdrawal permission for a one-time emergency. If that change is not reverted, the key now has more access than intended. Regular audits (quarterly at minimum) should compare current permissions against the baseline. Use a script to flag any key whose permissions exceed its role.

Cost of manual processes

If your onboarding checklist is a document that gets printed and signed, it will be ignored. The long-term cost is not just the time spent on manual reviews—it is the increased likelihood of human error. Invest in automation: use infrastructure-as-code principles for exchange configurations where the exchange's API allows it. Store key secrets in a vault, not in config files.

When to re-onboard

Trigger a full re-onboarding review when you change trading platforms, when the exchange updates its security features, or after a security incident. Also consider re-onboarding annually as a best practice. The review should regenerate all keys, re-verify whitelists, and re-confirm permissions.

When not to use this approach

This checklist is designed for institutions with dedicated security and operations teams. It assumes you have the ability to enforce policies programmatically and that you can manage multiple keys per exchange. In some scenarios, a simpler approach is more appropriate.

Small teams or early-stage funds

If your team has fewer than five people and you are not yet using sub-accounts, the tiered key hierarchy may be overkill. A simpler pattern: one trading key with withdrawal disabled, and one withdrawal key stored offline. Use the exchange's built-in 2FA for all logins. Revisit the full checklist as you grow.

Exchanges with limited security features

Not all exchanges support IP whitelisting, sub-account keys, or withdrawal whitelists. If the exchange's security features are minimal, your checklist should focus on what you can control: strong passwords, hardware 2FA, and limiting the number of keys. Consider whether the exchange meets your security requirements at all.

When the cost of automation exceeds the risk

If your trading volume is low and the assets held on the exchange are not material, the effort to automate key rotation and audit logging may not be justified. In such cases, a manual quarterly review with a simple spreadsheet may suffice. The key is to make an explicit risk decision, not to default to no process.

Open questions / FAQ

Should we use the exchange's web interface or API for configuration?

Use the API for all configuration changes that are supported. API calls are logged, can be automated, and are less prone to human error than clicking through a web UI. For settings that are only available via the web interface (e.g., some withdrawal whitelist settings), document the steps and have two people perform them together.

How do we handle emergency access when the primary key is revoked?

Maintain a break-glass procedure: a physical or hardware-stored admin key that is sealed and only used in emergencies. The key should be stored in a safe, and its use must trigger an alert to the security team. After the emergency, the key must be replaced.

What about exchanges that charge for API access?

Some exchanges have tiered API plans with costs. Factor this into your key hierarchy: you may need to reduce the number of keys to stay within a budget. In that case, consider using a single key per sub-account with the minimum permissions, and rely on IP whitelisting and withdrawal limits as compensating controls.

How often should we test our backup and recovery plan?

Test the recovery of API keys and access at least once per quarter. Simulate a scenario where all keys are revoked and you need to re-establish connectivity. This ensures that your procedures are up to date and that staff know what to do under pressure.

Next steps: Print this checklist, customize it for your exchange's specific features, and schedule a review meeting with your security and operations teams. Start with the tiered key hierarchy—it is the single highest-impact change you can make. Then automate one pattern per month until the entire checklist is enforced programmatically.