/obydul
Back
security

Fraud Detection System: A Live Risk Engine for Checkout

Digital goods checkout is a fraud magnet. Every rule change needed an engineer and a deploy. Built a rule engine with a live expression builder. Risky orders now get declined, ID-verified with liveness or held automatically.

securityfraudpayments

Selling digital goods means instant delivery. A stolen card becomes product in seconds. The chargeback arrives weeks later. Checkout takes cards, Apple Pay, Google Pay, PayPal and crypto, so the attack surface is wide.

The problem

Fraud rules were hardcoded in the application. Every change needed an engineer and a deploy. Fraud patterns change daily. Code does not.

What I built

A data-driven rule engine. A rule is a set of conditions over live data points that resolves to a risk level. Each level drives an action:

Risk levelAction
CriticalDecline
HighID verification with liveness
MediumSMS verification
LowInstant delivery

Staff write rules in an admin builder with a free-text expression editor, in the style of checkout.com:

:email_disposable: is_true OR (:ip_risk_score: > N AND :customer_status: != trusted)

The expression is parsed into a JSON condition tree and stored. The engine walks the tree against a whitelisted field registry. Stored strings are never executed as code. Saving busts the cache, so a new rule is live in seconds with no deploy.

The signals

  • IP intelligence: VPN, proxy, TOR, hosting, risk score, blacklist hits, geo mismatch against the payment account.
  • Email intelligence: disposable, suspicious, free provider, deliverability.
  • Velocity: orders, cards and emails tied to one device fingerprint or IP within a time window.
  • Account history: age, total spend, chargeback history.
  • Cross-account reuse: the same card, email, or device appearing across accounts.

Two enforcement points

Pre-payment, before the payment order even exists: a critical match blocks checkout with a generic decline, so no signal leaks to the fraudster. Post-payment, on checkout complete: high risk routes to KYC with a liveness selfie and government ID, or into a manual review queue that holds fulfillment until staff clear it.

flowchart LR O[Order] --> E{Rule engine} E -- critical --> D[Decline] E -- high --> K[KYC: liveness + ID] E -- medium --> S[SMS verify] E -- low --> I[Instant delivery] E --> L[(Decision log)]

Decisions that mattered

  • Fail-open. A reputation API timeout or engine error allows the order and logs loudly. Availability beats enforcement at checkout.
  • Deterministic outcomes. Rules run by priority and highest severity wins. A rule can stop evaluation on match.
  • Trusted customers are never auto-blocked. The match is still logged, then waved through.
  • Bounded latency. One cached reputation call per IP and email per window, with a short timeout, so checkout never hangs on a third party.
  • Every decision is logged with the matched rules and data points. Staff see exactly why an order was flagged. The same log becomes chargeback evidence.

Result

Reacting to a new fraud pattern went from a deploy cycle to minutes in the admin panel, by the people watching the fraud. High-risk orders route themselves to ID verification with liveness instead of blanket manual review. Every decision leaves an audit trail.