A fraud desk dashboard for card teams: queue, losses and rule alerts in one view

A card fraud desk is a queue with a cost attached. Alerts come in from the fraud engine around the clock, analysts work them in shifts, and every hour a genuine case waits is an hour the card can still be used. Most desks can answer “how many are open” quickly. Fewer can answer “how many are old, which team has them, and are the extra alerts real” without someone building a spreadsheet first.

This post walks through a fraud desk dashboard built with Agent Serve Dashboards. It sits on data you already have, it does not score transactions or replace your fraud engine, and every number on it comes from one governed definition. Each section below explains one part of it.

Start with the definitions, not the charts

The first job is agreeing what the numbers mean. Fraud teams often have three versions of “false positive rate”, one per report. In Agent Serve, the semantic model describes the alert, case, card and merchant entities, how they join, and which fields are dimensions such as channel, team and merchant category.

On top of it sit governed metrics, each written once:

• Open cases: a count of cases without a closed date.
• Confirmed fraud rate: a ratio of cases closed as confirmed fraud to all closed cases.
• False positive rate: closed as genuine customer activity divided by all closed cases.
• Net fraud losses: written-off amounts minus recoveries, summed over the period.

Every tile, chart and Relay reads these definitions, so the Monday briefing and the board pack cannot disagree. Data stays in your warehouse; Agent Serve reads it through a data source connection to Snowflake, BigQuery or a database you already run.

The four tiles and the trend

The top row answers the four questions a fraud lead asks first: how many cases are open, how many are past the ageing limit, what share of closed cases were real, and what the losses were. Each tile uses the period comparison built into dashboards, so the delta shows the change against the previous period or the same period last year.

Below the tiles, a bar chart shows alerts raised against cases closed per week. When the raised bars run ahead of the closed bars for two or three weeks, the queue is growing, and the lead can see it before the ageing tile turns.

Filters for date range, channel and team apply to the whole page. Drill-down on the chart goes from week to day, then through to the list of cases behind a bar.

Rules that flag the cases worth a look

Rules are plain checks over each row. They return a yes/no flag, a label or a score, and they show up as extra columns in the case table. For example:

• Ageing over the limit: a case open longer than the hours your procedures allow.
• Repeat merchant: a case whose merchant already has three or more confirmed cases this week, using a count your warehouse view carries on each row.
• No reason code: a case closed without the outcome reason your quality checks require.

These rules do not decide anything about a transaction or a customer. They point an analyst or a team lead at rows that need a second look, and the rule definitions sit in one place where the rules owner can review them.

Monitors that speak up first

Monitors check a metric or a rule on a schedule, from every five minutes to every seven days, and open an alert when the condition holds. A desk typically runs three:

1. Queue ageing: a rule monitor that fires when the ageing rule matches more than a set number of cases.
2. False positive rate: a metric monitor that fires above a threshold, a sign that an engine rule change is flooding the desk with genuine activity.
3. Repeat merchants: a rule monitor that fires when any merchant passes the repeat threshold.

Each monitor has a severity of info, warning or critical. Alerts always appear in the app, and can also go by email or to Slack or Teams through a webhook. They resolve on their own when the condition clears, so the alert list reflects the desk as it is now.

One limit to be clear about: monitors check thresholds and rule matches. They do not detect anomalies on their own, so pick thresholds from your own history and review them each quarter.

The briefing, the report and who sees what

Two pieces carry the dashboard beyond the screen.

A weekly briefing Relay. A Relay is an AI coworker with its own instructions and access. Set to the Observe autonomy level with a Monday schedule, it reads the dashboard and metrics and posts a short briefing into the lead’s chat. In Observe it can read and draft but cannot save files, send email or book meetings.