--- title: AI Made Building Cheap. What Are Fraud Vendors Still For? source_page: https://www.sardine.ai/media/the-saturday-fraud-strategist/episodes/building-vs-buying-fraud-vendors canonical: https://www.sardine.ai/media/the-saturday-fraud-strategist/episodes/building-vs-buying-fraud-vendors format: text/markdown date: 2026-10-31T01:01:00.000Z description: Building vs buying fraud vendors is no longer a yes or no question. Mapping what to build, what to buy, and what vendors still do best… --- **Quick links:** [Human page](https://www.sardine.ai/media/the-saturday-fraud-strategist/episodes/building-vs-buying-fraud-vendors) · [Home](https://www.sardine.ai) · [Customers](https://www.sardine.ai/customers) · [Blog](https://www.sardine.ai/blog) · [Demo](https://www.sardine.ai/demo) --- # AI Made Building Cheap. What Are Fraud Vendors Still For? **Published:** 2026-10-31T01:01:00.000Z Building vs buying fraud vendors is no longer a yes or no question. Mapping what to build, what to buy, and what vendors still do best… 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 relationship Why the most successful in-house builds so far are small tools that save one expert time and don’t replace a whole platform How vendors are shifting from end-to-end solutions toward data providers, with network data and device intelligence valued most by larger teams Why manual review viewers are easy to build with AI coding, and why a rule engine is a very different kind of project How AI slop shows up in risk teams, from dozens of models built overnight to latency and drift monitoring problems nobody planned for What foundation models and decision models change about features, anomaly detection, and who can deploy a real-time fraud model Why segmentation is the best place to start, and why building generic capabilities like KYC or sanction screening is a trap How to judge whether your organization is ready to build, including engineering support, access to risk talent, and leadership buy-in Why the maintenance trap catches analysts who become product manager, DevOps engineer, and backend engineer at once You should listen to this episode if you: Lead a fraud or risk team and are deciding what to build and what to keep buying Feel vendor fatigue and want a clearer way to think about which relationships still earn their place Have built something in house with AI and want to know whether it can scale Need to explain to leadership what a build roadmap requires beyond a quick proof of concept Want to know how foundation models and decision models may change the feature layer and vendor data ### Episode notes & key takeaways Vendor fatigue is pushing teams to build Netanel hears the same thing from teams across the industry. Everyone feels pressure to build, and that pressure started well before AI models were good enough to do the work. Now they are, and vendor fatigue has met real capability. The most successful builds he has seen are small, like a strong team member creating a tool that cuts the handling time of a task. For years, vendors offered a complete package of a decision, a guarantee, or a score, because teams lacked the expertise and bandwidth to use anything else. Today teams say they can handle something more granular and want pieces they can customize. My view is that vendors will increasingly be seen as data providers, and the heavy real-time engineering will still sit with them. The relationship is changing, and it will look different in each industry. Viewers are easy to build and rule engines are not Netanel separates viewers from actionable products. Manual review cockpits are the easy part, because AI coding makes them simple to customize and teams are tired of waiting for a vendor to prioritize a change. A rule engine is a different job. It is backend engineering that needs real-time performance, high availability, efficient data access, and testing and simulation. At Simplex, a Python rule engine built from the start let the team switch between strategies automatically. Most teams begin with manual analytical work, like pulling data from several sources to review a payment, and few want to replace a vendor’s algorithm outright. He also named a risk I recognize, AI slop. A team facing a new fraud problem can release 20 models overnight, and then latency and drift monitoring become problems nobody planned for. Foundation models change the feature layer and not the whole job I asked Netanel whether foundation models threaten vendors, because they replace the handcrafted feature layer where vendors built their edge. He believes standard LLMs have already taken over much of that work. Ask one which features to derive from a data set, and he estimates you get about 80% of what a team of specialists would produce. He sees the real value of foundation models in advanced anomaly detection. I added that the strongest results I have seen involve a known entity with history. The bigger change may be semi-deterministic decision models, which are forced to reach a decision and use an LLM for judgment. They raise the value of external data, network data, and feature stores. His chef analogy stayed with me. Having the ingredients isn’t the same as knowing what to do when the dish boils early, or when an attack wasn’t in the simulation. Build where your segments are underserved Netanel’s first piece of advice is to think about segmentation. New and returning users, geographies, products, and payment methods behave very differently. Look for pockets that underperform or have weak economics, and try something there, whether that is another vendor, AI, a custom solution, or a new hire. I would add that this is where building pays off most. A bigger business likely has a segment unique to it that no vendor will solve. Stolen cards are not that segment, and neither are sanction screening or KYC. Spending your time there is the trap. His second piece of advice is to ask how central risk is to your business. Then look at your roadmap from the last six to twelve months and count what was delayed because the risk setup made it too hard. If you build, think in atomic units of the decision, and decide whether to produce or buy each one. Readiness and the maintenance trap Netanel said most risk leaders trust their teams highly, and that can be a blind spot. He advises looking at the organization. Does it have the engineering capability, will the C level support a project that costs more before it pays back, and can you keep finding risk talent? I added the part teams miss most. Building is the easy part and maintenance is where it breaks down. An analyst can end up as the product manager, DevOps engineer, backend engineer, and UX engineer for their own tool. They don’t stop being an analyst. They stop maintaining the project. Getting leadership buy-in takes a different skill set than building a proof of concept in two days, and the build trap doesn’t skip risk teams. ### Final takeaway Building vs buying fraud vendors is not a question with a yes or no answer. It is a question about which pieces of your decisioning stack you need to own and which you are better off buying. The teams that do this well will start with their segments, count the cost of maintaining what they build, and get leadership aligned before the first line of code. We ended with more question marks than exclamation points, and I think that is right for a topic that is still moving this fast. Resources & links Not ready to stop the conversation about my, and hopefully your, favorite subject? Subscribe to The Saturday Fraud Strategist newsletter. Connect with Netanel Kabala | LinkedIn Co-Founder at Duly Connect with Chen Zamir | LinkedIn Host of The Saturday Fraud Strategist Helping fintechs build smarter fraud defenses Co-author of “The Fraud Fighter’s AI Playbook”