A bank loses money not where reports are calculated slowly, but where a fraudster manages to move funds to a drop account before a check can trigger. A once-a-day batch reconciliation finds fraud only after the money is gone. Streaming processing on Apache Kafka changes the equation: transactions and account events are analyzed as they happen, not hours later. Below is an open breakdown of what banks publicly do with this tool. This is not a KT.Team case study, but an overview of practices with source links.
What business result does the bank get
The main result is that the response window shrinks from hours to milliseconds and seconds. Krungsri (Bank of Ayudhya), one of Thailand's largest banks, uses an Apache Kafka streaming architecture to detect and block fraudulent transactions in less than 60 seconds, exactly within the window scammers usually need to move money to a mule account (Kai Waehner). In its fraud-scenario analysis, Confluent cites EVO Banco, which cut weekly fraud losses by 99% after moving to real-time streams (Confluent).
The second result is controlled cost and delivery speed. At Krungsri, offloading data from the mainframe through Kafka reduced the load on core banking and the bill, while project time to production dropped from 4–6 months to 6–8 weeks by reusing a single streaming bus instead of point-to-point integrations (Kai Waehner).
Why a streaming model, not just faster batch processing
Fraud detection is not just "one payment against one rule." It is a sequence: initiating the operation, calculating a risk score, triggering an SCA challenge, and settling the payment. SoftwareMill describes how, in Kafka, each step becomes a separate inspectable event: `TransactionInitiated`, `RiskScoreCalculated`, `SCAChallengeTriggered`, `TransactionSettled` (SoftwareMill). The model consumes these events on the fly instead of waiting for an overnight batch. Confluent describes this as analysis millisecond by millisecond while sustaining billions of events per day without losing speed (Confluent).
Replay: the same stream also powers audit
Kafka's key property for finance is its append-only log: events are stored as an ordered sequence with precise timestamps and retained for a configurable period. This makes it possible to reconstruct an account state at any point in the past, even if the current state has already changed (SoftwareMill). For a bank, this is two processes for the price of one: the same immutable log that powers fraud detection also answers regulator questions and supports dispute investigations, such as why a transaction was approved, which fraud signals were assessed, and what state the customer was in at that moment.
Replay has another practical effect: after a failure or lag, a consumer can catch up with the log without data loss, and a new fraud model version can be tested by running it again over the historical stream of real events before production rollout.
Typical architecture from public implementations
The pattern repeats across different banks. The source of truth is core banking and card processing; events are extracted from them through Change Data Capture (at Krungsri this is IBM CDC) and published to Kafka. On top of that sits stream processing (Kafka Streams / ksqlDB / Apache Flink): enrichment, windowed aggregation, and ML scoring model invocation. The decision to block or challenge returns to the operational flow within seconds. Krungsri runs a hybrid setup: an on-prem core plus cloud ML models and mobile apps, and the architecture meets Bank of Thailand requirements for security and data privacy (Kai Waehner).
What to watch for when designing it
- Minimal core changes. CDC extracts events close to core banking without rewriting it. Fraud business logic lives in separate streaming services, not inside the processing monolith, which is what loose coupling and portability mean.
- Exactly-once and ordering. For monetary events, idempotency and ordering within a key (account) are critical, otherwise you risk duplicate charges or state races.
- Retention for audit. Log retention and compaction are set to meet regulatory requirements; Confluent Platform also adds Audit Logs and RBAC (SoftwareMill).
- PII in the stream. Mask and control sensitive fields before they reach consumers.
Business process conclusion
The control process itself changes: instead of "night -> reconciliation -> after-the-fact investigation," it becomes "event -> stream scoring -> block or challenge within the same window, before the money is gone." One append-only log serves both flows: operational fraud detection in milliseconds and provable audit through replay. This reduces direct fraud losses while also removing separate workload for regulator reporting, without a dedicated audit subsystem.
Diagram (Text)
Core banking + card processing -> CDC -> Kafka topics (account and transaction events, append-only). From the topics, two branches come from one log: (1) real-time stream -> processing (Streams/Flink/ksqlDB) -> ML scoring -> "block / SCA-challenge" decision back to the operational flow within seconds; (2) the same log with configured retention -> replay -> audit, dispute review, and validation of a new model on historical events.
