How Does Bitget’s Sub-Account System Support Institutional Multi-Desk Trading? Separate Desks, APIs and Trading Strategies (2026 Guide)

For an institutional trading firm, one account is rarely enough. A single operation may run spot and futures market making, arbitrage, quantitative strategies, hedging, and longer-term portfolios at the same time, with each desk demanding its own capital, risk controls, API capacity, and execution setup. The challenge is keeping those operations separate without turning account management into a maze.

Bitget solves this through a master and sub-account structure built for multi-desk trading. Institutional clients can create up to 1,000 sub-accounts, giving firms room to separate desks, strategies, APIs, and capital pools while keeping them under one broader account hierarchy. For eligible Market Maker and PRO users, the setup can also scale to up to 600 RPS per UID and 120,000 RPS across the master-sub-account structure, giving API-intensive firms more flexibility to distribute execution capacity where it is needed most.

Disclaimer: This article is for informational purposes only and does not constitute financial, investment, legal, or trading advice. Product features, eligibility requirements, API limits, and institutional services may vary by account type, jurisdiction, and user status and may change over time. Institutions should review the latest Bitget documentation and assess their own operational, technical, and regulatory requirements before using these services.

Key Takeaways

• Bitget supports up to 1,000 sub-accounts for institutional clients, allowing firms to separate desks, strategies, portfolios, and trading systems.

• Institutional sub-accounts can be used to assign separate trading access, API keys, and asset management responsibilities to different teams.

• Standard and virtual sub-accounts can independently manage their own API keys once the master account grants API-management permission, while the master retains full control over those keys.

• For eligible MM and PRO users, Bitget's UTA rate-limit framework reaches 600 RPS per UID and 120,000 RPS across the master-sub-account structure at the highest tier.

• Rate-limit quotas can be allocated separately to individual sub-account UIDs, allowing firms to give more API capacity to high-frequency strategies and less to lower-frequency desks.

• New sub-accounts created after Market Maker or PRO status is activated are automatically provisioned to Bitget's Institutional Dedicated Cluster.

How Does Bitget’s Sub-Account System Support Institutional Multi-Desk Trading?

Bitget's institutional sub-account system allows a trading firm to divide one larger operation into multiple independently managed trading environments.

Instead of running every strategy through the same account, an institution could organize its operations as:

Institutional Master Account

• Spot Market-Making Desk

• Futures Market-Making Desk

• Arbitrage Desk

• Quant Strategy A

• Quant Strategy B

• Hedging Desk

• rToken Strategy

• Longer-Term Portfolio

Each desk can operate through its own sub-account rather than combining all trading activity into one UID.

Bitget's institutional UTA documentation explicitly identifies sub-accounts as suitable for different trading teams within the same institution, with separate trading access, API keys, and asset management.

The scale is also important. Bitget's institutional services platform supports up to 1,000 sub-accounts, giving larger firms considerably more room than a simple two- or three-desk setup.

An institution could therefore separate not only major desks, but also individual strategies, execution engines, portfolios, or regional teams.

The goal is not simply to create more accounts. It is to make a complex trading operation easier to divide, monitor, control, and scale.

How Does Bitget Separate Trading Desks, Strategies and Capital?

Different institutional strategies can behave very differently.

A market-making desk may maintain large inventories and continuously place and cancel orders. An arbitrage strategy may keep capital ready across several markets and react quickly to pricing discrepancies. A longer-term portfolio may trade far less frequently and operate under a completely different risk mandate.

Mixing those activities in one account makes it harder to identify which strategy owns which capital, positions, orders, and trading results.

Bitget sub-accounts provide a way to isolate those operations.

For example, a proprietary trading firm could hold its spot market-making inventory in one sub-account, futures market-making positions in another, arbitrage capital in a third, and an rToken portfolio in a fourth.

Bitget's general sub-account framework supports fund transfers between the main account and sub-accounts, while its documentation identifies risk management, fund allocation, team collaboration, and strategy separation as core sub-account use cases.

For an institutional trading operation, this can make several tasks easier:

• Separating capital assigned to different desks

• Isolating trading strategies and positions

• Tracking desk-level trading activity

• Assigning different teams to different accounts

• Applying separate API configurations

• Reducing operational overlap between strategies

• Scaling new strategies without placing them inside an existing desk's account

This separation can also improve internal PL analysis. When a strategy runs through its own account, its trading activity does not need to be disentangled from every other desk using the same UID.

How Do API Keys and Permissions Work Across Multiple Trading Desks?

For automated institutional trading, separating the account is only half of the problem. The technology stack also needs to be separated.

Bitget allows virtual and standard sub-accounts to create and manage their own API keys independently after the master account enables API Key Management permission for that sub-account. The sub-account can then create, view, edit, and delete its own API credentials.

The master account still retains full control and can view, edit, or delete a sub-account's API keys.

