在决定变更收款人之前，先读懂核验等级

问题：收款人变更取决于一个结果

墨西哥某电商平台的一位卖家申请更换新的结算 CLABE。危险的捷径是把任何没有报错的响应都当作批准，然后直接切换账户。核对结果包含几项彼此独立的内容：核验等级、任务状态、证据和费用。所支持的等级和所需操作以实时报价为准，而不是写死在你代码里的固定列表。你的决定其实比看上去更窄：在这份已接受的报价下，这个具体结果是否足以支持变更这位收款人，还是该请求必须等待审核？该产品不提供无条件批准，不查询任意个人，也不声称银行与 CURP 之间存在直接的标识符关联。

输入与输出的含义

输入包括已获授权的 CURP 和 CLABE、当前报价、所需的证据与同意记录，以及一个稳定的请求 UUID。这个 UUID 让重试指向同一个请求，而不是生成第二次核对。输出包含等级、任务状态、证据和费用，应当作为不同的信号分别解读。状态说明任务进行到哪一步；等级说明核对得出了什么结论，如果有的话；证据说明支持该结论的依据；费用说明按报价实际计费的内容。等级为空表示尚无结论，这并不等于个人与账户之间存在冲突。银行卡号不是受支持的输入；除非报价明确授权，否则不会发生任何转账。

假设场景与预期的示例输出

假设一位已登记的卖家提交了新的 CLABE。你的开户服务携带已接受的报价和一个新的请求 UUID，发送已授权的 CURP 与 CLABE。合成合约示例恰好返回以下字段：status review、grade null、verified false、automatic_business_approval false。预期处理方式是：保持当前结算账户有效，把新 CLABE 记录为待处理变更，附上请求 UUID，并把案例转入你自己的审核队列。不要向卖家显示拒绝，因为并没有得出对其不利的结论；也不要切换账户，因为 verified 为 false，automatic_business_approval 也为 false。该输出只是在不向任何服务商发出请求的情况下生成的合约示意，并不能证明进行过实时核验，也不代表存在任何客户。

拟议的应用设计与已实现的行为

已实现的行为（据文档）：核对接受上述输入，并报告等级、状态、证据和费用，等级与操作受实时报价和当前能力约束。商户执行需要当前能力、授权以及已接受的报价。拟议的设计（需由你实现）：一张决策表，把状态与等级映射为内部操作。例如，review 或空等级映射为暂停；带有证据的受支持等级进入你自己的策略检查，然后才可能做任何变更。即使得到积极的等级，也不应在你的系统中自动开启 automatic_business_approval；是否变更收款人，由你单独记录的规则决定。

失败处理

如果调用出现技术故障，保留原收款人，并使用同一个请求 UUID 重试，而不是生成新的 UUID，以免为两次核对付费或留下两条记录。如果报价已过期或发生变化，重新提交前先获取当前报价，不要沿用过时的条款。如果缺少所需证据或同意记录，应停止并先补齐，而不是直接提交。如果出现决策表无法识别的等级，按暂停处理并检查当前能力，因为受支持的等级以实时报价为准。费用应按输出中报告的内容记录，不要假设固定金额。

验收清单

在依据此结果启用收款人变更之前，请确认：示例输出 status review、grade null、verified false、automatic_business_approval false 导致暂停，而不是拒绝或切换；重试复用稳定的请求 UUID；所用报价为当前且已接受；CURP 与 CLABE 已获授权，同意记录已保存；不发送任何银行卡输入；没有报价的明确授权就不发生转账；未知等级一律暂停；费用依据输出记录；最终的收款人变更由你自己记录在案的规则执行。通过合成示例只能说明你的处理逻辑正确，并不代表真实的业务权限或服务商覆盖范围。

检查这项功能

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

gridzen tools --product mx-identity-account

来源与范围

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