Skip to content
CBN data localisation deadline, 1 Jan 2027: 99d 00h 25m left.Talk to us
NuxFamily

Banking · A European bank with a large card-payments business

Real-time fraud scoring on a private streaming platform

The bank's fraud checks ran in batch and missed the window in which a transaction could still be declined. NuxFamily built an on-premises streaming and in-memory platform that scores card transactions in real time, with full data residency.

  • < 50 ms

    Added latency per authorisation for real-time scoring

  • −31 %

    Fraud losses on card transactions in the first year

  • 100 %

    Of scoring decisions retained with features and model version

The challenge

The challenge

Card authorisations were scored against rules refreshed nightly. Fraud patterns changed faster than that, and the bank's fraud losses were rising while false declines annoyed customers. The fraud team wanted models scored on live transaction data, enriched with account history.

The data could not leave the bank's premises. Transaction records, customer identifiers and model features had to remain in its own data centres, and the regulator required auditable retention of every scoring decision.

Latency was the hard constraint: an authorisation decision had to include the fraud score within the time the card network allowed, with no degradation during peak shopping periods.

The architecture

The architecture

Transactions are captured from the core banking and card systems with change data capture and published to Apache Kafka clusters deployed across two sites. Kafka provides the durable, ordered event log for authorisations, account events and model outputs.

Stream processing services on Kubernetes enrich each authorisation with features held in Redis, an in-memory store loaded from the customer history and refreshed continuously from the same streams. Models are served on the same cluster and versioned through the deployment pipeline.

Every scoring decision, its features and the model version are written back to Kafka and persisted to PostgreSQL for operational queries and to Apache Iceberg tables for long-term retention and model retraining. OpenSearch indexes decisions for the fraud analysts' investigation tooling.

The platform runs on the bank's OpenShift clusters with dedicated node pools for the streaming and in-memory tiers. Disaster recovery uses cross-site Kafka replication and Patroni failover, tested during quarterly exercises.

Technologies

  • Apache Kafka
  • Change data capture
  • Redis
  • OpenShift
  • PostgreSQL
  • Apache Iceberg
  • OpenSearch
We went from finding fraud the next morning to stopping it at the point of sale.
Head of Fraud Prevention, European bank

Your institution could be the next case

Tell us about your platform and regulatory timeline; we will show you which of these patterns applies.

No mailing lists, no automated follow-ups. We reply personally within one working day.