13、外包与第三方风险管理：外包活动范围与限制、第三方尽职调查（如做市商技术供应商）、外包风险持续监控
做市商这个行当，说白了就是跟时间赛跑、跟风险博弈。但很多人忽略了一点——你跑得再快，鞋带是别人系的，那早晚得摔跟头。
我入行头几年，总觉得技术供应商、数据服务商这些“外包伙伴”是帮手，不是负担。直到有一次，我们的核心做市系统因为第三方行情源的一个配置失误，延迟了整整3秒。3秒啊，在结构化产品做市里，这够爆仓两轮了。从那以后，我对第三方风险管理再也不敢掉以轻心。
这一章，我们就聊聊外包与第三方风险。嗯，说白了就是：哪些活可以交给别人干，哪些活必须攥在自己手里，以及怎么确保“别人”不给你挖坑。
13.1 外包活动的范围与限制
先明确一个原则：核心风控与交易决策，绝对不能外包。这是监管的红线，也是做市商的生存底线。
我见过一些中小型做市商，为了省成本，把交易系统的运维甚至部分风控逻辑都丢给了技术供应商。结果呢？供应商一个版本升级，风控参数被重置，当天就出现了超限交易。嗯，这个教训挺贵的。
那么，哪些外包是合理的？我习惯把外包活动分成三类：
| 外包类别 | 典型活动 | 限制与要求 |
|---|---|---|
| 可外包 | IT基础设施托管、非核心数据清洗、合规报告生成 | 需签订明确SLA，保留审计权 |
| 限制外包 | 行情源接入、交易执行通道、部分模型计算 | 必须保留并行验证能力，不能完全依赖 |
| 禁止外包 | 风控决策、交易指令生成、资金划拨审批 | 必须由内部人员执行，系统权限严格隔离 |
这里有个避坑指南：“限制外包”类活动最容易出问题。我曾经遇到一个案例，做市商把波动率曲面计算外包给了一家第三方服务商。服务商用的模型参数跟内部不一致，导致报价偏差持续了整整一周才被发现。所以我的建议是——哪怕外包了计算，内部也要保留一套独立的验证脚本，每周跑一次对比。
13.2 第三方尽职调查：不只是填个表
很多机构做第三方尽调，就是发个问卷让对方填。说实话，这跟走形式没区别。真正有效的尽调，得“动手”。
我个人的习惯是，对技术供应商的尽调至少包含以下五个维度：
- 技术架构审查：供应商的系统是单点还是分布式？容灾能力如何？我见过一个号称“高可用”的行情供应商，实际架构里居然只有一个数据库节点。
- 数据链路验证：从源数据到你的交易终端，中间经过多少跳转？每一跳的延迟是多少？我曾经让供应商提供全链路延迟测试报告，结果发现他们自己都没测过。
- 安全合规审计：供应商有没有等保认证？数据存储是否加密？日志留存是否满足监管要求？嗯，这块不能只看证书，要抽查。
- 人员稳定性评估：核心团队流动率如何？我遇到过一家供应商，一年换了三拨开发，系统文档根本没人维护。
- 退出机制预案：如果合作终止，数据怎么迁移？系统怎么交接？这个很多人会忽略，但真到分手那天，没预案就是灾难。
核心原则：第三方尽调不是一次性工作。我建议每半年做一次复检，尤其是技术供应商的版本更新、人员变动、安全事件，都要触发重新评估。
13.3 外包风险持续监控
签了合同、做了尽调，就万事大吉了？当然不是。外包风险是动态的，你得持续盯着。
我搭建过一个外包风险监控看板，核心指标包括：
- 服务可用率：第三方系统的实际在线时间，低于99.9%就要预警。
- 响应延迟波动：行情推送延迟的标准差，如果突然变大，说明供应商那边可能有问题。
- 异常事件频率：比如数据丢包、接口报错、配置变更未通知等。
- 合规报告及时性：供应商是否按时提交了要求的日志或报告。
你想想看，这些指标如果全靠人工盯，根本盯不过来。所以我的做法是：把监控自动化。写个脚本，每小时拉一次供应商的接口状态，延迟超过阈值就自动发告警。
一个小技巧：我习惯在合同里约定“监控探针条款”——允许我们在供应商的系统里部署一个只读的监控探针，实时获取健康状态。很多供应商一开始会抵触，但只要你解释清楚这是为了双方好，大部分都能接受。
13.4 知识体系框架图
下面这张图，是我梳理的外包与第三方风险管理的核心逻辑。你可以把它当成一个检查清单，每次评估新供应商或者复检现有合作时，对着走一遍。
特别提醒：这张图里的每个节点，背后都要有具体的制度、流程和工具支撑。光有框架没有执行，等于白搭。我见过太多机构，框架图画得漂漂亮亮，结果供应商一出事，才发现监控指标根本没人在看。
最后说一句心里话：外包不是甩锅。你把活外包了，但风险永远是你自己的。所以，对第三方保持“信任但验证”的态度，是做市商合规的基本素养。
交易系统化学习资料 微信Strategy888888