Designing a Real-Time Fraud Detection System for Modern Banking

The Business Goal

In the modern banking ecosystem, a fraud detection system must balance two critical, often opposing objectives:

1. Minimize Fraud: Accurately identify and block malicious transactions (e.g., account takeovers, stolen cards) to protect the bank and its customers from financial loss.
2. Maximize Customer Experience: Minimize "false positives" (flagging a legitimate transaction as fraudulent). Every declined legitimate transaction causes customer friction, frustration, and potential loss of loyalty.

Achieving this balance requires an architecture that can process massive amounts of contextual data and execute complex machine learning models in real-time, all within a strict decision latency budget of under 100 milliseconds.

High-Level Architecture Overview

To achieve sub-100ms latency while scaling to thousands of transactions per second, we must employ a distributed, microservices-based architecture.

                            [ Mobile / Web App ]
                                     │ (1) Transaction Request
                                     ▼
                            [   API Gateway    ]
                                     │ (2) Route Payload
                                     ▼
                          [ Fraud Microservice ] ◄──────┐
                            │      │      │             │ (3) Fetch Features
                            │      │      ▼             ▼
                            │      │   [ ML Inference Model ]
                            │      ▼             
                            │   [ Rule Engine (Constraints) ]
                            │
                            ▼ (4) Decision (Approve/Decline/Step-up)
                    [ Return to API Gateway / App ]
                            │
                            ▼ (5) Async Event Streaming
                           [ Apache Kafka ]
                            │
          ┌─────────────────┼─────────────────┐
          ▼                 ▼                 ▼
  [ Snowflake DWH ]   [ SOC Dashboard ]  [ ML Retraining ]

1. The Entry Point: API Gateway

All transaction requests (from mobile apps, web portals, or payment networks) enter the system through an API Gateway. The gateway handles TLS termination, authentication, rate-limiting, and basic request validation before routing the payload to the internal microservices.

2. Fraud Detection Microservices

The core orchestration happens within the Fraud Detection Microservice. When invoked by the API Gateway, this service acts as the conductor, managing the data enrichment, scoring, and decision-making flow.

3. Data Enrichment (The Need for Speed)

An ML model is only as good as the features it receives. The raw transaction payload is rarely enough. The microservice must immediately enrich the request with contextual data:

• Customer Data: Historical spending habits, account age, average transaction size.
• Device Data: Is this a known device? Is the IP address risky?
• Beneficiary Data: Is the receiving account newly created or blacklisted?

To meet the 100ms SLA, this data cannot be queried from a traditional relational database (OLTP). Instead, we use ultra-fast, in-memory data grids or NoSQL stores like Redis or DynamoDB DAX to fetch pre-computed feature vectors in under 5-10ms.

4. ML Model Scoring & Rule Engine Fallback

Once enriched, the payload is sent in parallel (or sequentially, depending on dependencies) to two decision engines:

• Machine Learning Model: A lightweight, highly optimized model (e.g., XGBoost, LightGBM running via ONNX or TensorRT) evaluates the transaction and returns a probability score (0 to 100) indicating the likelihood of fraud.
• Rule Engine: Evaluates hard constraints that bypass ML logic. For example, "Decline all transactions to sanctioned countries" or "Decline if the amount exceeds daily limits."

Real-Time Flow and Risk Scoring

The orchestration of a decision happens in milliseconds:

1. Ingest: Transaction payload hits the API Gateway and is routed to the Fraud Microservice.
2. Enrich: Microservice queries Redis for historical context.
3. Score: The enriched payload is evaluated by the ML model (generating a risk score, e.g., 85/100) and the Rule Engine.
4. Decide: The microservice applies a threshold to the score.
   • Score < 40: Approve
   • Score > 90: Decline
   • Score 40-90: Review / Step-up

Handling False Positives: Step-Up Authentication

A rigid Approve/Decline binary creates a poor user experience for "grey area" transactions (e.g., a customer traveling abroad making a large legitimate purchase).

To maximize customer experience while managing risk, we use Step-Up Authentication. If the risk score falls in the middle range, the system issues a "Challenge" response rather than a decline.

• The API Gateway signals the frontend to prompt the user for Multi-Factor Authentication (MFA), such as an SMS OTP or a biometric Push Notification.
• If the user passes the challenge, the transaction is approved.
• Crucially, this result acts as a positive reinforcement signal fed back into the ML pipeline, teaching the model that this behavior pattern is legitimate for this specific user, thus reducing future false positives.

Resilience Strategies: Designing for Failure

In banking, a system outage means legitimate transactions are dropped, causing massive reputational damage. The architecture must be resilient to degradation.

Failover to Rules: Machine Learning inference can be computationally heavy. If the ML inference service degrades, experiences a latency spike, or times out (e.g., takes > 50ms), the Fraud Detection Microservice must automatically sever the connection (circuit breaking). Instead of failing the transaction, the system gracefully degrades by relying solely on the Rule Engine. While the Rule Engine is less sophisticated than the ML model, it guarantees that basic security constraints are met and legitimate transactions continue to flow, ensuring the bank meets its SLA.

Scalability and Asynchronous Processing

To handle peak traffic (e.g., Black Friday), the system must scale dynamically and decouple critical path processing from downstream tasks. The architecture must comfortably process 1 million transactions per day, requiring a sustained throughput of 300 to 500 Transactions Per Second (TPS), with the elasticity to scale up to 2,000 TPS during peak spikes.

• Microservices on Kubernetes / ECS: The API Gateway, Fraud Microservices, and ML Inference containers are deployed on orchestration platforms like Kubernetes (K8s) or Amazon ECS. These platforms are configured with Horizontal Pod Autoscalers (HPA), allowing them to spin up additional instances automatically as CPU utilization or request queues spike. This elasticity is what allows the system to seamlessly transition from 300 TPS to 2,000 TPS without manual intervention.
• Kafka for Event Streaming: Once a decision is made, the Fraud Microservice fires a "Decision Event" onto an Apache Kafka topic in a non-blocking "fire-and-forget" manner.
• Analytics and Monitoring: Downstream systems consume these Kafka streams for non-real-time tasks. This includes pushing data into an analytical data warehouse (like Snowflake) for reporting, retraining ML models based on recent trends, and updating real-time Grafana dashboards for the Security Operations Center (SOC) to monitor system health and fraud attack vectors.

By keeping the real-time path lean and offloading all secondary processing to Kafka, the architecture comfortably sustains the critical < 100ms decision latency.