He aquí lo incómodo de los sistemas antifraude: incluso cuando cada parte individual parece razonable, el conjunto todavía puede comportarse como un laberinto.
Arreglas una regla. Genial. Ajustas un modelo. Muy bien. Ordenas un flujo de revisión manual. Muy responsable. Y aun así, un buen usuario termina siendo bloqueado en otro punto porque otra regla, la respuesta de un socio, una decisión de enrutamiento de pago, una verificación KYC, un agente de IA, una señal de inteligencia del dispositivo o alguna lógica olvidada de hace tres trimestres decide intervenir y decir: en absoluto.
En este episodio de la False Positives Masterclass, hablo sobre la lógica de override de fraude, que es una de las herramientas más potentes que los equipos de fraude maduros pueden utilizar para reducir falsos positivos en una pila de fraude compleja. La idea es sencilla en teoría: construir una red de seguridad de alto nivel sobre el sistema que pueda reconocer a los usuarios en los que ya tienes fuertes motivos para confiar, incluso si algún actor de la pila intenta bloquearlos.
Pero es precisamente en lo que parece simple en teoría donde nacen muchas malas ideas sobre fraude. Así que debemos tener cuidado.
Una anulación del sistema de fraude no es un atajo. No es una capa de aprobación basada en “buenas vibras”. No es una excusa para ignorar la mala lógica subyacente. Es un mecanismo controlado y basado en evidencia que se pregunta: antes de bloquear a este usuario, ¿tenemos pruebas irrefutables de que realmente es legítimo?
Eso suena obvio. No lo es. De lo contrario, más equipos lo harían bien.
Lo que escucharás en este episodio:
- Por qué incluso una lógica de prevención de fraude bien ajustada puede seguir generando falsos positivos
- Cómo funciona la lógica de anulación de fraude como una red de seguridad por encima de las reglas, los modelos, los agentes de IA, la revisión manual, las verificaciones KYC y las respuestas de los socios
- Por qué algunas reglas de detección de fraude nunca deben anularse automáticamente
- Cómo los usuarios confiables conocidos y las señales de confianza heredadas pueden ayudar a reducir los falsos positivos
- Por qué los entornos de alta exposición pueden ser útiles como indicadores de falsos positivos
- Cómo el geo-encadenamiento puede ayudar a distinguir a los viajeros y las discrepancias legítimas del fraude
- Por qué los artículos no revendibles o de bajo riesgo pueden respaldar aprobaciones de fraude de pago más seguras
- Cómo implementar sistemas de anulación de fraude de forma segura utilizando pruebas en modo sombra y una implementación gradual
Deberías escuchar este episodio si:
- Trabajas en operaciones de fraude y tu stack tiene demasiados puntos de bloqueo independientes
- Están intentando reducir los falsos positivos sin debilitar las reglas de detección de fraude
- Necesita una forma más segura de identificar a los usuarios de confianza en distintas cuentas, dispositivos, tarjetas o flujos
- Quieren ejemplos prácticos de lógica de anulación de fraude más allá de simples listas de permitidos genéricas
- Están evaluando cuándo utilizar inteligencia de dispositivos, geoencadenamiento, revisión manual o reglas desafiantes para mejorar la toma de decisiones
Notas del episodio y conclusiones clave
La lógica de anulación de fraude es una red de seguridad que cubre toda la pila
La idea principal de este episodio es que la reducción de falsos positivos no termina cuando ajustas reglas de fraude individuales. Eso ayuda, por supuesto. Pero incluso si cada regla, modelo, agente de IA, respuesta de socios, cola de revisión manual, decisión de enrutamiento de pagos, verificación KYC y señal de inteligencia de dispositivos tiene sentido por sí misma, el sistema completo aún puede generar malos resultados.
Esto se debe a que los usuarios no experimentan tus controles de uno en uno. Experimentan todo el laberinto.
Un usuario puede cumplir una regla y luego ser bloqueado por un modelo. Puede superar el modelo y luego quedar retenido por la respuesta de un socio. Puede pasar el KYC y luego encontrarse con una decisión de enrutamiento de pagos. En algún punto del proceso, una parte del sistema dice que no, aunque el conjunto más amplio de evidencias indique que probablemente se trata de un buen usuario.
Ahí es donde entra en juego la lógica de anulación de fraude. Se sitúa por encima de la pila y evalúa si hay pruebas suficientemente sólidas para revertir un rechazo o bloqueo. Piénsalo como la imagen en espejo de las reglas de red de seguridad contra el fraude. En lugar de atrapar el fraude que se escapó, detecta a los buenos usuarios que fueron detenidos por error.
Vale, esto suena peligroso. Y puede serlo. Por eso el diseño es tan importante.
No todas las decisiones sobre fraude deben ser anuladas
La primera cuestión de diseño es sencilla: ¿qué no debería modificarse nunca?
Aquí es donde los equipos necesitan disciplina. No todas las soluciones en la pila de fraude merecen el mismo tratamiento. Algunas señales son débiles. Otras son direccionales. Algunas solo son útiles en un contexto determinado. Otras son lo suficientemente sólidas como para que ignorarlas o anularlas a la ligera sea una mala idea.
Por ejemplo, si una lista negra de tarjetas robadas indica que una tarjeta está comprometida, probablemente no quieras anular esa decisión solo porque la ubicación del dispositivo se vea bien. El proveedor de inteligencia de dispositivos podría estar equivocado. La red podría parecer limpia. El patrón de comportamiento incluso podría parecer normal. Pero si se sabe que el propio instrumento de pago está comprometido, eso es una categoría de señal muy diferente.
No necesitas complicar demasiado esto. No tienes que emparejar cada regla de fraude con una regla de falso positivo correspondiente. Simplemente marca las soluciones o familias lógicas que sean demasiado fuertes para anularse por defecto.
Ese único paso evita mucho dolor en el futuro. Porque si tu capa de anulación puede revertir cualquier cosa, tarde o temprano revertirá algo que no debería haber tocado.
Y entonces todos pueden tener una reunión divertida. Y por divertida, quiero decir nada divertida.
Las heurísticas para buenos usuarios deben ser más estrictas que las reglas normales contra el fraude
La segunda cuestión de diseño es qué heurísticas son lo suficientemente sólidas como para identificar falsos positivos dentro de una población bloqueada.
Esta parte es importante porque la población en la que estás buscando ya es de alto riesgo. No se trata de usuarios aleatorios de tu tráfico base. Son usuarios que tu sistema ya decidió bloquear. Así que, incluso si una regla de excepción puede ser más precisa que el rechazo original, la tasa de fraude en este segmento sigue siendo más alta de lo normal.
Eso significa que tus señales de buenos usuarios deben ser especialmente sólidas. Más herméticas que una regla de fraude normal.
No estás preguntando: “¿Este usuario parece más o menos bien?” Eso no es suficiente. Estás preguntando: “¿Tenemos pruebas sólidas de que este usuario es legítimo, a pesar de que algo en la pila antifraude intentó detenerlo?”
Ese es un estándar más alto. Debería serlo.
El episodio divide esto en cuatro familias de lógica útiles: usuarios conocidos como buenos, entornos de alta exposición, cadenas geográficas y artículos no revendibles o de bajo riesgo. Ninguna de ellas debe copiarse ciegamente. Pero cada una ofrece a los equipos de fraude un punto de partida práctico.
Los usuarios confiables pueden trasladar su credibilidad a nuevas cuentas y eventos
La forma más sencilla de excepción son los usuarios de confianza. Cuentas de larga duración con un historial de comportamiento limpio. Usuarios que han superado verificaciones de alta fricción. Personas en las que tienes sólidos motivos para confiar.
Ahora, sí, lo sé. Esto suena muy básico. “Los buenos usuarios son buenos usuarios”. Una idea fantástica. Quizá ponla en una diapositiva.
Pero la parte interesante no son las cuentas antiguas y de confianza. La parte interesante es lo que ocurre cuando esos usuarios aparecen en cuentas nuevas, países nuevos, flujos nuevos o transacciones puntuales.
A veces, un usuario “nuevo” no es realmente nuevo. Es un usuario que regresa y que tu sistema aún no ha vinculado. Si puedes relacionar el nuevo evento con un evento anterior ya comprobado como bueno, es posible que puedas reducir de forma segura la fricción innecesaria.
El ejemplo del episodio es personal: tener varias cuentas de PayPal por vivir en diferentes países. El recorrido del usuario no es ideal, pero el requisito de cumplimiento tiene sentido. Lo importante es que la plataforma pueda vincular la nueva cuenta con las anteriores utilizando señales como el dispositivo, el nombre y el historial de cuentas.
Esa es la verdadera lección. La confianza puede inferirse, no solo recopilarse.
Una nueva cuenta que utiliza el mismo dispositivo y nombre que una cuenta legítima verificada previamente es un ejemplo. Otras combinaciones podrían incluir tarjeta más dirección IP, correo electrónico más mismo artículo comprado, o incluso señales vinculadas a la familia, como el apellido más la geolocalización exacta.
La idea no es encontrar conexiones aleatorias. Las conexiones aleatorias son la forma en que, sin querer, construyes una lógica errónea con mucha seguridad. El objetivo es vincular un nuevo evento con un evento sólido y comprobado como bueno.
Los entornos de alta exposición pueden reducir la probabilidad de fraude
La segunda categoría son los entornos de alta exposición.
Los estafadores suelen evitar entornos donde su identidad real, empleador, institución o afiliación puedan quedar expuestos. Los usuarios legítimos, en cambio, a menudo realizan transacciones desde estos lugares de forma natural.
Eso genera una señal de falso positivo útil.
Si un usuario realiza transacciones desde un entorno de red altamente controlado o rastreable, la probabilidad de que esté cometiendo fraude puede disminuir. Algunos ejemplos son las redes corporativas, redes gubernamentales, rangos de IP militares, redes de IP universitarias o grandes organizaciones sin fines de lucro.
Esto no significa que toda persona en una red corporativa sea automáticamente legítima. Obviamente no. No exageremos.
Pero cometer fraude desde un entorno supervisado vinculado a tu empleador, escuela o institución es arriesgado de otra manera. Muchos estafadores no temen especialmente a un posible enjuiciamiento en abstracto. Pero ser sancionados por su empleador, universidad u organización puede ser un elemento disuasorio mucho más inmediato.
La misma lógica puede aplicarse a destinos de envío controlados. Un paquete que se envía a una base militar, por ejemplo, puede implicar un perfil de riesgo diferente al de un paquete enviado a una dirección residencial favorable a los reenviadores.
De nuevo, esto es contextual. No es magia. Pero cuando se evalúan adecuadamente, los entornos de alta exposición pueden ayudar a que los sistemas de anulación de fraude identifiquen a usuarios legítimos dentro de una población bloqueada.
La geoencadenación puede reducir los falsos positivos basados en la ubicación
Las reglas de desajuste geográfico son una fuente clásica de falsos positivos en la detección de fraude. Todo el mundo conoce la lógica: el país de la tarjeta no coincide con el país de la IP, el país de facturación no coincide con el país de envío, el país de la cuenta no coincide con el país de inicio de sesión. A veces esto detecta fraude. Otras veces bloquea el comportamiento humano normal, porque las personas insisten en viajar, desplazarse, usar VPN y, en general, se niegan a comportarse como filas limpias en una base de datos.
Muy desconsiderado.
La geoencadenación es una forma de utilizar los datos geográficos de manera más inteligente. En lugar de considerar todas las discrepancias como sospechosas, se buscan patrones geográficos contextuales que expliquen por qué la discrepancia puede ser legítima.
El primer tipo es la proximidad geográfica en ubicaciones específicas. Si una dirección IP se resuelve muy cerca de una dirección de facturación en la ciudad de Nueva York, eso puede no decirte mucho. Los estafadores pueden encontrar proxies abiertos cerca de las grandes ciudades. Pero si la dirección de facturación está en un pueblo pequeño o en una zona rural, y la IP se resuelve dentro de un radio reducido, eso puede ser un indicador más sólido de un buen usuario. Es más difícil falsificar una proximidad geográfica poco común que una proximidad genérica a una gran ciudad.
El segundo tipo es una discrepancia coherente con la nacionalidad. El episodio ofrece otro ejemplo personal: usar una tarjeta española en Israel y que la operación sea bloqueada por una discrepancia entre un BIN español y una IP israelí. Pero si el nombre parece israelí y la IP es israelí, ese contexto importa. Un estafador con una tarjeta española probablemente solo usaría una IP española. No hay ninguna razón evidente para complicar de más un patrón de tarjeta española, nombre israelí e IP israelí.
Ese es el valor del geo-chaining. Encuentra correlaciones sutiles y contextuales que pueden explicar comportamientos legítimos. Usado con cuidado, puede revertir falsos positivos basados en la ubicación sin introducir un riesgo de fraude innecesario.
Los artículos que no se pueden revender pueden respaldar aprobaciones de fraude de pago más seguras
La cuarta categoría se aplica principalmente al fraude en pagos: artículos no revendibles o de bajo riesgo.
Los estafadores normalmente no roban productos porque quieran el artículo para uso personal. Los roban porque pueden revenderlos; ese es el modelo económico. Si el artículo no tiene mercado de reventa, o solo uno muy limitado, rechazarlo por riesgo de fraude a veces puede ser contraproducente.
Entre los ejemplos se incluyen bienes y servicios educativos, artículos de nicho o hiperpersonalizados, regalos familiares personalizados, sesiones de terapia, entrenamiento personal u otros servicios que requieren consumo personal.
Esto es básicamente lo contrario del motivo por el que consideramos arriesgados los productos electrónicos, las autopartes o las tarjetas de regalo. Esos artículos son fáciles de revender. ¿Una taza familiar personalizada con el perro de alguien? Mucho menos atractiva para una banda organizada de fraude. O sea, probablemente.
En un sistema de anulación de fraude bien diseñado, un bajo valor de reventa puede convertirse en parte de la lógica de aprobación. No como un motivo independiente para aprobarlo todo, sino como una señal de apoyo que ayuda al sistema a reconocer las transacciones que es poco probable que los estafadores quieran.
Esa distinción es importante. La lógica de artículos de bajo riesgo debe respaldar la anulación, no sostenerla por completo por sí sola.
El despliegue seguro es tan importante como la lógica
La parte final del episodio trata sobre la implementación, porque es aquí donde las buenas ideas pueden convertirse en malos incidentes.
No activas la lógica de anulación de fraude para el 100% del tráfico el primer día. La pruebas. Con cuidado.
Un despliegue más seguro comienza con pruebas en modo sombra. Ejecuta la lógica de anulación sin permitir que afecte las decisiones. Mide si alcanza a la población que esperabas. Examina los casos. Compara los resultados con tu análisis.
Luego puedes introducir una regla desafiante para anular una pequeña parte de las denegaciones mientras el resto permanece en modo sombra. La transcripción usa el 20% como ejemplo, pero la cifra exacta depende de tu apetito de riesgo y del contexto de tu negocio.
Luego observas los resultados durante 30 a 60 días, o el tiempo suficiente para entender cómo evoluciona el fraude en la población que permitiste pasar. Si los resultados se ven bien, aumenta gradualmente. Si no son claros, espera. Si el fraude se dispara, vuelve al modo sombra al 100% y replantea la lógica.
Este aumento gradual y prudente también puede revelar qué soluciones de detección de fraude nunca deberían ser anuladas. Si la mayor parte del fraude que atraviesa la anulación proviene de un puñado de reglas o modelos, esas soluciones pueden pertenecer al nivel de “no anular”.
Y si llegas al punto en que estás creando excepciones a tus excepciones, felicitaciones. O estás liderando el grupo o estás muy cansado. Posiblemente ambas cosas.
Conclusión final:
La lógica de anulación de fraude es poderosa porque reconoce algo importante: los falsos positivos no siempre se deben a una sola regla equivocada. A veces son el resultado de un sistema en el que demasiados componentes razonables interactúan de maneras poco razonables.
Una capa de anulación de alto nivel puede ayudar a los equipos de fraude más maduros a aprobar a usuarios en los que ya tienen fuertes motivos para confiar. Pero solo si la lógica es precisa, las señales son totalmente fiables y el despliegue está controlado.
Los usuarios confiables conocidos, los entornos de alta exposición, el geoencadenamiento y los elementos de bajo riesgo pueden ayudar a reducir los falsos positivos. Las pruebas en modo sombra y la implementación gradual ayudan a garantizar que no soluciones un problema de falsos positivos creando un problema de fraude.
En fin, ese es el equilibrio. Construye la red de seguridad, pero no finjas que la gravedad dejó de existir.
¿Estoy siendo demasiado precavido? Tal vez.
Pero en los sistemas antifraude, la cautela suele envejecer mejor que la astucia.
Conecta con Chen Zamir | LinkedIn
Presentador de The Saturday Fraud Strategist
Ayudando a las fintech a construir defensas contra el fraude más inteligentes
Coautor de «The Fraud Fighter’s AI Playbook»
¿No estás listo para dejar de hablar de mi, y ojalá también tu, tema favorito? Suscríbete a The Saturday Fraud Strategist newsletter.
Episode transcript
Chen Zamir
00:07
In the previous part of this masterclass, we talked about how to tune your solutions so they create less false positives. This sounds great in theory, and it's often the case that it would work great in reality as well. But even if you do all of that perfectly, you still face one more problem. Your fraud system is a maze. You have rules, models, AI agents, manual review queues, partner responses, payment routing decisions, KYC checks, device intelligence, and dozens of other components That are each capable of blocking a user. Even if each component is reasonable on its own, their interactions can still produce false positives in places you never intended. A user might bypass one part of the system only to be caught by another. This is why mature fraud teams eventually introduce a different mechanism altogether, a high-level override layer that sits on top of the entire stack to help the system speed through users you already have reason to trust. Think of it as the mirror image of your fraud safety net rules. When any actor in the system, be it a rule, a model, an agent, or even a human, tries to block a user, this safety net checks whether there is strong evidence that the user is actually a good one. And if so, it reverses the decision. This idea is extremely powerful when implemented correctly, but it requires thoughtful design. So let's walk through how it works.
Chen Zamir
01:55
There are two questions you must answer before designing any override logic. The first one touches on the parts of your system that shouldn't be overridden, and definitely not by default. Why? Well, frankly speaking, not all solutions should be treated equally. If a stolen card blacklist says a card is compromised, you shouldn't automatically override the decision just because the device location looks good. After all, the data intelligence vendor can be wrong. That doesn't mean it has to be complex, and there is no need to pair fraud logics with false positive logics. Just mark the solutions in your system that are particularly strong and should never be overridden. The second thing you want to consider, obviously, is which heuristics are strong enough in detecting false positives. Keep in mind, you are searching for good users in a population that is inherently high risk. You already chose to block them. So even if this can be more accurate, the fraud rate in this segment is much higher than your baseline. So your false positive heuristics need to be especially airtight, much more than a normal fraud rule. The question then is, where do you start? I'd like to suggest four key heuristics, or logic families, that usually prove to be effective at sifting through high fraud rate populations and finding false positives in them. Which of them you implement, and how exactly, depends on your specific business context.
Chen Zamir
04:01
Let's start with the simplest and most intuitive category: users you already know and trust. These signals might include long-standing accounts with clean behavioral history, or users who passed high friction verification. And I'm not talking about your generic KYC, but something more meaningful. Now, I know what you must be thinking. Hold up, this is the most trivial piece of information ever. Surely I didn't waste my time watching this for this. But here's the catch: while flagging established accounts is straightforward, the logic changes entirely when you need to assess new accounts or one-time users. In many cases, these new users can be returning users. And if we manage to associate them with their past activity, we might exclude them from high friction risk mechanisms. For example, I myself have three PayPal accounts, as I've lived in three different countries, and PayPal requires users to open an account in each new country they move to. This is not the ideal user journey, but I understand the compliance requirements they need to uphold. At the same time, I also know that whenever I open a new account, They immediately link it to my previous ones. How?
Chen Zamir
06:30
Simply because I'm using the same device to open a new account with the same name as an account I already own. That's me. The key insight is that trust can be inferred, not just collected. You don't have to wait for someone to build a long history on one account if they are the same user behind multiple accounts, and you verify the legitimacy of any one of them, the new one inherits that trust. Now, using the same device and name to open a new account is not exactly a groundbreaking heuristic, even though not all teams have even that in place. But you can easily find similar logics that don't rely on the same device and are still as strong. Here are some examples: card plus IP address, email plus the same, item bought. And you can also infer across family members, for example, with last name plus exact geolocation. Just remember, it's not about finding random links. It's about linking a new event to an airtight, proven good event.
Chen Zamir
08:31
Fraudsters avoid environments where their real identity or real affiliations could be exposed. Legitimate users, on the other hand, often operate from those environments naturally. This leads to a surprisingly powerful heuristic. If a user transacts from a highly controlled or highly traceable network environment, the likelihood they are a fraudster drops dramatically. What could be examples of that? One example can be corporate, government, or military IP networks with strict access controls, where the user is likely an employee. University IP networks, where the user is either on staff or a student, are also a good example. And some large nonprofit organizations, think about like the UN, Where the user is likely an employee as well, can also be considered. Committing fraud from such a network is highly unlikely, as they are monitored for security breaches and can lead back to the individual user. Similarly, sending packages to a highly controlled shipping address, let's say a military base, for example, is another indicator the user is highly unlikely to be a fraudster. Now, keep in mind, it's not necessarily about identifying and prosecuting the fraudster. Most of them don't fear that. But it is about the fear of being sanctioned by their own employer that would deter them from utilizing these assets to commit fraud.
Chen Zamir
11:16
When we think about geographic data, we often think about rudimentary fraud detection logics that look for geo mismatches. And as rudimentary logics, we also know they are many times the main culprit when it comes to causing false positives. We just talked about it in the previous part, where I gave the US-Canada example. But we can also use geographic data to identify false positives quite accurately using a technique called geo chaining. Specifically, I'd like to point out two types of geo chains. The first one deals with geographic proximity in specific locations. Here's what I mean. If an IP address resolves to a location extremely close to the legitimate billing address, that on its own is not necessarily a redeeming indicator. For example, if the address is located in New York City, finding an open proxy IP that is less than 10 miles away from the billing address you stole is probably not so hard. But what if the address is in a small town or a rural area? When you get a strong match to the IP location, let's say less than 10 miles, this can be a stronger good user indicator than most people realize. Fraudsters can spoof large cities easily, but it is not that easy to do that with obscure villages in the countryside. The second thing you want to look for is nationality-consistent mismatch. And again, let me share an example from my own personal experience. When I use my Spanish card in Israel, I often get blocked. Why? Because of the Spanish BIN, Israeli IP mismatch. But it shouldn't be the case. Analyzing my name should mark it as Israeli. The technology exists, trust me. And matching it to the Israeli IP should be easy. That's not to say that when a name shares the same nationality as the IP address, it means it's a good event. But when we see a very specific pattern where the card mismatches the IP, but the name matches the IP, we find a correlation that is too obscure for a fraudster to mimic. Think about it. When a fraudster sees a Spanish card, they simply go for a Spanish IP. There's no reason for them to overengineer it. This is subtle and contextual, but when the logic is vetted properly, it can overturn a surprising number of geo-based false positives while introducing minimal additional fraud risk. As a side note, by using this heuristic, we basically identify travelers. And you can probably think of other ways to identify travelers. For example, identifying hotel or airport Wi-Fi IPs. Are travelers by definition good users? Not always, but it helps explain that rudimentary geo mismatch logic we mentioned earlier.
Chen Zamir
15:03
The final heuristic applies mainly to payment fraud. Usually fraudsters don't steal goods so they can use them themselves. They steal it so they can later resell it and pocket their earnings. This means that their economic model depends on transferring the stolen goods, whether digital or physical, to someone else. If the item being purchased has no resale market, or only a very weak one, then declining it for fraud risk is often counterproductive. Here are some examples. Educational goods and services, niche and hyper-personalized items, like think about customized family gifts, or services that require personal consumption, like a therapy session or a personal training session. If you think about it, we're basically reversing the heuristic that makes high-value products riskier. Why do we perceive electronics, auto parts, or gift cards as high risk? Because it's very easy to resell them. So in a well-designed override system, low resale value can help your system approve things fraudsters don't even want in the first place.
Chen Zamir
16:50
Let's make it simple. You do not turn on override logic for 100% of your traffic on day one. You test it robustly. A typical rollout might look like this. First, deploy the override rule in shadow mode only. Second, you measure the hits and compare them to your analysis. Is it hitting according to your expectations? Third, you lower the shadow mode rule to 80% of the population, and introduce a challenger rule that actually overrides declines for the rest of the 20%. These numbers are, of course, placeholders, so you can decide what's the level of risk you want to take here. Fourth, you watch the results over, say, 30 to 60 days, and this should show you how fast fraud matures in the undeclined population. If it looks good, you can ramp up to, let's say, 50%, and repeat the process. If it's not really clear yet, you want to wait another 30 days. And if fraud spikes, you go back to 100% shadow mode and to the drawing board in general. You go through several iterations, again, based on your risk appetite, and gradually increase it until you reach full deployment. One thing that you might find out throughout this cautious ramp up is that the fraud you do see penetrating these rules can come from a handful of fraud detection solutions. This is pretty common, and in that case, you should move these fraud solutions to that tier we mentioned that doesn't get overridden. And if you've gotten to this point, essentially developing exclusion logics to exclusion logics, you know you're leading the pack.
View full transcript
