A short one, but I keep seeing it cause real damage.
A fraud or risk score of 80 means "riskier than 40". It does not mean an 80% chance of fraud. It is an ordering, not a probability — and most scoring systems, ours included, do not claim otherwise anywhere in their docs.
Then someone builds arithmetic on top of it. Expected loss as score/100 × transaction_value. Averaging scores across a session. Multiplying two scores together for a combined risk. Every one of those operations is meaningful on probabilities and meaningless on an ordering, and none of them throw an error. You get a number. The number is confident. It means nothing.
The tell is any expression where you divide a score by 100, or where two scores get combined by anything other than max().
What makes it hard to catch is that the resulting system often behaves approximately right, because the ordering survives even when the arithmetic is nonsense. It fails at the edges, quietly, in the direction nobody is measuring.
If you want a real probability you have to calibrate against outcomes you have actually observed — which means feeding results back and measuring, not deriving it from the score.
Has anyone found a good way to stop this at review time? A lint rule feels too crude, but "remember scores are ordinal" in a doc nobody reads is clearly not working either.
Top comments (0)