Read the verification grade before deciding a beneficiary change

The problem: a beneficiary change waits on one answer

A marketplace seller in Mexico requests a new payout CLABE. The risky shortcut is to read any non-error response as approval and switch the account. The comparison returns several separate things: a verification grade, a task status, evidence and charges. Supported grades and required actions follow the live quote, not a fixed list in your code. Your decision is narrower than it looks: does this specific result, under this accepted quote, support changing this beneficiary, or must the request wait for review? The product does not give unconditional approval, does not look up arbitrary people and does not claim a direct identifier link between a bank and a CURP.

What the inputs and outputs mean

Inputs are an authorized CURP and CLABE, the current quote, the required evidence and consents, and a stable request UUID. The UUID lets a retry refer to the same request instead of creating a second comparison. The output carries a grade, a task status, evidence and charges. Read them as distinct signals. Status says where the task is. Grade says what the comparison concluded, if anything. Evidence says what supports that conclusion. Charges say what was billed under the quote. A null grade is no conclusion, which is not the same as a conflict between person and account. Card numbers are unsupported input, and no transfer happens unless the quote explicitly authorizes it.

Hypothetical scenario and expected fixture output

Hypothetically, a seller named in your records submits a new CLABE. Your onboarding service sends the authorized CURP and CLABE with the accepted quote and a fresh request UUID. The synthetic contract example returns exactly these fields: status review, grade null, verified false, automatic_business_approval false. The expected handling is: keep the current payout account active, record the new CLABE as a pending change, attach the request UUID, and route the case to your own review queue. Do not show the seller a rejection, because nothing was concluded against them. Do not switch the account, because verified is false and automatic_business_approval is false. This fixture output is a contract illustration produced without any provider request; it is not evidence of a live check or a customer.

Proposed application design versus implemented behavior

Implemented behavior, as documented: the comparison accepts the listed inputs and reports grade, status, evidence and charges, with grades and actions governed by the live quote and current capabilities. Merchant execution requires current capabilities, authorization and the accepted quote. Proposed design, which is yours to build: a decision table that maps status and grade to an internal action. For example, review or a null grade maps to hold; a supported grade with evidence maps to your own policy check before any change. Even a positive grade never flips automatic_business_approval in your system; your rule, recorded separately, decides whether the beneficiary changes.

Failure handling

If the call fails technically, keep the old beneficiary and retry with the same request UUID rather than a new one, so you do not pay for or record two comparisons. If the quote expired or changed, obtain a current quote before resubmitting; do not reuse stale terms. If required evidence or consent is missing, stop and collect it instead of submitting. If a grade appears that your table does not recognize, treat it as hold and check current capabilities, since supported grades follow the live quote. Log charges as reported in the output rather than assuming a fixed amount.

Acceptance checklist

Before enabling beneficiary changes on this result: the fixture output status review, grade null, verified false, automatic_business_approval false leads to a hold, not a rejection or a switch; retries reuse the stable request UUID; the quote used is current and accepted; CURP and CLABE are authorized and consents stored; no card input is sent; no transfer occurs without explicit quote authorization; unknown grades hold; charges are recorded from the output; and the final beneficiary change is made by your own recorded rule. Passing the synthetic example shows your handling logic, not live business permission or provider coverage.

Inspect this product

https://gridzen.ai/tools/mx-identity-account/ · Inspect the documented input, output and boundary. This command lists the product without executing a live request.

gridzen tools --product mx-identity-account

Sources and scope

https://gridzen.ai/tools/mx-identity-account/ https://gridzen.ai/guides/current-capabilities/ Based on the checked source snapshot and local fixture; proposed application rules are design advice, not proven production behavior. Written with AI assistance and reviewed independently.