Fraud Detection Pipeline: Mermaid Flowchart

Fraud Detection Pipeline flowchart diagram

About Source

A payment fraud detection pipeline is a real-time decision system that evaluates every incoming transaction against a set of rules and machine learning signals to produce a risk score, then routes the transaction to an appropriate action: approve, challenge, or decline.

The pipeline is triggered synchronously during the payment authorization flow — it must complete in milliseconds to avoid adding perceptible latency to checkout. The first stage is data enrichment: raw transaction attributes (amount, merchant category, card BIN, IP address) are combined with cardholder history from a fast-access data store (typically Redis or a feature store). Computed features might include: average transaction amount in the past 30 days, number of declined transactions in the past hour, whether the billing address matches the card's registered country, and whether the device has been seen before.

Enriched features are passed to a rule engine first. Hard rules — block cards on hotlists, block transactions above a threshold from high-risk merchant categories, block if IP is on a proxy list — are applied before invoking the more expensive ML model. If a rule triggers, the transaction is immediately declined or flagged without further evaluation.

Transactions that pass the rule engine are scored by an ML model (typically gradient-boosted trees or neural net) trained on historical fraud and legitimate transaction data. The model outputs a probability score (0.0 to 1.0). Scores below a lower threshold are auto-approved. Scores above an upper threshold are auto-declined. Scores in the middle range trigger a 3D Secure challenge (see 3D Secure Authentication) or are held for manual review depending on the merchant's risk tolerance.

The decision — along with the score and triggered rules — is logged to the fraud event store for model retraining and auditing. All disputed transactions ultimately generate chargebacks; see Chargeback Handling for how those are resolved.

Frequently asked questions

A fraud detection pipeline is a real-time decision system that evaluates every incoming transaction against rules and machine learning signals to produce a risk score, then routes the transaction to an appropriate action: approve, challenge via 3D Secure, or decline.

The pipeline first enriches raw transaction data with cardholder history from a feature store, then applies hard rules (blocklists, velocity limits). Transactions passing the rules are scored by an ML model. The score is compared against configurable thresholds to determine approve, challenge, or decline routing.

Add ML scoring once rule-only approaches produce too many false positives or miss novel fraud patterns. ML is most valuable with high transaction volumes that generate sufficient labelled training data. Start with rules to establish a baseline, then layer in gradient-boosted or neural-net models.

Common mistakes include running the pipeline asynchronously (outside the auth flow), using stale feature data that misses recent velocity signals, not logging decisions for retraining, and setting a single global threshold instead of per-merchant-category thresholds.

A rules engine applies deterministic, human-defined logic (block if IP is on proxy list) and is fast and explainable but brittle against new fraud patterns. An ML model learns statistical patterns from historical data, catches novel attacks, but requires labelled data, retraining, and more careful threshold calibration.

mermaid

flowchart TD
    A([Incoming transaction]) --> B[Enrich with cardholder history]
    B --> C[Compute behavioral features]
    C --> D{Hard rule match?}
    D -->|Blocked card or IP| E[Auto-decline]
    D -->|High-risk merchant + amount| E
    D -->|No rule triggered| F[Score with ML fraud model]
    F --> G{Risk score}
    G -->|Score < 0.2 low risk| H[Auto-approve transaction]
    G -->|Score 0.2-0.7 medium risk| I{Challenge method}
    I -->|3DS enrolled| J[Trigger 3D Secure challenge]
    I -->|Not enrolled| K[Flag for manual review]
    G -->|Score > 0.7 high risk| E
    J --> L{3DS result}
    L -->|Authenticated| H
    L -->|Failed| E
    H --> M[Log decision and score]
    E --> M
    K --> N{Reviewer decision}
    N -->|Approve| H
    N -->|Decline| E
    M --> O([Forward to card network])