Fraud Detection Model.

Project Overview

Flags suspicious transactions in real time with anomaly detection — where fraud is rare, so the class imbalance and the cost of errors define everything.

Fraud detection — spotting the tiny fraction of transactions that are criminal among the vast majority that are legitimate — is one of the highest-value applications of machine learning, protecting payments, banking and commerce. This project builds a model that flags suspicious transactions in real time. But its defining lesson is not the algorithm; it is that fraud detection is dominated by a single brutal fact — fraud is extremely rare — which reshapes how you build, train and, above all, evaluate the model.

That rarity — a severe class imbalance, often well under 1% of transactions are fraud — breaks the naïve approach. A model that simply predicts "not fraud" for everything achieves >99% accuracy while catching zero fraud, which is why accuracy is a worse-than-useless metric here. The project is really about the techniques that actually work under imbalance: choosing the right metrics (precision, recall, and their trade-off), handling imbalance (resampling, class weighting, anomaly detection that models "normal" and flags deviations), and engineering features that expose fraud patterns.

The value is real-time protection, and the honesty is about the cost of errors, which is asymmetric and business-critical. A false negative (missed fraud) means money lost; a false positive (a legitimate transaction wrongly flagged) means a blocked payment and an angry customer — and there are far more legitimate transactions, so even a low false-positive rate produces a flood of false alarms. So the whole game is tuning the precision/recall trade-off to the business's costs, not chasing accuracy. It is also honest that fraud adapts (an adversarial, drifting target requiring constant retraining), that decisions affecting people need care and often human review, and that labels are noisy. Built with imbalance-aware methods and cost-driven evaluation, it is both a genuinely valuable system and the definitive lesson in machine learning where the classes are rare and the errors are not equal.

What this project does

• Flags suspicious transactions in real time
• Handles severe class imbalance (fraud is rare)
• Uses anomaly detection / imbalance-aware methods
• Evaluates with precision/recall, not accuracy
• Tunes the precision/recall trade-off to error costs
• Engineers features that expose fraud patterns
• Supports human review of flagged cases

Real-World Applications

Deployment contexts where a build of this kind earns its keep.

Features & Capabilities

• Imbalanced-classification / anomaly detection
• Precision/recall (not accuracy) evaluation
• Resampling / class weighting
• Cost-aware threshold tuning
• Real-time scoring
• Retraining for adaptive fraud
• Honest about false-positive floods and adversarial drift

Difficulty, Time & Required Skills

Skills you should have (or will pick up)

• Imbalanced classification and anomaly detection
• Precision/recall and cost-aware evaluation
• Resampling / class weighting
• Threshold tuning to business costs
• Handling adversarial drift and retraining

Bill of Materials

Every part below is commonly available from Indian and international hobby-electronics suppliers. Prices are indicative 2026 retail figures in Indian rupees and will drift — treat them as a budgeting guide, not a quotation.

Estimated total: ₹0, excluding tools, shipping and consumables.

Tools and consumables

• Soldering iron (temperature controlled, 350 °C) with 0.8 mm 60/40 or lead-free solder
• Digital multimeter — continuity, DC volts and current ranges
• Wire strippers, flush cutters and a small set of precision screwdrivers
• Heat-shrink tubing and a heat gun (or a lighter, carefully)
• A laptop with a USB port and the toolchain listed above

Hardware Specifications

This is a pure-software ML system — no electronic hardware to specify. The "platform" is a computer: a CPU handles most models and real-time scoring; a GPU helps for large-scale training.

Memory scales with transaction volume and features; a real deployment adds a low-latency scoring service, a labelled-data pipeline, and a human-review queue. Everything else is the software stack, models and libraries below.

Software Requirements & Development Environment

Reference toolchain: Python 3.11 + ML (imbalanced classification). Anything newer normally works; anything older may lack the board definitions used here.

• Install the Arduino IDE 2.3.x (or PlatformIO if you prefer a real editor and dependency locking).
• Add https://espressif.github.io/arduino-esp32/package_esp32_index.json under File → Preferences → Additional Board Manager URLs, then install esp32 from the Boards Manager.
• Set the correct port under Tools → Port. On Linux add yourself to the dialout group: sudo usermod -aG dialout $USER and log out and back in.
• Open the Serial Monitor at 115200 baud — every sketch here logs its state there.
• Keep File → Preferences → Show verbose output during: compilation switched on while you are debugging build errors.

Required libraries

Block Diagram

The block diagram shows the functional decomposition of the system — what senses, what decides, what acts, and where the data ends up.

Circuit Diagram & Wiring