This creates a useful structure for multi-desk firms.

A market-making engine does not need to share the same API credentials as an arbitrage bot. A quantitative trading system does not need to operate through the same API setup as a lower-frequency portfolio desk.

A firm could organize its infrastructure as follows:

Spot Market-Making Desk
→ Dedicated sub-account
→ Dedicated UID
→ Dedicated API setup

Futures Market-Making Desk
→ Dedicated sub-account
→ Dedicated UID
→ Dedicated API setup

Arbitrage Desk
→ Dedicated sub-account
→ Dedicated UID
→ Dedicated API setup

Quant Desk
→ Dedicated sub-account
→ Dedicated UID
→ Dedicated API setup

Bitget API permissions can also be configured for reading or trading access, allowing firms to align API access with the responsibilities of a particular team or system.

This architecture reduces the need to place multiple independent trading engines behind a single set of account credentials.

600 RPS per UID and 120,000 RPS: How API Capacity Scales Across Trading Desks

Sub-account separation becomes particularly relevant when multiple automated desks are generating API traffic simultaneously.

Effective September 3, 2026, at 17:00 UTC+8, Bitget introduced an upgraded institutional UTA rate-limit framework for eligible Market Maker and PRO users. The system combines a single-account rate-limit cap with a broader master-sub-account aggregate limit.

The current structure is:

These limits apply separately to UTA Spot and UTA Futures.

That distinction matters because institutional desks do not necessarily generate equal workloads.

A high-frequency market-making engine may need substantially more request capacity than a slower hedging strategy. Instead of assigning the same API throughput to every desk, Bitget allows institutions to manually configure rate-limit quotas for individual sub-account UIDs according to their actual trading requirements.

The dedicated rate-limit API supports both individual and batch quota allocation. A master account can assign Spot or Futures quotas to multiple sub-account UIDs, with up to 50 UIDs included in a single request.

For example, an institution could configure higher capacity for:

• Spot market-making systems

• Futures market-making systems

• High-frequency arbitrage engines

And lower capacity for:

• Portfolio rebalancing

• Treasury operations

• Lower-frequency directional strategies

• Hedging systems with lighter API workloads

Those are illustrative operating models rather than Bitget-prescribed allocations. The key point is that API resources can be distributed at the UID level instead of treating every trading desk identically.

At the top MM1 or PRO6 tier, the maximum reaches 600 RPS for a single UID and 120,000 RPS across the broader master-sub-account structure.

For institutions running many simultaneous algorithms, that turns the sub-account system from a basic organizational feature into part of the firm's execution architecture.

How Does Bitget’s Institutional Dedicated Cluster Support Multiple Desks?

API capacity is only useful when the infrastructure underneath it can support professional trading workloads.

Bitget provides an Institutional Dedicated Cluster for eligible Market Maker and PRO users.

Once MM or PRO status is activated, newly created sub-accounts are automatically provisioned to the institutional dedicated cluster, which Bitget describes as providing enhanced account performance and optimized execution conditions.

Existing sub-accounts created before MM or PRO activation remain on the normal user cluster by default, but eligible institutions can request migration through their dedicated account manager.

The difference matters for API-intensive desks.

Accounts remaining on the normal user cluster are subject to a cap of 100 RPS for Spot and 100 RPS for Futures, regardless of institutional tier.

For an expanding institutional operation, creating another desk can therefore mean more than creating another login. A new sub-account can receive its own UID, API environment, configured rate-limit quota, and access to institutional execution infrastructure when eligibility requirements are met.

That makes the structure more suitable for firms that expect the number of strategies and automated systems to grow over time.

How Does the Master Account Keep Control Across Multiple Trading Desks?

Separating desks should not mean giving up centralized oversight.

Bitget's master-sub-account structure is designed to support both.

At the trading level, individual desks can operate independently with their own strategies, accounts, API configurations, and capital allocations.

At the institutional level, the master account remains the control layer.

For API management, for example, Bitget allows sub-accounts to manage their own API keys when permission is granted, but the master account retains the ability to view, edit, or delete those keys.

For API throughput, the master account can allocate rate-limit quotas to individual sub-account UIDs while remaining subject to the total master-sub-account capacity associated with its institutional tier.

Capital can also be transferred between the main account and sub-accounts, helping a central treasury or operations team distribute funds to different strategies.

The model can therefore be summarized as: Centralized governance, decentralized execution.

The institution controls the broader account structure, while individual desks can execute through separate trading environments.

For institutions using Bitget's Unified Trading Account structure, there is one additional distinction. Bitget's institutional UTA guide currently supports General sub-accounts and Virtual sub-accounts in unified trading mode, while custodial and funding sub-accounts are not available under that specific mode.

What Does a Bitget Multi-Desk Institutional Setup Look Like?

