Separate a name mismatch from missing evidence in CURP and CLABE onboarding

The problem and the decision

Your service lets a business register or change the CLABE that receives payouts. Before accepting it, you submit to the mx_identity_account task the authorized CURP and CLABE, the current quote, the required evidence and consents, and a stable request UUID. The decision is not pass or reject. It is a three-way question: does the result show a conflict between identity and account, does it show that evidence is missing or incomplete, or is the task simply not finished? Each answer leads somewhere different. A mismatch supported by evidence is a reason to stop the beneficiary change. Missing evidence is a reason to request more or route to manual review. An unfinished task is a reason to wait or recover, not to decide. The product boundary is explicit: no conclusion is not a conflict, and nothing in the output is an automatic business approval.

What the product returns and what it does not

The output contract names four things: verification grade, task status, evidence and charges. Supported grades and required actions follow the live quote, so your code should not hard-code a grade list taken from an article; read what the current capabilities and accepted quote allow. The boundary matters as much as the output. The comparison is not an arbitrary person lookup: you only submit identifiers you are authorized to check. It does not claim that a bank holds a CURP as a direct identifier. It does not accept unsupported card input instead of a CLABE. It does not move money unless the quote explicitly authorizes a transfer. Your application should store each field on its own rather than collapsing them into one boolean, because a single boolean hides exactly the difference between a mismatch and missing evidence.

Hypothetical scenario and expected fixture output

Hypothetically, a synthetic seller asks to replace its payout CLABE. Your proposed handler keeps the old CLABE active, creates a request UUID, attaches the accepted quote and consents, and calls the task. In the synthetic contract example the tested output is exactly: status review, grade null, verified false, automatic_business_approval false. Read it field by field. status review means the task has not reached a final conclusion and needs review. grade null means no grade was assigned, which is not a low grade and not a mismatch. verified false means you must not treat the beneficiary as verified. automatic_business_approval false means even a later positive grade would not, by itself, grant your business permission. The correct proposed action is to keep the change pending, leave payouts on the existing account and record that the outcome is unresolved. No live provider request is performed by this example, and its synthetic result is not permission to act on a real business.

Proposed application design versus implemented behavior

Implemented, according to the product contract: the task accepts authorized CURP and CLABE with a bound quote, returns grade, status, evidence and charges, and refuses unconditional approval. Also implemented in the content example: a synthetic output with the four fields above, executed locally without network. Proposed, and your responsibility: a beneficiary-change state machine with states such as pending_check, needs_evidence, blocked_mismatch and accepted_by_policy; a rule that only a supported grade backed by evidence, plus your own business policy, moves a change to accepted; and a separate ledger entry for charges reported by the task. The proposed design never infers a mismatch from grade null, and never infers approval from verified true alone. Your business rules, not the comparison, grant the right to pay a new account.

Failure handling

Handle each failure on its own path. If the call times out or the task stays in review, reuse the same request UUID and use the recover step rather than submitting again, so one beneficiary change does not become two charged tasks. If evidence or consents are missing, ask the business for them and keep the change pending. If the quote has expired or does not cover the requested action, obtain a new quote before any retry; do not assume an old quote still authorizes a transfer. If the input is a card number or otherwise unsupported, reject it locally before calling the task. If the grade indicates a conflict supported by evidence, block the change and notify a reviewer, without exposing identifiers in logs. Record charges exactly as reported; a failed or incomplete task is not a reason to invent a cost.

Acceptance checklist

Before relying on this flow, confirm: the handler stores grade, status, evidence and charges as separate fields; grade null with status review keeps the change pending and the old CLABE active; verified false never enables payouts to the new account; automatic_business_approval false is respected and your own policy is required for acceptance; retries reuse the stable request UUID; the quote is current and its authorization is checked before any transfer; unsupported card input is rejected locally; no arbitrary lookup of people you are not authorized to check; logs exclude CURP and CLABE values. Finally, label every fixture result as synthetic. Passing this checklist locally shows your state handling is consistent; it does not show live coverage, a real customer or business permission. Live execution requires current capabilities, enrollment, authorization and the accepted quote.

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.