The "wiring" is the detection data flow — a transaction is scored in real time by an imbalance-aware model; a cost-tuned threshold decides whether to flag it for action or review.

Wire one row at a time and tick it off — most "it does not work" reports trace back to a single swapped pair.

Wiring explanation

• Engineer features that expose fraud patterns (amount, velocity, location, history).
• Score each transaction with an imbalance-aware / anomaly-detection model.
• Apply a threshold tuned to error costs (not accuracy).
• Flag suspicious transactions for action and/or human review.
• Retrain regularly — fraud adapts.

System Architecture

Read the stack from the bottom up: physical hardware, the firmware that drives it, the transport that moves data off the device, and the software a human actually looks at.

Working Principle

Fraud detection looks like a classification problem — label each transaction fraud or not — but it is dominated by one property that changes everything: fraud is extremely rare. In real data, the fraudulent fraction is often well under 1%, sometimes a fraction of that. This severe class imbalance is not a detail to handle at the end; it is the central fact that dictates how you train, what algorithms work, and — most importantly — how you must measure the model. Internalising that is the whole point of the project.

The first casualty of imbalance is the metric everyone reaches for: accuracy is worthless here, actively misleading. A model that predicts "not fraud" for every transaction is >99% accurate and catches zero fraud — a perfect illustration of why accuracy on imbalanced data is meaningless. The right metrics are precision (of the transactions we flagged, how many were truly fraud?) and recall (of all the fraud, how much did we catch?), along with their trade-off (the precision-recall curve). These directly express what the business cares about, and they are the only honest way to judge a rare-event detector.

The techniques that work under imbalance follow from taking it seriously. You can resample (oversample fraud or undersample legitimate transactions to rebalance training), use class weighting (penalise missing the rare class more heavily), or frame it as anomaly detection — model what "normal" transactions look like and flag those that deviate, which is natural when fraud is rare and varied. Alongside, feature engineering exposes fraud signatures: transaction amount and its unusualness for this customer, velocity (many transactions in a short time), location/device anomalies, and deviation from the customer's history. Good features often matter more than the choice of model.

The deepest lesson, and where the honesty lives, is the asymmetric and unequal cost of errors. A false negative — missed fraud — costs money directly. A false positive — a legitimate transaction wrongly declined — costs a blocked payment, a frustrated customer, and support burden. These costs are different, and crucially there are vastly more legitimate transactions than fraud, so even a low false-positive rate produces a large absolute number of false alarms that can swamp a review team and anger real customers. The entire operational challenge is therefore tuning the decision threshold to the business's cost trade-off — how much recall (caught fraud) you buy at the price of how much precision (false alarms) — not maximising some single accuracy number. Three further honest realities complete the picture: fraud is adversarial and drifting (fraudsters actively adapt to evade detection, so the target moves and models must be retrained continually); decisions affect real people (a wrongful decline or accusation has consequences), so serious deployments keep human review in the loop and watch for bias; and labels are noisy (some fraud is never discovered, some flags are wrong). Built with imbalance-aware methods, precision/recall-and-cost-driven evaluation, and a threshold tuned to real error costs, the model delivers genuine value — real-time protection — while teaching the essential discipline of machine learning when the thing you're hunting is rare and the mistakes are not created equal.

The maths behind it

Why accuracy fails

fraud ≈ 0.2% of transactions
"predict not-fraud always" → 99.8% accuracy, 0 fraud caught

→ ACCURACY IS MEANINGLESS on imbalanced data.

The right metrics

precision = TP / (TP + FP)   # of flags, how many are real fraud
recall    = TP / (TP + FN)   # of all fraud, how much we catch

Tune the precision/recall trade-off (PR curve) to the business.

Cost-tuned threshold (the real game)

flag if fraud_score ≥ threshold

false negative (miss)  → money lost
false positive (false alarm) → blocked payment + angry customer
  and legit ≫ fraud → low FP RATE still = MANY false alarms

choose threshold by expected COST, not accuracy.

Program Flowchart

The firmware is a single cooperative loop. Nothing blocks for long, so networking, sensing and the user interface all stay responsive.

Assembly Instructions

Build on a breadboard first and only commit to solder once the whole system has run for an hour without a fault.

1. Engineer features and handle imbalance

   Engineer fraud-relevant features and handle the severe imbalance (resampling, class weighting, or anomaly detection).

2. Score and tune the threshold to cost

   Score transactions and set the decision threshold by the business cost trade-off between missed fraud and false alarms.

3. Review, feed back and retrain

   Route flags to human review where needed, and retrain regularly because fraud adapts.

Step-by-Step Implementation Guide

Work through these in order. Each step ends in something you can observe, so a failure is always localised to the step you just finished.

