The Saturday Fraud Strategist

Foundation models in fraud are on every conference agenda this year, and I keep hearing the same question. Is this the real thing or the next buzzword? When I landed at Money20/20 Vegas, I wanted to ask someone who builds with them every day.Pedro Sanzovo works on identity and fraud products, and has been in fraud his whole career. He started at Palantir, built a fraud company for merchants in Brazil, and sold it to Signifyd, where he led product work on machine learning models. Six months ago he joined Plaid.We kept this one short and practical. What is a foundation model, and how is it different from the models most of us run today? Where does it beat XGBoost, and where does it hit the same walls? And what do you do with an embedding when your team writes rules? Pedro had some good answers, and a few things I think you’ll want to hear.What you’ll hear in this episode:What a foundation model is, and how transformer models differ from the chained rules and XGBoost models fraud teams have used for yearsWhy legacy models depend on handcrafted features and clean supervised labels, and why that is hard for smaller companiesHow financial data foundation models treat transactions as a sequence of events and predict what comes nextWhat Pedro means by the precision uplift of up to 34% he is seeing, and why data quality still decides the outcomeWhy latency constraints, such as 300 milliseconds for card transactions, shape which model belongs whereHow foundation model explainability compares with XGBoost, and why credit and fraud face different expectationsWhy embeddings are hard to turn into rules, and how AI agents might helpYou should listen to this episode if you:Lead or work with a fraud data science team and are deciding whether to explore foundation modelsRun a smaller fraud team and struggle with labeling and feature engineeringWant a plain explanation of how foundation models differ from XGBoostNeed to weigh precision gains against latency and explainabilityAre curious how embeddings and AI agents could work together to produce fraud rules

There has always been an arms race in the vendor space, and this year it has been about AI. At the same time, the practitioners I talk with are building far more than they used to. A few weeks ago I spoke with a risk leader who described what her team built in house, and it was impressive. That made me wonder whether the ground is shifting beneath vendors, and whether we will still need them in a year or two.I invited Netanel Kabala to help me think it through. Netanel and I met at PayPal 17 years ago, when he started as a fraud analyst after the acquisition of PayPal’s Tel Aviv fraud sciences team. He later co-founded Simplex, the first crypto on-ramp provider, led AI and analytics at Nuvei after the acquisition, and recently co-founded Duly, which helps payment providers and fintechs own their decisioning stack. We look at building vs buying fraud vendors from several angles, including vendor fatigue, what teams build first, and what foundation models and decision models change. We don’t land on a yes or no answer, and I think that’s the honest result. Instead, we sketch where to build, where to buy, and where joint development makes sense.What you’ll hear in this episode:Why vendor fatigue is pushing teams to build, and what that means for the vendor relationshipWhy the most successful in-house builds so far are small tools that save one expert time and don’t replace a whole platformHow vendors are shifting from end-to-end solutions toward data providers, with network data and device intelligence valued most by larger teamsWhy manual review viewers are easy to build with AI coding, and why a rule engine is a very different kind of projectHow AI slop shows up in risk teams, from dozens of models built overnight to latency and drift monitoring problems nobody planned forWhat foundation models and decision models change about features, anomaly detection, and who can deploy a real-time fraud modelWhy segmentation is the best place to start, and why building generic capabilities like KYC or sanction screening is a trapHow to judge whether your organization is ready to build, including engineering support, access to risk talent, and leadership buy-inWhy the maintenance trap catches analysts who become product manager, DevOps engineer, and backend engineer at onceYou should listen to this episode if you:Lead a fraud or risk team and are deciding what to build and what to keep buyingFeel vendor fatigue and want a clearer way to think about which relationships still earn their placeHave built something in house with AI and want to know whether it can scaleNeed to explain to leadership what a build roadmap requires beyond a quick proof of conceptWant to know how foundation models and decision models may change the feature layer and vendor data

For a couple of years now, Jaanus Uudmäe’s LinkedIn posts have kept showing up in my feed, and they always carry a practical take on what fraud looks like at Bolt. Bolt is an on-demand marketplace headquartered in Estonia that operates in more than 50 countries, with ride hailing, food delivery, scooters, e-bikes, and car rentals. That means his team sees almost every kind of customer and almost every kind of abuse. Jaanus started as a software developer at Skype in 2007 and landed on the fraud team by accident. He joined Bolt in 2017 as a hands-on analyst when the fraud team had two people, and today he has 14 reporting to him.In this conversation, we spend most of our time in what I’d call the gray zone. Gray zone fraud is behavior where you can’t tell whether you’re looking at a fraudster, a frustrated customer, or an ordinary person who tried a trick a friend told them about. We talk about refund abuse and bonus abuse, why first time customers are the hardest to judge, and how to build labels when no one hands them to you. We also get into how to explain losses to the business when the numbers aren’t clean, and how Jaanus’s team uses AI in a way that surprised me.What you’ll hear in this episode:How Jaanus went from a software developer at Skype to leading a 14 person fraud team at BoltWhy marketplace fraud prevention gets harder in a three sided marketplace with riders, drivers, restaurants, and couriersWhat gray zone first party fraud looks like in practice, from refund abuse to bonus abuseWhy first time customer fraud is the hardest call, and how Bolt decides when to act and when to fall back on standard policyThe difference between opportunistic vs professional fraud, and why opportunistic customers make A/B testing unreliableHow fraud label manufacturing works when nobody hands you the answers, and how to avoid recursive fraud labelingWhy label maturity matters, and which proxy metrics keep a team honestHow Bolt thinks about fraud risk appetite and fraud expansion cost when entering a new marketHow AI works as a context layer for analysts, and why the fraud analyst mindset still mattersYou should listen to this episode if you:Deal with refund abuse or bonus abuse and can’t prove intentWork at a marketplace or on-demand platform with more than two sidesAre launching in a new market and need a way to talk about fraud losses with the businessCreate your own fraud labels and worry about fooling yourselfWant to see how a technical fraud team uses AI for analysis without removing human judgment

