What is AI fraud detection?

AI fraud detection is the use of machine learning or AI agents to decide whether an account, transaction, listing, or piece of content is fraudulent. The current generation differs from earlier systems in what it returns. A classifier hands back a probability score. An agent runs an investigation: it pulls records from internal and external sources, checks them against the company's own written compliance procedure, and returns a decision with the evidence attached. Variance, which sells agents for this work, describes the change as an industry shifting from scoring to investigating. The practical difference is that the output becomes usable by a compliance team and an auditor rather than only by another model.

Is AI fraud detection better than rules and classifiers?

The advantage is speed of adaptation more than raw accuracy. A traditional stack combines deterministic rules, trained classifiers, and human analysts, and each of those adapts on its own timescale: a rule needs someone to write it, a classifier needs labels and a retrain, an analyst needs to read and judge. Fraud is adversarial, so the attacker iterates faster than the slowest step in that chain. An agent can perform all three roles from one place, which collapses the loop from weeks to the time it takes to edit a procedure document.

Can AI agents fully replace human fraud analysts?

No, and the teams doing this well design for that. At Variance, agents triage roughly 99 percent of cases and the remaining 1 percent goes to a person. That residual is not a random sample, it is the most complex work in the queue, so the human reviewing it needs a strong investigative interface. Automating most of a queue does not remove the need for a review tool, it raises the requirement on it.

What do you need to build an AI fraud detection agent?

Variance co-founder and CEO Karine Mellata describes three building blocks: the compliance documents and standard operating procedures that define what must be verified, the tools the agent can call, and the data it reasons over, both internal and external. A custom model is not on the list. The hard engineering is in reaching the data, which in a real company is typically spread across five to 10 systems with no shared schema, and in encoding the procedure faithfully.

AI Fraud Detection: Build the Feedback Loop

Search for AI fraud detection and page one is a wall of vendor explainers. Machine learning spots anomalies faster than humans, they say, and it adapts to new patterns. Both true, and neither tells a founder what to build, what to remove, or why the fraud stack most companies run today cannot keep pace with the people attacking it.

A better answer came out of stealth in March 2026. Variance announced a Series A of $21.5 million led by Ten Eleven Ventures after roughly three years of building quietly. Quietly rather than invisibly, to be precise: the company shipped publicly under an earlier name, Intrinsic, and raised a seed round in that form. What it kept out of view was its customer list and the abuse patterns it was built to catch. Its agents review fundraisers on GoFundMe, verify identities for marketplaces and gig platforms, and run know-your-customer and know-your-business checks for Fortune 500s and financial institutions. If you have ever started a fundraiser or signed up to drive for a delivery app, software from a company of twelve people probably approved you without you ever hearing its name.

Co-founder and CEO Karine Mellata laid out the architecture in a Y Combinator Founder Fireside interview with YC Managing Partner Jared Friedman. The useful part is not the claim that agents beat classifiers. It is the reason, which is an argument about feedback loops rather than about model quality.

The stack AI fraud detection has to replace

Before large language models, a company defending itself at scale ran three kinds of node. Mellata and CTO Michael Lin met on Apple's fraud engineering, algorithms, and risk team, where she was a data engineer and he was a machine learning engineer, and his model decisions reached the rest of the company through her streaming jobs.

Rules. Deterministic thresholds of the form "if this transaction is over a thousand dollars, then do this." Fast, legible, brittle. Every rule is also a description of what you will not catch.
Classifiers. Trained models, each one good at detecting "one specific flavor of abuse." Accurate in their lane, blind outside it, and slow to retrain.
Humans. Analysts who, as she puts it, "are really good at understanding in context all of these different nodes and signals and then making a final decision." Also the slowest and least consistent element in the system.

None of that is wrong on its own. The problem is what the combination does to your response time.

The feedback loop is the product

Here is the argument worth the read. "The most important feature of a fraud system is that it needs to evolve really rapidly," Mellata says, and it needs a tight feedback loop. Fraud is not a static classification problem, it is a contest: "fraud is the most dynamic environment cuz you always have adversaries."

Put those two facts together and the conclusion is unforgiving. Your loop is only as fast as its slowest node. A rule needs a person to notice a pattern and write it. A classifier needs labels, a training run, and a deploy. An analyst needs to read, judge, and hand off. Each one is a queue, and stacking them means your defense adapts over weeks while your adversary iterates daily.

That is why the two founders were, in her words, "always really, really, really stubborn about making this system have no nodes that were inefficient." They were not optimizing for accuracy. They were optimizing for loop latency. In the old architecture she had never seen a way that "you could achieve a self-healing system that could thrive in a dynamic environment."

