A bank is building a fraud detection model. Missing an actual fraudulent transaction (a false negative) is far more costly to the bank than flagging a legitimate transaction for review (a false positive). Which metric should the team prioritize when evaluating the model?
Select an answer to reveal the explanation.
Short Explanation
When missing the bad thing is the expensive mistake, you care about recall. Recall answers the question: of all the actual fraud cases out there, how many did we actually catch? Prioritizing recall pushes the model to cast a wider net and catch as much real fraud as possible, even if that means flagging some legitimate transactions along the way — an acceptable tradeoff here since a false positive just means an annoying review, not a financial loss. That's answer A. Precision instead asks how many of your fraud flags were actually correct — great when false positives are the expensive mistake, which isn't the case in this scenario. Specificity for the negative class only ignores what happens with your actual fraud cases, the exact thing you're trying to optimize for. And raw accuracy is famously useless here because fraud is rare — a model that predicts "not fraud" every single time would score a sky-high accuracy while catching zero fraud.
Full Explanation
Recall (also called sensitivity or the true positive rate) is defined as true positives divided by the sum of true positives and false negatives: TP / (TP + FN). It measures the proportion of actual positive cases (here, real fraudulent transactions) that the model successfully identifies. When false negatives are the costly error — missing real fraud allows financial loss to occur — recall is the metric to prioritize, because maximizing recall directly minimizes the number of fraud cases that slip through undetected, even if doing so increases the number of false positives (legitimate transactions incorrectly flagged).
Precision, defined as TP / (TP + FP), measures how many of the model's positive predictions were correct; it is the right metric to prioritize when false positives are the expensive error, such as in a scenario where flagging a transaction triggers an irreversible, costly action for a legitimate customer. In this fraud scenario, however, the cost asymmetry runs the other way, making precision a secondary concern rather than the primary one. Specificity for the negative class (true negative rate, TN / (TN + FP)) measures how well the model correctly identifies legitimate transactions as legitimate, but it says nothing about how many actual fraud cases are captured, which is the crux of the problem being described. Raw accuracy, the proportion of all correct predictions over total predictions, is notoriously misleading on imbalanced datasets like fraud detection, where fraudulent transactions might represent well under 1% of all transactions — a naive model predicting "not fraud" for every transaction could achieve accuracy above 99% while having a recall of zero, providing no actual fraud-catching value.
In practice, teams often don't optimize recall in complete isolation; they typically examine the precision-recall tradeoff curve and may use the F1 score or a cost-weighted metric to balance both concerns, since driving recall to 1.0 by flagging everything as fraud would create an unmanageable volume of false positives for human reviewers. But when the explicit premise is that missed fraud is far more costly than a flagged legitimate transaction, recall is the metric that should be prioritized and optimized first.