{
  "id": 1724332,
  "title": "A risk score is not a probability. Does your code know that?",
  "url": "https://urgent.news/2026/08/18/a-risk-score-is-not-a-probability-does-your-code-know-that",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-18T14:00:00.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/layercall/a-risk-score-is-not-a-probability-does-your-code-know-that-401g"
  },
  "original_language": "en",
  "account": "A risk score is not a probability, and many people mistakenly treat it as if it were. When you see a score of 80, it signifies increased risk compared to a score of 40, but it doesn't equate to an 80% likelihood of fraudulent activity. The score simply denotes an order of riskiness, not a likelihood. Most scoring systems, including ours, never explicitly state this in their documentation.\n\nPeople often proceed to perform arithmetic operations on these scores, treating them as probabilities. For instance, calculating expected loss with a formula like score/100 × transaction_value. Averaging scores during a session, or multiplying two scores together to arrive at a combined risk. Each of these operations makes sense when dealing with probabilities, but they become meaningless when applied to risk scores, which are merely ordered values. Notably, none of these operations generate an error.\n\nThe problem lies in the confidence the numbers generate. A number is presented, but it doesn't convey any meaningful information. The telltale sign is any expression where you divide a score by 100 or where two scores are combined using methods other than a simple maximum. This issue is challenging to catch because the system often functions correctly, despite the nonsensical arithmetic. It merely fails at the edges, quietly and subtly, in areas that aren't being measured.\n\nTo obtain a genuine probability, one must calibrate the system against actual observed outcomes. This involves feeding back results and measuring them, rather than deriving the probability from the score itself. The question arises: is there a viable method to prevent this error at the review stage? A lint rule might seem too simplistic, but relying solely on documentation stating that \"scores are ordinal\" isn't proving effective.",
  "summary": "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…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}