An agent collapses all three nodes into one. It can materialize the features a rules engine would compute. It can read a standard operating procedure and reason over an image or a blob of unstructured text well enough to conclude that something looks like chargeback fraud, with no classifier trained for chargeback fraud. And it can do the contextual judgment that used to require an analyst. One node, one loop, and the loop closes in the time it takes to edit a document.

Variance's funding announcement describes the industry as "shifting from scoring to investigating," and that phrase is worth borrowing even though it comes from a company selling the thing. The distinction underneath it is concrete. A score is a number a compliance officer still has to interpret and then defend to somebody else. An investigation arrives with the registration documents it pulled, the ownership chain it traced, the adverse media it surfaced, and a recommended action attached. One of those is a starting point for work. The other is a case file a person can sign their name to.

Three building blocks, not a model

Founders overestimate the model and underestimate the scaffolding. Mellata's decomposition is refreshingly boring: "There's really only three building blocks that you need."

The compliance documents. The standard operating procedures, meaning what the company has decided must be verified at onboarding and at every later point in an entity's life. This is the spec, it is written in plain English, and it is the part that used to be untranslatable into code. Their first customer's marketing rules included constraints like "You can't give advice for legal defense," which is a policy no regular expression expresses, which is exactly why a large outsourced human team was doing the work.
Tools. The actions the agent is allowed to take.
Data. Internal and external.

"Those are the only building blocks you need to automate complex KYC, complex KYB, complex content review," she says. Notice what is absent: a bespoke model. The differentiation sits in the procedure encoding and the data reach, not in the weights. If you are building here, that is where the engineering should go, and it is the same lesson as context engineering for AI agents: what you assemble around the model decides the outcome more than which model you call.

Your hard problem is data access, not reasoning

Ask a founder what is hard about an AI fraud product and most will say accuracy. Mellata says data. Getting it in was "really the core hardest technical challenge."

Look at the shape of one decision. To adjudicate a single fundraiser you need the user's identity record, their login and device history, the personal information they submitted at onboarding, the associated business record, the fundraiser itself, and that fundraiser's full history. In a real company that material is "scattered across five to 10 different systems," in different stores, with no shared schema, and much of it unstructured.

Then it gets worse, because some of it has no API at all. It lives behind a screen built for a person. Variance's answer is the one nobody puts in a pitch deck: spin up a browser, open the old review tool, and "directly scrape from a UI that was built for a human." Friedman's reading of it in the interview is the right one, and Mellata agreed with it: the work was already being done by a human at that dashboard, so the agent can use the same dashboard.

The last piece is the open web, which she describes as one of the last things standing in the way: "access to the web was one of the final nodes that made this whole problem really hard to automate." A human analyst's real job was to search a name, read what came back, and apply judgment. Strip that out and an agent cannot trace the graph of connections that turns a set of unrelated accounts into a detected ring.

Build the console for the last 1 percent

This is the most valuable admission in the interview, and it generalizes well past fraud.

The founders started out convinced they were building a pure decisioning layer. Get the decisions right, the thinking went, and the product could be consumed as an API call. "We were not right about that."

What actually happened is that the agents absorbed the easy volume. They triage roughly 99 percent of cases. The 1 percent left over is not a random 1 percent, it is the most complex 1 percent, and it goes to a person. That person needs a genuinely good investigative interface to make sense of it. So the front end, which the founders had not expected to matter much, turned out to be a core part of the product, and it is now something they hire for.

Generalize the lesson: when agents take the routine work, the remaining human work gets harder, not easier. Automating most of a queue does not remove the interface requirement, it raises it. If you sell service as software, the escalation console is not an accessory. It is where your buyer forms their opinion of whether you are trustworthy.

Five engineers, and what that says about leverage

Variance is twelve people with five software engineers, processing petabytes of data and making automated decisions for some of the largest companies in the world. Mellata's own estimate of the gap: "I would say we're five, but I think in terms of software output, we're probably closer to a 25-people team."

The mechanics are mundane and worth copying. "Every engineer is going to have three monitors with their coding agents running." Oversight did not disappear: "We still review all of the PRs." And the customer success manager, who is not technical, now takes simple enterprise feature requests directly to a Cursor agent, ships them, and replies to the customer a few hours later without routing through the engineering team.

That is the revenue per employee argument playing out in one company. Note the ordering, though, because it matters. The agents multiply a team that already had unusual depth, including an engineer who by Mellata's account understands evaluations for large language models better than anyone else there. Coding agents raise the ceiling on strong engineers. They do not manufacture judgment, which is exactly why building real evals is the discipline that makes the rest of it safe to ship.

