The base rate is how common the target event is in the population being checked. Combine it with detection and false-positive rates to interpret an alert. Even a seemingly accurate rule can produce mostly false alarms when the event is rare.
Define the event and the population being screened
Begin with an event that can be independently assessed, such as a confirmed duplicate payment under an agreed review rule. Define the unit being screened and the time window. Transactions, accounts and daily account states create different denominators. An alert on a repeated transaction should not be evaluated against a count of unique customers without explaining that change in unit.
Estimate prevalence from a relevant, reviewable population rather than only from previously flagged cases. Reviewing alerts alone tells you little about missed events among unflagged records. If the reference assessment is incomplete or disputed, retain that uncertainty. A base rate from another business or an older operating period may not transfer to the present workflow, especially after eligibility rules, customer mix or recording practices change.
Build the complete table behind the headline accuracy
Separate true events detected, true events missed, non-events flagged and non-events left unflagged. Detection rate divides detected events by all true events. False-positive rate divides false alerts by all non-events. Alert precision divides detected events by all alerts. These denominators answer different questions and should be named rather than compressed into a single claim that the rule is accurate.
Use natural counts to make the implications tangible. A small false-positive rate applied to a large non-event population can exceed the number of detected events. Conversely, a high overall accuracy can arise from leaving almost every case unflagged when events are rare. Check whether repeated alerts concern the same underlying issue; counting them separately can distort both workload and apparent rule quality.
Connect alert quality to the review decision
Evaluate the consequences of missed events and unnecessary reviews separately. A queue for low-cost human triage can tolerate a different precision from an automated action that interrupts a customer's service. Include reviewer capacity, timeliness and escalation routes in the design. Raising a threshold may reduce false alerts while also missing genuine events, so report both effects rather than describing fewer alerts as an unqualified improvement.
Reassess the table when prevalence or operating conditions change. Monitor confirmed outcomes for a suitable sample of unflagged cases where feasible, while respecting the risks of the process. Record delayed confirmations and unresolved reviews rather than classifying them as non-events. The resulting rates describe performance under the assessment conditions; they do not certify a model, guarantee future detection or establish that every alert deserves the same action.
A fictional rare-event review queue
A fictional scenario to explain the method, not a customer result or a market benchmark.
A fictional payment team screens 10,000 transactions. Independent review in this illustration identifies 100 genuine duplicate payments and 9,900 non-duplicates. A rule detects 90 of the 100 duplicates, a 90% detection rate, and flags 5% of non-duplicates: 495 false alerts. It misses 10 duplicates and correctly leaves 9,405 non-duplicates unflagged.
The review queue contains 585 alerts, of which 90 are genuine. Alert precision is 90 divided by 585, approximately 15.4%. The false-positive rate of 5% is therefore quite different from the proportion of alerts that are false, approximately 84.6%. All four cells sum to 10,000. The team uses the example to budget human review and consider thresholds, without asserting that a real rule has these properties. It would need an appropriate reference assessment and evidence about missed cases before claiming observed performance in production. It also records how long review takes, whether one duplicate generates several alerts and when confirmation becomes available. These details affect queue capacity and prevent unresolved alerts from being silently counted as confirmed false alarms. A review outcome remains pending until the agreed assessment is complete.
TAKE THIS INTO YOUR NEXT CONVERSATION
A practical next-step checklist.
- Define the screened unit and target event.
- Include flagged and unflagged reference cases.
- Show all four classification counts.
- Compare alert workload with consequences of misses.
Common questions.
Is detection rate the probability an alert is correct?
No. Detection rate conditions on true events; alert precision conditions on alerts and also depends on prevalence.
Can I estimate missed events by reviewing alerts only?
No. You also need a defensible way to assess events among unflagged cases.
Further reading & source context.
These primary references provide background. They are not evidence for the fictional example above and do not endorse Accuralytix.
Found an error or a missing qualification? Send an editorial correction.
Check my data readiness.
Use a practical tool to turn this idea into a clearer starting point.
Check my data readiness