金融系统集成架构设计与排障：用 API、FIX、ISO…

适用于设计或排障金融系统之间的集成管道，尤其是托管行、交易、结算、对账数据流，并落实幂等、重试、DLQ、数据映射与审计要求。

适用场景

解决思路

1. API设计——REST 资源：用名词表示金融实体，例如 `/accounts/{id}/positions`、`/transactions`、`/orders/{id}/executions`；HTTP 方法按语义使用：GET 读持仓/余额，POST 提交订单/发起转账，PUT/PATCH 更新账户偏好/模型分配。
2. API设计——响应：返回标准 HTTP 状态码，错误体包含 error code、人类可读 message、correlation ID；区分同步操作（持仓查询立即返回）和异步操作（转账发起返回 202 Accepted 加状态轮询 URL 或 webhook）。
3. API设计——异步长操作：批量再平衡、批量交易提交等长时间运行操作使用 async pattern，避免客户端超时。
4. API设计——WebSocket/流：实时持仓更新、订单状态、市场数据用 WebSocket 服务器推送；实现 heartbeat/ping-pong 检测陈旧连接；自动重连并状态恢复，客户端重连后必须收到漏掉的更新；处理 back-pressure。
5. API设计——版本化：用 URL-based versioning（如 `/v2/positions`）；破坏性变更（字段删除、类型变化、语义变化）需新版本，附加性变更（新增可选字段）不需要；至少维护两个并发版本并发布 12-18 个月弃用时间表。
6. API设计——分页：持仓和交易端点用 cursor-based pagination（不透明 next-page token）优于 offset-based；包含 total count estimates、page size limits、sorting 参数；批量提取提供单独 export/download 端点返回文件，而非分页 API 调用。
7. API设计——限流：用 token bucket 或 sliding window 防市场开收盘/波动尖峰；返回 `429 Too Many Requests` 和 `Retry-After`；区分 per client、per endpoint、per operation type（读 vs 写）。
8. API设计——认证授权：服务间用 OAuth 2.0 client credentials flow；简单集成用 API keys + HMAC request signing；高安全托管/清算连接用 mutual TLS (mTLS)；RBAC 限定到 accounts、operations（read-only vs read-write）、data sensitivity levels；自动化 token expiration 和 rotation。
9. API设计——集成测试：使用镜像生产行为的 UAT/sandbox，包括真实数据量、错误场景、延迟；做 contract testing 验证生产者和消费者符合 API 规范；托管行/数据供应商 certification environments 完成认证后才生产连接；测试套件覆盖 happy path、每个文档化错误码、超时、分页边界、限流响应。
10. FIX——协议结构：消息是 tag=value 对，以 SOH (ASCII 0x01) 分隔；每条含 header（BeginString、BodyLength、MsgType、SenderCompID、TargetCompID、MsgSeqNum、SendingTime）、body（消息类型字段）、trailer（CheckSum）；tags 数字如 35=MsgType、55=Symbol、44=Price、38=OrderQty。
11. FIX——会话层：用 Logon (MsgType=A) 建立会话并同步序列号；Heartbeat (MsgType=0) 和 TestRequest (MsgType=1) 监控连接；ResendRequest (MsgType=2) 和 SequenceReset (MsgType=4) 处理断线缺口恢复；Logout (MsgType=5) 终止会话；每会话每方向序列号严格单调，缺口触发自动恢复。
12. FIX——应用消息：NewOrderSingle (MsgType=D) 提交订单；ExecutionReport (MsgType=8) 报告成交、部分成交、撤单、拒绝；OrderCancelRequest (MsgType=F) 和 OrderCancelReplaceRequest (MsgType=G) 修改/撤销订单；MarketDataRequest (MsgType=V) 订阅行情；MarketDataSnapshotFullRefresh (MsgType=W) 和 MarketDataIncrementalRefresh (MsgType=X) 交付行情。
13. FIX——版本：FIX 4.2 仍广泛用于股票订单路由；FIX 4.4 增强多腿工具、分配、持仓管理；FIX 5.0（with FIXT 1.1 transport）解耦会话和应用层；新实现按对手方选择 FIX 4.4 或 FIX 5.0/FIXT 1.1。
14. FIX——引擎/库：可用 QuickFIX、QuickFIX/J、Chronicle FIX、Cameron FIX、Onix FIX；引擎处理会话管理、解析、序列、持久化；应用逻辑通过回调如 onMessage handlers per message type。
15. FIX——连接管理：每个对手方独立 FIX session，约定 CompIDs、消息版本、自定义 tags，并在 UAT 测试后上生产；用 FIX hub 或 OMS 集中管理 20-50 个跨 broker/exchange/custodian sessions。
16. FIX——自定义 tag/扩展：对手方常要求 tag numbers above 5000 的自定义 tags 表示内部订单 ID、策略代码、清算指令、监管标识；在 FIX specification agreement 中按对手方记录所有自定义 tags；验证入站自定义 tags 检测 schema drift。
17. FIX——drop copy：用 drop copy 会话向风险、合规、中台提供所有 execution reports 实时副本，不影响主交易会话；需要实时交易监督或独立持仓跟踪时配合 OMS。
18. FIX——性能：高频交易关注解析/序列化延迟，用 binary FIX encodings（SBE，Simple Binary Encoding，用于 FIX 5.0 FIXT）降低开销；买方订单路由数百到数千订单/日可用文本 FIX 4.4，更易调试。
19. FIX——交易后：用 Allocation messages（MsgType=J，AllocationInstruction）沟通大宗交易拆分到账户；AllocationReport（MsgType=AS）确认分配；Confirmation（MsgType=AK）提供每 allocation 交易级明细；T+1 下分配须在成交后数小时内传达。
20. ISO 20022——结构：XML schemas 按业务域组织；每条消息有 Business Application Header (BAH) 含 sender、receiver、message type、creation date，然后 business document；消息由域类别中四字符代码标识。
21. ISO 20022——域类别：`pain` 支付发起、`pacs` 支付清算结算、`camt` 现金管理、`semt` 证券管理报表/余额、`setr` 证券交易订单/确认、`sese` 证券结算指令/确认/状态、`secl` 证券清算、`colr` 担保品管理、`reda` 参考数据。
22. ISO 20022——关键消息：semt.002 托管持仓报表；semt.017 证券交易报表；setr.004 赎回订单；setr.010 认购订单；sese.023 证券结算交易指令；sese.024 证券结算状态通知；pacs.008 FI to FI customer credit transfer；pacs.009 FI to FI financial institution credit transfer；camt.053 Bank-to-customer statement。
23. ISO 20022——SWIFT迁移：SWIFT 跨境支付 MT/MX 共存从 2023 年 3 月开始，2025 年 11 月 22 日完成；ISO 20022 (CBPR+) 是金融机构间跨境支付指令唯一标准，网络拒绝 legacy MT 支付指令（如 MT103、MT202）；证券消息迁移较晚，MT535、MT548 仍使用。
24. ISO 20022——MT边界：内部 MT 处理须在边界翻译；从 ISO 20022 回翻译到受限 MT 字段可能丢失信息；MT 用固定字段有限长度（MT103、MT202、MT535、MT548）。
25. ISO 20022——丰富性：ISO 20022 提供更长参考字段、结构化地址、LEI 支持、purpose codes、remittance information；ISO 15022（证券前身）用类似 SWIFT MT 的 tagged format；ISO 20022 替代两者。
26. ISO 20022——实现：消息比 MT 大 10-50x；高量下关注 XML 解析开销；处理前做 schema validation；许多公司实现 canonical internal format，在集成边界翻译到/从 ISO 20022，而非全程原生处理。
27. ISO 20022——测试认证：SWIFT 要求迁移前完成 readiness assessment 和 certification testing；测试覆盖 message format compliance、field population rules、character set handling（UTF-8）、end-to-end transaction flow validation；支付共存结束后并行 MT/MX 仅对仍在 legacy formats 的消息类别（如证券）要求。
28. EDA——核心模式：publish-subscribe（生产者发事件到 topics，消费者独立订阅）；event streaming（有序、持久事件日志，消费者按自己节奏读取）；event sourcing（系统状态由顺序事件日志派生而非可变记录）。
29. EDA——金融事件类型：交易事件（order submitted、acknowledged、partial fill、full fill、cancel、reject）；结算事件（instruction sent、matched、settled、failed）；公司行动事件（announcement、election deadline、ex-date、pay-date）；参考数据事件（new security created、identifier changed、price updated）；账户事件（opened、restricted、closed）；合规事件（alert triggered、alert resolved）。
30. EDA——broker选择：Apache Kafka 高吞吐、有序日志、replay、partitioning，用于交易事件流、审计轨迹、持仓更新；Solace 金融级、多协议（JMS、AMQP、MQTT、REST），用于市场数据分发、跨区域；RabbitMQ 灵活路由、AMQP 0-9-1，用于任务队列、请求-回复、异常处理；TIBCO EMS/FTL 企业中间件、legacy 集成，用于资本市场、主机连接；IBM MQ 事务性、exactly-once、银行级，用于银行支付、高价值交易；按吞吐、顺序保证、现有基础设施、运维经验选择；Kafka 在新资本市场/资管占主导，IBM MQ/TIBCO 扎根银行/清算。
31. EDA——事件溯源审计：每次状态变化追加 event，含 timestamp、actor、payload；重建账户/持仓/订单任意时点状态时回放事件到该 timestamp；符合 books-and-records（SEC Rule 17a-4、FINRA Rule 4511）。
32. EDA——CQRS：分离写（trade booking、settlement instruction）和读（position queries、reporting）；金融系统读多写少，每 trade writer 有数百报告消费者；优化读模型（物化视图、按查询模式反规范化），保持严格可审计写路径。
33. EDA——schema：事件含 metadata（event ID、timestamp、source system、correlation ID、schema version）和 business payload（trade details、settlement status、account attributes）；schema 演进向后兼容，新消费者处理旧事件，旧消费者容忍新字段；用 schema registry（Confluent Schema Registry、AWS Glue）发布时强制兼容性检查；破坏性变更用新 topic 或版本化事件类型并并行消费。
34. EDA——排序：fill event 在 order-acknowledged 前处理会破坏状态；Kafka 在 partition 内有序，按最重要 key 分区（持仓更新用 account ID，订单生命周期用 order ID）；跨 partition 顺序用应用层 sequencing（timestamps、sequence numbers）并处理乱序。
35. EDA——消费者恢复：Kafka 消费者重启从 last committed offset 恢复；若处理消息后、提交 offset 前崩溃会重处理，需幂等；标准模式：处理消息；在单事务中将结果和消息 offset 写入数据库；提交 Kafka offset；若提交失败，重处理时数据库事务通过存储 offset 检测重复并跳过。
36. 批处理——文件类型：Position files（每账户 EOD 持仓）、transaction files（交易、收入、费用、公司行动）、cash balance files、performance return files、billing files、reconciliation files、reference data files（security master updates、pricing）、tax lot files。
37. 批处理——频率/窗口：Position file 每日 1:00-4:00 AM ET，截止在早晨投组审查前；transaction file 每日 1:00-4:00 AM ET，截止在对账运行前；cash balance file 每日 2:00-5:00 AM ET，截止在现金管理前；pricing file 每日 6:00-8:00 PM ET 前一晚，截止在隔夜估值前；tax lot file 每日或每周 2:00-6:00 AM ET，截止在税务报告前；reconciliation file 每日 3:00-6:00 AM ET，截止在运营审查前；corporate action file 事件驱动+每日，截止在 ex-date 处理前。
38. 批处理——格式：CSV（托管行 feeds 最常见，列顺序因托管行而异）、fixed-width（部分托管行/清算公司仍用，列位置由规范定义）、XML（更丰富数据，证券领域与 ISO 20022 对齐）、JSON（现代 API-based file delivery 中新兴）、proprietary（供应商特定格式需专用解析器）。
39. 批处理——交付：SFTP（主流，定时 push/pull）、S3/cloud storage（托管行 feeds 增长）、API-based file download（REST 轮询新文件）、MQ/message-based（文件通知触发 pickup）、email with encrypted attachments（legacy 下降）；所有传输加密 in transit（SFTP 自带；S3 需 HTTPS；无 TLS 的 FTP 绝不可用于金融数据）；用 PGP/GPG 加密文件内容。
40. 批处理——管道阶段：1 File monitoring 检测到达并验证预期文件在截止前收到；2 File validation 做 checksum、record count 对照 trailer、schema、字符编码；3 Parsing 提取记录到结构化格式并处理各源差异；4 Business validation 做引用完整性（账户存在、证券存在）、值域、跨字段一致性；5 Transformation 映射 canonical format、翻译标识符、从参考数据 enrich；6 Loading 插入/更新目标系统并处理重复；7 Reconciliation 比较加载数据与源计数和控制总计。
41. 批处理——序列和幂等加载：托管行文件含 sequence numbers 或 file dates；跟踪每源 last processed sequence 检测缺口（缺失文件）和重复（重处理）；设计加载幂等，重处理同一文件产生相同结果且不重复计数。
42. 批处理——批 vs 实时：batch 简单、自然检查点、与 EOD 对账周期对齐；real-time 即时但增加状态管理、错误恢复、排序保证；多数公司混合：订单流/交易执行实时，EOD 持仓/对账/报告 batch。
43. 批处理——迟到/缺失：为每源定义文件到达 SLA 和升级流程；跟踪到达历史建立正常窗口并检测异常；迟到时决定等待（延迟下游）、不处理继续（不完整数据风险）、或用前一天数据并标 stale-data flag；选择取决于关键性（缺 position file 阻塞投组报告；缺 billing file 可次日处理）。
44. 批处理——重发/更正：托管行/对手方偶尔重发修正文件；管道检测重发（同日期、更新 sequence 或 timestamp），撤销原加载，应用修正数据；原加载需可逆，通过 soft deletes with version tracking 或按 file date 和 source 做 full replacement。
45. 幂等——必要性：金融交易要求 exactly-once；重复订单、重复结算指令、重复股息过账造成真实货币错误；网络不可靠，调用方常无法区分请求失败与成功但响应丢失；无幂等时重试超时订单提交可能创建重复订单。
46. 幂等——key设计：客户端为每个逻辑操作生成唯一 key（UUID，或确定性组合键如 account + security + side + quantity + timestamp）；服务端存储 key 和结果，重复 key 返回存储结果不重执行；key 有 TTL（小时到天）；金融操作优先用含业务属性的组合键（order ID、trade reference、settlement instruction ID），而非随机 UUID，以便不同客户端实例重试也能去重。
47. 幂等——重复检测模式：1 服务端 idempotency table (key, result, expiry) 处理前检查；2 数据库对业务键 unique constraints 防重复插入；3 消息 broker 去重（Kafka exactly-once via idempotent producers and transactional consumers）；4 分布式锁用于跨多系统操作；5 内容去重（payload hash）作为无 key 时二级检查。
48. 幂等——at-least-once：金融系统实用模式是 at-least-once delivery with idempotent processing；broker 保证 at-least-once，消费者幂等使同消息处理两次无额外效果；提供 effectively exactly-once 语义，避免真正分布式 exactly-once 复杂性和性能成本。
49. 幂等——replay安全：幂等系统支持安全 replay 事件流用于恢复、迁移、对账；运营团队可重处理一天交易对账而不担心重复入账。
50. 幂等——跨系统边界：集成跨多系统时 idempotency key 必须一致；如 broker 确认交易但内部入账超时，重试用同一 key 做 broker 重查询和内部入账；在业务操作级别而非单个 API 调用级别设计 key。
51. 弹性——重试：瞬时错误（network timeout、HTTP 503）立即重试；持续不可用用 exponential backoff with jitter（base delay * 2^attempt + random jitter）；设重试次数和总时长上限；分类可重试（timeout、429、503、connection reset）与不可重试（400、401、403、422）；无 idempotency keys 不重试非幂等操作。
52. 弹性——circuit breaker：用 Closed（正常，请求通过并计数失败）、Open（跳闸，所有请求立即失败不联系上游，保护调用方和上游）、Half-open（冷却后允许有限请求测试恢复）；转换阈值：连续 N 失败或窗口错误率超 X% 开，冷却后 half-open，half-open 中连续 N 成功闭；金融系统保护交易平台和结算系统；跳闸时定义 fallback（排队消息、缓存数据、告警运营）。
53. 弹性——DLQ：失败所有重试的消息路由 DLQ 而非丢弃；DLQ 保留消息及失败 metadata（error reason、attempt count、timestamps）；运营审查、诊断、重处理或手动解决；金融运营中丢弃结算指令比延迟更糟；监控 DLQ depth。
54. 弹性——补偿交易：多步部分完成且后续失败时，用 compensating transactions 撤销早期步骤；示例：broker 订单确认但内部入账失败时取消 broker 订单；为多系统工作流每一步设计补偿动作；补偿是新的前向动作（cancel、reversal、credit），本身可能失败，需监控和手动解决。
55. 弹性——超时：每个集成边界设 connect timeout（秒）、read timeout（秒到分钟，按操作）、多步工作流 end-to-end timeout；金融系统超时值考虑 market-hours load、EOD 峰值、托管行 batch windows。
56. 弹性——部分失败：多记录操作（batch order submission、bulk position update）处理部分成功；100 条中 95 成功 5 失败时报告哪些成功、哪些失败及原因、能否独立重试；绝不静默丢弃失败，返回每条记录详细 result manifest；金融运营中缺失记录与丢失交易无法区分。
57. 弹性——监控告警：跟踪 throughput（每通道每秒消息）、error rate（失败消息百分比）、latency（源事件到目标更新端到端）、queue depth（每消费者积压）、DLQ depth（未解决失败）；告警分级 warning（错误率升高）、critical（集成 down 或 DLQ 阈值超限）、emergency（数据丢失风险）；dashboard 可见性同等重要。
58. 映射——字段映射：维护 source-to-target mapping documents；金融映射常非平凡：一个源字段拆成多个目标字段（合并 name 拆 first/last）、多个源字段合并成一个目标字段、字段需 lookup 或 derivation；mapping specifications 作为版本化 artifacts 维护，是集成契约。
59. 映射——标识符：同一证券可能不同系统用 CUSIP、ISIN、专有 ID；集成层维护 cross-reference tables（来自 security master）翻译；始终通过 canonical internal ID 翻译，而非直接外部标识符之间，避免 N-to-N 复杂度。
60. 映射——代码标准化：货币代码用 ISO 4217（USD、EUR、GBP）；国家代码用 ISO 3166（US、GB、DE）；交易类型代码映射到 canonical code set 并维护 per-source translation tables；日期格式（YYYYMMDD、MM/DD/YYYY、ISO 8601）在管道早期规范化。
61. 映射——参考数据富化：入站数据常缺目标所需字段；转换时查 security master（asset class、sector、issuer）、client master（household、advisor）、account master（registration type、tax status）；设计 graceful degradation：参考数据不可用时排队记录重试而非整批失败。
62. 映射——未映射值：遇到无映射源值（新交易代码、未识别证券类型、国家代码变体）不得静默丢弃或默认；路由到 exception queue；记录供 steward review；解决后添加新映射到 translation table；跟踪每源未映射值频率作为数据质量指标，尖峰表示源系统变更需更新映射表。
63. 映射——canonical model：定义公司级 canonical representation of key entities（trade、position、account、security、client）；所有集成在边界翻译到 canonical model，再翻译到目标特定格式；将复杂度从 N-to-N 降到 N-to-1-to-N，简化新增系统和数据源。
64. 映射——数据类型：金额用 fixed-point decimal（不是 floating-point）避免舍入错误；quantity 对共同基金可 fractional，对股票为 whole；date/time 字段携带 timezone context；boolean 表示（Y/N、true/false、1/0、T/F）在边界规范化。
65. 安全——传输：所有传输数据用 TLS 1.2 或 1.3；托管行、清算、对手方连接用 mTLS；证书管理（颁发、轮换、撤销、过期监控）关键，过期证书是集成中断首要原因。
66. 安全——静态加密：所有持久化集成数据（message stores、file staging areas、DLQs、audit logs）用 AES-256 或等效；密钥管理用 HSM 或 cloud KMS；生产和非生产都加密，除非测试数据明确匿名化。
67. 安全——PII：集成 payload 常含 SSN/TIN、出生日期、账号、财务细节；最小化传输 PII；日志和监控 dashboard 中 mask 或 tokenize 敏感字段；给集成通道打数据分类标签（public、internal、confidential、restricted）并执行控制。
68. 安全——审计日志：记录每个集成事件：message sent、received、transformation applied、validation passed/failed、error、retry、manual intervention；包含 timestamp、source system、target system、message identifier、correlation ID、outcome；按 books-and-records 政策保留（broker-dealers 通常 SEC Rule 17a-4 下 6-7 年，investment advisers 通常 SEC Rule 204-2 下 5 年）；审计日志不可变，用 write-once 或 append-only。
69. 安全——correlation ID：单一业务操作可能穿越 5-10 个系统；在源头生成 correlation ID 并在每个系统传播，端到端追踪路径、时间、结果；没有它排查失败结算需手动跨日志关联时间戳；将 correlation ID propagation 作为所有集成通道强制标准（HTTP headers、FIX custom tags、message metadata、file record fields）。
70. 安全——SOC 2：集成基础设施属于 SOC 2 Type II 审计范围；控制含 access management、change management、availability、confidentiality；第三方集成供应商（iPaaS、middleware）须提供 SOC 2 reports。
71. 安全——非生产：集成测试环境常用生产衍生数据，含真实 PII 和财务信息；非生产必须使用完全匿名/合成数据，或实施与生产相同访问控制和加密；监管和审计特别审查非生产数据处理。
72. 工作示例：设计具体集成或用户要 worked architecture example 时加载 `references/examples.md`，包含多托管行 RIA 集成架构、Kafka 事件驱动交易通知、弹性 EOD 结算批处理管道。
73. 关键避免/检查：金融交易 API 必须加幂等，防止超时重试重复订单/结算指令。
74. 关键避免/检查：批处理不得简单加载文件，必须做 checksum、record count、sequence number tracking，防止损坏/截断/重复文件污染 book of record。
75. 关键避免/检查：避免每对系统点对点集成；用 canonical data model 和中央集成层，将 N*(N-1)/2 降到 N。
76. 关键避免/检查：FIX 会话恢复依赖正确序列号持久化；与对手方协调后重置序列号，否则消息丢失或重复。
77. 关键避免/检查：时间敏感数据不要用 polling，用 event-driven；polling 平均引入半个轮询间隔延迟、浪费空轮询、轮询间隙漏事件。
78. 关键避免/检查：失败消息必须进 DLQ；丢弃失败消息造成静默数据丢失。
79. 关键避免/检查：不要在集成逻辑硬编码标识符类型；假设所有证券都有 CUSIP 或 CUSIP 不变会破坏国际证券和公司行动；始终通过 security master 翻译。
80. 关键避免/检查：配置合适超时；默认 HTTP 30/60 秒常不适合金融操作，批量持仓查询可能数分钟，订单提交应快速失败。
81. 关键避免/检查：为 mTLS 连接监控证书过期，设置 30/14/7 天提前告警。
82. 关键避免/检查：处理 ISO 20022 必须 schema validation，否则 malformed XML 可导致下游隐蔽数据损坏。
83. 关键避免/检查：多步工作流必须预先设计 compensating transactions，否则部分失败只能人工恢复。
84. 关键避免/检查：不要在集成 debug 日志记录 PII（SSN、账号、财务数据），违反数据保护要求并产生监管暴露。
85. 交叉协作：与 reference-data 搭配，security master、client master、account master 提供集成 payload 的标识符和属性。
86. 交叉协作：与 market-data 搭配，实时/延迟市场数据分发复用 pub-sub、fan-out、conflation 等模式。
87. 交叉协作：与 data-quality 搭配，在集成边界做验证、监控、异常处理，作为数据质量第一道防线。
88. 交叉协作：与 settlement-clearing 搭配，结算指令在清算公司、托管行、存托机构间使用 FIX、ISO 20022、批文件。
89. 交叉协作：与 exchange-connectivity 搭配，交易所连接用 FIX 订单路由和行情；本技能覆盖协议层，后者覆盖运营和监管。
90. 交叉协作：与 order-lifecycle 搭配，OMS 到 broker 到 exchange 的订单流需要可靠集成、排序、确认、错误处理。
91. 交叉协作：与 stp-automation 搭配，STP 率受上游集成 feeds 可靠性和数据质量约束。
92. 交叉协作：与 portfolio-management-systems 搭配，PMS 是消费许多集成的 hub，是稳健集成架构主要受益者。
93. 交叉协作：与 books-and-records 搭配，集成审计轨迹（消息日志、文件处理记录、转换历史）是受保留和检查要求约束的监管记录。

适用边界 · 注意事项

• 不适用于无需金融交易、审计、对账、幂等或结算语义的简单 CRUD 或一次性脚本集成。
• 若没有金融系统上下文、无法实现幂等键/事件顺序/审计日志，或只是快速原型，应简化模式。
• 若组织没有 FIX/ISO 20022/SWIFT/托管行/清算行等对接需求，不要引入这些协议复杂度。