What a security-minded founder should notice

Two things stand out if you read this as a security problem rather than a product one.

The first is a go-to-market constraint most founders discover too late. Variance kept its customers and their abuse patterns out of public view for three years in part because describing them is free training material for the attackers. "We're building the systems that are often used by the bad guys, but we're building them for the good guys," Mellata says. If you sell into trust and safety, your best case studies are the ones you can never publish, and your customers actively prefer that you stay obscure. Plan the go-to-market around that rather than being surprised by it.

The second is that the stakes are concrete. During an election period, Variance's agents detected coordinated fraud rings including state-sponsored actors pushing a single narrative, which Mellata says was only possible because the agents could reason about each entity in relation to all the others rather than scoring one piece of content after another. Some investigations surface people planning physical harm at scale, and those end up with law enforcement.

Both point the same direction: build auditability in from the beginning instead of bolting it on. A probability score is not evidence. An investigation with its sources attached is. That is the standard any regulated buyer applies to AI, and it is why the products that win in this category look less like models and more like case files. It is also a good reminder that most of the AI decisions a startup makes are architecture decisions wearing a model's clothes.

Pick a problem that is already on fire

One more transferable lesson. Variance went enterprise from day one, which is the hard way to start, and their first customer was the publicly traded holding company IAC, working with its Ask Media Group on marketing content review. Friedman notes in the interview that landing it took eight months.

Mellata's rule for why it was winnable at all is the sharpest sales advice in the episode. The problem had to be urgent, because if it was not, nobody would take the risk: it "needed to be on fire because what we found is that if it wasn't on fire, then there was no reason to go and trust this really small startup that had no real proof points behind them."

That is the enterprise wedge in one sentence. A small startup does not win on credibility, it wins on urgency. If the buyer's pain is merely annoying, your lack of proof points decides the deal. If their pain is blocking growth, as it was here, where a slow human review team was capping how much marketing content the company could publish, they will take a chance on two engineers with a working pilot.

What to do this week

Time your loop. Take the last real change in attack pattern you saw and measure how many days passed between detection and a shipped countermeasure. That number, not your model's accuracy, is what your adversary is actually competing against.
Find the slowest node. Write down every step between a signal arriving and a policy changing. Rules, retrains, analyst queues, deploys. The longest one sets your ceiling, so fix that before you touch anything else.
Write the procedure down in plain English. If your review policy lives in analysts' heads, you have nothing for an agent to execute and no consistency to audit. Getting the standard operating procedure written is useful even if you never automate it.
Inventory where the evidence lives. List the systems holding the data needed for one decision. If it is five to 10 places and some of it is only reachable through a screen, that is your real roadmap, not the model choice.
Design the escalation console early. Assume agents handle the routine cases and a person handles the hard residue. Build the tool that person needs before you need it.
Check what you can legally and safely say. If your product describes how abuse works, decide now what goes in public case studies and what never does.

If you want the wider version of this, where fraud review is one workflow among many that agents are quietly taking over inside startups, that is what I teach in AI Operating System for Startups.

Sources

This Startup Catches Fraud at Scale on Y Combinator's Founder Firesides, the interview this article distills: YC Managing Partner Jared Friedman in conversation with Variance co-founder and CEO Karine Mellata.
Variance Raises $21.5M Series A to Transform Risk Workflows with AI Agents, the company's announcement on BusinessWire, for the round size and lead investor, and for the scoring-to-investigating framing quoted above. Additional coverage: SecurityWeek. A note on the number, since the company published two: its own blog post is titled "Announcing our $21M Series A" and the interview says $21 million, while the BusinessWire release issued the same day and the press coverage that followed all say $21.5 million. This article uses $21.5 million.
Variance on Y Combinator for the batch (Winter 2023) and company description, and variance.com for the product. The same page records the company's earlier life as Intrinsic, including a seed round announced in January 2024, which is why this article says the founders built quietly rather than in total stealth.
Founder backgrounds and current roles from their LinkedIn profiles: Karine Mellata (co-founder and CEO) and Michael Lin (co-founder and CTO). Both worked on trust and safety machine learning and data engineering at Apple, where they met on the fraud engineering, algorithms, and risk team.
Cross-source from our video knowledge base: The Most AI-Pilled CEO We Know, where Brex describes rebuilding its KYC process around AI rather than automating pieces of the old one, the same redesign-versus-bolt-on choice this article argues for.