资本市场工作流的难点不只是“数据多”,更在于规则复杂、错误代价高,而且很多判断依赖资深从业者。Chatham Financial 将 Codex 和 GPT-5.6 用于技术建设与流程重构,把交易验证时间从约 30 分钟压缩到不足 4 分钟。这个结果值得关注的地方,并不是单纯让模型读一份交易文件,而是把专家知识、确定性规则、模型能力和人工审批重新编排成一条可审计的生产流程。
真正被压缩的是等待与重复劳动
传统交易验证经常需要在交易录入、确认书、定价系统和内部政策之间来回核对。即使每一步都不复杂,字段查找、格式转换、差异定位和结果说明仍会消耗大量时间。
从 30 分钟降到 4 分钟以内,意味着自动化不能只停留在生成摘要。更有效的流程通常会拆成三层:
- 确定性检查:校验必填字段、币种、名义本金、日期和数值范围。这些规则应该由普通代码执行,而不是交给大模型猜测。
- 语义分析:解释非结构化确认文本、归纳差异,并根据内部检查清单提出复核建议。
- 人工决策:由分析师处理高风险异常并作出最终批准,模型不能成为没有责任边界的自动签字人。
来源摘要没有披露 Chatham 的具体系统架构,因此不能假定其采用了上述实现细节。不过,这种分层方式可以作为同类资本市场团队落地 Codex 和 GPT 模型时的工程参考。
Codex 与 GPT-5.6 应放在不同的控制点
两类工具可以进入同一项目,但职责不应混在一起。
Codex 更适合辅助工程团队编写解析器、补充单元测试、重构验证服务,以及把专家给出的检查规则转成代码。生成的代码仍需经过代码评审、测试和安全扫描,特别是金额计算、日期规则与产品适用性判断。
GPT-5.6 则可以参与运行时的语义任务,例如:
- 将异常转换成分析师容易阅读的说明;
- 比较结构化交易记录与确认文本;
- 根据检查清单列出缺失信息;
- 为复杂案例生成复核步骤,而不是直接作出批准结论。
关键原则是:能由代码精确表达的规则,不要只写在提示词里;模型给出的结论,也不要直接覆盖原始交易数据。
一个可运行的交易验证原型
下面是一个可直接改造的最小示例,并不代表 Chatham 的内部实现。脚本先执行确定性检查,发现异常后再调用 GPT-5.6 生成复核建议;即使没有 API 密钥,规则检查部分也可以独立运行。
将以下内容保存为 trade_validator.py:
import json
import os
import sys
from pathlib import Path
def deterministic_checks(trade: dict) -> list[dict]:
issues = []
required = ["trade_id", "product", "currency", "notional", "confirmation_notional"]
for field in required:
if trade.get(field) in (None, ""):
issues.append({
"code": "MISSING_FIELD",
"field": field,
"message": f"Required field is missing: {field}",
})
if trade.get("currency") not in {"USD", "EUR", "GBP", "JPY"}:
issues.append({
"code": "UNSUPPORTED_CURRENCY",
"field": "currency",
"message": "Currency is outside the configured validation set",
})
notional = trade.get("notional")
confirmed = trade.get("confirmation_notional")
if not isinstance(notional, (int, float)) or notional <= 0:
issues.append({
"code": "INVALID_NOTIONAL",
"field": "notional",
"message": "Notional must be a positive number",
})
if isinstance(notional, (int, float)) and isinstance(confirmed, (int, float)):
if abs(notional - confirmed) > 0.01:
issues.append({
"code": "NOTIONAL_MISMATCH",
"field": "confirmation_notional",
"message": f"Booked notional {notional} differs from confirmation {confirmed}",
})
if trade.get("product") == "interest_rate_swap" and trade.get("fixed_rate") is None:
issues.append({
"code": "MISSING_FIXED_RATE",
"field": "fixed_rate",
"message": "Fixed rate is required for this swap example",
})
return issues
def get_model_review(trade: dict, issues: list[dict]) -> str:
from openai import OpenAI
model = os.getenv("OPENAI_MODEL", "gpt-5.6")
client = OpenAI()
prompt = f"""
You are assisting a capital-markets trade validation analyst.
Rules:
- Do not approve or reject the trade.
- Do not invent contractual terms.
- Use only the supplied JSON.
- Explain each issue and propose a human verification step.
- Return concise JSON with keys: risk_level, summary, review_steps.
Trade and deterministic findings:
{json.dumps({"trade": trade, "issues": issues}, indent=2)}
""".strip()
response = client.responses.create(model=model, input=prompt)
return response.output_text
def main() -> None:
path = Path(sys.argv[1] if len(sys.argv) > 1 else "trade.json")
trade = json.loads(path.read_text(encoding="utf-8"))
issues = deterministic_checks(trade)
print(json.dumps({"deterministic_issues": issues}, indent=2))
if not issues:
print("No deterministic issues found; no model review requested.")
return
if not os.getenv("OPENAI_API_KEY"):
print("OPENAI_API_KEY is not set; skipping model-assisted review.")
return
print(get_model_review(trade, issues))
if __name__ == "__main__":
main()
准备一笔故意包含差异的示例交易:
cat > trade.json <<'JSON'
{
"trade_id": "TRD-2025-001",
"product": "interest_rate_swap",
"currency": "USD",
"notional": 5000000,
"confirmation_notional": 5100000,
"fixed_rate": null
}
JSON
python trade_validator.py trade.json
如需启用模型复核,安装 SDK 并设置凭证:
python -m pip install -U openai
export OPENAI_API_KEY="replace-with-your-key"
export OPENAI_MODEL="gpt-5.6"
python trade_validator.py trade.json
运行前应把示例规则替换为组织批准的规则集。如果账户尚未提供指定模型,也应将 OPENAI_MODEL 改成实际可用并经过评估的部署模型。生产环境还要避免把客户身份信息、未脱敏确认书或受限制交易数据直接发送给未经批准的外部服务。
不要只盯着“4 分钟”
端到端耗时很重要,但它不是唯一指标。上线时至少应同时记录:
- 交易验证的 P50、P95 耗时;
- 自动检查发现的真实异常数量;
- 误报率与漏报率;
- 转交人工复核的比例;
- 分析师推翻模型建议的比例;
- 每笔交易的模型调用成本;
- 每次结论所使用的规则版本、模型版本和输入摘要。
还应为模型设置明确的失败路径:超时就回退到原有流程,输出格式不合法就进入人工队列,高风险产品始终要求双人复核。这样,效率提升才不会以控制能力下降为代价。
采用时从一条窄流程开始
Chatham 的案例说明,生成式 AI 在资本市场中的价值可以体现为显著缩短验证周期,但复制这一成果不能从“给所有人一个聊天窗口”开始。更稳妥的做法是选择交易量高、规则相对稳定、历史结果可评估的一类产品,先建立基线,再逐步放开模型承担的任务。
落地前可以使用这份检查表:
- [ ] 确定性规则已经从提示词中分离出来;
- [ ] 原始输入、规则版本和模型输出可追踪;
- [ ] 模型无权自行批准或修改交易;
- [ ] 敏感数据经过分类、脱敏和访问控制;
- [ ] 使用历史案例测试误报与漏报;
- [ ] 保留人工回退路径和停用开关;
- [ ] 用端到端业务时间衡量收益,而不只看模型响应速度。
真正可扩展的不是一次漂亮的模型回答,而是一套能把专家判断固化、复用并持续审计的工作流。