为资金管理者、支付运营、工程师与审计人员提供直接解答。问题按人们实际提问的方式表述。如需更深入的技术细节，请参阅技术参考。
面向资金与财务负责人#
用一段话说明：什么是 pain.001？
pain.001 是客户发送给银行以发起贷记转账的 ISO 20022 报文——它是 SWIFT MT101 及各类本地平面文件格式的 XML 继任者。您的银行在接受该文件前，会根据模式和方案规则手册对其进行校验。Pain001（本软件）利用您已有的数据生成这些文件，并在提交前证明其有效。
pain.001 与 pain.008 有什么区别？
区别在于资金流向。pain.001 发起贷记转账——您把钱付出去。pain.008 发起直接借记——您根据扣款授权收取他人欠您的款项。Pain001 两者都能生成：十个版本的 pain.001（.001.03 至 .001.12）以及 pain.008.001.02。
我们仍在发送 MT101 文件。迁移有多紧迫？
非常紧迫。SWIFT 已于 2025 年 11 月停用跨境银行间支付指令的 MT 第 1、2、9 类报文；仍接受 MT 的对公渠道完全取决于各银行的自主决定，且时日无多。MT101 加载器可将现有 MT101 流程转换为经过校验的 pain.001，无需重新录入任何数据。
2026 年 11 月的结构化地址期限对我们意味着什么？
自 2026 年 11 月底起，CBPR+ 跨境支付不再接受完全非结构化的邮政地址；地址必须是结构化或混合形式——使用城镇（
Pain001 要花多少钱？
免费。核心采用 Apache-2.0 / MIT 双重许可；配套软件包采用 Apache-2.0。商业使用、修改与再分发均被允许。作为规模参照，仅 SWIFT 的转换 SDK 每年报价即达 €10,000–30,000。
面向支付运营#
银行为什么会拒收支付文件？
四个常见原因：模式违规（元素错误、版本错误、命名空间错误）、标识符错误（IBAN 校验和不符、BIC 格式错误）、控制总计不符（NbOfTxs / CtrlSum 与交易不匹配），以及超出 ISO 20022 拉丁字符集的字符。Pain001 在文件生成之前就检查全部四项：逐条记录的 JSON Schema 校验、mod-97 IBAN 与 ISO 9362 BIC 检查、重新计算的控制总计、字符集转写，以及对渲染 XML 的最终 XSD 校验。
能否只校验文件而不生成任何内容？
可以——使用 pain001 --dry-run（或 validate 子命令，或 POST /api/v1/validate）。退出码 0 表示有效；1 表示校验失败并给出字段级错误。可将其接入 CI 或提交前检查清单。
覆盖哪些 SEPA 规则手册？
内置五套方案规则手册：SEPA 贷记转账（sepa-sct）、SEPA 即时转账（sepa-inst）、SEPA 直接借记 Core（sepa-sdd）、SEPA B2B（sepa-b2b）以及跨境贷记转账（xborder-ct）。使用 --scheme 可查看每条规则的通过或失败情况。
我们的数据都在 Excel 里。有什么坑？
Excel 会悄悄把类似 IBAN 的字符串强制转换成数字。Excel 加载器直接读取 .xlsx/.xlsm，一旦发现 IBAN 列包含数值单元格便立即终止——数据损坏在加载时即被发现，而不是到了银行才暴露。
它如何处理 500,000 行的批量？
--streaming 以内存受限的分块方式处理输入（默认每块 1,000 笔交易），每个分块输出为独立的 XML 文件，并附带正确重算的控制总计。出于同样的原因，REST API 提供 POST /api/v1/generate/async 及任务轮询。
面向工程师与架构师#
我们该如何集成——库、CLI 还是 API？
三者都是一等接口：带类型标注的 Python API、退出码对 CI 友好的 CLI，以及带同步、异步任务、健康检查与 Prometheus 指标端点的 FastAPI 微服务（pain001 serve）。底层是同一条校验流水线，因此各接口的结果永不分歧。
XML 生成真的能避免浮点舍入问题吗？
金额在生成与方案校验中全程使用 decimal.Decimal——按精确十进制解析、按精确十进制求和、渲染时不经过浮点表示。控制总计根据已校验的记录重新计算，绝不采信输入。
安全态势如何？
所有 XML 解析均经由 defusedxml（阻断 XXE 与实体扩展攻击）；依赖树中不含 lxml。输入会经过路径遍历校验器。Docker 镜像以非 root 运行。核心版本发布时生成 CycloneDX SBOM，且可通过 PAIN001_DISABLE_PLUGINS=1 彻底禁用第三方插件发现。
质量如何保障？
核心以 100% 行与分支覆盖率作为 CI 硬性门禁（可验证：3,828 行、926 个分支均为 100%），加上严格 mypy、100% docstring 覆盖率、Bandit 与 pip-audit 安全检查以及 CodeQL 扫描。配套软件包遵循同样的 100% 覆盖率纪律。
能否扩展以支持专有格式？
可以——四个插件入口点组（pain001.loaders、pain001.validators、pain001.schemes、pain001.writers）。Excel 加载器本身就是使用公开协议的插件，因此也可作为参考实现。
面向审计与合规#
能否复现上个季度生成的文件？
可以。锁定软件包版本、重放相同输入，输出即是确定性的。由于工具链是开源的，审计线索可以一直延伸到代码路径本身——而不仅仅是供应商的一纸声明。
支付数据会离开我们的环境吗？
不会。每个组件——CLI、库、REST API、MCP 服务器、LSP——都在本地执行。没有遥测、没有 SaaS 回调、没有外部校验服务。MCP 服务器仅通过 stdio 通信，其全部 17 个工具均标注为只读且幂等。
Pain001 由谁维护？
Sebastien Rousseau——常驻伦敦的金融科技工程负责人——以及社区贡献者。开发在 GitHub 上公开进行，版本发布至 PyPI，且每次发布都附带版本化的变更日志。