券商交易平台与 API
本文介绍量化交易中常用的券商平台和 API 接口，包括机构级 Prime Broker 和零售级交易 API。
一、Prime Broker（主力经纪商）
通过哪个券商的平台？
Renaissance 等顶级量化对冲基金不使用零售券商平台（如 IBKR 零售版或富途），而是通过 Prime Brokers（主力经纪商） 执行交易。
常见 Prime Brokers 包括：
- Goldman Sachs
- Morgan Stanley
- JPMorgan Chase
- IBKR Prime Services（针对中小型基金，注意：这是 IBKR 的机构服务，与零售版 TWS 不同）
这些prime brokers提供融资、证券借贷、清算、报告等服务，并支持高频/算法交易的低延迟执行。Renaissance可能使用多个prime brokers分散风险，并自定义连接（co-location、低延迟线路）到交易所。
二、零售级量化 API
富途牛牛（Futu NiuNiu）是否有这种API支持？
是的，富途牛牛提供强大的OpenAPI，支持程序化交易和自动化下单。
Futu OpenAPI专为量化投资设计，包括：
- 行情接口（实时报价、K线、tick数据等）
- 交易接口（下单、撤单、改单、查询订单/持仓等）
支持市场：港股、美股、A股通、期货、期权等。
支持语言：Python、Java、C#、C++、JavaScript等（有官方SDK）。
架构：需运行本地/云端网关程序Futu OpenD，然后通过API连接，支持实盘和模拟交易。
2025 年重要变化：在境外投资监管收紧背景下，富途、老虎等跨境券商自 2025 年 9 月起大幅收紧中国大陆居民开户——富途现阶段仅支持港澳身份开户，老虎不再接受海外工作/生活证明。存量账户的 OpenAPI 仍正常可用，但如果你目前没有账户且无海外身份，这条"个人做港美股量化"的路径基本关闭，应转向 IBKR（同样有大陆开户限制，需自行确认最新政策）或以 A 股 QMT/PTrade 为主。
A股个人程序化通道：QMT 与 PTrade
2026 年个人在 A 股跑程序化，事实标准是券商提供的 QMT（迅投） 和 PTrade（恒生）。开通门槛因券商而异：QMT 常见 10 万–50 万资产要求（部分券商 10 万即可开），PTrade 普通版门槛较低、专业版通常 50 万+；普遍要求半年交易经验与 C4 风险测评，且需走客户经理渠道而非自助开户。注意：所有程序化账户均需按 2025 年 7 月实施的交易所细则完成"先报告、后交易"。
许多个人宽客和开发者使用它构建算法交易系统（如双均线策略、高频框架），社区有大量开源项目（如futu-api Python包、futu_algo框架）。
局限：适合零售/个人量化，不适合机构级超高频（延迟更高，无co-location），但对于中低频策略非常友好，且免费/低成本。
三、Interactive Brokers：事件驱动执行案例
3.1 架构与接口边界
IBKR 提供多个相互独立的接口。TWS API 是运行在 TCP socket 上的消息协议：客户端连接 Trader Workstation 或 IB Gateway，再由它们维持券商会话。它不是 FIX 连接。Client Portal 与机构 FIX 产品有不同的认证、会话、权限和运维契约；应明确选择接口，不要设计一个含义模糊的“IB API”适配器。
这意味着两条规则：
- 把响应当作异步事件，而不是同步函数返回值。
- 分别测量客户端发送、网关接收、券商确认、成交和客户端回调等边界，不发布一个通用往返延迟。
网络位置只能改变延迟的一部分，不能消除券商路由、市场状态、排队、限流和交易场所延迟。使用 VPS 也不能证明某策略适合高频交易。
3.2 订单生命周期与幂等
为每个交易意图分配跨重试稳定的内部 intent ID，并映射到 orderId、permId 等券商标识；提交前持久化映射。状态至少包括：已创建、已提交、已确认、部分成交、完全成交、待撤、已撤、被拒、未知/对账中。
不要只靠 orderStatus 推断成交。IBKR 建议同时监控 execDetails；每个部分成交都有独立 execId。佣金通过单独的 commissionReport 消息到达，可用 execId 与成交关联，但 API 不保证固定延迟。所有更新都应幂等，重复或重放的事件不能重复计入仓位、现金、费用或 P&L。
3.3 重连意味着对账，不是“连上就健康”
连接消息会区分：连接丢失、恢复但行情订阅丢失、恢复且行情保持。断线或进程重启后：
- 在会话完成分类前停止新增风险；
- 若连接代码表明订阅丢失，就重新请求行情；
- 查询未完成订单、近期成交、持仓/账户值和现金；
- 与持久化意图及已知成交对账；
- 对无法匹配的记录显式分类，不能静默采纳或删除；
- 只有明确的不变量全部通过后才恢复交易。
本地状态只权威地说明程序“想做什么”；券商报告的订单、成交、持仓和现金才说明外部账户“实际发生了什么”。安全系统两者都需要。
3.4 限流与行情额度
TWS API 存在 pacing 限制。IBKR 文档把一般请求上限定义为账户行情线数的函数；默认 100 条行情线时，示例上限为每秒 50 个请求。历史数据请求与活跃 ticker 订阅还有额外限制。这些是运维约束，不应散落在策略代码中：读取当前账户权限，集中限流，使用有界退避，并监控队列深度和被拒请求。
3.5 模拟盘是必要测试，但不是成交模型
IBKR 明确说明模拟盘使用了比实盘更多的模拟技术，订单执行行为可能不同。模拟盘适合验证 API 接线、合约解析、状态转换、权限和恢复演练；它不能证明队列位置、市场冲击、流动性、融券或实盘成交质量。上线应经过历史回放、模拟盘、影子观察，再以单独批准的风险限额进行小规模实盘验证。
3.6 安全运维清单
- 唯一且持久化的意图 ID 与券商 ID 映射
- 订单、成交、佣金和账户事件的幂等处理
- 部分成交、撤改单、拒单和未知状态测试
- 断线重连后的订单、成交、持仓和现金对账演练
- 集中请求限流与行情权限检查
- 版本化的合约定义、交易日历、币种和费率规则
- 对账完成前以只读恢复模式启动
- 独立的 kill/flatten 流程，并证明外部账户状态收敛
- 记录模拟盘与实盘差异，并在有限敞口下验证
- 每日券商对账单核对与未解决差异告警
官方资料：IBKR TWS API 文档与 TWS API Reference。