Sandeep Bhardwaj

Backend Engineer • SaaS Builder

Anomaly Detection for Fraud and Operations

Anomaly detection is used when rare harmful events matter more than average behavior. Examples include payment fraud, infrastructure incidents, insider abuse, and sensor failures.

The hard part is not generating anomaly scores. The hard part is generating useful alerts with acceptable precision.

Define Anomaly Type First

Different problems require different detectors.

  • point anomaly: single unusual event
  • contextual anomaly: normal globally but unusual in context
  • collective anomaly: sequence-level unusual pattern

If anomaly definition is vague, thresholding and evaluation become inconsistent.

Method Selection by Data Regime

Statistical Baselines

  • z-score or robust z-score
  • percentile thresholds
  • seasonal residual bounds

Great as first baseline and operational fallback.

Isolation Forest

Effective on tabular data with mixed features. Detects points easier to isolate in random partitioning.

One-Class SVM

Useful in specific medium-scale settings; sensitive to scaling and parameter tuning.

Autoencoder Reconstruction

Useful for high-dimensional signals where normal patterns can be learned compactly. Requires careful drift and threshold monitoring.

Evaluation Without Perfect Labels

In many anomaly pipelines, labels are sparse and delayed. Use mixed evaluation strategy:

  • precision on analyst-reviewed alerts
  • recall on known incident subset
  • alert volume stability
  • mean time-to-detect
  • cost saved per true positive incident

Business-aligned evaluation is essential.

Threshold Design and Alert Fatigue

Static thresholds usually fail under seasonality and growth. Better approaches:

  • segment-specific thresholds
  • adaptive baselines per entity/time
  • percentile-based dynamic cutoffs
  • top-k per time window when analyst capacity is fixed

If alert volume is uncontrollable, detection system will be ignored.

Feature Engineering for Anomaly Use Cases

High-value features:

  • velocity features (events per minute/hour)
  • peer-group deviation
  • sequence deltas and burstiness
  • graph features (shared devices/accounts)
  • recency and rarity indicators

Context-aware features usually outperform raw-value thresholding.

Deployment Pattern

Typical real-time architecture:

  1. ingest event stream
  2. enrich and compute features
  3. generate anomaly score
  4. apply threshold + rule layer
  5. route alerts to triage queue
  6. collect analyst feedback
  7. update detector/threshold policy

Feedback loop is required to improve precision over time.

Common Mistakes

  1. shipping unsupervised scores directly to end users
  2. no analyst feedback capture
  3. no drift tracking for base behavior
  4. optimizing only recall and creating unusable alert load
  5. ignoring sequence context for transactional data

End-to-End Code Example (Isolation Forest + Alert Threshold)

This example shows a complete anomaly workflow:

  • build features
  • train detector
  • score incoming events
  • create top-percentile alerts
import pandas as pd
from sklearn.ensemble import IsolationForest
from sklearn.metrics import precision_score, recall_score

# Historical data with delayed labels (1 = confirmed fraud, 0 = normal)
train_df = pd.read_csv("transactions_train.csv")
valid_df = pd.read_csv("transactions_valid.csv")

feature_cols = [
    "amount",
    "txn_velocity_10m",
    "failed_attempts_1h",
    "device_count_24h",
    "geo_distance_km",
]

X_train = train_df[feature_cols]
X_valid = valid_df[feature_cols]
y_valid = valid_df["is_fraud_confirmed"]

# Unsupervised detector fit on mostly-normal behavior
detector = IsolationForest(
    n_estimators=300,
    contamination=0.01,   # expected anomaly rate
    random_state=42,
    n_jobs=-1,
)
detector.fit(X_train)

# Higher anomaly score => more suspicious
valid_scores = -detector.score_samples(X_valid)

# Pick alert threshold by review capacity (top 1%)
threshold = valid_scores.quantile(0.99)
valid_alerts = (valid_scores >= threshold).astype(int)

print("Threshold:", round(threshold, 4))
print("Precision:", round(precision_score(y_valid, valid_alerts), 4))
print("Recall:", round(recall_score(y_valid, valid_alerts), 4))
print("Alert rate:", round(valid_alerts.mean(), 4))

# Simulate scoring new streaming batch
new_events = pd.read_csv("transactions_realtime_batch.csv")
new_scores = -detector.score_samples(new_events[feature_cols])
new_events["anomaly_score"] = new_scores
new_events["raise_alert"] = (new_scores >= threshold).astype(int)

alerts = new_events[new_events["raise_alert"] == 1].copy()
alerts = alerts.sort_values("anomaly_score", ascending=False)
alerts.to_csv("alerts_for_review.csv", index=False)
print("Alerts generated:", len(alerts))

In production, keep threshold policy tied to analyst capacity and update it as base rates drift.

Key Takeaways

  • anomaly detection is a decision workflow, not only a model
  • thresholding and triage design determine practical value
  • feedback-driven iteration and drift-aware policies are mandatory for long-term effectiveness

You may also enjoy