We talk about fraud rules all the time, but I rarely hear anyone ask what we actually mean by the word. What are rules for, who should write them, and how often should they be reviewed? Over the course of my career, I've found that fraud rule types fall into three distinct categories, and most teams manage all of them the same way. That habit quietly costs a lot. Teams end up over-monitoring some rules, under-monitoring others, handing ownership to the wrong people, and expecting rules to perform in ways they were never designed for.In this episode, I walk through strategy rules, behavioral rules, and trend rules, and explain how each one is written, measured, and owned. If you manage a rule engine, or you're responsible for how a fraud team spends its time, this is a practical way to organize that work.What you'll hear in this episode:Why the three fraud rule types need different monitoring cadences, different owners, and different success criteriaHow ML score fraud rules and threshold fraud rules segment your population into approve, decline, and step-up groupsWhy changing one threshold in a strategy ruleset often means adjusting the others, and why those rules should be measured as a setHow behavioral rules fraud teams write, including velocity rules fraud examples, can catch several rings with the same MO without overfitting to one attackWhat compound fraud rules look like in practice, including a device fingerprint fraud rules example that combines email risk, a new device, and a country mismatchWhy trend rules are your fastest and most accurate tool at first, and why they degrade so quicklyHow the fraud rule lifecycle should work, with narrow rules acting as a stopgap while stronger defenses take overWhat goes wrong with fraud rule prioritization when every rule gets the same attentionYou should listen to this episode if you:Manage a rule engine and want a clear framework for how to write fraud rules that fit their purposeAre building or restructuring a fraud team and need to decide which team should own which rulesWant to improve fraud rule deployment by tying strategy rules to your model release processKeep adding narrow rules to stop attacks and are worried about the false positives piling upRely on a vendor model and need to know what to ask them for when setting thresholds

A few weeks ago I walked through the framework for the AI transformation journey. This conversation with Lalitha Rao, Chief Risk Officer at Imprint, is the natural next step. It is a real, in-the-field look at what it actually takes when a team commits to scaling agentic AI past the theory stage.In the nine months since her risk team started building out their agentic AI infrastructure in earnest, they’ve grown their loan book by 150%, increased revenue by 2.5x, and actually lowered loss rates on newer cohorts. All without cutting a single headcount. Lalitha’s team didn’t treat this as a cost-cutting exercise, they treated it as a way to create more value for Imprint's members and partners. And the results speak for themselves.If you’re further along in your own AI transformation journey and want a real example of what scaling agentic AI actually looks like once the framework meets the field, this is the conversation.What you'll hear in this episode:Why Imprint's centralized AI platform, built by their CTO's team, turned out to matter more than any individual agent they've builtHow ARIA, an autonomous credit policy agent, scours bureau and internal data to find early signs of portfolio deterioration and pushes the efficient frontier outward instead of just optimizing itWhy agentic AI unlocked something a SQL query or a standalone model couldn't, digesting multiple data sources in different formats into one coherent, repeatable workflowHow a residual mining agent continuously finds model errors, builds new features, and retrains models using out-of-time testing to guard against overfittingWhy Imprint never measured success by headcount reduction, and what they built instead with the team's freed-up timeInside Project Shield, a suite of ten fraud agents that runs for six hours, costs about $300 in tokens, and saves hundreds of thousands of dollars in fraud lossesHow a shared skills repository and clear data ownership let a non-engineering risk team build and maintain production-grade agentsLalitha's honest build versus buy framework, and the specific vendors, including Sardine, LexisNexis, and Proof, Imprint still relies onThe real hiccups Imprint hit along the way, bloated proposals, false certainty in AI-generated reviews, and how they built guardrails to fix bothYou should listen to this episode if you:Are further along in the AI transformation journey and want a concrete look at what scaling actually requires beyond the initial frameworkLead a risk, fraud, or credit team and are trying to decide which agentic AI use cases to prioritize firstAre weighing build versus buy decisions for AI agents and want a clear mental model for where proprietary data changes the calculusWorry that scaling AI means shrinking your team, and want to hear a real counterexampleWant practical detail on how to actually enable non-engineers to build and maintain production-grade AI agents