Scaling the Analyst Team Doesn't Scale

The Conversation That Repeats

Every time I hear how a growing fraud team operates, the conversation is the same. "We have a review backlog, we're going to hire two more analysts." "The team is saturated, we need a junior analyst." "False positives are growing, we need to expand QA."

It makes sense. More transactions, more cases, hire more people.

But there's a ceiling, and almost every team finds it late.

How Fraud Scales, How the Team Scales

Your company's transaction volume grows — if things go well — exponentially, or at least strongly linearly. Fraud grows at the same pace or worse: attackers find you more easily when you're bigger.

Your analyst team, meanwhile, grows by one person per quarter, if budget allows.

The gap between problem growth and team capacity is what eventually breaks the operation. The math doesn't add up, and it's not something you fix by asking the team for more.

A Normal Day for a Fraud Analyst

Let's do the honest exercise. Here's what the day actually looks like — not in a product brochure, but in a real operation:

• 9:00am. Arrives and takes the "temperature" of yesterday's operation.
• 9:15am. Opens Excel, connects to the client's database, runs hand-written SQL queries, exports thousands of records to a local file.
• 9:30am. Applies manual filters in Excel to find the weird stuff: score > 80 AND decision = ACCEPT (possible false positives), score < 20 AND REJECT (over-restrictive rules), the same BIN repeated several times within an hour, emails from suspicious domains (tempmail, mailinator), customers with too many transactions in a short window.
• 10:00am. Marks suspicious cases with cell color or by copying to a "TO_REVIEW" sheet. Takes notes in their head, or in free Excel cells.
• 10:30am to 1pm. Investigates each case across five tools in parallel: KPI dashboard, graph view, individual transaction view, client database, Slack with teammates. Recently added a sixth: pasting Excel chunks into ChatGPT or Claude, hoping the model spots the pattern. But the file has thousands of rows, the model's context fits only small blocks, every round-trip is paid in tokens, and each response takes minutes. By the time they finish processing a fraction of the file, the afternoon is already gone.
• 2pm to 3pm. Takes actions: creates a rule, adds to blacklist, communicates with the client, leaves a mental note for follow-up.
• Next day. Goes back to Excel and tries to remember where they left off. Cases lose tracking.

That's the analyst's day in most operations I know.

Where the Time Goes

If you break the day down by block, it looks like this:

75% of the analyst's day happens outside the fraud product. The product the client paid for covers the remaining 25%.

What Breaks in That Flow

It's not just an efficiency problem. It's an operational quality problem. What breaks, every day, silently:

• Lost tracking between days. Monday's "for tomorrow" case gets forgotten; the analyst doesn't remember why they flagged it.
• No audit trail. When the client asks "why didn't you catch this fraud?", there's no way to show what was reviewed, when, by whom, and what was decided.
• Stale data. The analysis is from the previous day. If there's an attack in progress, it's detected 24 hours late — the damage already happened.
• Forced trade-offs under pressure. When an attack is in progress at the same time as routine operation still needs validation, the analyst has to pick which one to watch. The one that waits rarely waits for free.
• No protected focus time. To concentrate on either mode, the analyst has to block their calendar and close Slack. If someone interrupts, the context is lost and the next stretch goes into rebuilding where they were.
• Duplicate work. Two analysts look at the same case without knowing.
• Cases with no natural grouping. An attack of 1,000 transactions against 1,000 ad-hoc customers looks like 1,000 separate rows in Excel, not a pattern.
• Outliers slipping through unreviewed. If the analyst forgets the score > 80 AND ACCEPT filter one day, those cases don't get reviewed. Nothing surfaces them.
• No automatic follow-up. The "monitor for 1 week" case depends on the analyst remembering and going back to the right Excel.
• No link to chargebacks. A chargeback arrives and there's no fast way to know "this belonged to a case we validated as OK three weeks ago — the decision failed."
• Overrides without ex-post validation. The analyst ACCEPTs with a high score, and that override isn't validated later. If it was human error, no one finds out until the chargeback hits.

Each of those points is lost money, regulatory risk, or a false sense of control.

The Analyst Is Doing the System's Job

Here's the part almost no one audits.

The fraud analyst's real value is in judgment: investigating rings, reading patterns, deciding under ambiguity. It's what the machine can't do on its own, and it's exactly why they're on the team.

But 75% of the day goes into writing queries, exporting to Excel, filtering columns, copying IDs between tabs, remembering by hand where they left off yesterday.

That's not fraud work. It's work the system should be doing, and it gets pushed onto the analyst because the product wasn't designed to do it.

The result: the most capable person on the team — the one with the trained eye for what the rule doesn't codify — spends most of the day assembling the data the product doesn't deliver.

When the System Absorbs the 75%

The question changes the day the system stops pushing work onto the analyst and starts pushing decisions instead.

The day stops starting with queries and filters. It starts with cases. Everything else — how they get prioritized, enriched, closed, tracked over time — is engineering the product has to absorb, not the fraud team.

When that happens, the analyst goes back to their actual territory: reading a network of connected accounts, spotting the new pattern before the model learns it, deciding under ambiguity what no rule can encode in advance. That's the part of the work where their fraud experience really pays off, and the only part the product can't automate.

It's not an upgrade to the Excel. It's a different way of operating.

When an operation crosses that threshold, what changes isn't the size of the team. What changes is the value each hour of the team produces: more cases resolved with real judgment, sharper decisions, patterns spotted before the damage shows up.

The Right Question

Growing the fraud operation isn't the same as growing the team. The operation grows when what each hour of the team produces grows: detecting earlier, deciding better, covering more without losing quality.

The right question isn't "how many more cases can my team review." It's:

Of every 100 cases my operation generates, how many does the system close without an analyst ever opening them?

It's a simple question, but few operations answer it with a concrete number. If yours doesn't, it doesn't know how much human judgment it's consuming on work the system could do on its own. And that number is the one that defines whether your fraud operation scales or not.

Closing

The fraud team breaks when the system forces the analyst to connect the tools, clean the data, and remember by hand where each case left off. The product covers 25%; the rest gets held together with Excel and memory.

That's exactly what we're building at Frauddi, and it's the product that matters most to us right now.

It's not a new layer on top of the Excel. It's closing the gap between when a pattern shows up and when it gets stopped, raising the quality of every decision, and running the whole operation from a single place. The effect lands where it hurts: fewer chargebacks, fewer legitimate customers blocked, fewer team hours lost to work the product should be doing.

If you want to see what a risk operation looks like when all of that happens from one place, book a demo.

Next in the series: False Positives: The Damage Your Fraud System Does to Your Best Customers (Part 5/8).