Aqui está o aspecto desconfortável dos sistemas de fraude: mesmo quando cada parte individual parece razoável, o conjunto ainda pode se comportar como um labirinto.
Você ajusta uma regra. Ótimo. Você calibra um modelo. Legal. Você organiza um fluxo de revisão manual. Muito responsável. E então um bom usuário ainda acaba bloqueado em outro lugar porque outra regra, resposta de parceiro, decisão de roteamento de pagamento, verificação de KYC, agente de IA, sinal de inteligência de dispositivo ou alguma lógica esquecida de três trimestres atrás resolve entrar em ação e dizer: de jeito nenhum.
Neste episódio da False Positives Masterclass, vou falar sobre a lógica de override de fraude, que é uma das ferramentas mais poderosas que equipes de fraude maduras podem usar para reduzir falsos positivos em uma pilha de fraude complexa. A ideia é simples na teoria: construir uma rede de segurança em alto nível sobre o sistema, capaz de reconhecer usuários em quem você já tem fortes motivos para confiar, mesmo que algum dos componentes da pilha tente bloqueá-los.
Mas é justamente na simplicidade teórica que muitas ideias ruins de combate à fraude nascem. Por isso, precisamos ter cuidado.
Uma substituição manual do sistema de fraude não é um atalho. Não é uma camada de aprovação baseada em “boas vibrações”. Não é uma desculpa para ignorar uma lógica ruim por trás. É um mecanismo controlado, baseado em evidências, que pergunta: antes de bloquearmos este usuário, temos provas irrefutáveis de que ele é realmente legítimo?
Isso parece óbvio. Não é. Caso contrário, mais equipes fariam isso bem.
O que você vai ouvir neste episódio:
- Por que mesmo uma lógica de prevenção a fraudes bem ajustada ainda pode gerar falsos positivos
- Como a lógica de substituição de fraude funciona como uma rede de segurança sobre regras, modelos, agentes de IA, revisão manual, verificações de KYC e respostas de parceiros
- Por que algumas regras de detecção de fraude nunca devem ser substituídas automaticamente
- Como usuários comprovadamente confiáveis e sinais de confiança herdados podem ajudar a reduzir falsos positivos
- Por que ambientes de alta exposição podem ser indicadores úteis de falsos positivos
- Como o geo-chaining pode ajudar a diferenciar viajantes e divergências legítimas de fraudes
- Por que itens não revendíveis ou de baixo risco podem contribuir para aprovações de fraude em pagamentos mais seguras
- Como implementar sistemas de substituição de decisões de fraude com segurança usando testes em modo sombra e implantação gradual
Você deve ouvir este episódio se você:
- Trabalha em operações de fraude e a sua stack tem demasiados pontos de bloqueio independentes
- Estão tentando reduzir falsos positivos sem enfraquecer as regras de detecção de fraude
- Precisam de uma forma mais segura de identificar usuários confiáveis em diferentes contas, dispositivos, cartões ou fluxos
- Quer exemplos práticos de lógica de substituição de fraude que vão além de listas de permissão genéricas
- Estão avaliando quando usar inteligência de dispositivo, geo-chaining, revisão manual ou regras desafiadoras para melhorar a tomada de decisão
Notas do episódio e principais aprendizados
A lógica de substituição de fraude é uma rede de segurança sobre toda a pilha
A ideia principal deste episódio é que reduzir falsos positivos não termina quando você ajusta regras de fraude individuais. Isso ajuda, é claro. Mas mesmo que cada regra, modelo, agente de IA, resposta de parceiro, fila de revisão manual, decisão de roteamento de pagamento, verificação de KYC e sinal de inteligência de dispositivo faça sentido por si só, o sistema como um todo ainda pode gerar resultados ruins.
Isso acontece porque os usuários não vivenciam seus controles um de cada vez. Eles vivenciam o labirinto inteiro.
Um usuário pode passar por uma regra e, em seguida, ser bloqueado por um modelo. Ele pode passar pelo modelo e depois ficar retido por uma resposta de parceiro. Pode passar pelo KYC e então esbarrar em uma decisão de roteamento de pagamento. Em algum ponto desse caminho, uma parte do sistema diz não, mesmo que o conjunto mais amplo de evidências indique que provavelmente se trata de um bom usuário.
É aí que entra a lógica de substituição de fraude. Ela fica acima da pilha e verifica se há evidências suficientemente fortes para reverter uma recusa ou bloqueio. Pense nela como a imagem espelhada das regras de rede de segurança contra fraude. Em vez de capturar fraudes que passaram despercebidas, ela captura bons usuários que foram bloqueados incorretamente.
Ok, isso parece perigoso. E pode ser mesmo. É por isso que o design é importante.
Nem toda decisão de fraude deve ser anulada
A primeira questão de design é simples: o que nunca deve ser substituído?
É aqui que as equipes precisam de disciplina. Nem toda solução na pilha de fraude merece o mesmo tratamento. Alguns sinais são fracos. Alguns são direcionais. Alguns só são úteis em determinado contexto. Outros são fortes o suficiente para que ignorá-los de forma casual seja uma má ideia.
Por exemplo, se uma lista negra de cartões roubados indicar que um cartão foi comprometido, você provavelmente não vai querer substituir essa decisão só porque a localização do dispositivo parece confiável. O fornecedor de inteligência de dispositivo pode estar errado. A rede pode parecer limpa. O padrão de comportamento pode até parecer normal. Mas se o próprio instrumento de pagamento é conhecido por estar comprometido, isso é uma categoria de sinal completamente diferente.
Você não precisa complicar demais isso. Você não precisa associar cada regra de fraude a uma regra correspondente de falso positivo. Basta marcar as soluções ou famílias de lógica que são fortes demais para serem substituídas por padrão.
Esse único passo evita muita dor de cabeça no futuro. Porque, se a sua camada de substituição puder reverter qualquer coisa, eventualmente ela vai reverter algo em que não deveria ter mexido.
E então todo mundo acaba participando de uma reunião divertida. E por divertida, quero dizer nada divertida.
As heurísticas para bons usuários precisam ser mais rigorosas do que as regras normais de fraude
A segunda questão de design é quais heurísticas são fortes o suficiente para identificar falsos positivos dentro de uma população bloqueada.
Esta parte é importante porque a população na qual você está pesquisando já é de alto risco. Não se trata de usuários aleatórios do seu tráfego base. São usuários que o seu sistema já decidiu bloquear. Portanto, mesmo que uma regra de exceção possa ser mais precisa do que a recusa original, a taxa de fraude nesse segmento ainda é mais alta do que o normal.
Isso significa que seus sinais de bons usuários precisam ser especialmente fortes. Mais à prova de falhas do que uma regra de fraude comum.
Você não está perguntando: “Esse usuário parece mais ou menos confiável?” Isso não é suficiente. Você está perguntando: “Temos evidências sólidas de que esse usuário é legítimo, apesar do fato de que algo na pilha de fraude tentou bloqueá-lo?”
Isso é um padrão mais alto. E deveria ser mesmo.
O episódio divide isso em quatro famílias lógicas úteis: usuários comprovadamente confiáveis, ambientes de alta exposição, cadeias geográficas e itens não revendíveis ou de baixo risco. Nenhuma delas deve ser copiada cegamente. Mas cada uma oferece às equipes de fraude um ponto de partida prático.
Usuários confiáveis podem transferir sua credibilidade para novas contas e eventos
A forma mais simples de exceção é a dos usuários confiáveis. Contas de longa data com histórico de comportamento limpo. Usuários que passaram por verificações de alta fricção. Pessoas em quem você tem fortes motivos para confiar.
Agora, sim, eu sei. Isso parece muito básico. “Bons usuários são bons usuários.” Que grande insight. Talvez coloque isso em um slide.
Mas a parte interessante não são as contas antigas e confiáveis. A parte interessante é o que acontece quando esses usuários aparecem em novas contas, novos países, novos fluxos ou em transações pontuais.
Às vezes, um usuário “novo” não é realmente novo. Ele é um usuário recorrente que o seu sistema ainda não conectou. Se você conseguir vincular o novo evento a um evento anterior comprovadamente bom, talvez consiga reduzir com segurança atritos desnecessários.
O exemplo mencionado no episódio é pessoal: ter várias contas do PayPal por morar em diferentes países. A jornada do usuário não é ideal, mas o requisito de conformidade faz sentido. A parte importante é que a plataforma consiga vincular a nova conta às anteriores usando sinais como dispositivo, nome e histórico de contas.
Essa é a verdadeira lição. A confiança pode ser inferida, não apenas coletada.
Uma nova conta usando o mesmo dispositivo e nome de uma conta legítima previamente verificada é um exemplo. Outras combinações podem incluir cartão mais endereço IP, e‑mail mais o mesmo item comprado ou até sinais ligados à família, como sobrenome mais geolocalização exata.
A questão não é encontrar conexões aleatórias. Conexões aleatórias são a forma como você acaba criando lógicas ruins com confiança. O objetivo é vincular um novo evento a um evento sólido, comprovadamente confiável.
Ambientes de alta exposição podem tornar a fraude menos provável
A segunda categoria é a de ambientes de alta exposição.
Fraudadores geralmente evitam ambientes onde sua identidade real, empregador, instituição ou afiliação possam ser expostos. Usuários legítimos, por outro lado, costumam realizar transações nesses locais de forma natural.
Isso gera um sinal útil de falso positivo.
Se um usuário estiver realizando transações a partir de um ambiente de rede altamente controlado ou rastreável, a probabilidade de que ele esteja cometendo fraude pode diminuir. Exemplos incluem redes corporativas, redes governamentais, faixas de IP militares, redes de IP de universidades ou grandes organizações sem fins lucrativos.
Isso não significa que toda pessoa em uma rede corporativa seja automaticamente legítima. Obviamente que não. Vamos com calma.
Mas cometer fraude a partir de um ambiente monitorado ligado ao seu empregador, escola ou instituição é arriscado de uma forma diferente. Muitos fraudadores não têm um medo especial de processos judiciais em termos abstratos. Mas serem sancionados pelo seu empregador, universidade ou organização? Isso pode ser um fator de dissuasão muito mais imediato.
A mesma lógica pode ser aplicada a destinos de envio controlados. Um pacote enviado para uma base militar, por exemplo, pode ter um perfil de risco diferente de um pacote enviado para um endereço residencial favorável a redespachantes.
Novamente, isso é contextual. Não é mágica. Mas, quando avaliados corretamente, ambientes de alta exposição podem ajudar os sistemas de exceção de fraude a identificar usuários legítimos dentro de uma população bloqueada.
O geo-chaining pode reduzir falsos positivos baseados em localização
As regras de incompatibilidade geográfica são uma fonte clássica de falsos positivos na detecção de fraude. Todo mundo conhece a lógica: o país do cartão não corresponde ao país do IP, o país de cobrança não corresponde ao país de envio, o país da conta não corresponde ao país do login. Às vezes isso detecta fraude. Às vezes bloqueia o comportamento normal das pessoas, porque elas insistem em viajar, se deslocar, usar VPNs e, de modo geral, se recusam a se comportar como linhas limpas em um banco de dados.
Muito inconveniente.
Geo-chaining é uma forma de usar dados geográficos de maneira mais inteligente. Em vez de tratar todas as divergências como suspeitas, você busca padrões geográficos contextuais que expliquem por que a divergência pode ser legítima.
O primeiro tipo é a proximidade geográfica em locais específicos. Se um endereço IP se resolver muito perto de um endereço de cobrança em Nova York, isso talvez não signifique muita coisa. Fraudadores podem encontrar proxies abertos perto de grandes cidades. Mas se o endereço de cobrança estiver em uma cidade pequena ou área rural, e o IP se resolver dentro de um raio bem limitado, isso pode ser um indicador mais forte de bom usuário. É mais difícil falsificar uma proximidade geográfica obscura do que uma proximidade genérica em grandes cidades.
O segundo tipo é a inconsistência que ainda é coerente com a nacionalidade. O episódio traz outro exemplo pessoal: usar um cartão espanhol em Israel e ser bloqueado por causa de uma divergência entre o BIN espanhol e o IP israelense. Mas, se o nome parecer israelense e o IP for israelense, esse contexto importa. Um fraudador com um cartão espanhol provavelmente usaria simplesmente um IP espanhol. Não há nenhum motivo óbvio para criar um padrão excessivamente complexo de cartão espanhol, nome israelense e IP israelense.
Esse é o valor do geo-chaining. Ele encontra correlações sutis e contextuais que podem explicar comportamentos legítimos. Quando usado com cuidado, pode reverter falsos positivos baseados em geolocalização sem introduzir risco de fraude desnecessário.
Itens não revendíveis podem contribuir para aprovações de fraude em pagamentos mais seguras
A quarta família se aplica principalmente a fraudes de pagamento: itens não revendíveis ou de baixo risco.
Os fraudadores geralmente não roubam mercadorias porque querem o item para si. Eles roubam porque podem revendê-las. Esse é o modelo econômico. Se o item não tiver mercado de revenda, ou tiver apenas um mercado fraco, recusá-lo por risco de fraude às vezes pode ser contraproducente.
Exemplos incluem produtos e serviços educacionais, itens de nicho ou hiperpersonalizados, presentes de família personalizados, sessões de terapia, treino pessoal ou outros serviços que exigem consumo pessoal.
Isso é basicamente o oposto do motivo pelo qual consideramos eletrônicos, peças de automóveis ou cartões-presente arriscados. Esses itens são fáceis de revender. Uma caneca personalizada de família com o cachorro de alguém estampado? Bem menos interessante para uma quadrilha de fraude organizada. Quer dizer, provavelmente.
Em um sistema de substituição de decisões antifraude bem projetado, um baixo valor de revenda pode se tornar parte da lógica de aprovação. Não como um motivo isolado para aprovar tudo, mas como um sinal de apoio que ajuda o sistema a reconhecer transações que os fraudadores provavelmente não vão querer.
Essa distinção é importante. A lógica de itens de baixo risco deve apoiar a exceção, não sustentá-la sozinha.
A implementação segura é tão importante quanto a lógica
A parte final do episódio é sobre implantação, porque é aqui que boas ideias podem se transformar em incidentes graves.
Você não ativa a lógica de substituição de fraude para 100% do tráfego no primeiro dia. Você a testa. Com cuidado.
Uma implementação mais segura começa com testes em modo sombra. Execute a lógica de substituição sem permitir que ela afete as decisões. Meça se ela atinge a população que você esperava. Analise os casos. Compare os resultados com a sua análise.
Depois, você pode introduzir uma regra desafiadora para reverter uma pequena parte das recusas, enquanto o restante permanece em modo sombra. A transcrição usa 20% como exemplo, mas o número exato depende do seu apetite de risco e do contexto do negócio.
Em seguida, você acompanha os resultados por 30 a 60 dias, ou pelo tempo necessário para entender como a fraude evolui na população que você deixou passar. Se os resultados forem bons, aumente gradualmente. Se forem inconclusivos, espere. Se a fraude disparar, volte para 100% de modo sombra e repense a lógica.
Esse aumento gradual e cauteloso também pode revelar quais soluções de detecção de fraude nunca devem ser substituídas. Se a maior parte das fraudes que passam pelo override vier de um pequeno conjunto de regras ou modelos, essas soluções podem pertencer à categoria de “não sobrescrever”.
E se você chegar ao ponto de criar exceções para as suas exceções, parabéns. Você ou está liderando o grupo ou está muito cansado. Possivelmente ambos.
Conclusão final:
A lógica de substituição de fraude é poderosa porque reconhece algo importante: falsos positivos nem sempre são causados por uma única regra ruim. Às vezes, eles são causados por um sistema em que componentes razoáveis demais interagem de maneiras irracionais.
Uma camada de override em alto nível pode ajudar equipes de fraude maduras a aprovar usuários em quem já têm fortes motivos para confiar. Mas isso só funciona se a lógica for precisa, os sinais forem irrefutáveis e o lançamento for controlado.
Usuários confiáveis, ambientes de alta exposição, geoencadeamento e itens de baixo risco podem ajudar a reduzir falsos positivos. Testes em modo sombra e implantação gradual ajudam a garantir que você não resolva um problema de falsos positivos criando um problema de fraude.
Enfim, esse é o equilíbrio. Construa a rede de segurança, mas não finja que a gravidade deixou de existir.
Estou a ser cauteloso demais? Talvez.
Mas em sistemas de fraude, ser cauteloso costuma envelhecer melhor do que ser esperto.
Conecte-se com Chen Zamir | LinkedIn
Apresentador de The Saturday Fraud Strategist
Ajudando fintechs a construir defesas contra fraudes mais inteligentes
Coautor de “The Fraud Fighter’s AI Playbook”
Ainda não está pronto para encerrar a conversa sobre o meu e, espero, o seu assunto favorito? Assine a newsletter The Saturday Fraud Strategist.
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