1. Score and decide with a cost-tuned threshold

   Score each transaction's fraud probability and flag it against a threshold tuned to error costs, routing to review.

   pythonfraud.py Copy Download

   def score(txn, model, features):
       return float(model.predict_proba([features(txn)])[0][1])   # fraud probability
   
   def decide(txn, model, features, threshold):
       # threshold TUNED TO COST (precision/recall), NOT accuracy
       p = score(txn, model, features)
       if p >= threshold:
           return {"action": "flag", "score": round(p, 3), "route": "review"}  # people-affecting
       return {"action": "allow", "score": round(p, 3)}

   return float(model.predict_proba([features(txn)])[0][1]) # fraud probabilityThe model outputs a fraud probability from engineered features — a score, not a hard label, so the threshold can be tuned.

   # threshold TUNED TO COST (precision/recall), NOT accuracyThe decision threshold is set by the business cost trade-off between missed fraud and false alarms — the real operational lever.

   return {"action": "flag", "score": round(p, 3), "route": "review"} # people-affectingFlags route to human review because these decisions affect real people — a wrongful decline has consequences.

2. Manage false-alarm volume and drift

   Tune to keep false-alarm volume manageable for the review team, and retrain regularly as fraud patterns adapt.

Complete Source Code

The listing below is complete and compiles as written — there are no elided sections. Read the annotations under each block before you upload it.

#!/usr/bin/env python3
"""
Fraud Detection Model

Flags rare fraudulent transactions in real time. The defining fact is
IMBALANCE (fraud is very rare), which makes ACCURACY MEANINGLESS. Use
precision/recall, handle imbalance (resample/weight/anomaly detection),
and TUNE THE THRESHOLD TO ERROR COSTS. Fraud adapts -> retrain; decisions
affect people -> human review.
"""
class FraudDetector:
    def __init__(self, model, features, threshold):
        self.model = model; self.features = features
        self.threshold = threshold          # cost-tuned, NOT accuracy-tuned

    def score(self, txn):
        return float(self.model.predict_proba([self.features(txn)])[0][1])

    def decide(self, txn):
        p = self.score(txn)
        if p >= self.threshold:
            return {"action": "flag", "score": round(p, 3), "route": "human_review"}
        return {"action": "allow", "score": round(p, 3)}

    @staticmethod
    def evaluate(y_true, y_prob, threshold):
        pred = [1 if p >= threshold else 0 for p in y_prob]
        tp = sum(t and p for t, p in zip(y_true, pred))
        fp = sum((not t) and p for t, p in zip(y_true, pred))
        fn = sum(t and (not p) for t, p in zip(y_true, pred))
        return {                              # NOT accuracy
            "precision": tp / (tp + fp + 1e-9),   # false-alarm control
            "recall":    tp / (tp + fn + 1e-9),   # fraud caught
            "false_alarms_abs": fp,               # legit >> fraud -> watch this
        }

if __name__ == "__main__":
    det = FraudDetector(trained_model, make_features, threshold=0.7)
    print(FraudDetector.evaluate(Y_TEST, PROBS, threshold=0.7))
    # Tune threshold to cost; retrain as fraud drifts; keep humans in the loop.

Configuration & Calibration

Configuration steps

• Configure fraud-relevant features and imbalance handling.
• Configure the model / anomaly detector.
• Configure the decision threshold to error costs (precision/recall).
• Configure review routing and retraining cadence.

Calibration procedure

An uncalibrated sensor produces confident, precise, wrong numbers. Do this once per physical unit and record the constants.

1. Metrics

   Evaluate with precision/recall and PR curves; never accuracy.

2. Threshold

   Tune to the business cost trade-off and the false-alarm volume review can handle.

3. Drift

   Monitor for adversarial drift; retrain regularly.

Dataset, Model & Training

Dataset

Highly imbalanced labelled transactions (fraud ≪ legitimate). Labels are noisy (undiscovered fraud, wrong flags).

Feature engineering (amount, velocity, history deviation) often matters more than model choice.

Data preprocessing

• Engineer fraud-relevant features (amount, velocity, location/device, history deviation).
• Handle imbalance: resampling, class weighting, or anomaly-detection framing.
• Split time-aware (fraud drifts); avoid leakage.

Hyperparameters

Training process

• Handle imbalance (resample/weight or anomaly detection); engineer strong features.
• Evaluate with precision/recall and PR curves — never accuracy.
• Split time-aware; plan continual retraining as fraud adapts.

Evaluation, Metrics & Deployment

The honest metrics are precision, recall and their trade-off at a cost-tuned threshold — accuracy is meaningless under this imbalance.

