A Mexico payout team wants to compare a beneficiary name against bank evidence for one CLABE. The quote may include a microtransfer. If your ledger records the whole quote as one fee, you cannot tell what left your account as transfer principal, what the evidence source charged, and what the service fee was. This article proposes how an application could keep those amounts apart, how to read the synthetic contract example, and what to check before trusting any result. The example is a synthetic contract illustration, not a live check or live acceptance.
The problem and the decision
Your payout integration must check the name on a new beneficiary CLABE. The product compares an expected beneficiary name with supported bank evidence for one authorized CLABE. Its inputs are the CLABE, expected beneficiary name, holder type, current quote, authorization reference and a stable request UUID. A quoted microtransfer may apply. That matters because a microtransfer moves money to a recipient; it is not only a service charge. Your decision is whether to accept a quote at all and, if you do, how to record it so finance, support and audit see three different things: the transfer principal sent to the recipient, any source cost incurred obtaining evidence, and the fee. Folding them into one number hides who received money, why, and whether spending was authorized for that recipient.
What the product contract states versus what your application designs
Implemented contract, as documented: the output is a task state and a name comparison with its evidence and charges; uncertain similarity requires review. A microtransfer requires explicit recipient and spending authority. The result is not document identity and not proof of current account control. Merchant execution requires current capabilities, authorization and the accepted quote. The listed tools are mexico_account_name_capabilities, quote_mexico_account_name, verify_mexico_account_name, get_mexico_account_name and recover_mexico_account_name. Proposed application design, which is yours to build: a quote record with three separate amount lines (principal, source cost, fee), a recipient field bound to the CLABE, a spending-authority reference, and a rule that no line may be accepted unless its authority exists. The product does not create these ledger lines for you, and this article does not claim a specific quote layout.
A hypothetical scenario and the expected fixture output
Hypothetical: a marketplace seller asks to route payouts to a new CLABE and gives an expected name. Your service calls the capabilities tool, then requests a quote. Suppose the quote shows that a microtransfer may apply. Your design splits it: the principal line names the CLABE holder as recipient; the source cost and fee lines name the evidence path and the service. An operator holding spending authority for that recipient accepts it, and the request is sent with the same stable request UUID. The synthetic contract example returns exactly: status review, name_match inconclusive, verified false, automatic_business_approval false. Read it literally. Review means a person must look. Inconclusive is not a mismatch and not a match. Verified false means no verified conclusion. Automatic_business_approval false means no payout detail may change automatically. No live provider request is performed by this example.
Failure handling
If capabilities do not list the task, do not quote. If the quote has expired or changed, request a new one rather than reusing the old acceptance. If a microtransfer appears without a named recipient or spending authority, stop before submitting. If the result is review or inconclusive, keep the old payout CLABE active and open a review case; never treat uncertain similarity as a pass. If a task stays pending or a worker restarts, use get or recover with the same request UUID instead of submitting again, so one change request cannot produce two charges. Record which charge lines actually occurred versus were only quoted. A technical failure should not silently become an accepted spend in your ledger.
Limits to keep visible
A name comparison does not establish who the seller is and does not prove they control the account today. It covers one authorized CLABE, not a portfolio. Documentation and the synthetic example are not evidence of a live check or of any customer. Synthetic output grants no live business permission. Product feedback counts are aggregates and currently show no observed use, so nothing here claims effectiveness. Current access, supported inputs and charges follow current capabilities and the accepted quote, not this article.
Acceptance checklist
Before trusting the integration: the quote is stored with principal, source cost and fee as separate lines; each microtransfer line names a recipient and a spending-authority reference; the authorization reference and stable request UUID are persisted before submission; a retry reuses the UUID; the fixture output status review, name_match inconclusive, verified false and automatic_business_approval false routes to manual review and leaves payout details unchanged; an expired quote forces a new quote; recovery does not duplicate a task; and your notes label the fixture as synthetic contract evidence, not live acceptance.
Disclosure: this tutorial was drafted with AI and checked against executable local examples and an independent factual review. Sample values are test inputs, not verified people or accounts. Application policy remains the caller’s responsibility.
