Fraud Detection Engine

Payment processing requires fraud decisions in milliseconds. Transactions need to be screened for common fraud patterns — card testing, velocity abuse, device fingerprint mismatches, unusual geography — before authorization, without adding perceptible latency to the payment flow.

The challenge was building a system that was both fast enough to operate synchronously in the transaction path and flexible enough for fraud analysts to tune rules without engineering involvement.

Rule Engine — A synchronous rule evaluation chain built in Java. Rules are loaded from MongoDB at startup and cached in-memory with a background refresh every 30 seconds. Each rule is a lightweight evaluator that operates on a normalized transaction context object.

Scoring — Rules emit weighted signals that are aggregated into a composite fraud score. Thresholds for block, review, and pass are configurable per merchant category.

Velocity Checks — Redis is used for sliding-window velocity counters (transactions per card per hour, per IP per day, etc.). Redis EXPIRE handles window cleanup automatically.

Enrichment — Before rule evaluation, transactions are enriched with device fingerprint data, IP geolocation, and BIN lookup. Enrichment calls are parallelized using CompletableFuture to minimize latency.

Feedback Loop — Chargebacks and manual review outcomes are written back to MongoDB. This data feeds periodic rule tuning sessions with fraud analysts.

Synchronous vs async screening — Screening synchronously in the transaction path means a slow fraud check can delay authorization. We set a hard 50ms timeout after which transactions are passed with a review flag. The alternative (async screening with post-authorization blocking) has higher risk of disputed transactions.

Rules vs ML — Pure rule-based systems are interpretable and tunable by analysts; ML models catch patterns rules miss but require more infrastructure and are harder to explain for dispute resolution. We started rule-based and are gradually incorporating ML-derived signals as additional rule inputs.

Fraud patterns shift faster than rule update cycles. Building a fast feedback loop between fraud analysts and the rule engine is as important as the engine itself.

Redis TTL-based velocity counters have an edge case: a window reset at the exact moment of a burst attack. Sliding-window implementations using sorted sets are more accurate but more expensive. For most use cases, the simpler approach is sufficient.