What goes on a fraud team's dashboard, and what doesn't

The dashboard that matters is the one your team leaves open.

If analysts close it by 9:15 and spend the rest of the day working from a spreadsheet somebody updates by hand, the dashboard is wrong. That is not a design critique. It is production evidence.

Open the spreadsheet. Whatever they are tracking there is probably what the dashboard should have shown them in the first place.

Most fraud dashboards I see go the other direction. They look good in a leadership deck. Big “fraud dollars prevented” number in the top-left. A year-over-year trend line nobody can act on. A total-alerts gauge that climbs every time someone ships a new rule.

That stuff might have a place somewhere. It does not help an analyst decide what to work next.

The dashboard a fraud team uses every day is usually uglier and more specific. It also serves a different person than the dashboard your boss checks on Monday morning.

Two dashboards, not one

A fraud team needs two dashboards. Most teams build one and pretend it serves both audiences. It usually serves neither.

The analyst dashboard is open all day. The job is triage. The analyst needs to know what is in the queue right now, which alerts are getting old, which rules are acting strange today, and which accounts can be cleared quickly because the team has already seen them.

The manager dashboard is checked once a day or once a week. The job is tuning. The manager needs to know which rules are drifting, whether backlog is growing, whether analysts are keeping up, and which rules should be retired.

Those are different products. They can share tables, definitions, and pipelines. The surface should be different.

The analyst dashboard

What belongs on it:

1. Open queue size by rule. Not lifetime alert count. Not yesterday’s total. The number an analyst can actually work down.
2. Median alert age by rule. If a rule that usually clears in under an hour has alerts sitting for four hours, somebody needs to look.
3. Median time-to-investigate by rule, today vs normal. When velocity alerts usually take 3 minutes and today they take 12, something changed. Could be a real burst. Could be a bad upstream feed. Either way, it is worth seeing.
4. Cleared rate by rule, today. A rule that normally clears at 80 percent but is clearing at 20 percent today is telling you something. The rule shifted, the traffic shifted, or the team is treating it differently.
5. Stale alerts. Color by hours waiting. This is the embarrassment column, which is why it works.
6. Highest-confidence open alerts. The model’s or rule stack’s best guesses, ranked. Useful when someone has 20 free minutes and wants to maximize hits.
7. Repeat-offender alerts. Accounts the team has cleared before, sortable by prior clear-on-sight count. Not glamorous. Very useful.

What does not belong on it:

• Total alerts. No context, no action, and it rewards rule-bloat.
• Year-over-year trends. An analyst on a four-hour shift cannot do anything about the last 12 months.
• “Fraud dollars prevented” as the headline. Real-time analysts do not directly control this metric. On a working dashboard it mostly creates noise.

A queue-by-rule view is a good starter query:

SELECT
  rule_name,
  count(*) FILTER (WHERE status = 'open') AS open_queue,
  count(*) FILTER (WHERE status = 'cleared' AND cleared_at >= current_date) AS cleared_today,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY extract(epoch FROM (now() - created_at)) / 60
  ) FILTER (WHERE status = 'open') AS median_age_open_min,
  count(*) FILTER (
    WHERE status = 'open' AND created_at < now() - INTERVAL '4 hours'
  ) AS stale_4h_plus
FROM alerts
WHERE created_at >= current_date - INTERVAL '7 days'
GROUP BY rule_name
ORDER BY open_queue DESC;

Five columns, one row per rule.

An analyst can glance at that and know where the problem is. If stale_4h_plus is non-zero for a rule that is supposed to clear in under an hour, that is not a chart. That is a work queue.

The manager dashboard

What belongs on it:

1. Time-to-first-alert distribution by rule, last 30 days. How long after the first fraudulent transaction did this rule fire? Trending up is bad. Trending down usually means recent tuning helped.
2. Precision by rule over time, last 90 days. This is the chart I would put in the center of the page. Anyone leading the team should be able to see which rules are getting worse.
3. Backlog growth or shrinkage. Weekly net change in open alerts. This tells you whether team capacity matches alert volume.
4. Disposition mix by rule. Confirmed fraud, confirmed legitimate, unknown. The unknown column is the early warning that disposition discipline is slipping.
5. Killed-rules log. Every rule retired this quarter, with the precision number at retirement and the reason. Keeps pruning visible.

What does not:

• Real-time alert counts. A manager checking the dashboard Monday at 9 AM does not need the alert count from 10 minutes ago.
• The same “fraud dollars prevented” headline. Put it in the quarterly review deck if you need it. Do not make it the centerpiece of a working dashboard.
• Aggregate precision across all rules. Averages hide the problem. A team can report 85 percent average precision while running three excellent rules and nine mediocre ones. Show every rule.

The precision-over-time query, weekly buckets:

SELECT
  rule_name,
  date_trunc('week', cleared_at) AS week,
  count(*) FILTER (WHERE disposition = 'fraud') AS true_positives,
  count(*) FILTER (WHERE disposition = 'legitimate') AS false_positives,
  count(*) FILTER (WHERE disposition = 'fraud')::float
    / nullif(count(*) FILTER (WHERE disposition IN ('fraud', 'legitimate')), 0)
    AS precision
FROM alerts
WHERE cleared_at >= current_date - INTERVAL '90 days'
  AND disposition IN ('fraud', 'legitimate')
GROUP BY rule_name, week
ORDER BY rule_name, week;

Plot it one line per rule.

The lines trending down are your next threshold-tuning queue. The flat lines at bad precision are your retirement candidates.

The metric I would keep off every working dashboard

Total alerts.

Total alerts rewards the wrong behavior. More rules means more alerts. More alerts means a bigger visible number. A bigger visible number makes it look like the team is doing more, even when the extra work is mostly false positives.

The first time leadership gets used to seeing that number go up, rule pruning gets harder. Now every useful cleanup looks like a decline.

That is how teams end up defending alert volume instead of defending alert quality.

Replace total alerts with two better views:

• On the analyst dashboard: open alerts by rule.
• On the manager dashboard: precision by rule over time.

If an executive absolutely needs one headline number, use median precision across active rules. It is still imperfect. But at least it moves in the right direction when bad rules are fixed or retired.

The practical test

The test is simple: does the team leave the dashboard open?

If they do, you probably built something useful.

If they do not, go find the spreadsheet, Slack message, notebook, or browser tab they are actually using. That is the dashboard. It just has worse plumbing.

Start there.