Distinguir una discrepancia de nombre de la falta de evidencia al registrar CURP y CLABE
Un flujo de alta en México envía una CURP y una CLABE autorizadas para un cotejo de identidad y cuenta beneficiaria. La respuesta no es un aprobado limpio. ¿Es un conflicto entre la persona y la cuenta, o simplemente aún no hay conclusión? Tratar ambos casos como rechazo bloquea a negocios legítimos; tratarlos como aceptables puede dejar pasar a un beneficiario equivocado. Este artículo propone cómo una aplicación podría leer por separado el grado de verificación, el estado de la tarea, la evidencia y los cargos, usando el ejemplo de contrato sintético cuya salida probada es status review, grade null, verified false y automatic_business_approval false. Esa salida es una ilustración de contrato, no una aceptación real.
gridzen tools --product mx-identity-accountEl problema y la decisión
Tu servicio permite que un negocio registre o cambie la CLABE que recibe pagos. Antes de aceptarla, envías a la tarea mx_identity_account la CURP y la CLABE autorizadas, la cotización vigente, la evidencia y los consentimientos requeridos y un UUID de solicitud estable. La decisión no es aprobar o rechazar. Es una pregunta de tres vías: ¿el resultado muestra un conflicto entre identidad y cuenta, muestra que falta evidencia o está incompleta, o la tarea simplemente no ha terminado? Cada respuesta lleva a un lugar distinto. Una discrepancia respaldada por evidencia es motivo para detener el cambio de beneficiario. La falta de evidencia es motivo para pedir más o pasar a revisión manual. Una tarea sin terminar es motivo para esperar o recuperar, no para decidir. El límite del producto es explícito: sin conclusión no es un conflicto, y nada en la salida es una aprobación comercial automática.
Qué devuelve el producto y qué no
El contrato de salida nombra cuatro elementos: grado de verificación, estado de la tarea, evidencia y cargos. Los grados admitidos y las acciones requeridas siguen la cotización vigente, así que tu código no debe fijar una lista de grados tomada de un artículo; lee lo que permiten las capacidades actuales y la cotización aceptada. El límite importa tanto como la salida. El cotejo no es una búsqueda arbitraria de personas: solo envías identificadores que estás autorizado a verificar. No afirma que un banco tenga la CURP como identificador directo. No acepta datos de tarjeta no admitidos en lugar de una CLABE. No mueve dinero salvo que la cotización autorice explícitamente una transferencia. Tu aplicación debe guardar cada campo por separado en lugar de reducirlos a un único booleano, porque un booleano oculta justamente la diferencia entre una discrepancia y la falta de evidencia.
Escenario hipotético y salida esperada del fixture
Hipotéticamente, un vendedor sintético pide reemplazar su CLABE de pagos. Tu manejador propuesto mantiene activa la CLABE anterior, crea un UUID de solicitud, adjunta la cotización aceptada y los consentimientos, y llama a la tarea. En el ejemplo de contrato sintético la salida probada es exactamente: status review, grade null, verified false, automatic_business_approval false. Léela campo por campo. status review significa que la tarea no llegó a una conclusión final y necesita revisión. grade null significa que no se asignó grado, lo cual no es un grado bajo ni una discrepancia. verified false significa que no debes tratar al beneficiario como verificado. automatic_business_approval false significa que ni siquiera un grado positivo posterior otorgaría, por sí solo, permiso comercial. La acción propuesta correcta es dejar el cambio pendiente, mantener los pagos en la cuenta existente y registrar que el resultado no está resuelto. Este ejemplo no realiza ninguna solicitud a un proveedor real, y su resultado sintético no es permiso para actuar sobre un negocio real.
Diseño propuesto frente a comportamiento implementado
Implementado, según el contrato del producto: la tarea acepta CURP y CLABE autorizadas con una cotización vinculada, devuelve grado, estado, evidencia y cargos, y rechaza la aprobación incondicional. También implementado en el ejemplo de contenido: una salida sintética con los cuatro campos anteriores, ejecutada localmente sin red. Propuesto, y responsabilidad tuya: una máquina de estados para el cambio de beneficiario con estados como pending_check, needs_evidence, blocked_mismatch y accepted_by_policy; una regla según la cual solo un grado admitido respaldado por evidencia, más tu propia política comercial, lleva un cambio a aceptado; y un asiento contable separado para los cargos que informa la tarea. El diseño propuesto nunca deduce una discrepancia a partir de grade null, ni deduce una aprobación solo de verified true. Tus reglas de negocio, no el cotejo, otorgan el derecho a pagar a una cuenta nueva.
Manejo de fallos
Trata cada fallo por su propio camino. Si la llamada agota el tiempo o la tarea sigue en revisión, reutiliza el mismo UUID de solicitud y usa el paso de recuperación en lugar de enviar de nuevo, para que un solo cambio de beneficiario no se convierta en dos tareas cobradas. Si faltan evidencia o consentimientos, pídelos al negocio y mantén el cambio pendiente. Si la cotización venció o no cubre la acción solicitada, obtén una nueva antes de reintentar; no supongas que una cotización antigua sigue autorizando una transferencia. Si la entrada es un número de tarjeta u otro dato no admitido, recházala localmente antes de llamar a la tarea. Si el grado indica un conflicto respaldado por evidencia, bloquea el cambio y avisa a un revisor, sin exponer identificadores en los registros. Registra los cargos exactamente como se informan; una tarea fallida o incompleta no justifica inventar un costo.
Lista de verificación de aceptación
Antes de confiar en este flujo, confirma: el manejador guarda grado, estado, evidencia y cargos como campos separados; grade null con status review mantiene el cambio pendiente y la CLABE anterior activa; verified false nunca habilita pagos a la cuenta nueva; se respeta automatic_business_approval false y se exige tu propia política para aceptar; los reintentos reutilizan el UUID de solicitud estable; la cotización está vigente y su autorización se comprueba antes de cualquier transferencia; los datos de tarjeta no admitidos se rechazan localmente; no hay búsquedas arbitrarias de personas que no estás autorizado a verificar; los registros excluyen valores de CURP y CLABE. Por último, etiqueta todo resultado del fixture como sintético. Superar esta lista localmente demuestra que tu manejo de estados es coherente; no demuestra cobertura real, un cliente real ni permiso comercial. La ejecución real requiere capacidades vigentes, alta, autorización y la cotización aceptada.
Revisar este producto
https://gridzen.ai/tools/mx-identity-account/ · Revise entrada, salida y límites. El comando muestra el producto sin ejecutar solicitudes reales.
gridzen tools --product mx-identity-accountFuentes y alcance
https://gridzen.ai/tools/mx-identity-account/ https://gridzen.ai/guides/current-capabilities/ Basado en las fuentes comprobadas y el ejemplo local; las reglas propuestas son recomendaciones de diseño, no comportamiento de producción demostrado. Redacción asistida por IA con revisión independiente.