Gestión de casos de fraude: qué alertas revisar
El lunes por la mañana, abre la cola de alertas de fraude. Ya está ordenada por puntaje y las alertas del fin de semana con puntajes bajos se descartaron automáticamente durante la noche. La lista parece ordenada: las alertas que siguen en pantalla esperan que alguien decida si requieren un caso, y las que desaparecieron ya no generan trabajo. Pero una de esas alertas descartadas correspondía a una solicitud asociada a un dispositivo en el que otro analista confirmó un fraude el viernes. Usted ve la cola después de que el sistema la ordenó y actuó, pero todavía no sabe qué implica esa alerta que ya no aparece para los casos que trabaja su equipo.
La gestión de casos de fraude incorpora solicitudes vinculadas a la revisión
La gestión de casos de fraude abarca el trabajo entre una alerta y una decisión registrada. El caso reúne la información disponible, asigna una revisión cuando hace falta y conserva la decisión para las tareas posteriores.
Un caso reúne la alerta, el cliente y la solicitud, las solicitudes vinculadas como registros, la tarea asignada y su plazo, el resultado y la nota del analista, además de un memo y un registro de actividad. Un diseño de caso define esos registros, tareas y decisiones para un trabajo que sigue abierto a medida que llega información. Se diferencia de una llamada de decisión única.
En una cola, la alerta suele mostrar las reglas antifraude que se activaron para una solicitud. Una regla también puede buscar actividad repetida a lo largo del tiempo. Pero un mismo dispositivo, teléfono, correo electrónico o cuenta puede aparecer en otras solicitudes que, por separado, parecen normales. A menudo, el equipo busca esos datos manualmente, si llega a buscarlos. La gestión de casos también puede reunir tareas de revisión repetitivas y evidencia, como se explica en este resumen sobre la gestión de casos en iniciativas antifraude.
Las solicitudes vinculadas pueden cambiar la ruta de una alerta
Si una solicitud vinculada se confirmó como fraude, una alerta con puntaje bajo pasa a revisión. En el ejemplo, A-1042 se confirmó como fraude el viernes. El lunes llega A-1101, asociada al mismo dispositivo y sin señales propias. Una regla que solo evalúe el puntaje de A-1101 la descartaría.
Las reglas de fraude generan muchas alertas que se cierran como no fraudulentas, por lo que los equipos priorizan las alertas en lugar de revisar cada una por separado. Pero si la ruta depende solo del puntaje de la alerta, pueden quedar fuera de vista los datos reutilizados en varias solicitudes.
En el ejemplo, una tarea puntúa las señales propias de cada alerta. Luego, otra tarea de red recibe el nivel de las señales y las solicitudes vinculadas, y define la ruta. Las reglas de señales y de red se probaron con estas alertas en el entorno de prueba de Decisimo.
Los resultados ponen en contexto la decisión sobre la alerta con puntaje bajo:
| Alerta | Señales | Puntos, nivel | Vinculadas, fraude confirmado | Ruta |
|---|---|---|---|---|
| Solicitud limpia, correo antiguo, mismo país | ninguna | 0, bajo | 0, 0 | clear |
| Correo nuevo, IP de otro país | correo nuevo, país de la IP distinto | 2, revisión | 1, 0 | review |
| Pocas señales, dispositivo compartido con un caso de fraude confirmado | ninguna | 0, bajo | 2, 1 | review |
La solicitud limpia se descarta automáticamente, y la solicitud con un correo nuevo y una IP de otro país pasa a revisión por sus propias señales. A-1101 no tiene señales propias, pero una de sus dos solicitudes vinculadas está confirmada como fraude.
Incorpore las solicitudes vinculadas al caso
Las solicitudes vinculadas deben llegar junto con la alerta. El análisis de vínculos, otra fuente de datos o el sistema que originó la alerta proporciona esas conexiones. El caso conserva las solicitudes como registros y permite que la ruta las tenga en cuenta.
La tarea Linked applications consulta las solicitudes que comparten con la alerta un teléfono, correo electrónico, dispositivo o cuenta bancaria. Cuenta las solicitudes vinculadas y las que se confirmaron como fraude, define la ruta y crea un registro para cada solicitud. Cada registro se identifica con el id de la solicitud. Si esa misma solicitud vuelve a llegar al caso, el registro se actualiza.
La tarea recibe las solicitudes vinculadas como entrada y genera registros y una ruta para el caso.
La sección Flow del diseño muestra cómo las tareas consultan información y generan resultados que otras tareas pueden usar.
La herramienta de análisis de vínculos de fraude permite identificar solicitudes conectadas por datos compartidos. Su demostración muestra 11 solicitudes sin etiqueta a dos vínculos de un fraude conocido, 5 de ellas en un grupo de 8. Estos resultados indican qué solicitudes sin etiqueta están cerca de un fraude conocido. La demostración muestra proximidad a fraudes conocidos, no puntajes de alertas. Compárelos con las decisiones tomadas solo a partir de alertas antes de evaluar cómo se habrían enrutado esas solicitudes.
Muestre la evidencia de la red durante la revisión del analista
El analista necesita ver las señales de la alerta y su red en una misma revisión. La revisión se asigna al rol Fraud analyst y vence en 24 horas. La información de revisión muestra las señales y los recuentos de la red, y solicita un resultado y una nota del analista.
El analista puede revisar los datos compartidos junto con la alerta. La información de revisión y el gráfico de la tarea humana reúnen los datos y las relaciones del caso en la tarea donde se toma la decisión.
En el caso de A-1101, el gráfico la conecta con A-1042 mediante un dispositivo compartido y con A-1043 mediante un teléfono compartido. Una regla de nodos incorpora las solicitudes, y dos reglas de vínculos conectan las solicitudes con el dispositivo o el teléfono que comparten.
Cuando el analista confirma el fraude, el caso puede añadir el dispositivo, teléfono, correo electrónico o cuenta compartidos a una lista de bloqueo. Una solicitud posterior que use ese dato puede rechazarse, y las solicitudes vinculadas que ya se aprobaron pueden revisarse.
Defina la ruta antes de despejar la próxima alerta
Volvamos a la cola del lunes. Una alerta con puntaje bajo puede requerir revisión si el dispositivo, teléfono, correo electrónico o cuenta que comparte la conecta con un fraude confirmado. Configure el caso para que considere las señales propias de la alerta y sus solicitudes vinculadas antes de despejarla.
- Defina qué convierte una alerta en un caso, qué resultados pueden cerrarlo y qué rol lo revisa y en qué plazo. Especifique los resultados: despejada, fraude confirmado o fraude descartado.
- Puntúe las señales propias de la alerta en una tarea y las solicitudes vinculadas en otra, para que la ruta tenga en cuenta ambos resultados.
- Incorpore las solicitudes relacionadas junto con la alerta, desde el análisis de vínculos o el sistema que la originó, y conserve un registro por id de solicitud.
- Despeje automáticamente solo cuando las señales sean bajas y ninguna solicitud vinculada se haya confirmado como fraude.
- Incluya las señales y los recuentos de la red en la información de revisión del analista, y muestre en el gráfico de la tarea las solicitudes vinculadas y los datos que comparten.
- Cuando el analista confirme el fraude, añada el dispositivo, teléfono, correo electrónico o cuenta compartidos a la lista de bloqueo desde el caso.
- Cargue en la herramienta de análisis de vínculos de fraude las solicitudes del mes pasado y revise las que no tienen etiqueta y están cerca de un fraude conocido. Compárelas con las decisiones tomadas solo a partir de alertas para ver cuáles se habrían despejado según su propio puntaje.
Preguntas sobre la gestión de casos de fraude
¿Qué es la gestión de casos de fraude?
La gestión de casos de fraude convierte una alerta en un caso, reúne la información disponible, asigna una revisión y registra la decisión para las tareas posteriores. Defina qué contiene el caso, quién lo revisa y qué resultados puede registrar.
¿Qué debe hacer un sistema de gestión de casos de fraude?
Debe reunir los registros, las tareas, las asignaciones, los plazos y las decisiones del caso, y permitir que el equipo registre los resultados y sus consecuencias. Configure la ruta, la información de revisión y la acción ante un fraude confirmado según las decisiones que toman sus analistas.
¿Cómo se deben gestionar las alertas de fraude relacionadas o duplicadas?
Incorpore las solicitudes relacionadas al caso como registros identificados por id de solicitud. Así, si la misma solicitud vuelve a llegar al caso, se actualiza su registro. Use los datos compartidos para definir la ruta y durante la revisión del analista.
¿Qué alertas de fraude se pueden despejar automáticamente?
Despeje automáticamente una alerta solo cuando sus señales sean bajas y ninguna solicitud vinculada se haya confirmado como fraude. El diseño probado envía A-1101 a revisión porque una solicitud vinculada se confirmó como fraude. Configure la regla de despeje automático para que verifique ambas condiciones.
¿Qué necesita ver un analista para decidir sobre una alerta de fraude?
El analista necesita ver las señales de la alerta, los recuentos de la red, las solicitudes relacionadas y los datos que comparten. Incluya esa información en la información de revisión y el gráfico, y luego registre el resultado y una nota.
¿Qué ocurre cuando un analista confirma un fraude?
Desde el caso, se puede añadir el dispositivo, teléfono, correo electrónico o cuenta compartidos a una lista de bloqueo, y revisar las solicitudes vinculadas que ya se aprobaron. Incluya la actualización de la lista entre las acciones asociadas al resultado de fraude confirmado.
¿Qué puntaje límite debe enviar una alerta de fraude a revisión?
Defina el límite para puntajes bajos a partir de los resultados de sus alertas y la capacidad de revisión del equipo. Luego, exija una segunda condición antes de despejar automáticamente: que ninguna solicitud vinculada se haya confirmado como fraude. Un umbral de puntaje por sí solo puede despejar una solicitud asociada a un dispositivo ya vinculado con un fraude. Vuelva a evaluar el límite frente a los resultados confirmados, especialmente después de cambiar las señales de alerta o las fuentes de vínculos.
¿Basta una solicitud vinculada con fraude confirmado para impedir el despeje automático?
Sí, si el vínculo se basa en un dato útil, como un dispositivo o una cuenta, y la solicitud vinculada tiene un resultado de fraude confirmado. En ese caso, envíe la alerta a revisión del analista, aunque sus propias señales sean bajas. Un teléfono o correo electrónico compartido puede conectar a solicitantes legítimos. Muestre el dato compartido y el criterio del vínculo, en lugar de tratar toda conexión como prueba.
¿Cómo se debe probar una regla de despeje automático antes de activarla?
Vuelva a procesar solicitudes recientes con la ruta propuesta. Incluya alertas con puntaje bajo y vínculos con fraude confirmado, alertas sin vínculos, ids de solicitud repetidos y datos de vínculos faltantes o retrasados. Compare las rutas con los resultados registrados por los analistas y calcule cuántos casos pasarían a revisión. No active el despeje automático hasta que los datos de vínculos faltantes envíen la alerta a revisión, en lugar de interpretarse como ausencia de conexiones.
