Cambios de reglas sin sorpresas

Las reglas rara vez actúan solas. Una nueva regla de rechazo quita pagos a la regla de verificación adicional que antes los trataba, un umbral más bajo envía más casos a revisión manual y un modelo reentrenado desplaza las puntuaciones de las que dependen todas las reglas posteriores. El efecto de un cambio depende de todos los demás, de modo que un cambio que parecía seguro sobre el papel puede comportarse de forma muy distinta en producción.

El costo además llega tarde. Un buen cliente rechazado puede simplemente irse sin quejarse. El fraude que se cuela aparece semanas o meses después en forma de contracargos o de reclamaciones por estafa. Cuando cualquiera de los dos es visible, normalmente ya han entrado en producción varios cambios más y la causa es difícil de rastrear.

Las sumas en juego son grandes en ambos lados. UK Finance informa de que en 2025 sus miembros evitaron £1,68 mil millones de fraude no autorizado, 70 peniques de cada £1 intentado, mientras que los delincuentes aún robaron £1,28 mil millones mediante fraude autorizado y no autorizado. A esa escala, una pequeña pérdida de precisión mueve dinero real en uno u otro sentido.

La reproducción depende de un registro de cada decisión con sus datos de entrada exactamente como eran en ese momento. Eso incluye las respuestas de servicios externos, como una verificación de dispositivo o una consulta a una lista de vigilancia, porque esas respuestas cambian con el tiempo y no pueden volver a obtenerse después. Una puntuación almacenada no basta. Muestra lo que concluyó el sistema, pero no por qué, y no puede ejecutarse bajo una regla nueva.

El mismo registro sirve a los equipos de riesgo de modelos y de auditoría. La guía revisada de gestión del riesgo de modelos de los organismos bancarios de Estados Unidos, la SR 26-2 de abril de 2026, que sustituyó a la SR 11-7, considera el análisis de resultados, es decir, comparar las salidas del modelo con los resultados reales mediante supervisión o pruebas retrospectivas (backtesting), parte de una buena validación. También excluye de su definición de modelo los procesos deterministas basados en reglas, por lo que los cambios de reglas pueden quedar fuera de la validación formal. Conviene que los equipos de fraude apliquen esa misma disciplina a sus propias reglas.

Ejecute el cambio candidato sobre un período de pagos pasados, con los datos de entrada archivados, y compare sus decisiones con las que realmente se tomaron. El resultado útil es el conjunto de decisiones que se invierten: aprobaciones que ahora se rechazarían o se someterían a verificación, y rechazos que ahora se aprobarían.

Desglose esas inversiones por segmento de clientes, valor del pago, canal y comercio. Después clasifique cada pago invertido según lo que se sabe de él: fraude confirmado, bueno confirmado o aún desconocido. El fraude confirmado es lo que el cambio gana y el bueno confirmado es lo que cuesta. El grupo desconocido requiere cuidado, porque se reduce a medida que llegan los resultados.

Un cambio destinado a no alterar nada, como la reescritura de una lógica existente, no debería producir ninguna inversión. Cualquier diferencia que muestre es un defecto hallado antes de que lo encuentren los clientes. Este paso importa más en los sistemas de pagos instantáneos como Aani en los EAU y Pix en Brasil, donde el dinero sale en segundos y una aprobación errónea es difícil de deshacer.

Un cambio puede verse excelente en conjunto mientras que los buenos pagos que detiene pertenecen a sus clientes más valiosos o a un comercio al que no puede permitirse perturbar. Tome una muestra de los pagos invertidos y léalos como lo haría un analista, empezando por los clientes de alto valor, los clientes antiguos y los comercios clave.

Para cada bloqueo, pregúntese si el equipo podría explicárselo al cliente en palabras claras. Los casos que sorprenden a los revisores suelen señalar una condición de la regla más amplia de lo previsto, y es más barato encontrarlos aquí que en la cola de quejas.

Una reproducción mira al pasado, y el comportamiento cambia. El siguiente paso es ejecutar el candidato en modo sombra junto al tráfico real: ve cada pago y registra lo que habría hecho, mientras las reglas actuales siguen decidiendo. Compare cada día sus decisiones con las reales y compruebe que el patrón coincide con la predicción de la reproducción. Una diferencia entre ambos es en sí misma un hallazgo.

Después libere por etapas, empezando por una parte pequeña del tráfico, un segmento o un canal, con una reversión probada. Registre quién aprobó el cambio, la evidencia que vio y el motivo. Ese registro es lo que pedirá un auditor y lo que necesitará su propio equipo cuando un resultado parezca extraño meses después.

Algunos cambios son datos y no lógica. Añadir una cuenta a una lista de cuentas mula conocidas, o quitarla tras una queja, debería surtir efecto en instantes y ser reversible de inmediato, con un registro de quién lo hizo. Una regla nueva, un umbral nuevo o un modelo reentrenado pasan por reproducción, modo sombra y aprobación. Acuerde de antemano qué cambios siguen cada vía, para que una edición urgente de una lista nunca se retrase y un cambio de lógica nunca omita la revisión.

Haga seguimiento de estas medidas antes y después de cada cambio, por segmento, y vuelva a leer las cifras de fraude cuando los resultados hayan madurado.

Tasa de aprobación

Proporción de pagos aprobados, por segmento y canal

Fraude detectado y no detectado

Por valor y por número de casos

Tasa de verificación adicional

Con qué frecuencia se pide a los clientes una verificación adicional y cuántos la completan

Volumen de revisión

Casos enviados a los analistas y el tiempo que llevan

Contactos de clientes

Llamadas y quejas por pagos rechazados o retenidos

Mantika Argus conserva cada decisión tal como se tomó, de modo que una regla nueva puede ejecutarse con sus pagos pasados y luego en modo sombra antes de entrar en producción.