{
  "id": 5610659,
  "title": "How Banks Detect Fraud in 27 Milliseconds (The System Design)",
  "url": "https://urgent.news/2026/09/04/how-banks-detect-fraud-in-27-milliseconds-the-system-design",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-04T17:54:44.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/shohruh_sharipov/how-banks-detect-fraud-in-27-milliseconds-the-system-design-1ldk"
  },
  "original_language": "en",
  "account": "In the world of banking, detecting fraudulent transactions in a fraction of a second is crucial. A company's system goes through a 5-stage pipeline to accomplish this feat in under 30 milliseconds, processing millions of transactions per day.\n\nStage 1, \"Ingest,\" involves Apache Kafka, which handles the streaming of millions of transactions per second. Each transaction is logged, ensuring nothing is lost and everything is processed in real-time. This stage takes approximately 1 millisecond.\n\nStage 2, the \"Rules engine,\" runs fast, hard-coded checks before anything else. These checks include geo-velocity, which verifies if a card used in Lagos is valid after being tapped in New York. If the time taken is physically impossible (like two minutes), the transaction is blocked instantly. Other checks involve the transaction amount in relation to the user's historical average, time-of-day patterns, and spending limits.\n\nStage 3, the \"ML model,\" performs the heavy lifting. It analyzes features such as transaction amount, geographic distance, merchant category, and device fingerprints. The model, trained on 500 million real transactions, outputs a fraud probability score within 15 milliseconds.\n\nStage 4, the \"Graph database,\" checks if the card, merchant, or device is connected to any known fraud rings. Because a single fraudster can potentially connect thousands of cards, this graph query quickly surfaces connections, taking around 8 milliseconds.\n\nThe final stage, the \"Decision engine,\" combines all the signals into a final score ranging from 0 to 30. A score between 0 and 30 means the transaction is auto-approved. A score between 31 and 69 prompts an OTP challenge, while a score between 70 and 89 sends the transaction to a human analyst queue. Scores between 90 and 100 result in an instant block, with the cardholder receiving an SMS alert within about a second. A combined score of 94/100 means the transaction is BLOCKED, and the cardholder is alerted in roughly a second.\n\nThe speed of this process is attributed to pushing slow decisions off the critical path. Kafka absorbs bursts, the rules engine eliminates obvious cases before the ML model runs, and scoring is achieved through precomputed features and fast inference, avoiding large database scans during the hot path. By visualizing this system design, the author aims to provide clarity on backend and DevOps processes.",
  "summary": "You tap your card in New York. Two minutes later, someone tries to use it in Lagos — and the bank blocks it instantly. How does it decide in under 30 milliseconds, across billions of transactions a day? I animated the whole pipeline below 👇 — the rest of this post walks through it in text. The 5-stage pipeline (~27ms total) 1. Ingest — Apache Kafka (~1ms). Millions of transactions per second…",
  "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."
}