Clic fuera de la imagen o ESC para cerrar
Un módulo de autorización en tiempo real que le devuelve al titular de un empeño el poder de decir que no.
Un tercero podía ejecutar movimientos en sucursal contra el ID de un cliente. El titular legítimo se enteraba después, cuando el efectivo ya había salido.
Un módulo de Acciones que convierte cada operación prendaria en una autorización explícita del titular antes de que la caja procese el pago.
El camino de rechazo se diseñó con el mismo rigor que el de aprobación: rechazar equivale a denunciar y anula la operación automáticamente.
El negocio prendario opera con efectivo entregado en caja y bienes físicos en resguardo. Cuando una operación fraudulenta se completa, no hay chargeback al cual recurrir. Hay una pérdida.
La validación existente vivía en dos lugares, ambos insuficientes por separado: la identificación en mostrador, sujeta al criterio del cajero y a documentos falsificables; y la MAGC, la plataforma antifraude, que evalúa la operación desde el backend pero no le pregunta nada al titular real.
El costo no era solo la pérdida directa. Era la restitución, la carga en el Contact Center y la disputa larga con un cliente que —correctamente— sostiene que él nunca estuvo en esa sucursal.
Cliente en sucursal
El cajero captura
ID en mostrador
MAGC (backend)
Pago en caja
El titular se entera después
El cajero captura
Estatus pendiente (ENP)
Push + Dondé Móvil
Titular autoriza/denuncia
Biométrico/contraseña
Pago o anulación
El cliente prendario de FRD no es un usuario digital intensivo. Con frecuencia empeña por necesidad inmediata. Una notificación informativa llega tarde por definición: había que mover la decisión antes del punto sin retorno.
Buena parte del riesgo no viene de un desconocido, sino del cotitular: alguien autorizado en el papel ejerciendo un control. Eso obligó a volverlo un elemento visible y confirmable en pantalla, no enterrado en la boleta.
Confirmación por OTP
Un OTP confirma presencia, no consentimiento informado. Si el cliente no ve el monto y rubro, no previene nada.
Autorizar en la boleta
Fragmentaba la tarea y dejaba a usuarios sin push (Huawei) sin lugar donde buscar su autorización.
Módulo de Acciones
La fuente de verdad es una bandeja donde toda autorización existe aunque el push no llegue. Resuelve Huawei y escalabilidad.
Se diseñó un doble gate —un checkbox de confirmación que habilita el botón, y biométrico o contraseña que ejecuta— para impedir la autorización por inercia.
El archivo final documenta tres flujos completos, extremo a extremo, con sus variantes de producto, estados vacíos, casuísticas de boleta y árboles de decisión trazados sobre el propio canvas.
Una bandeja con pestañas de Pendientes e Historial, cards diferenciadas por ícono de operación y agrupación temporal legible.
| Estado | Significado |
|---|---|
| Pendiente | En espera de decisión del titular |
| Autorizado | El titular aprobó desde la app |
| Autorizado en sucursal | Se resolvió por el canal presencial |
| Rechazado | El titular denunció; la operación se anuló |
Una jerarquía de tres niveles sobre el contenido denso de la boleta:
En este producto, rechazar es la funcionalidad antifraude. "No reconozco esta operación" abre un modal tipificado que exige la misma confirmación biométrica que autorizar. Simétrico a propósito para garantizar el repudio.
Se validan estatus después del biométrico, cerrando la ventana de carrera con caja. Si la operación ya se procesó, un diálogo devuelve a Acciones reflejando la realidad.
La confirmación biométrica invoca el componente nativo del OS. En seguridad, una pantalla biométrica dibujada es indistinguible de phishing.
"Valida tus datos" (sin alarmismo) vs "Autorización requerida: $X" en disposición, donde la cifra es el dato para detectar fraude desde el lockscreen.
Árbol de decisiones y casuísticas del sistema antifraude. Haz clic en la imagen para explorar con zoom interactivo.
El criterio de aceptación quedó sólido: sin autorización del titular, no se procesa el pago. La prevención pasó de ser un control de backend a un consentimiento explícito y trazable del dueño del ID.
El 1% de los casos en que un usuario dice 'esto no fui yo' no es un edge case — es la única razón por la que este módulo existe. En un producto de prevención de fraude, ese camino de excepción es el camino principal, y mereció el mismo esfuerzo de diseño que el flujo normal.
3 flujos completos, 3 esquemas, 5 casuísticas de boleta, con árboles de decisión y estados de error documentados.
Tasa de autorización, motivos de rechazo, proporción de resolución presencial vs app, y reporte de Contact Center.
Operaciones fraudulentas detenidas en piloto
Cuéntame en qué estás trabajando — con gusto lo platicamos.
Hablemos →