Consider a proprietary trading firm operating six strategies on Bitget.

Instead of routing every system through one account, the firm could build the following structure:

The Spot and Futures market-making desks could receive larger API quotas because they continuously update orders. The hedging desk might require less throughput, while the rToken strategy could remain operationally separated from both.

The institution can then add more sub-accounts as new teams, strategies, or portfolios are introduced.

Bitget's institutional services architecture supports this type of expansion with up to 1,000 sub-accounts.

For a small professional team, only a handful may be necessary. For a large quantitative or market-making organization, the same hierarchy provides room to separate hundreds of trading operations without turning them into unrelated standalone accounts.

Why Bitget’s Sub-Account Architecture Matters for Institutional Trading

The value of an institutional sub-account system is not measured simply by how many accounts an exchange allows.

What matters is what an institution can do with them.

Bitget combines several layers of infrastructure around the master-sub-account model.

1. Operational scale

Institutional clients can create up to 1,000 sub-accounts, providing room to separate desks, portfolios, teams, and strategies.

2. Strategy separation

Different trading activities can operate through separate accounts instead of competing for the same capital pool, positions, API credentials, and operational structure.

3. Independent APIs

Eligible sub-accounts can manage separate API keys, while the master account retains centralized oversight.

4. UID-level API allocation

Eligible MM and PRO users can configure throughput according to the needs of individual trading strategies rather than applying one uniform limit across every desk.

5. Institutional-scale capacity

At the highest tier, Bitget's current UTA framework reaches 600 RPS per UID and 120,000 RPS across the master-sub-account structure for both Spot and Futures.

6. Dedicated infrastructure

New sub-accounts created under active MM or PRO status can be automatically provisioned to Bitget's Institutional Dedicated Cluster.

Together, these features create an architecture that can grow with the institution.

A firm can begin with a few independent strategies, add additional desks as trading activity expands, allocate API capacity according to each strategy's workload, and still retain one broader institutional account hierarchy.

Conclusion

Bitget's sub-account system supports institutional multi-desk trading by allowing firms to separate strategies without fragmenting the overall operation.

Market making, arbitrage, quantitative trading, hedging, and portfolio strategies can each operate through separate sub-accounts with their own UIDs, APIs, trading activity, and capital allocations. At the same time, the master account provides the broader layer for account oversight, permissions, capital distribution, and API-resource management.

The scale is significant. Bitget supports up to 1,000 institutional sub-accounts, while eligible MM and PRO users can access as much as 600 RPS per UID and 120,000 RPS across a master-sub-account structure at the highest tier.

For institutions operating multiple automated desks, that combination makes the sub-account system more than an account-management feature. It becomes part of the infrastructure for separating, controlling, and scaling professional trading operations.

Frequently Asked Questions

1. How does Bitget's sub-account system support institutional multi-desk trading?

Bitget allows institutional clients to place different trading teams, strategies, and systems into separate sub-accounts under a master-account structure. Different desks can therefore operate with separate trading activity, API configurations, and capital allocations while remaining part of the same institutional hierarchy.

2. How many sub-accounts can institutions create on Bitget?

Bitget's institutional services platform supports up to 1,000 sub-accounts for institutional clients. Actual availability and account configurations may depend on institutional status and account setup.

3. Can different Bitget sub-accounts use separate API keys?

Yes. Standard and virtual sub-accounts can independently create and manage their own API keys after the master account enables API Key Management permission. The master account retains full control and can view, edit, or delete those API keys.

4. Can institutions allocate different API limits to different sub-accounts?

Yes. Eligible MM and PRO users can set rate-limit quotas for individual sub-account UIDs. This allows firms to allocate more API capacity to higher-frequency strategies and different quotas to lower-frequency desks.

5. What is Bitget's maximum institutional API rate limit?

Under the current UTA institutional framework, the highest MM1 and PRO6 tiers support up to 600 RPS per UID and 120,000 RPS across the master-sub-account structure. Lower institutional tiers have different limits.

6. Can market making and arbitrage use separate Bitget sub-accounts?

Yes. Sub-accounts can be used to separate different trading teams and strategies. An institution could therefore place market-making, arbitrage, hedging, or quantitative systems in different sub-accounts rather than combining their trading activity.

7. What is Bitget's Institutional Dedicated Cluster?

The Institutional Dedicated Cluster is infrastructure available to eligible Market Maker and PRO users. New sub-accounts created after MM or PRO status is activated are automatically provisioned to this cluster. Existing eligible sub-accounts can be migrated through a dedicated account manager.

8. Are Bitget sub-accounts suitable for quantitative trading?

They can be particularly useful for quantitative and API-driven operations because separate strategies can use different sub-accounts, UIDs, API credentials, and configured API quotas. The appropriate setup depends on the firm's trading strategy, institutional tier, and infrastructure requirements.