Fraud Alert Triage Sankey Diagram: Template
Show where 2,000 weekly fraud alerts come from, how many are closed automatically or reviewed by an analyst, and how few turn out to be real. Operational view with invented counts.
A fraud alert triage Sankey puts the alert sources on the left and the outcomes on the right. Because four sources merge into three review levels, it shows which sources create work and which produce real cases.
The example takes 2,000 weekly alerts from four sources into three levels of review, and then to a verdict. 1,100 are closed automatically, 800 go to an analyst and 100 to a priority queue. In the end only 200 of the 2,000 are confirmed.
The picture is for deciding where analyst time goes: a source with a wide ribbon into review and a narrow one into confirmed fraud is generating noise. It shows counts, not losses, and it does not say how any particular system should be tuned.
How to read this diagram
- Card rules raise 900 of the 2,000 alerts, 45% of the total, but only 40 of them reach the priority queue.
- 800 alerts need an analyst, and 620 of those (78%) turn out to be false positives.
- The priority queue is small (100) but 70% of its alerts are confirmed, the highest hit rate.
- In total 200 alerts are confirmed (10%), 1,730 are false positives and 70 are inconclusive.
The data behind it
Invented figures for illustration. Not data about any real organisation. Alert counts for one week, not losses.
| From | To | Amount (alerts) |
|---|---|---|
| Card rules | Auto-closed | 500 |
| Card rules | Analyst review | 360 |
| Card rules | Priority queue | 40 |
| Velocity checks | Auto-closed | 350 |
| Velocity checks | Analyst review | 230 |
| Velocity checks | Priority queue | 20 |
| Device signals | Auto-closed | 180 |
| Device signals | Analyst review | 100 |
| Device signals | Priority queue | 20 |
| Customer reports | Auto-closed | 70 |
| Customer reports | Analyst review | 110 |
| Customer reports | Priority queue | 20 |
| Auto-closed | False positive | 1090 |
| Auto-closed | Confirmed fraud | 10 |
| Analyst review | False positive | 620 |
| Analyst review | Confirmed fraud | 120 |
| Analyst review | Inconclusive | 60 |
| Priority queue | False positive | 20 |
| Priority queue | Confirmed fraud | 70 |
| Priority queue | Inconclusive | 10 |
The same data as CSV
source,target,value
Card rules,Auto-closed,500
Card rules,Analyst review,360
Card rules,Priority queue,40
Velocity checks,Auto-closed,350
Velocity checks,Analyst review,230
Velocity checks,Priority queue,20
Device signals,Auto-closed,180
Device signals,Analyst review,100
Device signals,Priority queue,20
Customer reports,Auto-closed,70
Customer reports,Analyst review,110
Customer reports,Priority queue,20
Auto-closed,False positive,1090
Auto-closed,Confirmed fraud,10
Analyst review,False positive,620
Analyst review,Confirmed fraud,120
Analyst review,Inconclusive,60
Priority queue,False positive,20
Priority queue,Confirmed fraud,70
Priority queue,Inconclusive,10How it works
List the alert sources
One node per rule family or signal, with the alerts it raised in the period.
Add the review levels
Create nodes for automatic closure, standard review and priority review, and connect every source to each level it feeds.
Add the verdicts
Connect each review level to the verdicts it produced. A verdict reached later belongs in the period the alert was raised.
Frequently asked questions
Does this show which rules to switch off?
It shows where volume and confirmed cases sit. Whether to change a rule is a judgement that also depends on the cost of a missed case, which a Sankey does not show.
Should I include customer data?
No. Use aggregate counts only. The diagram needs totals per source and outcome, never records.
Edit this fraud triage Sankey
Open the example as your own chart and enter your weekly alert counts.