01 / COMPARE THE CHECKS
银行卡异议工作流验证
在一个合成的表单后工作流中,一份有效的账单错误通知在模型第 6 天未经调查便进入关闭状态。异议工作流验证探索该输入模型中的所有可达路径,检查其配置的合规义务,并展示未通过属性背后的事件路径。
93
已探索的可达状态
内置表单后模型
4 of 4
配置属性未通过
同一合成模型
Day 6
通知进入已关闭的死状态
模型时钟,非客户真实案例
这些结果针对的是人工编写的 JSON 模型和编码的演示规则,并非关于银行实际异议处理业务的调查结论。
常规跟踪系统只能报告其接收到的异议案件。如果一条路径未包含在其预期情况测试中,它便无法展示有效通知在调查前即被关闭的路径。
这份 CFPB 2024 年 10 月 Apple 同意令 描述了在首次提交异议后增加表单的情况,以及当表单未完成时符合条件的通知未被转交的情况。我们的表单后案例是对该失效模式的说明性重构,而非 Apple 的状态机或对消费者记录的重放。
审查的核心问题十分明确:在收到有效通知后,是否有任何建模路径会到达一个无法再进行调查的状态?
状态图和规则结果由针对所提供 JSON 工作流运行的确定性 Python 代码生成。
01 / MODEL
位置、转换、时间范围、标记以及产品或卡组织标签共同定义了这四个合成工作流。
02 / EXPLORE
广度优先搜索检查是否有任何有效通知状态会脱离调查路径陷入停滞,并对照配置的时序标记追踪路径。
03 / REVIEW
检验结果将属性判定与状态图、带有模型时钟值的有序反例以及可导出的审查证书关联起来。
属性判定为 COUNTEREXAMPLE 表示检验器发现失效路径, PROVEN 表示在所探索的有限模型中均成立,或 BOUNDED 表示 200 个日历日的上限限制了时间线结论。只有确定性检验器才能分配这些状态。可选的模型综合智能体可以起草模型,但它不能验证模型。
录制演练内部细节
这些界面来自所提供的合成工作流。首先查看基准的绿色通过结果,然后追踪它从未检查过的分支。每张图片均可全屏打开。
01 / COMPARE THE CHECKS
02 / FIND THE BRANCH
在状态图中,建模的通知从 Messages Submitted 转移至 Secondary Form Requested。完成表单将继续走向路由和调查。而超时则会到达 Closed Incomplete。检验器在该输入模型中探索了 93 个可达状态,并发现 4 项配置属性未通过。
03 / INSPECT THE WITNESS
未通过的属性会附带一个有序的反例。在此处,建模序列记录了第 0 天的提交、第 1 天请求二级表单以及第 6 天超时关闭。在该路径上,通知从未到达调查阶段。
04 / CHECK THE CHANGE
独立的修复模型将未完成表单的通知送入路由和调查,而不是将其关闭。随着该路径的更改,所有 4 项配置属性均为 PROVEN ,覆盖 153 个可达状态。该结论属于所提供的有限模型及其编码属性。
A SECOND WORKFLOW / TIMING
夜间批处理示例测试了在另一个独立合成模型中编码的条件性临时贷记假设。其中一条路径在第 14 个营业日才首次记入建模的贷记金额,超出了该模型的 10 个营业日限制。检验器在 79 个可达状态中,从 7 项配置属性里返回了一个反例。实际的 Reg E 例外情况和适用期限需要单独审查。
此对比针对的是同一套编写的工作流中预期路径基准与状态探索之间的差异。它并非针对已部署银行系统的基准评估。
| 审查路径 | 当前能发现的情况 | 尚未涵盖的问题 |
|---|---|---|
| 理想路径基准 | 预期路径报告 COMPLIANT。 | 它从未探索二级表单超时分支。 |
| 状态探索 | 在所提供的表单后模型中,存在 93 个可达状态以及一条通往 ClosedIncomplete 且未经调查的路径。 | 所提供的模型是否与实际工作流完全匹配。 |
| 修复后的模型 | 所有 4 项配置属性在 153 个可达状态中均成立。 | 这些属性是否涵盖了所有适用的合规义务或例外情况。 |
这四个工作流和十个基准测试夹具均为人工编写的合成模型。本页面没有连接银行、卡组织网络、核心系统、信函生成或消费者数据的实时连接器,且审查证书属于模型审查产物,而非监管机构的认可。编码的 Reg Z 和 Reg E 时钟简化了 Reg Z 账单错误规则 与 Reg E 错误解决规则;其通知条件、例外情况和实际适用性需要专业评估。Visa 和 Mastercard 的时间窗口为说明性的配置值,并非经核实的当前卡组织规则。
追踪已在队列中案件的监控面板,可能会遗漏从未进入该队列的有效通知。在这个合成表单后模型中,理想路径基准报告 COMPLIANT,而状态探索发现在模型第 6 天存在一条从有效通知到 ClosedIncomplete 且未经调查的路径。反例展示了该路径上的每个事件。
否。PROVEN 仅表示配置的属性在所提供有限模型的已探索状态中成立。实际合规取决于模型是否与实际工作流相符、通知是否合规以及适用哪些规则和例外情况。本演示仅作为审查辅助工具,并非法律意见。
录制的演示使用了四个合成 JSON 工作流模型。它与银行队列、核心系统、通知生成器、Visa 或 Mastercard 系统或消费者记录没有任何实时连接。实际评估首先需要建立一个针对实际流程和适用合规义务的经验证模型。
对于未通过的配置属性,检验器会显示状态图、带有建模事件和时钟值的有序反例轨迹,以及可导出的审查证书。在表单后示例中,轨迹在二级表单超时后到达 ClosedIncomplete 且未经调查。证书记录了所检查的模型和边界限制;它并非经监管机构认可。
演示使用了简化的编码时钟。其 Reg Z 解决检查将两个完整账单周期的条件缩减为 90 个日历日的上限,其 Reg E 10 个营业日检查采用固定的 7/5 换算且不考虑节假日。例外情况、延长周期以及规则适用性需要单独的专家审查。
探索上限为 200 个日历日。如果在未找到适用时间线属性反例的情况下达到该上限,检验器将报告 BOUNDED 而非 PROVEN。在已探索路径内发现的反例依然可见。
否。在配置后,可选的模型综合智能体可以提出工作流模型建议,但探索状态并分配 PROVEN、COUNTEREXAMPLE 或 BOUNDED 的是确定性 Python 代码。内置的四个案例在运行时无需任何大语言模型(LLM)或实时网络连接。
探索相关研究以获取关于本演示更广泛的背景信息。
完整解决方案
探索面向银行的金融合规形式化验证解决方案 →一个行之有效的第一步是梳理符合条件的通知在何处进入、等待、路由以及关闭。
在将模型作为实际流程的证据之前,我们可以帮助构建工作流模型框架、选择待测试的合规义务,并与异议处理业务、工程和合规专家共同审查反例。