Real-Time Fraud Detection System for Digital Payments

An ML-powered fraud detection pipeline replacing a rule-based system, using streaming features, ensemble scoring and a phased traffic migration for a digital payments...

[Overview] Scope of the engagement

This anonymized Ampity engagement involved building a layered fraud detection pipeline for a digital payments platform. The work replaced a manually maintained rule system with an ML-based inference pipeline that combined streaming feature computation, specialized models per fraud type and an ensemble aggregation layer.

This case focuses on the architecture, implementation approach and operating responsibilities. It does not provide verified before-and-after measurements or a regulatory assessment.

[Context] Why rules alone reached a limit

The account describes an interdependent rule set that was difficult to change safely. New rules required checking against existing behavior, while analysts still had to review the transactions those rules flagged.

The account identifies three distinct problems. Detection accuracy was declining as fraud patterns evolved faster than rules could be updated. False positives were creating a review burden that did not scale with the business. Latency in the rule engine was preventing real-time decisioning for a portion of transactions.

The architectural observation in the account is that each transaction was evaluated independently without behavioral context. A transaction unusual for one user could be routine for another. Population-level rules could not capture per-user patterns without generating excessive alerts.

[Diagnosis] Batch design and absent feedback

The account frames the deeper problem as the system being organized around batch analysis rather than real-time decisioning. Transaction data was captured and then analyzed, creating a structural gap between when a transaction occurred and when detection could act.

Rules were also described as a symptom rather than a root cause. When a fraud label was confirmed or a false positive was identified, that information did not return automatically to improve detection logic. The feedback loop depended on analysts writing new rules from post-mortem review.

Additional technical debt is noted: the rule engine had no shadow mode, no A/B testing infrastructure and limited rollback capability. Each rule change was all-or-nothing.

[Decisions] Ensemble versus single model

The account describes evaluating a single large neural network against an ensemble of specialized models, one per fraud type.

A single deep learning model was considered and not selected. The recorded concern was interpretability: individual decisions may need to be explained to reviewers and compliance teams, and a single opaque model makes that more difficult to support. Retraining and deploying one model for every fraud-pattern update also concentrates deployment risk.

The recorded choice was an ensemble covering account takeover, transaction anomalies and network patterns. Separating these models creates smaller change boundaries. The combined score still needs a decision policy and an explanation that a reviewer can evaluate; showing component scores does not establish either.

Streaming feature computation was chosen for real-time feature generation, with batch processes retained for model training, reflecting different latency requirements for inference and training.

[Design] Pipeline responsibilities

The account describes five detection layers: device trust scoring, behavioral pattern matching, transaction velocity analysis, graph-based network analysis and ML classification. Each operates independently with its own latency budget.

A feature store backed by Redis serves computed features for low-latency lookup during inference. Flink processes the event stream from Kafka, computing rolling behavioral windows per user.

The Decision Orchestrator fans requests to the specialized models in parallel and aggregates scores through a configurable policy engine. The policy engine allows operational teams to adjust thresholds without a code deployment.

A feedback loop captures fraud confirmations and manual review outcomes and routes them into model retraining on a scheduled cadence. Automated gates check accuracy, fairness and latency before a retrained model promotes to production.

For a similar implementation, define which model responses are required to complete a decision and what happens when one times out. Measure the whole path, including feature misses and aggregation. Review the explanation separately from score arithmetic. Define how new fraud patterns trigger evaluation rather than assuming a retraining schedule establishes coverage.

[Approach] Phased rollout with shadow mode

The account describes a four-phase migration. Phase one built the streaming infrastructure and feature store in shadow mode, collecting data without making decisions. Phase two deployed the first models in shadow mode and compared their decisions against the existing rule system. Phase three introduced gradual traffic migration, starting with a small percentage before expanding. Phase four focused on retraining with production data now available.

The account describes retaining a rule-based fallback. It does not publish the activation policy or failure-exercise results. Before reusing that approach, establish who may activate the fallback and how its different decision behavior is communicated and monitored.

Each traffic expansion step required sign-off from fraud operations, compliance and engineering leadership. This is qualitative information from the account and does not imply specific sign-off criteria or that the same process would apply to another engagement.

[Delivery scope] What the implementation covered

The technical scope described is streaming feature computation, specialized model serving, policy-based aggregation, feedback handling and staged decision routing. The account does not establish improved fraud loss, approval rates, review volume, latency or financial return.

The described approach may be useful context for a similar engagement. A specific result cited in the original source should not be used as a performance promise for a new workload.

[Operating considerations] Questions for similar implementations

Separate the feature pipeline latency from the inference latency and test them independently. A feature-store miss that falls back to a slower source can push total latency beyond the decision budget without surfacing as an obvious error.

Define how the feedback loop handles ambiguous labels. A manual review closed without a confirmed fraud or legitimate label adds noise to training data. Establish explicit label definitions before training on production outcomes.

Test what happens when a model is unavailable during inference. An ensemble that silently reduces to fewer models may produce different score calibration than expected. Decide whether that is acceptable or whether the transaction should route to a fallback path.

Test novel fraud patterns separately from normal workload variation. Define the retraining trigger conditions separately from the retraining cadence.

[Applicability] When this approach applies

ML-based fraud detection with streaming features is relevant when fraud-pattern evolution exceeds the capacity of a manually maintained rule system, when false positives create material user or operational costs, and when labeled historical data is available for model training.

The approach requires the organization to operate ML infrastructure including model serving, monitoring, retraining pipelines and drift detection. These responsibilities do not disappear after initial deployment. A smaller workload with lower fraud complexity may be served adequately by a commercial rule engine or managed fraud service.

Before expanding automation, ask reviewers to explain a sampled decision from the recorded inputs, model version and policy. Treat an unexplained or unsupported decision as an unresolved review item.

Technical reference

The NIST AI Risk Management Framework discusses validity, false-positive and false-negative measures, and the consequences of errors. This guidance is not a measurement of this deployment.