Leer el registro de un proveedor de verificación

Cada fila trae el resultado de tres comprobaciones (documento legible, rostro que coincide, vivacidad), un puntaje del rostro, un código de motivo cuando algo no salió limpio, el número de intentos de la sesión, la decisión y quién la tomó, que puede ser el sistema o una persona. Esas columnas no se leen aisladas: una decisión «aprobada» con una comprobación en rojo es lo primero que busca un auditor.

Abre el registro con SELECT * FROM verificaciones y recorre las diez filas con la política PD-1 al lado.

Los códigos de motivo son abreviaturas del proveedor: sin su diccionario no se sabe qué significa lo que se lee. Un código no es una condena, es un aviso, y el que importa es el que no está en blanco aunque la decisión haya sido «aprobada». La política PD-3 pide que todo código distinto de «-» quede a la vista del equipo de fraude.

Una verificación quedó en la cola de fraude con un código que habla de un documento ya visto. Busca el código en el registro y su significado en el diccionario.

Los intentos repetidos en una misma sesión son una señal de comportamiento. Una persona legítima con una foto borrosa lo intenta dos o tres veces; una cifra mucho mayor sugiere ensayo y error contra el control, o un cliente al que el sistema no está ayudando. Sea cual sea la causa, merece mirarse.

Cuando una persona aprueba lo que el sistema marcó en rojo, hay que poder explicarlo. La política PD-2 dice cuándo está permitido: una vivacidad fallida solo se aprueba a mano con la firma de una segunda persona. El registro del proveedor no tiene una columna de segunda firma, así que, de entrada, la aprobación solo consta con un nombre.

Para saber cuánta carga y cuánto riesgo asume el automatismo, se mide la proporción de verificaciones aprobadas sin intervención humana sobre el total del día. Una cifra muy alta pide mirar que los umbrales sean los correctos; una muy baja, que el proveedor esté sirviendo para algo.