TOPIC HOME
SWIFT 状态与异常图专题主页 / SWIFT 状态与异常图
这张图区分消息发送、技术校验、业务受理、处理中、结算完成、失败、取消、修订和异常处理等不同层级状态。
RELATED SUBMAPS
相关专题子图
可在主图和其他专题子图之间切换，继续查看相邻业务链路。
这张图建立 SWIFT 的基础认知，区分网络、机构、BIC、消息、报文标准、MT、MX、ISO 20022、网关和内外部系统。
进入子图 →这张图从内部付款指令出发，展示付款方、收款方、机构角色、代理行、Nostro、消息类型、状态、Statement 和对账之间的真实联系。
进入子图 →这张图把 FX Trade、Value Date、Expected Cashflow、SSI、付款指令、SWIFT、代理行、Nostro、对账、会计和监管报表串成一条完整外汇交割链路。
进入子图 →这张图展示债券和证券交易如何通过结算指令、DVP、CSD、托管、证券账户、状态消息、Statement 和持仓对账形成可信资产记录。
进入子图 →这张图展示账户 Statement 如何把外部账户结果带回内部系统，并与 Expected Cashflow 进行现金和 Nostro 对账，最终形成 Matched、Unmatched、Cash Break 和 Reporting Data。
进入子图 →这张图区分消息发送、技术校验、业务受理、处理中、结算完成、失败、取消、修订和异常处理等不同层级状态。
进入子图 →这张进阶图解释传统 MT、结构化 MX、ISO 20022、数据映射、遗留系统、网关、校验、下游、对账、报表和数据质量之间的系统关系。
进入子图 →完整地图更适合横屏 / 平板 / 电脑查看
子节点目录
当前筛选显示 34 个节点、37 条关系线。
🔒 Message Sent
process · Level 2
Message Sent 表示内部系统或网关已尝试把消息发送到外部通道。
🔒 Technical Validation
process · Level 2
Technical Validation 检查消息格式、必填项、路由和技术规则。
🔒 ACK
concept · Level 2
ACK 表示消息在某个技术接收或校验层被确认。
🔒 NACK
concept · Level 2
NACK 表示消息在技术层未通过接收、格式、路由或其他校验。
🔒 Accepted
concept · Level 2
Accepted 表示接收方或下游系统已在业务层受理消息。
🔒 Rejected
concept · Level 2
Rejected 表示消息在业务规则、账户、合规或处理条件上未被受理。
🔒 Pending
concept · Level 2
Pending 表示业务已受理但尚未完成。
🔒 Settled
concept · Level 2
Settled 表示付款或证券结算在业务层达到完成状态。
🔒 Failed
concept · Level 2
Failed 表示付款或结算未能完成。
🔒 Cancelled
concept · Level 2
Cancelled 表示消息或业务被取消，后续不再按原计划执行。
🔒 Amended
concept · Level 2
Amended 表示业务或消息内容经过受控修改并形成新版本。
🔒 Business Status
concept · Level 2
Business Status 汇总消息对应业务在受理、处理中、完成或失败的状态。
🔒 Payment Status
concept · Level 2
Payment Status 专门描述付款的受理、处理、结算和失败状态。
🔒 Settlement Status
concept · Level 2
Settlement Status 描述资金或证券结算的业务进度和结果。
🔒 Exception Queue
process · Level 2
Exception Queue 集中管理需要人工或自动处理的消息和业务异常。
🔒 Investigation
process · Level 2
Investigation 用于定位消息或业务未完成的真实原因。
🔒 Repair
process · Level 2
Repair 是对错误或不完整消息进行受控修正。
🔒 Resend
process · Level 2
Resend 是在消息内容有效但传输或处理需要重试时重新发送。
🔒 Resolution
process · Level 2
Resolution 表示异常经过处理并达到可关闭或继续业务的状态。
🔒 Audit Trail
system · Level 2
Audit Trail 记录消息和业务状态变化、处理动作、人员、时间和版本。
🔒 Validation
process · Level 2
Validation检查消息是否满足格式 标准和业务规则
🔒 Approval
process · Level 2
Approval是消息发送前的业务授权和操作控制
🔒 Account or Position Result
concept · Level 2
Account or Position Result是消息处理后在现金账户或证券持仓上形成的实际结果
🔒 Archive
process · Level 2
Archive保存消息原文 状态 时间和处理轨迹
🔒 RMA
process · Level 2
RMA是控制金融机构之间是否允许交换特定消息的授权机制
🔒 Sanctions Screening
process · Level 2
Sanctions Screening检查消息中的参与方 地区和业务信息是否触发合规审查
🔒 Settlement Matching
process · Level 2
结算前双方指令关键要素的匹配过程
🔒 Fail Reason
concept · Level 2
说明证券结算失败原因的状态信息
🔒 Duplicate Control
process · Level 2
Duplicate Control识别同一业务消息是否被重复发送或重复处理
🔒 Owner Assignment
process · Level 2
Owner Assignment将异常分派给负责处理的团队或人员
🔒 SLA
process · Level 2
SLA定义异常必须在多长时间内被处理或升级
🔒 Cut Off Time
concept · Level 2
Cut Off Time是某个币种 市场或结算系统接受当日处理的截止时间
🔒 Operational Monitoring
process · Level 2
Operational Monitoring持续观察消息流量 队列 错误和延迟
🔒 End of Day Control
process · Level 2
End of Day Control确认当天消息 账户 状态和异常是否完整处理
SWIFT 状态与异常图
这张图区分消息发送、技术校验、业务受理、处理中、结算完成、失败、取消、修订和异常处理等不同层级状态。
地图定位
这张图区分消息发送、技术校验、业务受理、处理中、结算完成、失败、取消、修订和异常处理等不同层级状态。
这张图回答的问题
- ACK 为什么不等于业务完成
- NACK 和 Rejected 有什么区别
- Accepted、Pending、Settled 如何衔接
- Payment Status 与 Settlement Status 为什么不同
- Repair、Resend、Investigation 如何处理异常
- 为什么所有状态变化都需要 Audit Trail
建议学习路径
- 1. 从 Message Sent 和 Technical Validation 开始
- 2. 理解 ACK、NACK 与 Accepted、Rejected 的层级差异
- 3. 沿 Pending 观察 Settled 或 Failed
- 4. 理解 Business Status、Payment Status、Settlement Status
- 5. 最后看 Exception Queue、Investigation、Repair、Resend、Resolution 和 Audit Trail
本图使用的业务案例
- 案例 F：付款报文技术层 ACK，但业务状态长期 Pending，后因收款账户关闭变为 Failed，需要 Repair 或 Resend
- 案例 C：银行 A 买入面值 50,000,000 CNY 的案例债券 BOND-001，约定 T+1 通过 DVP 交收
- 案例 G：旧系统将付款人地址放在自由文本中，新 MX 报文要求拆成国家、城市、街道等结构化字段，映射不完整导致校验失败
节点目录
- 1. Message Sent
- 2. Technical Validation
- 3. ACK
- 4. NACK
- 5. Accepted
- 6. Rejected
- 7. Pending
- 8. Settled
- 9. Failed
- 10. Cancelled
- 11. Amended
- 12. Business Status
- 13. Payment Status
- 14. Settlement Status
- 15. Exception Queue
- 16. Repair
- 17. Resend
- 18. Investigation
- 19. Resolution
- 20. Audit Trail
建议知识库条目
- Message Sent、ACK、Accepted、Settled 的区别
- Technical Validation 与 Business Validation 的区别
- ACK 和 NACK 是什么
- Accepted 和 Rejected 是什么
- Pending 为什么需要 SLA
- Settled 为什么仍需对账
- Failed 与 NACK 的区别
- Cancelled 与 Amended 的区别
- Exception Queue 如何管理异常
- Repair、Resend、Reprocess 的区别
- Investigation 如何定位原因
- Resolution 和 Audit Trail 为什么重要
后台展示建议
- 1. 节点详情建议按以下顺序展示：一句话解释、详细说明、业务与系统案例、相近概念区别、常见误解、上下游。
- 2. 案例板块建议使用可折叠卡片，标题统一为“业务案例：这项能力在真实链路中如何出现”。
- 3. 关系线说明应写入 edge description 或 relation description，不要改变现有 source / target。
- 4. 若同名节点被多张地图复用，优先写入 mapNode override 或子图专属内容，避免覆盖其他地图语境。
- 5. 完成更新后，可将当前地图和成功更新的节点状态设置为“已更新”或项目已有等价状态。
从 0 到 1｜本图学习引导
同一笔业务可以同时具有网络状态、业务状态、账户状态和对账状态。先区分 ACK、NACK、Pending、Settled、Failed，再看 Exception Queue、Owner、SLA、Repair、Resend、Duplicate Control 和日终控制。
Branch 访问说明
所有 Branch 都由后台权限控制。未授权访客只能看到锁定预览，开通授权后可查看完整节点文章和关系解释。