Fraud Detection and Monitoring

Single-feature or low-dimensional feature sets catch fraud that matches simple patterns — a transaction that exceeds a velocity threshold, or a device that has appeared in previous fraud cases. They miss fraud that operates within those thresholds by design — structuring, where transaction amounts are kept below rule boundaries; device rotation, where fraudsters cycle through devices to avoid fingerprint matching; and cross-channel patterns, where the fraud signal is distributed across multiple interaction types that individually appear normal. Two-hundred-plus features capture signal across device behaviour, session dynamics, transaction sequencing, historical baseline deviations, and cross-channel activity simultaneously. The model learns which combinations of these features are predictive of fraud in the specific deployment's pattern distribution — correlations that a human analyst would not identify from manual review.

The feedback loop ingests two signal types: confirmed fraud outcomes — transactions that were scored as fraud, reviewed, and confirmed — and false positive corrections — transactions that were flagged, reviewed, and cleared as legitimate. These are added to the training dataset and used in periodic model retraining cycles rather than continuous online learning, which would introduce instability from individual noisy feedback signals. Retrained model candidates are evaluated against a held-out validation set before deployment — a model that performs worse than the current production model on validation data is not deployed, regardless of its performance on the training set. This means the feedback loop improves accuracy over time without the risk of a single miscategorized feedback signal degrading production performance.

A fraud score tells a reviewer that the model assessed the transaction as high-risk. SHAP values tell the reviewer which specific features drove that assessment and by how much — the top three contributing features might be an unusual device behaviour pattern, a velocity anomaly across the previous four hours, and a transaction amount that sits in the 99th percentile for that merchant category for that user. This is the information that makes manual review of borderline cases efficient — the reviewer is not investigating an opaque score, they are evaluating a specific set of flagged signals. For regulatory purposes, SHAP documentation also satisfies the explainability requirement that financial regulators increasingly apply to automated decision systems that affect customers — the ability to explain why a specific transaction was declined.

Transaction events are published to a Kafka stream at the point of occurrence. A feature computation service consumes the stream and updates the relevant feature values in Redis — session velocity counts, rolling transaction aggregates, device activity patterns — as each event arrives. The feature store, therefore, reflects the transaction history up to the most recent event rather than a batch-computed snapshot from the previous hour or day. This matters for velocity-based features in particular: a structuring pattern that distributes transactions across a short window is only detectable if the feature store captures all transactions in that window in near real time, not if it is updated on a batch schedule that may miss transactions occurring within the same window.

The accuracy-false positive trade-off is managed through the decision threshold applied to the model's output score rather than through the model architecture itself. The model produces a continuous score between zero and one. The threshold at which a score becomes a fraud flag is calibrated against the deployment's specific cost structure, the relative cost of a missed fraud versus a false positive decline. A deployment where fraud losses are high relative to customer friction costs will use a lower threshold. A deployment where false positive declines carry high churn risk will use a higher one. H2o.ai AutoML produces the model; threshold calibration is a separate tuning step performed against the deployment's actual fraud and transaction distribution after model selection.

A full fraud detection platform, covering h2o.ai AutoML model training, 200+ feature engineering, real-time Redis inference, Kafka event streaming, SHAP explainability, and continuous learning feedback loop — typically runs fourteen to twenty weeks from architecture sign-off to production. The range depends on the volume and quality of historical transaction data available for initial model training, the complexity of the existing transaction event infrastructure, and the number of data sources feeding the feature store. We assess scope during the discovery phase before committing to a timeline.