Issue Summary

Fraud Detection

Issue Description

**Explainable AI for Fraud Detection — why a transaction was flagged **

Banks and payment providers use machine learning to spot suspicious transactions at scale. But a score alone (“Fraud probability = 0.85”) isn’t enough for an investigator or a regulator — they need why the model thinks a transaction is risky. Explainable AI (XAI) adds that “why” and, when used well, reduces false positives, speeds investigations, and improves model trust and governance. Below is a detailed, end-to-end explanation.

1. How fraud-detection models usually work (short)
   Data & features: transaction amount, timestamp, merchant category, merchant country, cardholder location, device fingerprint, velocity features (e.g., transactions in last hour/day), historical behavior (avg txn amount), account age, past chargebacks, etc.
   Model types: supervised classifiers (XGBoost, Random Forest, neural nets), anomaly detectors (isolation forest, autoencoders), and hybrid rule + ML systems.
   Pipeline: data ingestion → feature engineering (create velocity, recency, aggregation features) → model scoring → rule-based filters/thresholds → human analyst review / automated action.

2. Why false positives happen
   Unusual but legitimate behavior: a customer travels and uses card abroad; high-value recurring bill.
   Sparse labels / concept drift: models trained on old fraud patterns miss new legitimate patterns.
   Correlated features & proxy signals: e.g., a merchant category correlated with fraud historically but not fraudulent now.
   Threshold tuning: conservative thresholds reduce missed fraud but increase false alarms.
   False positives are expensive: wasted analyst time, customer friction (calls/card blocks), reputational cost.

3. What XAI gives you — the kinds of explanations and techniques
   Local (case-level) explanations — explain this specific transaction:
   SHAP (additive feature attributions; shows how each feature moved the prediction from a baseline).
   LIME (locally approximates the model with an interpretable surrogate).
   Counterfactual explanations (“If the amount were $300 lower, fraud probability would drop to 0.03”).
   Anchors (rules that “anchor” the prediction).
   Global explanations — explain model behavior overall: feature importance, partial dependence plots (PDP), accumulated local effects (ALE).
   Model-specific tools: e.g., Integrated Gradients or Captum for neural nets; tree-SHAP for tree ensembles.
   Why these matter: they tell an analyst which features pushed the score up or down, and by how much — enabling quick, evidence-based decisions.

4. Concrete single-transaction example (numeric)
   Suppose the model baseline (expected fraud probability for an average transaction) = 0.02 (2%). The model’s feature attributions for a flagged transaction are:
   High transaction amount → +0.60
   Transaction in foreign country → +0.12
   High velocity (many txns recently) → +0.07
   New merchant for this account → +0.04
   Compute step-by-step:
   0.02 + 0.60 = 0.62;
   0.62 + 0.12 = 0.74;
   0.74 + 0.07 = 0.81;
   0.81 + 0.04 = 0.85 (85% fraud probability).
   How the explanation would be presented to an analyst:
   Top contributors: 1) Amount (huge jump — +0.60), 2) Foreign country (+0.12), 3) Rapid recent transactions (+0.07), 4) New merchant (+0.04).
   Suggested summary sentence: “Flagged mainly because of a very large transaction in a foreign country combined with a sudden burst of activity and a previously unused merchant.”
   Additionally a counterfactual can be shown:
   “If the amount were ≤ $500, the probability would drop from 0.85 to 0.03.”

5. How XAI reduces false positives — operational mechanisms
   Faster triage: analysts see why a transaction was flagged (top 3 contributors) and can quickly decide if it’s likely legitimate.
   More informed escalation rules: only escalate cases where explanations match strong fraud signatures (e.g., high amount + new device + known risky merchant). If explanation shows expected legitimate cause (recurring subscription merchant + customer travelled), auto-clear or downgrade priority.
   Counterfactuals help automated de-escalation: if a single removable factor (e.g., one-time high amount) pushes the score up, rules can flag for softer action (SMS verification) instead of a card block.
   Human-in-the-loop feedback: analysts mark false positives and those labels feed retraining/threshold re-tuning, improving future precision.
   Feature / model debugging: XAI reveals when a model relies on spurious or outdated signals (e.g., merchant code that’s no longer risky), enabling feature fixes and retraining.
   Regulatory & audit evidence: explanations provide a documented reason for why actions were taken — important for compliance and SARs.

