Broker Trading Platforms and APIs

This article introduces commonly used broker platforms and API interfaces in quantitative trading, including institutional-grade Prime Brokers and retail-grade trading APIs.

1. Prime Brokers

Which Broker Platforms Do Top Funds Use?

Top quantitative hedge funds like Renaissance do not use retail broker platforms (like IBKR retail or Futu). Instead, they execute trades through Prime Brokers.

Common Prime Brokers include:

Goldman Sachs
Morgan Stanley
JPMorgan Chase
IBKR Prime Services (more common for small to medium-sized funds; note: this is IBKR's institutional service, different from retail TWS)

These prime brokers provide financing, securities lending, clearing, reporting, and other services, and support low-latency execution for high-frequency/algorithmic trading. Renaissance likely uses multiple prime brokers to diversify risk and customizes connections (co-location, low-latency lines) to exchanges.

2. Retail-Grade Quantitative APIs

Does Futu NiuNiu Have This Kind of API Support?

Yes, Futu NiuNiu provides a powerful OpenAPI that supports programmatic trading and automated order placement.

Futu OpenAPI is designed for quantitative investment, including:

Market data interface (real-time quotes, K-lines, tick data, etc.)
Trading interface (place orders, cancel orders, modify orders, query orders/positions, etc.)

Supported markets: Hong Kong stocks, US stocks, A-share Connect, futures, options, etc.

Supported languages: Python, Java, C#, C++, JavaScript, etc. (official SDKs available).

Architecture: Requires running a local/cloud gateway program Futu OpenD, then connecting via API. Supports live trading and paper trading.

Important 2025 change: As China tightened rules on offshore investment, cross-border brokers sharply restricted mainland-Chinese onboarding from September 2025 — Futu currently opens accounts only for Hong Kong/Macau ID holders, and Tiger Brokers stopped accepting overseas work/residence proof. Existing accounts keep full OpenAPI access, but if you have no account and no overseas identity, this "personal HK/US-stock quant" route is effectively closed; look at IBKR (which has its own mainland onboarding limits — verify the current policy) or run A-shares through QMT/PTrade.

For an individual running programmatic A-share trading in 2026, the de facto standard is broker-provided QMT (XunTou) or PTrade (Hundsun). Thresholds vary by broker: QMT commonly requires CNY 100k-500k in assets (some brokers open at 100k); PTrade's standard tier is lower, its professional tier usually 500k+. Expect a six-month trading-history requirement, a C4 risk assessment, and onboarding through an account manager rather than self-service. All programmatic accounts must complete "report first, trade second" under the exchange implementation rules effective July 2025.

Many individual quants and developers use it to build algorithmic trading systems (such as dual moving average strategies, high-frequency frameworks). The community has many open-source projects (like the futu-api Python package, futu_algo framework).

Limitations: Suitable for retail/individual quantitative trading, not suitable for institutional-level ultra-high-frequency (higher latency, no co-location), but very friendly for medium-low frequency strategies and free/low-cost.

3. Interactive Brokers as an Event-Driven Execution Case Study

3.1 Architecture and Interface Boundary

IBKR offers several separate interfaces. The TWS API is a message protocol over a TCP socket: your client connects to Trader Workstation or IB Gateway, which in turn maintains the broker session. It is not a FIX connection. Client Portal and institutional FIX offerings have different authentication, session, entitlement, and operational contracts; choose one explicitly rather than designing a generic "IB API" adapter.

This architecture implies two rules:

Treat responses as asynchronous events, not synchronous function returns.
Measure latency at several boundaries—client send, gateway receipt, broker acknowledgement, execution, and client callback—rather than publishing one universal round-trip number.

Network location can change one component of latency, but it does not remove broker routing, market state, queueing, throttling, or venue latency. A VPS is therefore not evidence that a strategy is suitable for high-frequency trading.

3.2 Order Lifecycle and Idempotency

Maintain an internal intent ID that is stable across retries and map it to broker identifiers such as orderId and permId. Persist the mapping before submission. Model at least: created, submitted, acknowledged, partially filled, filled, cancel pending, cancelled, rejected, and unknown/reconciling.

Do not infer fills from orderStatus alone. IBKR recommends monitoring execDetails as well; each partial fill has its own execId. Commission information arrives through a separate commissionReport message and can be correlated with the execution by execId, but the API does not guarantee a fixed delay. Updates must be idempotent because duplicate or replayed events should not duplicate positions, cash, fees, or P&L.

3.3 Reconnect Is Reconciliation, Not "Connected = Healthy"

Connectivity messages distinguish lost connectivity, restored connectivity with lost market-data subscriptions, and restored connectivity with data maintained. After a disconnect or process restart:

stop creating new risk until the session is classified;
re-request market data when the connectivity code says subscriptions were lost;
query open orders, recent executions, positions/account values, and cash;
reconcile them against persisted intents and known executions;
classify unmatched records instead of silently adopting or deleting them;
resume only after explicit invariants pass.

Local state is authoritative for what the program intended. Broker-reported orders, executions, positions, and cash are authoritative for what reached or changed the external account. A safe system needs both.

3.4 Pacing and Market-Data Limits

The TWS API has pacing limits. IBKR documents the general request limit as a function of the account's market-data lines; with the default 100 lines, the example limit is 50 requests per second. Historical-data requests and active ticker subscriptions have additional limits. These are operational constraints, not constants to scatter through strategy code: read current account entitlements, centralize throttling, apply bounded backoff, and expose queue depth and rejected-request metrics.

3.5 Paper Is Necessary but Not a Fill Model

IBKR states that paper trading uses more simulation than live trading and that execution behavior can differ. Paper trading is useful for API wiring, contract resolution, state transitions, permissions, and recovery drills. It does not validate queue position, market impact, availability of liquidity, borrow, or live fill quality. Promotion should proceed through historical replay, paper, shadow observation, and deliberately limited live exposure with separately approved risk limits.

3.6 Safe Operational Checklist

Official references: IBKR TWS API documentation and TWS API reference.