Crea conmigo una regla antifraude de alto rendimiento: un ejemplo del mundo real

--- title: Crea conmigo una regla antifraude de alto rendimiento: un ejemplo del mundo real source_page: https://www.sardine.ai/es/blog/ai-assisted-fraud-rule-writing canonical: https://www.sardine.ai/es/blog/ai-assisted-fraud-rule-writing format: text/markdown date: 2026-03-12T00:00:00.000Z author: Chen Zamir description: Aprende a escribir reglas antifraude resilientes y de alto rendimiento utilizando un enfoque iterativo y basado en datos. Esta guía explica la detección de anomalías, la reducción de falsos positivos, los compromisos entre precisión y recall, y cómo la IA y los LLM aceleran la investigación moderna de reglas antifraude. --- **Quick links:** [Human page](https://www.sardine.ai/es/blog/ai-assisted-fraud-rule-writing) · [Home](https://www.sardine.ai) · [Customers](https://www.sardine.ai/es/customers) · [Blog](https://www.sardine.ai/es/blog) · [Demo](https://www.sardine.ai/es/demo) --- # Crea conmigo una regla antifraude de alto rendimiento: un ejemplo del mundo real **Author:** Chen Zamir · **Published:** 2026-03-12T00:00:00.000Z · **Categories:** Fraud Aprende a escribir reglas antifraude resilientes y de alto rendimiento utilizando un enfoque iterativo y basado en datos. Esta guía explica la detección de anomalías, la reducción de falsos positivos, los compromisos entre precisión y recall, y cómo la IA y los LLM aceleran la investigación moderna de reglas antifraude. Redactar una regla contra el fraude es una tarea que la mayoría de analistas de datos y especialistas en fraude pueden hacer en su primera semana de trabajo. Redactar una buena regla contra el fraude, sin embargo, es un poco más complicado. Para entender por qué, primero debemos establecer qué es lo que hace que una regla antifraude sea buena. La respuesta es bastante sencilla: su desempeño debe ser eficaz en el momento y, al mismo tiempo, resistente a los cambios de comportamiento de los estafadores. En esta entrada del blog, quiero compartir el proceso de análisis que seguí recientemente al redactar una regla antifraude para un grupo de nuestros clientes. Espero que pueda darte algunas ideas sobre cómo estructurar la tuya. Antes de empezar, unas palabras sobre la metodología El enfoque de hoy es la fase de investigación de una nueva regla. Y como en toda tarea de análisis, mi recomendación es llevarla a cabo en un entorno SQL en lugar de en Excel o directamente en tu propio motor de reglas. Por supuesto, siéntete libre de hacer la investigación como prefieras, pero en mi experiencia el ejercicio será más eficaz dentro de tu almacén de datos.¿Apenas estás empezando con SQL? No te preocupes, ¡para eso tenemos LLMs hoy en día! Otra cosa que me gustaría señalar es el conjunto de KPI que me guían cuando llevo a cabo un proceso de investigación iterativo. Antes de aprobar que una regla entre en producción, mi organización tiene una política que define los criterios de éxito que debe cumplir. En muchas organizaciones, esto consiste en un conjunto de objetivos, validaciones y documentación necesarios para publicar una nueva regla. Los criterios finales de éxito deben orientar el diseño de nuestro proceso de investigación iterativo, hasta definir qué KPI debemos analizar y qué objetivos debemos perseguir. Cuando construyo una regla condición por condición, esto me ayuda a entender si estoy tomando las decisiones correctas. Aunque esto puede variar de un caso de uso a otro, hay dos KPI que me gusta seguir de cerca en cada etapa del proceso: Precisión: cuán precisa es mi regla y, por extensión, cuántos falsos positivos se ven afectados Cobertura: Cuántos de los casos de fraude detecto El acto de equilibrio es bastante directo, pero no sencillo. Por cada condición que añado a la regla, quiero ver que mi precisión aumenta mientras mi recall se mantiene prácticamente igual. Por último, unas palabras sobre el conjunto de datos con el que estuve trabajando. Cuando comencé mi revisión, me centré en un segmento específico: eventos de pago de cualquier tipo, en un período de tiempo concreto, de un conjunto específico de clientes. Mi conjunto de datos inicial incluía casi 476 mil registros, de los cuales 1.480 estaban etiquetados como fraudulentos. Esto fijó la precisión inicial (o tasa de fraude) en 0,31%. Siempre uso un 40% de precisión como referencia para las reglas de rechazo automático de pagos, así que si puedo alcanzar ese valor con un nivel de recall suficientemente alto, estaré satisfecho. Cómo redactar reglas contra el fraude en 3 sencillos pasos: He pasado 16 años en la prevención del fraude, he escrito cientos de reglas y he supervisado sistemas que ejecutaban miles de reglas de prevención de fraude. Este es el proceso que utilizo para redactar reglas de alto rendimiento: Encuentra una “anomalía desencadenante”. Define el comportamiento sospechoso principal que intentamos detener. Explica la anomalía. Refina la regla para reducir los falsos positivos excluyendo: Explicaciones de la anomalía: comportamientos legítimos que imitan nuestra principal sospecha. Señales de confianza: indicadores que caracterizan a una población generalmente de bajo riesgo Validar y aprobar. Desglosemoslo. Encontrar la «anomalía desencadenante» Allí estaba yo, explorando el conjunto de datos que describí arriba, revisando contracargos y buscando inspiración. Entonces me di cuenta de algo: varios casos de fraude en los que la geolocalización de la IP (en concreto, el estado de la IP) no coincidía con la dirección del usuario. Eso me hizo reflexionar. La discrepancia geográfica es una señal de fraude tan característica, y aun así encontré bastantes de estos casos. Uno esperaría que el sistema identificara fácilmente este tipo de discrepancias, ¿no? La razón, como quizá ya hayas imaginado, es que la población de “desajustes aprobados” estaba saturada de falsos positivos. De 4.355 casos, solo 370 fueron etiquetados como fraude. Podía ver por qué estos desajustes de “bajo riesgo” no eran rechazados, pero también ofrecían un buen “gancho” para investigar una regla, o una “anomalía incitadora”: una señal anómala que describe muchos casos de fraude, aunque con baja precisión. Y, de hecho, una precisión del 8,5% significa que tener una discrepancia entre la IP y la dirección ya es 27 veces más arriesgado que en la población general, y detecta exactamente el 25% del fraude. Percibí potencial. Por lo general, cualquier señal que sea 20 veces más riesgosa que la población general es un buen punto de partida para la investigación de reglas. Borrador de regla IP_state != address_state Rendimiento de la regla Explicación de la anomalía Una vez que encuentro una anomalía desencadenante, mi siguiente objetivo es aumentar la precisión sin reducir demasiado el recall. Lo que no quiero hacer es añadir más indicadores sospechosos a mi lógica de reglas. ¿Por qué? Porque eso tiene una alta probabilidad de dividir a la población fraudulenta en distintos anillos de fraude. Eso no solo reduciría el recall, sino que también haría la regla muy específica. Y recuerda, las reglas específicas son fáciles de eludir. En cambio, quiero describir cómo es el comportamiento de un cliente de confianza para poder excluirlo de la lógica de la regla. Suena a cuestión semántica, pero pronto te darás cuenta de que la parte clave al redactar reglas es formular los falsos positivos, no encontrar indicadores sospechosos. Hay dos maneras de identificar patrones de falsos positivos que podemos excluir: las explicaciones de anomalías y las señales de confianza. Explicaciones de anomalías Una explicación de anomalía es cualquier señal que no sea necesariamente de bajo riesgo por sí sola, pero que pueda “resolver” la anomalía. Básicamente, muestra por qué un buen usuario presentaría ese comportamiento. Por ejemplo, siempre que trato con anomalías relacionadas con direcciones IP, mi explicación de referencia es el propio tipo de IP. Si se trata de una IP altamente controlada (.gov, .mil, .edu), puede explicar por qué hay una discrepancia geográfica entre ella y la dirección del usuario. Esto se debe en parte a que puede implicar viajes frecuentes, pero más importante aún, a que a menudo indica el uso de VPN internas. Por supuesto, usar una IP altamente controlada suele ser seguro incluso fuera de nuestra anomalía en particular. Pero tiene un precio: no son tan comunes. Y ese fue precisamente el caso aquí también. Borrador de la regla IP_state != address_state Y IP_connection_type EN (“mil | gov | edu | org | corp”) Rendimiento de la regla Solo logramos reducir un puñado de falsos positivos, pero el rendimiento es prácticamente el mismo. Luego quise analizar más de cerca las señales de proxy IP. Era evidente que muchos de los incidentes de fraude se originaban cuando la probabilidad de uso de un proxy IP era media o alta. Esto tiene sentido, ya que los estafadores a menudo usan de forma descuidada proxies IP que están muy lejos de la dirección de su víctima, siempre que estén en el mismo país. Así que me centré en los eventos en los que la probabilidad de uso de un proxy era baja y noté que los tipos de conexión de ISP eran mucho más seguros que las conexiones móviles o híbridas. Eso también tenía sentido: es menos probable que los estafadores utilicen rangos de IP estables que puedan delatarlos. Con ello, añadí una condición en la que excluí los casos en los que la probabilidad de proxy es “baja” y el tipo de conexión es ISP. Borrador de regla IP_state != address_state Y IP_connection_type EN (“mil | gov | edu | org | corp”) Y (IP_proxy == “low” Y IP_connection_type == “ISP”) Rendimiento de la regla Se ve bastante bien, ¿verdad? Puede ser, pero no estaba satisfecho con la cantidad de casos de fraude que “perdimos” aquí. Aunque redujimos muchos falsos positivos, estaba seguro de que un análisis más profundo me ayudaría a mantener a los malos dentro. Aquí tienes un breve clip que grabé y que muestra cómo suelo hacerlo: Puedes verme revisando los 1,484 casos que la última exclusión eliminó de la población de mi regla. Lo primero que hago es ordenar los resultados poniendo los casos de fraude arriba, para poder detectar patrones fácilmente. Luego reviso rápidamente cuántos casos de fraude veo en total (los 46 excluidos) y, por último, intento identificar cómo diferenciar la población mala de la buena. En este caso (y obviamente me di cuenta antes de grabar el video), noté que todos los casos malos no tenían una dirección de correo electrónico verificada. Lo incorporé rápidamente en la lógica de mis reglas. Borrador de regla IP_state != address_state Y IP_connection_type EN (“mil | gov | edu | org | corp”) Y (IP_proxy == “low” AND IP_connection_type == “ISP” AND cust_email_verified == TRUE) Rendimiento de la regla (ignorando la última versión) Observa que, aunque mi precisión es la misma y no excluí tantos falsos positivos, el recall ha mejorado mucho. Esa es una versión de la regla mucho mejor. Señales de confianza En este punto, pasé varias horas más tratando de averiguar si podía encontrar otras buenas explicaciones de por qué la IP y la dirección deberían no coincidir. Al no encontrar más, pasé a mi segunda táctica: identificar señales generales de confianza. Aquí, la idea no es explicar por qué esta anomalía tiene sentido, sino reducir la población excluyendo de ella los segmentos generales de bajo riesgo. La señal de verificación de correo electrónico que usamos arriba es un ejemplo perfecto. Dentro del contexto de este conjunto de datos, no era particularmente fuerte por sí sola, hasta que la combinamos con la condición del tipo de IP. Por otro lado, tener un teléfono verificado resultó ser una señal lo suficientemente sólida por sí sola, así que la incluí como mi siguiente capa. Borrador de regla IP_state != address_state Y IP_connection_type EN (“mil | gov | edu | org | corp”) Y (IP_proxy == “low” E IP_connection_type == “ISP” Y cust_email_verified == TRUE) Y cust_phone_verified == TRUE Rendimiento de la regla Finalmente, noté que muchos buenos clientes detectados por mi versión de la regla tenían correos electrónicos corporativos. Por lo tanto, opté por conservar únicamente los dominios de correo electrónico “gratuitos” en mi conjunto de datos. Esto no es necesariamente un indicador sólido por sí solo (los estafadores pueden robar tu correo electrónico sin problema), pero podría explicar más historias de viajes o de uso de VPN que no pudimos identificar directamente. Borrador de regla IP_state != address_state Y IP_connection_type EN (“mil | gov | edu | org | corp”) Y (IP_proxy == “low” AND IP_connection_type == “ISP” AND cust_email_verified == TRUE) Y cust_phone_verified == TRUE Y email_domain_type == "free" Rendimiento de la regla Como puedes ver, aunque nuestro recall cayó casi una quinta parte, también duplicamos nuestra precisión hasta un punto en el que, con algunos ajustes, la regla puede ponerse en producción. Preparar la regla para el lanzamiento Una vez que definamos la lógica de la regla, quedarán dos pasos por completar antes de poder ponerla en producción. El primero es aprobar el rendimiento general de la regla y su impacto esperado en el negocio. Para ofrecer una visión completa del rendimiento cuando lo envíe para su aprobación, compartiré lo siguiente: Esto debería darle al gerente aprobador todo lo que necesita para autorizar mi solicitud con confianza. Pero la aprobación es solo la mitad de la batalla. Lo segundo que tenemos que hacer es completar todo el proceso de validación de la regla. ¿La buena noticia? ¡Acabamos de completar el primer paso (de seis)!