6. Visualizations & UX that help investigators
   Waterfall / SHAP force plot showing baseline → feature contributions → final score.
   Top-k feature list (feature name, value, contribution magnitude, direction).
   Counterfactual toggles: let analyst change a feature (amount/country) to see predicted impact.
   Timeline view of recent transactions with explanations per txn (helps detect bursts).
   One-line human-readable explanation for face-saving automation (e.g., “High risk due to international high-value payment; recommend 2FA”).
   These elements reduce cognitive load and speed decisions.

7. Monitoring, governance & continued improvement
   Explainability monitoring: track changes in the distribution of top contributors (explanation drift) — big shifts may signal data drift or adversarial behavior.
   Consistency checks: ensure similar transactions receive similar explanations; flag inconsistent cases for review.
   Instrumentation: log explanations along with scores and final analyst labels to create an explainability audit trail for regulators.
   Privacy & security: avoid surfacing sensitive attributes (race, religion) in UI; use proxies carefully and log access controls.

8. Pitfalls & limitations
   Approximation & instability: LIME/SHAP approximate model behavior locally — correlated features can make attributions unstable. Interpret with domain context.
   Over-interpretation risk: explanations don’t prove causality; they show which features influenced the model, not the ground-truth cause.
   Adversarial adaptation: fraudsters may learn which features models use and adapt — monitor for that.
   Performance trade-offs: more interpretable models may sacrifice some accuracy; often a hybrid approach (black-box scoring + XAI + rules) works best.

9. Quick tech stack suggestions
   Libraries: SHAP, LIME, Alibi, Captum (PyTorch), ELI5, interpretML.
   Models: XGBoost / LightGBM (work well with tree-SHAP), neural nets + Captum/IG for embeddings, isolation forest/autoencoders for anomalies.
   Dashboard: simple web UI (Streamlit/Flask + React) showing SHAP waterfall, top features, and counterfactual control.
   Ops: logging (scores + explanations), retraining pipelines, explanation drift alerts.

Proposed Solution (Optional)

1. Goal
   Detect likely fraudulent transactions in near-real-time and present case-level explanations (why the model flagged it) so analysts can triage faster, reduce false positives, and provide audit-ready reasons for actions.

2. High-level architecture
   Data ingestion layer: stream transactions (Kafka / Kinesis) + batch historical data from core banking/transaction DB.
   Feature store: precomputed behavioral/velocity features (Feast or custom Redis/Postgres).
   Scoring service: model (online) that returns score + explanation for each txn.
   Decision engine: rules + thresholds that combine score + explanations → action (auto-clear, soft-block + 2FA, escalate to analyst).
   Analyst UI: shows score, SHAP/LIME waterfall, top contributors, counterfactual slider, transaction history timeline, suggested action.
   Feedback loop: analyst labels feed into retraining pipeline.
   Monitoring & governance: data & model drift, explanation-drift, fairness checks, audit logs for regulators.

3. Data & features (must-haves)
   Transaction-level: amount, currency, merchant_category_code (MCC), merchant_id, merchant_country, timestamp, terminal_type, channel (POS/online), device_fingerprint, IP/geolocation.
   Card/account-level aggregations (velocity/behavioral): txns_last_1h, txns_last_24h, avg_amount_30d, max_amount_30d, days_since_last_txn, new_merchant_ratio, fraction_foreign_txns.
   Customer metadata: account_age_days, KYC_level, prior_chargebacks, risk_score, flagged_countries.
   External signals (optional): device reputation, BIN risk, sanctions list hit, geolocation risk from third-party.
   Label: fraud / not_fraud (from chargeback/investigator outcome).
   Quality checks: null handling, consistent timezone (UTC), dedupe, label timestamp alignment (labeling lag).

4. Model strategy — hybrid (recommended)
   Use a hybrid pipeline combining (A) a high-performance black-box scorer and (B) an interpretable surrogate / local explainers for case-level transparency.

