Cómo gestiona controles y reglas un motor antifraude
En su pantalla siguen abiertos los casos del fin de semana. Su analista de fraude confirma qué tienen en común: un dispositivo, varias direcciones de correo electrónico y una red de fraude que avanza por sus verificaciones. Usted quiere que se rechace el próximo intento desde ese dispositivo y contar con una regla de velocidad que detecte la siguiente red antes de que llegue al mismo punto. El equipo del sistema de crédito dice que no puede hacer ninguno de esos cambios antes del próximo release. Entonces alguien pregunta a cuántos clientes legítimos del mes pasado habría rechazado la regla. Puede analizar los casos que tiene delante, pero no tiene a la vista esas decisiones anteriores.
Defina la decisión antifraude antes de elegir los datos
Un motor de reglas antifraude ejecuta un flujo de decisiones cada vez que recibe una solicitud. El flujo ejecuta verificaciones, evalúa reglas y devuelve un resultado, como aprobar, enviar a evaluación o rechazar. El motor de decisiones antifraude reúne esos componentes en un solo flujo de decisiones.
En un pago BNPL, cada componente cumple una función distinta:
- Fuentes de datos ejecutan verificaciones, como la identificación de dispositivos o la comprobación de un correo electrónico. Una verificación de huella digital del dispositivo proporciona información que el flujo puede utilizar.
- Listas permiten al flujo comprobar si un dispositivo o correo electrónico es conocido, confiable o está bajo investigación.
- Un conjunto de reglas evalúa condiciones en orden y aplica las acciones que usted defina.
- Una puntuación de fraude proporciona un valor que el flujo puede utilizar junto con otros datos.
- Una bifurcación dirige la solicitud a un resultado, como aprobar, enviar a evaluación o rechazar.
En el recorrido habitual, se ejecutan las verificaciones del dispositivo y del correo electrónico, el flujo compara sus valores con las listas y el conjunto de reglas evalúa los resultados antes de que la bifurcación seleccione un resultado.
Distinga las verificaciones fallidas de los resultados limpios
La misma solicitud BNPL puede llegar a las reglas con una verificación fallida del dispositivo, una lista no disponible o una puntuación vacía. Cada situación deja un resultado distinto que el flujo debe gestionar. Antes de asignar un resultado, distinga lo que ocurrió de lo que vería un flujo que solo lee el valor devuelto.
| Qué ocurrió | Resultado del motor | Flujo sin control | Qué agregar |
|---|---|---|---|
| El proveedor del dispositivo no respondió | La verificación marca su propio resultado como fallido y el resto del flujo continúa | Sin datos, se interpreta como ausencia de coincidencia | Una regla para el error de la verificación: otro proveedor, evaluación o un resultado prudente |
| No se pudo acceder al almacén de listas | hit está vacío y __list_status es unavailable | El correo electrónico se trata como ausente de la lista de bloqueo | Una regla para __list_status igual a unavailable |
| El valor que se debía comprobar estaba vacío | __list_status es no_input | Un resultado limpio | Una regla para no_input |
| La puntuación de riesgo está vacía | En una comparación numérica cuenta como 0 | El nivel de riesgo más bajo | Una condición «no es un número» al principio |
| Ninguna rama de la bifurcación coincide | La ejecución termina en la bifurcación con HTTP 200 | Una respuesta breve que parece válida | Una rama final con «cualquier valor», dirigida a evaluación manual |
Haga que la falta de datos cambie la decisión
Si un proveedor supera el tiempo de espera, marca su propio resultado como fallido y el resto del flujo continúa. Así, las reglas pueden enviar la solicitud a evaluación, usar otro proveedor o elegir un resultado prudente. Si la regla solo lee el valor del dispositivo o la IP, la falta de respuesta puede pasar por una ausencia de coincidencia.
Configure por separado el tiempo de espera de cada fuente de datos. Si un proveedor no responde dentro de ese plazo, el motor continúa, hasta un tiempo máximo de respuesta de 15 segundos. Para cada verificación, decida si es necesaria en todas las solicitudes y qué debe hacer el flujo cuando no obtiene respuesta. Una verificación fallida puede enviar a evaluación a un cliente legítimo, pero tratar el fallo como un resultado limpio puede dejar pasar un fraude. Defina la alternativa de forma deliberada.
En las verificaciones de listas, agregue reglas para los resultados no disponibles y sin datos antes de las reglas que utilizan el valor de coincidencia. Para una puntuación, coloque una condición «no es un número» antes de las comparaciones numéricas.
Aplique valores confirmados mediante listas
Las listas permiten guardar valores que cambian más rápido que la política. Use una lista de bloqueo para fraudes confirmados, cuentas mula y contracargos, una lista de permitidos para clientes o dispositivos legítimos conocidos y una lista de vigilancia para valores bajo investigación que deban enviarse a evaluación.
Cuando el analista confirme el dispositivo de los casos del fin de semana, podrá agregarlo a la lista de bloqueo desde el caso. Agregue también un correo electrónico solo si la investigación confirma que debe bloquearse. El flujo puede consultar los cambios en las listas en la siguiente solicitud, sin un nuevo release. Si el flujo tiene una regla para rechazar los dispositivos incluidos en esa lista de bloqueo, puede rechazar la siguiente solicitud de la red que use ese dispositivo.
La lista guarda el valor confirmado y la política versionada determina qué ocurre cuando hay una coincidencia.
Ordene las reglas y asigne un resultado a cada solicitud
Redacte las reglas de modo que el flujo gestione los fallos y la falta de datos antes de utilizar los valores afectados. Registre las coincidencias en el conjunto de reglas para que la respuesta de cada decisión incluya la lista ordenada de reglas que se activaron.
Para la regla de velocidad propuesta, especifique la condición: la cantidad de intentos que comparten un dispositivo o correo electrónico alcanza el umbral que usted defina dentro del intervalo elegido. El flujo solo puede evaluar esa condición si una verificación proporciona la cantidad. Elija la acción correspondiente, como enviar a evaluación o rechazar, y manténgala separada de las reglas para coincidencias confirmadas en la lista de bloqueo.
Una bifurcación toma la primera rama cuyas condiciones coinciden. Agregue una rama final que acepte cualquier valor y envíe la solicitud a evaluación manual. Así, una solicitud que no coincida con ninguna rama tendrá un resultado que el equipo de evaluación podrá gestionar.
Compare las reglas propuestas con decisiones anteriores
Compare la regla propuesta con la política vigente antes de aplicarla a las solicitudes. Un backtest ejecuta un release con decisiones de producción anteriores, informa qué resultados cambiarían e incluye el desempeño de las solicitudes cuando hay datos disponibles sobre sus resultados.
Para cada decisión anterior, el backtest usa las listas tal como estaban cuando llegó la solicitud. Por eso, un dispositivo agregado después afecta las decisiones posteriores, no una decisión histórica anterior a su inclusión en la lista. Revise los clientes legítimos que la nueva regla rechazaría junto con los casos de fraude que detectaría.
Use resultados etiquetados para evaluar el equilibrio entre ambos efectos. Una regla que detecta más casos de fraude también puede rechazar a más clientes legítimos. Revise ambos resultados antes de decidir si el cambio debe pasar a producción. La minería de reglas puede proponer reglas candidatas a partir del historial etiquetado, pero el equipo de fraude decide cuáles se ajustan a su política.
Pruebe las reglas de dispositivo y velocidad antes del release
Para el dispositivo confirmado y la regla de velocidad propuesta, siga esta secuencia con su propia cartera.
- Defina los resultados que puede devolver el flujo y determine quién está a cargo de la cola de evaluación. Así, el equipo sabrá dónde se dirige una solicitud incierta y quién la resuelve.
- Elija las verificaciones que el flujo necesita para cada solicitud y configure el tiempo de espera de cada fuente de datos. Para la regla de velocidad, asegúrese de que una verificación proporcione la cantidad de intentos y el intervalo que evaluará la regla.
- Mantenga listas de bloqueo para fraudes confirmados, cuentas mula y contracargos, listas de permitidos para clientes o dispositivos legítimos conocidos y listas de vigilancia para valores bajo investigación.
- Redacte en orden las reglas estrictas contra el fraude y active el registro de coincidencias. Para la regla de velocidad, defina una cantidad y un intervalo a partir de su propio historial y elija si una coincidencia se envía a evaluación o se rechaza.
- Agregue reglas para llamadas fallidas, listas no disponibles, valores sin datos y puntuaciones vacías antes de las reglas habituales que utilizan esos resultados.
- Agregue una rama final a la bifurcación para enviar a evaluación manual cualquier solicitud que no coincida con otra rama.
- Cuando un caso confirme que un dispositivo o correo electrónico es fraudulento, agregue ese valor confirmado a la lista de bloqueo desde el caso. Compruebe la siguiente solicitud con la lista y confirme que la regla correspondiente la dirige al rechazo.
- Compare las revisiones vigentes y propuestas, y luego ejecute un backtest de un release con decisiones anteriores. Revise los clientes legítimos que ahora serían rechazados junto con los resultados de los casos de fraude que detectaría.
- Use la minería de reglas para sugerir candidatas a partir de resultados etiquetados. Conserve una candidata solo si el equipo puede explicar su condición, su acción y su efecto en los casos legítimos y de fraude.
Preguntas que nos hacen sobre motores de reglas antifraude
¿Qué es un motor de reglas antifraude?
Un motor de reglas antifraude ejecuta un flujo de decisiones que realiza verificaciones, evalúa reglas ordenadas y devuelve un resultado, como aprobar, enviar a evaluación o rechazar. Incluya en el flujo los datos, las listas y los resultados que utiliza su equipo, y registre qué reglas se activaron.
¿Cómo funcionan los motores de reglas antifraude para proteger pagos en línea?
Ejecutan verificaciones para una solicitud o un pago, comparan valores con listas, evalúan reglas y dirigen el resultado a una acción. Para un pago BNPL, configure las verificaciones del dispositivo y del correo electrónico, las consultas a las listas y las ramas que requiera su política.
¿Cuál es la diferencia entre un motor de reglas antifraude y una puntuación de fraude?
La puntuación de fraude es uno de los valores que puede usar un flujo. El motor ejecuta verificaciones, aplica reglas y listas, y dirige la decisión. Use la puntuación como un dato más y defina la política que convierte todos los datos en un resultado.
¿Qué debe hacer un motor de reglas antifraude si se agota el tiempo de espera de un proveedor de datos?
Debe exponer la llamada fallida a una regla para que el flujo elija una respuesta, como recurrir a otro proveedor, enviar la solicitud a evaluación o elegir un resultado prudente. Defina esa respuesta para cada verificación antes de basarse en el valor que devuelve.
¿Cómo se prueba una regla antifraude nueva antes de ponerla en producción?
Compare las revisiones vigentes y propuestas, y luego ejecute un backtest de un release con decisiones anteriores. Revise qué clientes legítimos serían rechazados por la nueva regla y cómo resultaron las solicitudes afectadas cuando haya datos disponibles.
¿Puede un motor de reglas antifraude encontrar reglas nuevas por su cuenta?
La minería de reglas puede proponer candidatas a partir del historial etiquetado, pero el equipo de fraude elige la política. Revise las condiciones y los resultados de cada candidata y use solo reglas que el equipo pueda explicar.
