更改收款信息前，先核对新收款人 CLABE 的账户姓名

问题与你要做的决定

更改打款信息是一项高影响的修改。卖家提交新的 18 位 CLABE，期待下一笔打款进入该账户。你的团队只需决定一件事：银行证据中与该 CLABE 关联的姓名，是否与预期收款人足够一致，可以直接应用变更，还是必须先由人工审核？这项比对只回答一个范围很窄的问题。它不是证件身份核验，不能证明申请人当前控制该账户，也不是业务批准。在你的应用自身规则另行决定之前，原有打款信息应保持有效。

产品接受什么、返回什么

根据产品合约，一次请求包含 CLABE、预期收款人姓名、持有人类型、当前报价、授权引用以及稳定的请求 UUID。输出是任务状态和姓名比对结果，并附带证据与费用。相似度不确定时需要审核。为获取证据，可能会使用一笔已报价的小额转账；这需要对收款方和支出都具备明确授权。重试时复用同一个请求 UUID，使一次打款变更只对应一个任务。商户执行取决于当前能力、有效授权和已接受的报价。先做本地 CLABE 格式校验，可以避免把付费请求花在不可能通过的输入上。

假设场景与预期的 fixture 输出

假设：一位以公司身份注册的卖家更改打款信息，预期收款人姓名与证据中的姓名只在法律后缀缩写上不同。合成合约示例精确返回：status review、name_match inconclusive、verified false、automatic_business_approval false。请逐字理解每个字段。status review 表示任务需要人工决定。name_match inconclusive 表示相似度既不是明确一致，也不是明确冲突。verified false 表示没有任何内容被确认。automatic_business_approval false 表示该结果本身永远不会授权打款变更。此示例不会向真实服务商发出任何请求，因此只演示合约处理方式。

建议的应用设计

以下是设计建议，并非已实现的行为。把变更申请保存为待处理状态，同时让原 CLABE 继续生效。在调用核验之前，记录请求 UUID、已接受的报价和授权引用。遇到 status review 或 name_match inconclusive 时，创建审核工单，展示预期姓名、返回的证据和费用，打款继续使用原信息。只有审核人员或明确的策略才能批准切换；任何代码都不得覆盖 automatic_business_approval false。如果报价中包含小额转账，应在接受报价前请有权限的人确认收款方与支出。告知卖家变更正在审核中，而不是被拒绝。

失败处理

超时或未知任务状态应视为未完成，而不是姓名不一致。使用同一个 UUID 重新查询结果，不要提交新任务，否则可能产生第二笔费用。不确定的结果不等于冲突；即使出现冲突，在对账户采取任何行动之前也应先审核。如果报价已过期或缺少授权，应停止并申请新的报价或授权，而不是继续执行。按返回内容如实记录费用，并把小额转账与核验费用分开。切勿把合成 fixture 当作真实权限，也不要把它当作某家银行已有生产覆盖的证据。

验收清单

启用此流程前请确认：在批准前原打款信息保持有效；每个请求都带有稳定 UUID、持有人类型、授权引用和已接受的报价；fixture 返回 status review、name_match inconclusive、verified false 和 automatic_business_approval false，且你的处理逻辑把它转入审核；重试复用 UUID；小额转账必须记录对收款方和支出的授权；费用按任务保存；超时不会变成拒绝；审核界面展示证据，而不仅是分数；任何人都不把这项核验描述为身份核验或账户控制权证明。目前的产品反馈只是汇总观察，不能证明任何结果或因果关系。

检查这项功能

https://gridzen.ai/tools/mx-account-name/ · 核对输入、输出与能力边界。以下命令只读取产品说明，不执行真实请求。

gridzen tools --product mx-account-name

来源与范围

https://gridzen.ai/tools/mx-account-name/ https://gridzen.ai/guides/current-capabilities/ 依据已检查的来源快照与本地模拟；建议的业务规则属于设计建议，不代表已证明的生产行为。内容使用 AI 辅助写作，并经过独立审稿。