A. Primary scorer (black-box)
Model: XGBoost / LightGBM or neural net for complex patterns. Tree models are practical (fast, good with tabular).
Output: fraud_score ∈ [0,1].

B. Explainability components
Tree-SHAP for local attributions (works efficiently for tree ensembles).
Counterfactual generator (DiCE-style) for actionable “what-if” suggestions (e.g., reduce amount or add 2FA) — limited to feasible feature changes.
Rule-based anchors for fast human-readable reasons (e.g., “High amount + new merchant + foreign country”).

C. Fallback interpretable model (optional)
Train a logistic regression on top-features or a surrogate decision tree to give a quick global explanation or to use where regulatory requirements prefer simple models.

5. Explainability design — what to present to analysts
   For every flagged transaction produce:
   Fraud score (0–100%).
   Top 5 feature contributions (SHAP): feature name, value, contribution magnitude, direction (+/-). Show baseline → contributions → final (waterfall/force plot).
   Human-readable summary sentence, e.g. “Flagged primarily because of a very large foreign transaction (+0.61) and a burst of activity in last hour (+0.08).”
   Counterfactual suggestions: minimal, realistic changes that would flip the decision (e.g., “If amount ≤ ₹35,000 then score → 3%”).
   Transaction timeline: last 10 txns with small explanation per txn to detect bursts or pattern.
   Recommended action: auto-clear / 2FA / escalate / block — based on score + explanation template rules.
   Confidence & provenance: model version, data timestamp, explanation method (SHAP v0.41), feature store snapshot id.
   UX must hide sensitive attributes (race, religion) and show only business-relevant signals.

6. Decisioning / action rules (example)
   If score ≥ 0.9 → auto-block + immediate alert.
   If 0.6 ≤ score < 0.9:
   If top contributors include only one removable factor (e.g., unusually large amount but normal device + merchant) → soft-action (SMS OTP).
   Else escalate to analyst.
   If 0.3 ≤ score < 0.6 → queue for low-priority review (auto-clear if counterfactual shows legitimate cause).
   If score < 0.3 → auto-clear.
   These thresholds must be tuned to business risk appetite and regulatory constraints.

7. Training, validation & metrics
   Train/val/test split: time-based split to avoid leakage (train on older months, test on more recent). Use cross-validation across time windows.
   Primary metrics: Precision @ fixed Recall (or recall at acceptable false positive rate), AUC-ROC, Precision-Recall AUC.
   Operational metrics: false positive rate (FPR), analyst triage time, % cases auto-cleared, time-to-resolution, reduction in manual reviews.
   Explainability metrics:
   Explanation stability: measure SHAP variance for small perturbations.
   Explanation usefulness: % analyst agrees with top contributor (via sampling).
   Counterfactual realism: fraction of counterfactuals that are feasible (business rule).
   Business KPIs: reduction in manual review volume, cost saved, customer friction (blocked accounts), SAR accuracy.

8. Monitoring & model governance
   Data drift detection: monitor feature distributions vs. train baseline (KL divergence).
   Model drift: track score distribution shifts.
   Explanation-drift: track changes in top contributors over time; abrupt shifts trigger investigations.
   Label feedback loop: log analyst outcomes and retrain periodically (or via online learning if safe).
   Audit logs: store score + explanation + model version + action for every decision (for regulators).
   Access control & privacy: role-based access to sensitive explanation fields; PII masking in UI logs.

9. Implementation stack
   Data ingestion: Kafka / AWS Kinesis.
   Feature store: Feast or Redis/Postgres.
   Training infra: Airflow + Spark / Pandas; model: XGBoost or LightGBM (scikit-learn compatible).
   Explainability: SHAP (tree_explainer), DiCE for counterfactuals, LIME if needed for non-tree models.
   Serving: FastAPI / Flask + model server (TorchServe or custom) for low latency.
   UI: React or Streamlit for PoC; integrate SHAP plots (JS or PNG).
   Monitoring: Prometheus + Grafana, and Sentry for errors.
   Storage: ElasticSearch for logs + Kibana for investigation dashboards.
   Audit & governance: append-only audit store (secure S3 / DB) with IAM controls.

Please assign this issue to me.
Parthavi K - GSSOC'25 Contributor