SWIFT CSP
CSP（Customer Security Programme，客户安全计划）是 SWIFT 于 2016 年启动的用户侧安全计划，其中的控制框架称 CSCF（Customer Security Controls Framework）。CSCF 每年出一个新版本，大致 7 月发布、 次年在 KYC-SA 平台生效。可核实的最新版是 v2025，文件日期 2024-07-01；v2026 及之后是否已发布 待验证，本次核对时 swift.com 全部返回 403。
CSP 与同目录其他框架的性质不同。它不是可以自愿采纳的标准，而是接入 SWIFT 网络的机构每年必须完成并提交的动作。
控制项组织
三个目标（objective），其下分 7 条原则，控制项编号从 1.1 到 7.4：
| 目标 | 关注点 |
|---|---|
| Secure your Environment | 系统加固、网络分区、恶意代码防护 |
| Know and Limit Access | 身份与凭据、特权访问、物理访问的收敛 |
| Detect and Respond | 活动监测、异常检测与事件响应 |
v2024 与 v2025 均为 32 项控制，其中 25 项强制、7 项建议性。建议性控制的编号带后缀 A，如 2.4A、7.3A。三条原则各自对应的控制项分布 待验证。
适用范围
按 architecture type 划分，共五种，适用控制的数量随类型递减：
| 类型 | 形态 |
|---|---|
| A1 | 通信接口 |
| A2 | 报文接口 |
| A3 | SWIFT Connector |
| A4 | 客户 Connector |
| B | 仅使用 GUI |
A1 适用的控制最多，B 最少。五种类型的判定边界 待验证，网上流传的另一套「local / shared / remote」以及「B1–B3」的划分方式与 CSCF 不符，不要混用。
architecture type 的判定会直接改变适用控制的数量，判错了整个范围就错。这一步建议在项目初期就与 SWIFT 侧确认，不要自行推断。
Attestation
每年强制提交，窗口为 7 月至 12 月，12 月 31 日截止，通过 KYC-SA（KYC-SAP 平台）提交。结果对交易对手与监管可见——这是 CSP 与其他合规框架最不一样的地方：不合规不是内部问题，是会被同行看到的。未按期提交的后果包括公开披露、SWIFT 通报，直至中断服务。
评估路径有两条。自评本身就被视为一条不合规路径；独立评估可以由 SWIFT 名录内的外部认证机构做，也可以由组织内部独立的第二、三道防线做。SWIFT 每年随机强制一部分用户接受外部评估。
时限规则有几条容易忽略：评估结论最多沿用两个年度，每两年须做一次全量重评；报告出具后 30 天内提交；证据留存 5 年。
与 ISO 20022 的关系
ISO 20022 是 SWIFT 的报文标准（MX 报文），与 CSP 属不同体系，一个管报文格式，一个管安全。两者常在同一个迁移项目里推进，但合规义务的来源完全不同，不要用报文迁移的进度去替代 CSP 的 attestation。CSP 的强制性在 SWIFT 用户协议中对应哪一条款 待验证。
落地时的难点
32 项控制里真正难的不是技术项，是取证项。attestation 要求为每条控制提供证据，而多数机构的日志留存与变更记录达不到 5 年的要求；等到提交窗口打开才去补，补出来的证据本身就不成立。
另一个常见失误是把 CSCF 当成一次性项目。它每年换版，控制项会增删，上一年的评估结论最多沿用两个年度，实际上意味着整改必须常态化运行。
参考
- SWIFT 官网（CSCF 文档经 MySWIFT 客户门户分发，公开抓取受限）：
https://www.swift.com/