Figures from the reference training run described above — reproduce them before trusting your own changes.

Inference example

def score(transaction, model, features):
    x = features(transaction)                # amount/velocity/history deviation
    return float(model.predict_proba([x])[0][1])   # fraud probability

def decide(transaction, model, features, threshold):
    # threshold is TUNED TO COST, not accuracy.
    p = score(transaction, model, features)
    if p >= threshold:
        return {"action": "flag", "fraud_score": round(p, 3),
                "route": "human_review"}     # decisions affect people
    return {"action": "allow", "fraud_score": round(p, 3)}
    # Legit >> fraud: even a low FP RATE = many false alarms. Retrain often.

Testing Procedure & Expected Output

Test from the bottom up. Confirm power, then each sensor in isolation, then the integrated loop — the first failing step tells you exactly where to look.

Bench-test checklist. If a row fails, stop and fix it before moving on.

Expected output

Real-time fraud flags with precision/recall-based evaluation and cost-tuned thresholds, routed to review.

{
  "precision": 0.82,
  "recall": 0.64,
  "false_alarms_abs": 1240,
  "accuracy": "ignored (meaningless here)",
  "threshold": 0.70,
  "note": "tune to cost; legit >> fraud floods false alarms; fraud adapts"
}

An honest evaluation: precision and recall (not accuracy), with the absolute false-alarm count front and centre — because even a good rate produces many false alarms when legitimate transactions vastly outnumber fraud.

Troubleshooting: Common Errors & Fixes

Performance Optimisation

• Never use accuracy — evaluate precision/recall and PR curves.
• Handle imbalance (resample/weight/anomaly detection).
• Tune the threshold to error costs and false-alarm volume.
• Retrain regularly for adversarial drift; engineer strong features.
• Replace every delay() with a millis() comparison — blocking delays are the single most common cause of dropped readings.
• Sample sensors on a fixed cadence and publish on a slower one; you almost never need to transmit at the sampling rate.
• Move networking into its own FreeRTOS task so a slow DNS lookup cannot stall the control loop.
• Use uint8_t / uint16_t where the range allows; on an 8-bit AVR a 32-bit add costs four times as much.
• Profile before optimising — print micros() deltas around each stage and fix the slowest one first.

Safety Precautions

• Decisions affect people — keep human review for flagged cases; a wrongful decline has consequences.
• Watch for and mitigate bias; audit fairness of decisions.
• Transaction data is sensitive/regulated — secure and handle it lawfully.
• Fraud adapts — do not treat a static model as reliable; monitor and retrain.
• Wear eye protection when soldering or cutting, and solder in a ventilated space — rosin flux fumes are a respiratory irritant.
• Power the circuit through a bench supply with a current limit while you are testing. A 300 mA limit turns a wiring mistake into a beep instead of a dead board.
• Disconnect power before changing any wiring. Hot-plugging a sensor onto a live bus is the fastest way to lose a controller.

Maintenance

• Retrain frequently as fraud patterns drift.
• Monitor precision/recall and false-alarm volume in production.
• Refresh features and feedback labels from review outcomes.
• Audit fairness and data handling.
• Re-check every screw terminal and header after the first week — thermal cycling loosens connections that felt tight on day one.
• Recalibrate at the interval given in the calibration section, and keep the constants in a text file next to the firmware — not only in flash.
• Keep a short logbook of firmware versions and what changed. Six months later you will not remember why that constant is 1.083.

Future Improvements & Upgrades

A working v1 is a platform, not a finish line. These are the upgrades that add the most capability for the least rework.

• Add graph/network features (fraud rings).
• Add real-time streaming and adaptive thresholds.
• Add explainability for review and appeals.
• Add active learning from review outcomes.
• Design a proper PCB. Once the breadboard version has run for a month, moving to a two-layer board removes the intermittent-contact failures that dominate prototype faults.
• Add connectivity — an ESP32 and an MQTT publish turn a local gadget into something you can graph, alert on and analyse over months.
• Add persistent local storage (microSD or the on-chip flash) so a network outage does not create a hole in your data.
• Move configuration out of the source: a captive-portal setup page or a JSON config file makes the build reusable without a recompile.
• Add a battery and solar option so the unit survives a power cut and can be sited away from a socket.
• Write a small test harness that feeds synthetic sensor values through the decision logic, so you can validate thresholds without physically triggering the event.

Frequently Asked Questions

References & Learning Resources

These are the primary sources worth reading in full. Manufacturer datasheets always outrank forum posts when the two disagree.

1. Fraud detectionReference
2. Class imbalance problemReference
3. Precision and recallReference
4. Anomaly detectionReference
5. Accuracy paradoxReference